「システム」を知るのは難しい

とかくシステムというと、多くの人がそれぞれ異なった考え方をもってイメージします。なかでもＩＴエンジニアやＩＴ投資をするお客様はその乖離が顕著なことで有名です。

システム開発系の中ではよく言及されていますが、

　「自分が欲しいと思うものが、本当に必要だったものとは限らない」

と言う話です。もうちょっと強く言うと、コンピューターによって構築されるシステムは「作ってみて」「監視・測定して」「改良して」みないと、本当に必要なものを知ることができないからです。

実のところ、開発側から見てどんなに「検収できた」「クレームは無かった」「リピートで発注が来た」といっても、それがイコール『顧客が本当に必要だった物』かどうかは誰も把握していませんし、理解していません。

それを知ることができるのは開発中でもなく、納品時でもなく

　『運用開始後の効果測定によってのみ把握できる』

ものであり、けれども多くのＩＴエンジニア、多くのＩＴ企業は

　「検収があがって契約満了するまでが仕事」

だと言い聞かせ続けられ、システムのライフサイクル自体をどうこうしようなんて考えを持ちえないからです。

通常、私たちＩＴ企業を選定するずっと前から顧客の中では顧客自身のプロジェクトとして発足します。後々ＲＦＰ（Request for Proposal（提案依頼書））などにも記載されていることが多いのですが、ＩＴ投資を実施する際に多くのビジネス的な目標値が設定されています。

　生産性 〇% の向上
　利益回収率〇% の改善

などがまさにそれです。

当然ながら、こうした大本の経営・事業・ビジネスに根付いたニーズがあり、これに対してＩＴ投資を行うことでその目的を達成できると思っているからこそ私たちSIerやITベンダーに発注という流れをとります。

ですが、ＩＴエンジニアやＩＴ企業にとってはそんなニーズはどうでもいいと考えているのがほとんどでしょう。だって、そのニーズは具体的に「なにを作ればいいか」という情報と直接的な因果関係を持たないからです。

間接的、最終的には紐づくものかもしれませんが、それは発注側が考えることで、自分たち開発作業を行う者たちには関係ないものと考えているのです。その証拠に、納品し、検収があがった時点で安堵し、売上／利益貢献さえできればその後の顧客の経営、事業、ビジネスがどうなったかについてはとんと無関心です。

ＲＦＰを受け取った頃には多少気にしていたかもしれませんが、その気にしたことすらどの作業、どの業務にも紐づいておらず、紐づいたかどうかを測定することも無く、いつの間にか風化し、忘れ去られているのです。

そしてそれは発注側…お客さま側でも同様のことが起きています。

開発側のエンジニアたちが、

　「なにを作りましょうか」
　「おたくはどんな業務となっていますか」

ばかり聞いてきて、プロジェクトが進行していく中で

　「こんな"システム"を作成しますが認識に相違ありませんか」
　「こんな機能で業務は成立しますか」
　「なにか懸念や不足はありませんか」

といったプログラムの出来ばかりを質問されるため、発注側もいつのまにか

　『業務が成立するか』
　『欲しい機能は揃っているか』

というものづくり目線でしか物事を観ようとしなくなっていきます。

それもそのはず。

お互いに「システムとはなんぞや？」ということを正しく理解していないのですからそうなってしまうのも無理はありません。

たとえばシステム開発などの世界では上図のような領域の切り分けが行われることが非常に多いのではないでしょうか（なかにはそんなことすら考えずに設計やテストをしている企業、エンジニアも多いみたいですが）。

いわゆるＶ字モデルをベースとした開発の考え方（ウォーターフォールやアジャイルの違いは関係ありません。すべての開発のベースモデル）です。

このソフトウェアとシステムの違いという切り口だけで見ると多くの人は

　「ソフトウェア以外というと、ハードウェアや…ネットワーク？」

と考えがちですが、これはちょっと違います。いわゆるインフラと呼ばれる領域は、ソフトウェアと並行して活動しているものです。システムのなかにそれらが含まれるのは間違いありませんが、だからと言って

　・ソフトウェア
　・ハードウェア
　・ネットワーク

だけでシステムが成立するかというとそれは誤りです。

システムとは「仕組みを構築する要素を組み合わせたすべて」を指します。物理的な構成要素だけのことを言っているわけではありません。

仕組み（ルールやプロセス、手順等）そのものもそうですし、そこに必要となる人的リソースも構成要素の１つです。施設や設備なども必要です。

　「何か１つでも欠けると運用することができない」

そのすべての要素を組み合わせてシステムというものは成立します。

よく言いますよね。人が社会や会社の「システムに組み込まれる」と表現したり、集団スポーツの戦略を「〇〇システム」と呼んだりすることもあります。ＩＴの存在の有無に関わらずシステムは存在できるのです。ゆえに、ソフトウェア等よりも『仕組み』そのものの方がシステムとしてのあり方として近いと言って差し支えないでしょう。

