読者です 読者をやめる 読者になる 読者になる

エンタープライズ系開発でコンストラクション・マネジメントは成立するか

さった11月18日のシステムイニシアティブ協会の例会で、明豊ファシリティワークス株式会社の坂田社長による講演を拝聴しました。
http://system-initiative.com/HTML/workshop.43.html

同社の「コンストラクション・マネジメント」ビジネスとは、顧客企業と契約し、顧客企業の代役として、建設会社と主に予算削減についての折衝を行います。プロ同士の議論で削減可能なポイントを見つけ出し、実際に削減できたという成果に対して料金がいただけるというものです。

具体的な事例は公開不可ということでここでは書けませんが、聴講していて驚きました。建設分野は積算根拠がしっかりしており、かつ法令遵守義務もあるので、大きな削減にはつながらないのではないかと思っていたのですが... 改善しようという熱意があれば、成熟分野であっても、まだまだアイデアは尽きないということでしょう。

誤解のないように補足しますと、同社自身が高度な技術的視点で、建設会社と改善ポイントを探すということで、決してコストを盾にして建設会社に無理をさせることではない、ということです。もちろん違法建築によるコストダウンは論外です。

なぜ建設分野のノウハウ事例をシステムイニシアティブ協会で取り上げたかという狙いも明白で、このコンストラクション・マネジメント(以下、CMと呼びます)がエンタープライズ開発でも適用できないだろうかということを会場で議論するためです。

面白い視点ですが、私自身はそのままでは難しいという印象を持ちました。理由は次のとおりです。

従来の「統合型システムの一括発注」方式に、CMはそぐわないのではないか

ここではフルスクラッチのエンタープライズ開発を想定しています。往々にして、設計が進むにつれ、要件が膨らみます。当初は要求以前のふわふわしたレベルの話であったものが、関係者ヒアリングの積み重ねで各所より「あれも必須、これも必要」という声があがり、いつのまにか想定見積を超える規模の要件になります。

この段階でも、まだ仕様は固まっていません。全従業員の話を聞いているわけでもないので、一部で合意した内容をもとに開発を進めますが、その成果が現場にお披露目されてはじめて、「これでは使えない」という意見が上がってきます。さもありなんと予想して、なんとか予備費を確保していたかも知れませんが、後工程での変更インパクトは想像を超える変更費の見積となり、発注側も驚きます。コストを下げるためには機能を削減するしかないのですが、どれも必要、と現場が要求する以上、削減できるものなど見つかりません。受注者が涙して赤字プロジェクトとするか、法廷闘争に持ち込むかという難しいケースになります。

このストーリーのどこに、CM が機能するのか、ということです。

坂田社長の説明でも、建設においても発注側の要求が膨れることは当然、あるということでした。CM の仕事としては、その要求についてはこれだけコスト高になるということを真摯に説明し、予算追加するか、諦めるかを諭すそうです。そのような形であれば、CM 制度の導入は SIer にとってむしろありがたいのですが、お客様の方にメリットがないと感じられてしまうことでしょう。(お客様視点では、最初から受注者にデスマーチを求めているわけではありません。要求が膨らんでも追加コストは出せない、しかし機能削減もできないというジレンマを解消できないのです。よくわかりますが、どこかに歪みが生じるのも明白です。)

もう一つ、坂田社長のお話では、同じテーマの建物に関するノウハウをつけることで、積算の標準化を徹底したということがありました。私たちの業界でいえば、ある分野についての開発に特化するということでしょう。しかし私の経験では、例えば法律で決まっているように見える自治体業務であっても実際にはばらばらで、共通で使えるコードは多くありませんでした。さらにこの業界は定期的にインフラが代わり、プログラミング言語が代わり、作り方のポイントやアーキテクチャも変わります。これほど変化の激しい業界でなお蓄積・流用できるノウハウは何かを突き詰める必要があります。

モデリング分野では、うまくいくのではないか

それでも私が可能性を見出している点があります。エンタープライズ系開発の本質はインフラやプログラムコードではなく、データモデルであるという視点から、モデリングに対するコンサルテーション業務こそが、CM の役割を果たすのではないかというアイデアです。

建設会社に相当するSIerは、業務のテンプレートモデルを提供します。いわゆるERPですが、ソースコードは除きます。(よって、この段階では動作しません。それが今の ERP との大きな違いです。)このテンプレートモデルと、発注側の要望をヒアリングして、巨大なテンプレートモデルから必要な最小限のモデルを抽出するのが、CM です。

もちろん、選び抜かれたモデルから、アプリケーションを自動生成します。私は超高速開発ツール推進派なので、ここでコーディングは考えません。画面も含め、おおむね動作するアプリケーションは即座に手に入ります。それをもとに現場でレビューし、モデルにフィードバックします。フィードバックの回数は、予算内で終えるよう、CMが調整します。

現場レビューが収束するタイミングで、コーディングを行います。主に業務ロジックで、バッチ処理やレポートを含みます。モデルが固まっているので、追加コードの開発はスムーズです。さらに、自動生成されたコードを流用する形で業務ロジックを作成することで、この部分の開発も削減効果を期待できます。そのアドバイスもまた、CMの役割です。

このような CM 的ポジションこそが、超高速開発ツールを使う SIer の立ち位置になるのではないか、というのが私の考えです。

サービス開発分野でも適用できる

現代の SI は、いわゆる事務処理の効率化を目的とした従来のエンタープライズ開発とは異なり、直接、利益を有むサービスの開発が盛り上がっています。この分野でも CM 的な役割は期待できそうです。

発注者自身が仕様を決められないというのがサービス開発の特徴です。ここでの CM とは、はやく、小さくサービスを提供して、市場と対話しながら次の展開を考えるというアジャイル的アプローチを提案できることが求められます。エンタープライズ系とは異なる立ち位置です。さらに CM には、「より儲かるためのアドバイス」が求められます。よりよくつくる、とは異なるニーズであることを理解しないとよい成果が出せません。また CM の報酬規定も難しいと思います。試行錯誤しながら業界内で決まっていくのでしょう。案外、人月が向いているかも知れません。

余談ですが米国の建設分野では高スキルの技術者は時給制になっているという話もありました。置き換えて考えると、儲かるためのアドバイスは1時間で終わるかも知れないので、そうすると時給数万円という報酬も成立しそうです。

まとめ:コンストラクション・マネジメントは形を変えた SI の姿

以上から、建設分野の CM はそのままではなく、この業界に合う形で取り込まれる(ビジネスモデルとして成立する)可能性はある、と考えています。超高速開発ツールの普及が進むと労働集約型の産業構造が変わるといわれていますが、その先の姿をかいま見たようで、興味深いです。

Wagby開発スタッフ募集中です!