超高速開発コミュニティの幹事として活動していますが、今年に入って、いろいろな団体でお話できる機会が増えました。昨日も、14社20名の方々（すべてSIer）に超高速開発コミュニティの説明を行いました。懇親会の場でいただいた代表的な6つの質問について、このタイミングで整理してみました。（以下は私見であり、コミュニティの公式見解ではありません。）
内容はエンタープライズアプリケーションに関するものです。それ以外の分野には適合しませんので、こちらもご了承下さい。
ユーザー要件を完全に満たすことができない限り、ツールを採用するのにはリスクがある
その要望を満たそうとがんばったのが1990年代のCASEツールベンダーで、完璧を求めようとして複雑化し、結果的に使うのが難しいというジレンマに陥ったと理解しています。そして現在、コミュニティで活動しているツールベンダーは (1) 要件を完全に満たすよう、さらなる努力を続けている。(2) 適用範囲を決め、その範囲内で超高速開発を実現する。など、さまざまなアプローチをとっています。私自身の立場は、自動化できるところは自動化を押し進め、不向きなところは人間が対応するというハイブリッド方式を検討するのが現実解というものです。
仮にツールを使う案件があったとして、一回目は不慣れなこともあってうまくいかないのではないか
何事にも最初というのはあるので、すべて成功すると安易には言えません。ただ私の経験から、そのツールに携わるキーマンとなる技術者を決めてもらえれば、確実にノウハウが蓄積され、利益率の改善に貢献するということです。より踏み込んでいえば、多くのSIerではそれが難しいです。空いた人を空いたプロジェクトに投入したり、火消しに投入することがあり、一つの技術の核となる人を育てることが困難な事情もわかります。ただノウハウの蓄積が加速すると、得られる果実は着実に大きくなります。ツールを採用すれば誰でも成功ではないからこそ、そこに至るまでどれだけ投資するか、も問われていると受けとっていただければと思います。
自社の開発要員は、自動化ツールに激しい抵抗を示すので、説得ができない
人によって採用判断の基準は異なるため、無理強いはしない方がよいです。ただ国内で入手可能は自動化ツールは増え続けており（コミュニティに参加していないツールも数多く存在します）それらが「できること」も日々、広がっています。そこに市場があると考えて参入している人が増えているということです。いずれかのタイミングで、これらのツールの採用を検討しよう、というターニングポイントがやってくるかも知れないという意識で、アンテナだけは張っておくことをお薦めします。
「リポジトリ（設計情報）が資産」という世界は、開発者にとって面白みに欠けるのではないか
案外、そうでもない、というのが実感です。設計情報のキモはモデリングです。実世界のモデル化は、設計者の視点で情報を取捨選択し、分解し、再統合するという高い創造性を要求される分野であり、プログラミングに勝るとも劣らない面白さがあります。モデリングには業務知識とコンピュータの仕組みの双方を知っている人が、理想と現実（ソフトやハードの制約条件）の中で、落としどころを探ることが求められており、さらに業務の変化によってモデルの形も変えていくことになります。決して素人がパラメータをちょっと設定するとアプリケーションができる、というものではありません。いわゆるシステムエンジニアという職種の醍醐味です。
設計も開発能力も著しく低下してしまったユーザーに、いまさらツールで内製というのは無理ではないのか
日本のSIerがあまりにも優秀で、丸投げの方がユーザーにとって楽であったため、ユーザー側の設計・開発能力が低下したという見方はあるでしょう。しかしこのときの前提条件は、少なくともユーザーは要求は明示し、SIerは「その要求をどう実現するか」という役回りだったと理解しています。そこで求められていたシステムは、定型化された業務（つまり、その企業が儲かる仕組み）が存在し、それをソフトウェアによって省力化することでした。今、多くのユーザーが直面しているのは、儲かる仕組みそのものの再構築です。それは「そもそも何をつくったらいいか」というところから試行錯誤することになり、要件が固まることはありません。そのような状況下では内製に回帰するほかなく、ユーザーが再びシステムの主導権（イニシアチブ）を持つという方針を掲げる方が妥当です。ただしユーザー自身がいわゆるフルスタックエンジニア - OSからDB、ミドルウェア、Webまですべてを理解する - を抱えるのは難しいでしょう。理由は、そのような高度なスキルを持つエンジニアの絶対数が不足しているという認識をもっているためです。そのようなエンジニアを育成し、高い給与で採用するという案もあります。一方で、その部分をツールが担うという案もあります。いずれにせよ、ユーザーには「ネット時代に儲かる仕組みの設計」に注力できるようにすることが必要です。その動きを支援するSIというビジネスがあってもいいと考えています。
ユーザーにとって、工数が削減される手法と認識されるのがSIerにとって不都合という点についてはどう考えるのか
最も難しいテーマです。コミュニティとして「こうすればいい」という回答はなく、むしろ各社にとっての大きな差別化要因になるため、コミュニティ内の企業同士で連携し、また切磋琢磨してほしいというのが優等生的な回答です。
ただ、工数が削減されるから開発費も安くなるだろう、と指摘されるというのは、人月という指標以外の見積方式を持てなかったSI業界にも問題があると考えています。むしろ工数削減をチャンスと捉え、新しい価値を提案する価格体系を各社で模索するよいタイミングです。
個人的には、プログラム（あるいは動作するモジュール）を納品するのではなく、ユーザと一緒になってリポジトリを継続的に保守するという形で関わっていくことになるのではないかと思います。ユーザからみたSIerの不満の一つに「納品後の変更依頼で、想定以上の見積がでてきて納得できない。」というものがあります。SIerにとってみればプログラムの修正箇所が多ければ作業工数が増えるため妥当な金額となるのでしょうが、ユーザはその説明を（理解はしても）納得していない、ということは自覚していることでしょう。リポジトリの変更によりコードが再生成されるメリットはここにあります。保守ではなく、常に継続開発という説明が可能です。もちろん、それによってプログラマの実稼働は削減されますが、確実にユーザからの満足度、信頼度は高まります。これをどう捉え、売上に結びつけるのかという視点でSIerのビジネスモデルを考えることが求められています。繰り返しになりますが、明確な回答がない分、独自のモデルを打ち出せるチャンスです。
まとめ：コミュニティでの議論を歓迎しています
ということで私の主張は、「いずれ変わるということが予見されるなら、先に変わって主導権をとった方がいい。」です。是非ともコミュニティに入って、さまざまな議論に加わってくださいとお願いしました。これらは機微なテーマが多いので、ネット上での議論は行っていません。そのため東京での会合が中心になってしまっているのが難点ですが... 呼んでいただければコミュニティとして地方行脚を企画できるので、是非ともご連絡ください。コミュニティの幹事会に諮ります。
最後になりますが、本日、「超高速開発が企業システムに革命をおこす」が書店に並びます。超高速開発とは単に開発工程の一部自動化という話ではなく、より大きな可能性があるという視点を拡げるきっかけになります。是非、手にとってお読みいただければと思います。
