超高速開発ツールに関する誤解の１つに「未熟なエンジニアでも高い生産性でシステムを開発できる」というものがあります。
・・・「あります」などと言い切ってしまったが、少なくとも私の周りには、そんな誤解がありました。あなたには周りではどうでしょうか。明確に言語化されていなくても、ぼんやりと、そんなイメージが持たれてはいないでしょうか。
内製化を推し進めるためのツールとして、超高速開発ツールの採用を検討するケースもあるでしょう。しかし、開発経験の乏しいメンバーや、レガシーな環境での開発しか経験がないメンバーが中心の場合、JavaやRuby等での業務用アプリケーション開発は、相当にハードルが高いです。
Web開発の技術を習得する代わりに超高速開発ツールを採用することで、習得すべき要素技術をツールの使い方だけに集約させるという発想もあるかもしれません。
しかし、『新しく覚えることが少ないから、どんなエンジニアでも、簡単に、高速に開発できる』 ・・・そんな訳はなく、多くの問題が起きます。未熟なエンジニアが扱った場合に何が起きるのか、私の周りで起きたことを１つの事例として紹介したいと思います。
Contents
ところで、そのツールがカバーする範囲はどこですか？
ツールによって得意とする範囲は違っています。いわゆる詳細設計・プログラミングに相当する部分を自動化するツール・結合テストに相当する部分をカバーしているツール・デプロイで管理・自動化できるツールなど、様々です。
当然、ツールが守備範囲としない領域は、自動化されません。エンジニアが、いままで通り（あるいは、いまやっていないなら、自力で）手動で実施する必要があります。
守備範囲の「外」のアウトプットの質は、エンジニア次第。
当然の話ですが、ツールがやっていない事が、人間が実施する必要があります。
たとえば設計〜プログラミング・単体テストに相当する部分を自動化・高速化するツールなら、条件定義〜基本設計に相当する部分や結合テスト以降の工程は、エンジニアが担当します。
これらの”ツールが守備範囲としていない領域”は、エンジニアの経験・力量次第でアウトプットが良くもなれば、悪くもなってしまいます。
そして、工程のどこかの質が下がれば、それに応じてシステムの質も悪くなってしまいます。
場合によっては、ツールの守備範囲”内”のアウトプットの質も、エンジニア次第。
ノン・コーディングがウリのツールでも、やはりどうしても短いコードを書かなければならないシーンがあります。どんなに短いコードでも、何かコードを書けばバグが埋め込まれる可能性があります。また、どうしてもコードを書かなければならない場合でも、設計をシンプルに保つための工夫は必要です。
このような場合もやはり、未熟なエンジニアには少し荷が重いタスクになります。
“超高速開発ツールはイレギュラーな要件・機能には向いていないので、イレギュラーでない要件のシステムに適用する”だとか、“コードは一切書かない。書かなければいけないような要件の場合、仕様を変える。仕様を変えられない場合は運用でカバーする。”というような方針・規約を設けることもあるかと思います。
ただし、要望がノンコーディングで済むかどうか、要件のすべてが高速開発ツールの標準機能でカバーできるか という事柄は、プロジェクトの初期に確定できることは極めて稀です。
そのため、このような原則をプロジェクト開始時に利用部門と合意するのは、なかなか難しいです。
ツールが持つ制約の中でどう作るか、創意工夫が必要になる場面も。
ツールにはいろいろな制約があります。その制約のおかげで高速で開発したり、バグの混入を防ぐことができると言えるでしょう。
例えばマスタメンテナンス画面のような、ド定型的な画面・機能でも十分な場合は良いのですが、すべての画面・すべての機能をド定形な画面・機能にしてしまうと、使い勝手が非常に悪くなってしまいます。
より使いやすくするために、ツールの制約の中でどうやって使い勝手を良くするか？どうやって要件を実現させていくか？の工夫が必要なシーンもあります。
マニュアルに書いてあることを基本事項として飲み込んだ上で、自分のプロジェクトではどうするべきか考え、応用していくことも必要です。
中には、少しの工夫で実現可能なのに、早々に『このツールではできない』という判断を下してしまうエンジニアもいるかもしれません。
「マニュアルに書いてないから、このツールでは対応できない。こんなこともできないツールは使い物にならない。」
自分の能力不足を棚に上げて、こんな結論に至ってしまうこともありえます。
担当エンジニアの未熟さが、ツールの未熟さに置き換えられて語られてしまうこともあるので、注意が必要です。
製品のサポートが不可欠だけど、”聞き方”が効率を左右する。
殆どのプロダクトはオープンソースではなく、利用者も少ないため、Web上の技術情報は非常に少ないです。そのため、製品のサポート体制が非常に重要になります。（超高速開発ツールに限らず、エンタープライズ向けの製品の多くで同じ事が言えるかと思います。）
何か解決できない問題がある場合は、それをサポートに問い合わせることになると思いますが、”聞き方”次第では、なかなか適切な回答が得られずに、多くの時間を浪費してしまいます。
さすがに『何もしてないのにエラーになる』というような尋ね方をするエンジニアは少ないと思いますが、起きている事象・期待していた動作・直前の変更点や作業などを適切に伝えられるエンジニアは意外と少ないものですし、未熟なエンジニアならなおさらです。
超高速開発ツールを最大限活用できるエンジニア像
他にもいろいろあると思いますが、思いつくまま、未熟なエンジニアが利用した場合の問題点・懸念点を挙動してみました。このように、未熟なエンジニアが超高速開発ツールを使った場合、なんとか簡単な開発をやりきることができるかもしれませんが、十分に製品の利点を活用できません。
とはいえ、内製化を進める場合には、一定の開発経験があるメンバーが揃うように、恵まれた環境ばかりではないかと思います。じゃあどのようにばよいのか？どんなエンジニアがツールを活用できるのか？というよう質問に対しては、僕自身もまだ答えを持っていません。これから試行錯誤して、答えを見つけていきたいと思います。