超高速開発ツールはエンジニアの未熟さを覆い隠すためのものではない

以前書いた↓の記事の続きです。たくさんの方に読んでいただいたのですが、続きを書くのにエネルギーが必要で、結構間が空いてしまいました。。。

www.cycle-g.info

無計画に書き始めてしまいましたので、↑の記事もそのうち書き直そうと思います。

超高速開発ツールに関する誤解の一つに、“未熟なエンジニアでも高い生産性でシステムを開発できる”というものがあります。

・・・『あります』などと言い切ってしまいましたが、私の周りではそんな誤解がありました。あなたの周りではどうでしょうか。明確に言葉になっていなくても、ぼんやりと、そんなイメージが持たれていたりしないでしょうか。

内製化を推し進めるためのツールとして超高速開発ツールの採用を検討されるケースもあるかと思います。開発経験の乏しいメンバーや、レガシーな環境での開発しか経験がないメンバーが中心の場合、いきなりJavaやRuby等で業務用のWebアプリケーションを開発するためには、覚えることがあまりにも多岐に渡るためハードルが高すぎます。代わりに超高速開発ツールを採用して、習得すべき要素技術をツールの使い方だけに集約させる という手段もアリかもしれません。

しかし、『新しく覚えることが少ないから、どんなエンジニアでも、簡単に、高速に開発できる』・・・訳もなく、多くの問題も起きます。未熟なエンジニアが扱った場合に何が起きるのか、私の周りで起きたことを一つの事例として紹介したいと思います。

ところで、そのツールがカバーする範囲はどこ?

ツールによって得意とする範囲は異なります。いわゆる詳細設計・プログラミングに相当する部分を自動化するツールだったり、結合テストに相当する部分をカバーしているツール、デプロイまで管理・自動化できるツールなどなど、様々です。

守備範囲の"外"のアウトプットの質は、エンジニア次第。

当然の話ですが、ツールがやってくれない事は、ヒトがやる必要があります。例えば詳細設計~プログラミング・単体テストに相当する部分を自動化・高速化するツールなら、要件定義~基本設計に相当する部分や結合テスト以降の工程は、エンジニアが担当します。

これらの"ツールがやらない領域"は、やはりエンジニア次第でアウトプットが良くもなれば、悪くもなってしまいます。 そして、工程のどこかの質が下がれば、それに応じてシステムの質も悪くなってしまいます。

場合によっては、ツールの守備範囲"内"のアウトプットの質も、エンジニア次第。

ノン・コーディングがウリのツールでも、やはりどうしても短いコードを書かなければならないシーンがあります。どんなに短いコードでも、何かコードを書けばバグが埋め込まれる可能性があります。また、どうしてもコードを書かなければならない場合でも、設計をシンプルに保つための工夫は必要です。

このような場合もやはり、未熟なエンジニアには少し荷が重いタスクになります。

“超高速開発ツールはイレギュラーな要件・機能には向いていないので、イレギュラーでない要件のシステムに適用する”だとか、“コードは一切書かない。書かなければいけないような要件の場合、仕様を変える。仕様を変えられない場合は運用でカバーする。”というような方針・規約を設けることもあるかと思います。ただし、要望がノンコーディングで済むかどうか?要件のすべてが高速開発ツールの標準機能でカバーできるか?という事は、利用部門・企画部門はプロジェクトの初期にはわかりません。システム部門の担当者でさえ判断が困難かと思います。そのため、このような原則をプロジェクト開始時に利用部門と合意するのは、なかなか難しいです。

ツールが持つ制約の中でどう作るか、創意工夫が必要になる場面も。

ツールにはいろいろな制約があります。その制約のおかげで高速で開発したり、バグの混入を防ぐことができると言えるでしょう。例えばマスタメンテナンス画面のような、ド定型的な画面・機能でも十分な場合は良いのですが、すべての画面・すべての機能をド定形な画面・機能にしてしまうと、使い勝手が非常に悪くなってしまいます。より使いやすくするために、ツールの制約の中でどうやって使い勝手を良くするか?どうやって要件を実現させていくか?の工夫が必要なシーンもあります。

マニュアルに書いてあることを基本事項として飲み込んだ上で、自分のプロジェクトではどうするべきか考え、応用していくことも必要です。

中には、少しの工夫で実現可能なのに、早々に『このツールではできない』という判断を下してしまうエンジニアもいるかもしれません。

マニュアルに書いてない → このツールではできない → こんなこともできないツールが悪い

という図式で、担当エンジニアの未熟さが、ツールの未熟さに置き換えられて語られてしまうこともあります。

製品のサポートが不可欠だけど、"聞き方"が効率を左右する。

殆どのプロダクトがオープンソースではなく、利用者も少ないため、Web上の技術情報は非常に少ないです。そのため、製品のサポート体制が非常に重要になります。(超高速開発ツールに限らず、エンタープライズ向けの製品の多くで同じ事が言えるかと思います。)

何か解決できない問題がある場合は、それをサポートに問い合わせることになると思いますが、"聞き方"次第では、なかなか適切な回答が得られずに、多くの時間を浪費してしまいます。

さすがに『何もしてないのにエラーになる』というような聞き方をするエンジニアはいないと思いますが、起きている事象・期待していた動作・直前の変更点や作業などを適切に伝えられるエンジニアは意外と少ないものですし、未熟なエンジニアならなおさらです。

www.nanigoto.net

超高速開発ツールを最大限活用できるエンジニア像

他にもいろいろあると思いますが、思いつくままに、未熟なエンジニアが利用した場合の問題点・懸念点を挙げてみました。未熟なエンジニアが超高速開発ツールを使った場合、なんとか開発できるかもしれないけど、十分に製品の利点を活用できない(できなかった)です。

とはいえ、内製化を進めたい場合に、一定の開発経験があるメンバーが揃うような、恵まれた環境ばかりではないかと思います。じゃあどうすればよいのか?どんなエンジニアがツールを活用できるのか?という問いに対しては、まだ答えを持っていません。これから試行錯誤して、答えを見つけていきたいと思います。