総務省「Liveモデリングイベント」の報告

さった10月27日、総務省「Liveモデリング」イベントが無事に終了しました。

yoshinorinie.hatenablog.com


総務省の企画ではありますが、当日は各省庁から20名以上が参加され(部屋に入りきれずに廊下から覗いただけの人もいたとのことで)大いに興味をもっていただけたようです。15時からの開始で、その場で開発テーマが公開されましたが、私が予想していた以上に本格的な業務で、これを1時間で実装する…だと…?と、焦ったことを告白します。担当者曰く「今、実際に困っていること」ということで、単なるデータ入力的な台帳管理業務ではなく、複数部署との連携を含む「システム」がテーマでした。

それでも自ら手をあげた6チームだけあって、きっかり1時間で、UIとデータベース管理を備えたアプリケーションをそれぞれ構築できていたのはさすが、と感心しました。平均すると5テーブルほどの規模ですが、UIならびに業務機能込みです。ただし1時間以内という制約のため、もちろん要求にある全機能はカバーできません。そこで各チームとも「自分たちのツールで特に、得意な機能」を重点的に開発し、アピールしていました。ちなみに Wagby は「メール受信」機能を使って、業務のトリガーとなる他部署からの連絡を自動でDB化する、ということをデモしました。これは他ツールにはなかった機能だったため、好評でした。

イベント終了後に、意見交換の場がありました。別の省庁の方から「自分たちも企画したい」というコメントもいただくことができたので、成果は上々といってよいでしょう。参加された官僚の皆様に「この手のツールは実用段階に入った」と評価いただくことを願っています。もちろん、すぐに大規模システムへの適用は、ないでしょう。まずは中小規模の入札で、超高速開発ツールの利用を促進していただければ、何かが変わるはずです。地道ですが、大切な一歩を踏み出せたイベントだったと思います。

超高速ならではの懸念と、その対応

意見交換の場で、指摘されたことがありました。

超高速に成果物ができると、利用者(エンドユーザ)があれこれと要望を出してしまい、かえって収拾がつかなくなるのではないか?

この質問は私にとって初出ではありません。これまでも営業活動をとおして何度も問われてきたことでした。

もちろん質問された方は、だからといって現状の方法(仕様提示から、開発完了まで相応の期間を要し、蓋をあけてみたら予想していたものとは違ったものになっていた)を肯定しているわけではない、ということも承知しています。ただこれを「贅沢な悩みです。」と、はねつけることもできません。この問いの根本には、外部の開発業者と、内部の利用者の橋果たし役となっている IT 担当者の立ち位置が難しいという問題があります。どちらかの味方をしても反目されてしまうため、お互いの主張を聞きつつも足して二で割るような調整役ならではの視点でしょう。

私自身は、この構図に囚われている以上、納得できる解決は難しいと考えています。運用の工夫として、例えば手戻りは3回まで、というルールをつくることは可能でしょうが、声の大きいエンドユーザには効果はありません。

実は失敗するプロジェクトには共通の要素がある、というのが私の仮説です。(1) エンドユーザに開発費、というコスト意識がない。(2) 大手SIerを窓口に契約することで、無理をいいやすい。この2つですが、(1) が土台にあって、そのために (2) が生じます。要望を聞き入れてもらって自分の財布が痛まなければ、それは言いたい放題となるに決まっています。もちろん開発費には上限があるのですが、窓口(受注企業)が中小企業の場合、無理をいうと会社の体力的に持たない可能性があることを懸念するから大手SIerに頼む...という思考は別の歪みを生じさせます。大手SIerも赤字を受け入れるわけはなく、下請け、孫請けに無理が伝搬します。利用者の要望を原則、受け入れるという体制維持のためにできあがったのが多重下請け構造というわけです。

だからといって今度は利用者に「要望は受け付けません」といっても解決しません。使えないシステムを押し付けられたと怨嗟の声があがることでしょう。

ではどこに解決の糸口があるのか。そこで開発費 = コスト、の精査となります。システム開発はほぼ人件費ですが、似たような機能を毎回、手作りしていることが問題ではないのか、というのか(私を含めた)超高速開発を推進するエンジニアの共通理解です。パッケージソフトほど融通が効かないわけでもなく、さりとてスクラッチ開発ほどコストがかからない、双方の良いとこどりを行う解決策を提示するのはエンジニアの出番です。これは利用者の要望を完全に満たすことを保証するものではありませんが、例えば8割を満たすことができ、コストも抑えられるという解決策を提示することは意味がある、と考えています。ツールベンダーがさらに努力して8割を9割に、そしてさらにその上を目指すことは可能です。そのためには関係者(発注者も利用者も開発者も含めた全員)が、ツールの能力向上を支援する体制を支えるという理解のもと、最善を目指すことが求められます。

それはツールベンダーにとって都合が良すぎる話と思われるかも知れません。しかしさまざまな可能性を検討した結果、業務アプリケーション開発工程の自動化を行わない限り、この問題を根本的に解決することは難しい、というのが現時点の見解です。それを後押しするかのように、ツールを提供できるというベンダーはますます増えており、ユーザー企業自らがこのようなツールを自作しているという例もあります。超高速開発とはこのように、開発工程の限定的影響にとどまらず、開発体制を大きく変えるものであり、いやむしろ、開発体制を変えなければ効果がないのだ、ということがより正しい説明なのではないかと考えています。