SIビジネスのダメだしを読んで －「製造業」の終焉
こんにちは。プリーストです。
SIビジネスは必要不可欠なのに何故ダメ出しされるのか
そうですよね。。SIが終わるのではなく、工程分離、人月モデル、ゼネコン構造というビジネスモデルが終わる。これはそうだと思います。
同僚とも話したのですが、そもそも現在、日本のソフトウェア開発で「製造」とされている工程って本質的には「製造」じゃないんですよね。
粒度は違っても「機能・処理の詳細を設計」をしているんです。プログラムってコンパイラの為の設計書ですから。
本質的な「製造」っていうのはコンパイラがバイナリを作ったり、インタプリタが命令を生成されたりする部分でしかないとどこかで読んだことがあります。
そこだけが設計が決まったものをただ作るだけの「製造」なんです。間違いのないプログラム(設計書)って初めからからはできないから何度もコンパイラに「製造」してもらわないといけないんですけど。
ソフトウェア開発って、要求や要件、ニーズをコンピュータが理解できる粒度まで論理的段階的に詳細化していく作業なので、それを表現する手段がWordだろうとExcelだろうとJavaだろうとRubyだろうと粒度と詳細度が違うだけで同じ目的の為の論理構造なんです。
なのに、ニーズを分析・学習してコンピュータで動作可能な論理構造に変換してマッピングしていくという本質的には一連の作業を分断してしまったらうまくいかないし、「手戻り」とされる事象が発生するのは当たり前。
必要なのは論理構造の詳細化の順番とニーズのマッピングの方法です。もちろん、そもそもの出発点であるニーズを正確に把握したり関係者間で調整したりする事はとても重要ですが、論理構造への詳細化や変換の方法やマッピング手法を知らない人がニーズを適切に調整できるはずはありません。
なので、唯一分離できそうな要件定義であっても、人や組織を分断すると無理や衝突が発生するのは当たり前なんです。
それを無理やり押さえ込もうっていうのが今日の日本流プロマネであり、リスクヘッジとして下請け構造がある訳で本質は無視しているけど一部の人たちの為には最適化された手法ではあるんです。
ただ、本質を無視している限り継続可能ではないですけど。
本当に考えなければならないのは、ソフトウェア開発のようにプロジェクト型で必要な人員のスキルやボリュームが大きく変動するという制約と本質的にプロセスを分断できないというソフトウェア開発上の制約を同時に満たす構造・仕組みであり、どうすれば効率よく有利に他に投げられるか、どうすれば自分たちに有利なニーズに押さえ込めるかではありません。
それぞれが目の前の利益を優先して行動すると、結果的に全体の利益にならず全員が損をするというよくあるパターンです。
SIのビジネスモデルのように、その構造が本質からずれている状況に浸かっていると、課題や問題の設定を間違えることが多くて問題がある「人」や「組織」に矛先が向かいがちです。
これから更に過熱するであろう格差間闘争や世代間闘争、国際経済闘争における叩き合いにも同じ匂いがあって、問題の設定を誤って奪い合いながら全体として縮小して沈没していくというのが素直に想像できるストーリーです。
本当はどの人でもないどの組織でもない「構造」とその「構造を変える仕組み・制度」に問題や課題があるのに。
「構造」以外のことについては、自分がどの立ち位置になるかなんて運がほとんどだし立ち位置が変わればきっとまた違う問題を設定してしまうのが人間というものなのに。
ソフトウェアでも何でも「アーキテクチャ」は人の行動にとても影響を与えるということでしょうね。自分が関与できるアーキテクチャはなるべく良い行動を引き出すものにしたいです。
それではまた♪
最近のコメント