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