このことを「システムを運用する」発注者自身も、「システムを構築する」開発者自身もあまりよくわかっていないのです。

先ほど載せた画像は一時期ネットでよく流れていた"システム開発(やサイト構築)などを皮肉にしたジョーク"ですが、この図で本質的に重要な事は最初と最後の絵だけです。

発注者自身もどこか「当初のニーズを満たすために必要なこと」という目線を忘れてしまい、担当レベルになると「仕事だから」という認識だけで元々自社が持っているニーズを満たすためにはどのようなシステムであるべきか、という目線を持たないためにどこか本当に必要だった物とは乖離した要件となってしまうことがあります。

そして途中では色々な人の思惑が混ざり、紆余曲折を経るわけですが、「最初に顧客が注文したとおりに作っても不正解」というところが言い得て妙ですね。

よって、「顧客がそう言ったから」を盾に自身を正当化しようとする開発側のリーダーやマネージャーは、最初から確信犯的に間違える気しかないと言っているのと同じだということが、その姿勢からうかがえるわけです。相手の言質を取ることは確かに重要かもしれませんが、それは「逃げ腰のビジネス」「信用を裏切るビジネス」にしかなりません。

顧客の意図していることが本当に顧客にとって必要なことなのかを別の立場から考えてあげることは、私たちシステム開発側の役割であり、責任です。

このことは、システム開発やデザイン、プロダクト開発全般に言えることで、これらに関わる人間全てが肝に銘じて置く必要がある最重要事項の一つだと私は考えています。

とはいえ、システム開発において、

開発対象となるシステムが必要とする機能（性能・運用性などの非機能性能）については、そのシステムを作ってみないと知ることができない

というのも事実です。これは絶対的な法則と言っても良い、厳然たるものといっていいでしょう。プロジェクトは基本的に未知なものであり、必ず不確実性がともないます。

こうした不可知の原則によって、システム開発に関わるあらゆることが反直感的に振る舞われます。何故ならば、人は「自分のことを自分でわかっている」と過信してしまいがちだからです。

そのため自分自身に対しては盲目的となってしまい、どうしても暗黙的に「知っていること」を前提に計画を立てるため、知っているつもりであることと現実が乖離すると、全てがうまくいかなくなるのです。

逆に「知ることができない」事を前提にしてみると、そもそもソフトウェア工学（エンジニアリング）において様々なことが"必要"と言われている理由もおのずと理解できるようになってくるのではないでしょうか。

また、システム開発がうまくいかない理由によく挙げられるものに、

　「お客様の意見をうまくヒアリングできていないからだ」

と言うのがあります。実際、そのことが理由で問題を起こすプロジェクトも毎年、凝りもせずに数多く発生しています。

つまり、「お客さまはすべての正解を知っていて、私たちはそれをちゃんと聞き出してシステムを作れば、失敗することはない」ということが暗黙的な前提としてあって、そのゴールを目指すためにより良いシステム開発を目指していけばよいと言うものですね。

しかし、この前提は間違っています。いえ、そうすることによって開発側にとっては一部の改善を実施することが可能かもしれませんが、それだけで充足するということはありません。

そもそもお客さまは神様ではないのです（当然）。

所詮、人です。開発側と同じ不完全で、未完成な『人』なのです。人は、自分が本当に必要とする物を「作ってみないと」理解することができない部分も必ず存在します。

ゴールの見えない競争に勝つことはできません。
かと言って、不可知の原則によってすべての正解をあらかじめ定義するのはまず不可能です。

ではどうすればよいか？

まずは、一刻も早く「不正解」を作ることです。
望むものをすべて洗い出すことは難しくても、明らかに望まないものを確認することは可能です。正解するためには、それ以外の不正解を全て挙げてしまえばいいわけですから、早期から実現していれば消去法でたどり着くことも可能となります。

とは言え時間が無限にあるわけではないですから、最小のコストで不正解を導き出したほうが好ましいのは事実です。そのため、最小のコストで目標に向かっているかお客さまにとって検証可能な（つまり動作可能な）システムを作る必要があるわけです。

これは、結果的にアジャイルやイテレーションというパラダイムが目指していることと合致しますが、なにもアジャイル開発系だけが優れているというわけではありません。ウォーターフォール系開発が致命的欠陥を抱えているのと同様、アジャイル系開発にもかなり致命的な欠陥があるため一概にどちらが良いと言えるものではありませんが、

　・システムの本質を理解すること
　　（モノづくりだけをターゲットにしないこと）

　・顧客の言葉だけを鵜呑みにしないこと
　　（顧客が本当に求めている「ニーズ」の実現を目標とすること）

は絶対に外してはいけないのではないでしょうか。そのことを大前提としていれば、ウォーターフォールだのアジャイルだので揉める必要も無いのではないかと思っています。