人類がプログラミングをやめるまで、フルスクラッチの仕事は残る：SEの未来を開く、フルスクラッチ開発術（2）（1/2 ページ）

プログラムレス開発が全盛の中、フルスクラッチ開発こそ、顧客のためになり、SEにとっても強みとなると主張する企業がある。彼らはなぜあえて今、このような主張をするのだろうか？

[森川滋之，ITブレークスルー]

前編まとめ

• 前編：システムを持たぬ時代に、あえてフルスクラッチに特化する

　プログラムレス開発が主流の今、プラムザはあえて「フルスクラッチ専門で開発する」と宣言する。同社の代表取締役 島田徹氏と取締役 内藤洋史氏はそれぞれ、フルスクラッチ開発のメリットを語る。その内容は、以下のようなものだった。

• フルスクラッチには確実な市場がある
• パッケージのカスタマイズの方がリスキー
• フルスクラッチに必要な技術はシンプルでつぶしがきく

システムを持たぬ時代に、あえてフルスクラッチに特化する：前編

　後編では、引き続き「なぜ今、あえてフルスクラッチ開発なのか」を掘り下げていく。

要件定義は方法そのものではなく、コミュニケーション技術で決まる

――フルスクラッチ開発では、要件定義が大変なんじゃないでしょうか？

島田氏　必ずしもそうとはいい切れません。そもそも、要件定義の時点では、お客さんの要望そのものが固まっていないことが多いです。なので、まずは直感的に分かりやすい「画面」を使って話をするのが、要件定義の常とう手段です。OSツールを使えば、その場で画面が作れるので、確かに画面の要件を決めるのは楽だと思います。

　しかし、OSツールだと、まずは「できる・できない」という判断をしなくてはなりません。

――ツールの仕様が、要件に対する制約条件になるということですね。

島田氏　そうです。私たちはそのような要件定義の進め方はしません。まず要望をヒアリングして、「できる・できない」の判断を最初はしないんです。議事録を書いて、それを基に要件定義書をおこすことさえしません。せいぜい、要望リスト（図1）をベースに機能一覧を作り、それに工数見積もりをつける程度です。お客さんはそれを見て「いる・いらない」の判断をして、場合によってはうちのSEと一緒に、実現機能の調整をする感じです。

図1　要望リスト

――納得ですが、それでも画面で話をした方が早いのでは？

島田氏　はい、なので 重要な画面については早い段階で目に見えるようにします。実際の画面を作って確認をしてもらうこともあれば、ワープロで作成して紙で見せる場合もあります。重要でないものについては、α版と呼ぶリリースの段階で見ていただいて、レビューをしてもらうようにしています。

――プロトタイピングやアジャイルというよりは、スパイラル的な開発と言えばいいのでしょうか。

島田氏　そうですね。

――重要度は、どうやって判断するのでしょう。

島田氏　「これが定義だ！」といったものがあるわけではありません。お客さんのこだわりといいますか。重要な部分については、お客さんは早い段階から何度もその話をします。打ち合わせの中のお客さんの反応を見て、つまりコミュニケーションを通して、重要度や優先度を探っていきます。

――SEの仕事はコミュニケーションありき、ということですね。

“仕様変更”とは言わない

――要件定義としては機能一覧を作る程度ですが、重要な画面についてはプロトタイプかラフスケッチで確認するということですね。そうなると、これはかなりゆるい要件定義だと思います。ということはつまり、仕様変更による手戻りが発生しやすいのではないでしょうか。

内藤氏　私たちは、仕様変更という言い方はしません。お客様からの要望変更に対しては、柔軟に対応します。

――それでは赤字になりやすいのでは？ 「SEやプロジェクトマネージャの仕事は、いかにお客さんからの仕様変更を断るかだ」と私たちは習いました。

島田氏　要望の変更は必ずありますよね？ それをいちいち断るのは、逆に工数がかかるんですよ。非の打ち所のない要件定義書と、詳細な議事録がまず必要となる。それを作る工数が、まず大変です。それらを基に、交渉用の資料を作成する。この工数もバカにならない。そして、交渉のためのミーティングをする。関係者の中で重要な人が集まっても、延々と水掛け論を繰り返す。これぐらい無駄な工数はない。

――それは実感として、よく分かります。

島田氏　その上、お客さんにはキラーフレーズがあります。「それだと業務に使えない」。実際にそうかは別として、開発側はこれに対抗できる言葉を持っていません。結局やることになる確率が高いのなら、やってしまう方が得だと思いませんか？

――それも分かるんです。とはいえ、仕様変更への対応も、工数がかかるはずです。これがバカにならないから、多くの会社は仕様変更を断ろうと努力するわけですよ。

内藤氏　そこは技術面で工夫できます。エンジニアはあらかじめお客さんの要望がブレそうな部分については、先回りしてコードの修正がなく変更できるようにしておきます。

――確かにその工夫はできますね。設定ファイルを使うとか、データベースにあらかめフラグ的な項目を用意しておくとか。私も現役時代、よくやりました。ただ、先行して作成したドキュメントの修正はどうなるのでしょう。この工数はバカにならないと思いますが。

内藤氏　はい、なので私たちは、最小限のドキュメントしか作成しません。データベース設計書（図2）とアルゴリズム仕様書（図3）、インターフェイス仕様書（図4）を提出するだけです。

図2　データベース設計書

図3　アルゴリズム仕様書

図4　インターフェイス仕様書

島田氏　徹底した合理化を考えると、これが正解だと思うんです。お客さんの予算は減り続け、納期は短くなり続ける一方です。内藤が言う3つのドキュメントはメンテナンスに不可欠なもので、お客さんに引き継ぐ場合、彼らが絶対に必要とするものです。後は事前にどんな完ぺきなドキュメントを作ったとしても、お客さんは目を通す暇さえありません。それで意思決定はできませんし、仕様変更があるたびにメンテナンスしたとしてもお客さんはチェックさえできないでしょう。

――ユーザー企業側のITコンサルタントもやっていたので、よく分かります。かなり大規模なシステムに関わっていましたが、だからこそ、設計書なんかより動くものを見せてほしいと、お客さんはいつもぼやいていました。設計書でのチェックは無理なんですよね。

島田氏　私たちがいわゆる“仕様変更”に柔軟に対応できる理由は、「不要なものは作らない」ポリシーを徹底しているからなのです。

――なるほど。過去の私は、徹底した合理化をする勇気が足りなかったような気がします。現場での充実した教育を受けられたことには今でも感謝していますが、いわゆる“常識”に縛られてもいたんでしょうね。