僕はライターの仕事の他に、自分軸の発見支援ファシリテーターをやっています。

詳しくはHPを見てほしいのですが、自分軸を一言でいうと、

　　「誰に・何を・なぜ」提供しているのかを突き詰めると、
　　うまくいきたいことがうまくいくようになる

というものです。

うまくいきたいことは人それぞれで、仕事とか就職・転職とか独立とか起業とか事業の立て直しとか、あるいは人生とか、つまり何でもなんですが、本人がそれを願う理由（なぜ）がはっきりしたものでないとダメです。

さて、あることに自分軸が応用できないかという相談がきました。

 

相談をくださったのはHさん。研修の企画・実施会社の社長です。僕からみたら法人研修の講師を斡旋してくれるエージェントです。

Hさんは客先で、大規模システム開発が暗礁に乗り上げ、訴訟寸前で物別れしたという話を聞きました。

話してくれた方は、発注元の企業（A社とします）に勤めていました。

大手ITベンダー（B社とします）が、自社のパッケージソフトを活用する提案をしてきました。A社は、B社にしては安いなということで採用しました。

ところがB社の担当チームは、その業界での開発経験が少なかった。業務知識が浅く、薄い。ところがA社は、当然知っているだろうと思ったことに対しては、細かい説明をしなかった。B社担当チームの業務知識のレベルをあとで知ったのです。

気づいたときには後の祭り。とても使えるシステムができるとは思えない設計書ができていました。その後は、A社とB社は対立関係となり、年を経るごとに関係は悪化していきました。

IT業界の動向に詳しい方は、スルガ銀行とIBMの話に似ているなと思ったかもしれません。別件のようですが。

 

「森川さんからすると、『よくあること』というお話だと思います」と相談メールにはありました。

はい。訴訟寸前までいくとなると数%でしょうが（それでも数%もある、さすがに訴訟沙汰になるのはレアケースですが寸前ならよくあることです）、物別れに終わって結局完成しないという案件も数%はあると思います。いちおう完成したが、結局利用されないシステムであれば十数%（いや、もっとか）はあるでしょう。

ユーザーとベンダーの双方が満足するプロジェクトは1%あるかないか。多くの場合は双方が不満に思っています。

そして恐ろしいことに、ベンダー側の業務知識の有無と成功・失敗はあまり関係ありません。業務知識があるほうが成功しやすいという傾向はあると思いますが、いくら業務知識があっても失敗するプロジェクトは失敗するし、逆に業務知識が皆無でも成功するプロジェクトもあります。

もちろんベンダー側だけが悪いということはレアケースです（ひどい業者がいるのは事実としても）。そもそも管理責任は発注元にあるので、失敗した場合には発注元にも問題があることがほとんどです。

しかし、最初の歩み寄りは注文を受けている方からするのが筋だというのは言えます（これは顧客の奴隷になれということではなく、まずは自分たちの問題を解決してから、顧客にも要求をするのが本来の姿だと言っているにすぎません）。

 

Hさんは、仮説を持っていました。

「こういうことになるのは、ベンダー側に『システムの先には人がいる』という概念がないからではないか」という仮説です。

一見諸手を挙げて賛成したくなるような意見（特にユーザー側の関係者は）ですが、実はそれほど簡単な話ではありません。

少なくともシステムの先に人がいるということを理解していないITエンジニアは存在しないと思います（人によっては、人も含めてシステムだと教わった人もいるはずですが、これは単にシステムの定義の問題です）。

UI（ユーザインタフェース）という言葉を知らないITエンジニアはいません。システムには人（プログラムの場合もありますが）とのインターフェースが存在するということは、まず間違いなく、みな意識しているのです。

たとえば、ITエンジニアであれば、かいたことはなくても、必ず見たことはあるユースケース図というものがあります（下図）。

 

これはUMLという国際標準的な書式に基づいたものであり、この通りにかかなければいけないということではありません。なのでこれ以外の記法でかく人もいるでしょう。

いずれにしろ、業務アプリケーションの開発で、顧客とシステム化の範囲を決める際に、このような感じの図をかきながら話をしないITエンジニアは、どちらかというと少ない。

システムの先か中かは別として、システムに人が関わらないと考えているITエンジニアは、まず存在しません。

 

Hさんの言っていることを文字通りに受け取るとこういう反論になってしまいますが、しかし、Hさんもそんな単純なことを言っているわけではなさそうです。

「システムの先に人がいる」という概念がないITエンジニアはいないとしても、それが本当に分かっているITエンジニアは少ないということは言えるかと思います。

その証拠に、たとえば先ほどのユースケース図。実にシンプルな記述法ですが、これがきちっとかけるITエンジニアは少ない。上の図はかなり省略されています。ATMに関わる業務も、すべての機能と関係者を網羅したらかなり複雑な図になります。

スキル的に人、というよりも業務が表現できるITエンジニアが少ないのは事実なのです。

他の例も挙げます。

データベースの設計には3つの段階があると、どの教科書にも書かれています（下図）。

細かい説明は省きましょう。簡単にいうと、対象業務のすべてのデータ項目を洗い出して分析するのが概念設計、その中でシステム化する範囲のデータ項目（はみ出しているのは、業務には使わず、システム運用のためだけに使う項目）を分析したものが論理設計です。ここまでは、特定のDBMS（DataBase Management System; Oracle、SQL Serverなど）を意識しません。特定のDBMSに特化し、プログラムを作成するのに必要な形に落とし込んだものを物理設計といいます。

ベンダー側から見れば、概念設計は利用者との同意のため、論理設計はシステム部門担当者との同意のため、物理設計はプログラマへの仕事の依頼のために、それぞれ作成します。

 

さきほどのユースケース図と同様、論理設計はできても、概念設計（データ分析と呼ぶこともあります）ができるITエンジニアはほとんどいません。物理設計は得意でないと、少々不味いです。

特にプログラマからキャリアを開始した人は、どうしても実装（注1）よりで物事を考えてしまいます。

ユースケース図もデータベースの概念設計も、業務そのものの表現ということになるのですが、そのスキルを持つITエンジニアがとても少ないのが実態なのです。

このあたりが強い人は、エンジニアよりは、コンサルタントと呼ばれる人に多い。

であれば、業務分析（いわゆる要件定義）においては、専門のコンサルタントをアサインすべきなのですが、Hさんが聞いたA社の案件では、おそらくコンサルタントをアサインしなかったのでしょう（したとしても名ばかりだったかどちらかです）。

注1：「実装」というのは、実は業界用語のようです。漢字からおおよその意味はつかめると思いますが、若干補足します。プログラミングも実装の一部ですが、それだけではなく、ハードウェアやネットワークの手配、基本ソフトという業務システムが利用するソフトウェアの導入・設定、開発環境の整備、本番環境への移行、テストデータや初期データの投入など、実際の運用に必要な準備をすべて含めて実装というのが普通です。

 

ただ、ITエンジニアには業務の分析ができる能力がないかというと、そういうことではありません。

特殊な才能が必要というわけではないので、本気で勉強すればできるはずなのです。

ではなぜ勉強しないのか。

これは私見（注2）にすぎませんが、おそらくは面倒なので軽視しているのだと思います。

ITエンジニアとしては、実装に強いということがもちろん強みになります。この部分は専門技術だし、仲間内でも実装に強いほうが尊敬されます。

業務分析などは、はっきりいって地味です。また実装が好きな人にとっては、あまり楽しくありません。現実問題として安価な教科書や参考書も存在していません。

また、実装は設計書さえあれば、人と接しなくてもできる作業です。しかしながら、業務分析となると、ITエンジニアからみてもっとも厄介な人種、すなわち利用者と話をしなければなりません。面倒です。

Hさんが本当に言いたかったのは、ここだと思うのです。

「システムの先に人がいる」という概念がないのではなく、そんなことは重々承知しているのに、それを面倒だと思い、また軽視しているということなのです。

Hさんとしては、概念があればそれに向けて努力するのが普通のことなので、「概念がない」という言い方になったのでしょう。しかし、長年ITエンジニアを職業にしていた僕には、面倒だから軽視するという、その気分は十分理解できるものです（それで良いかというと別ですが）。

注2：僕の経験に基づく偏見もあるかもしれません。ただ、僕は日本の４大システムインテグレーターすべてが常駐し、またそれらの外注先の社員が多数出入りする場所で、ユーザー企業側のITコンサルタントをしていました。また、それ以前には17年半のSE経験があり、多くのIT企業と関わってきました。何千人ものITエンジニアを見てきたので、偏った人とばかりお会いしてきたとは思いづらいのです。

 

以上が正しければ、Hさんのいうとおり、自分軸をシステム開発の成功に結び付けることが可能になります。

 「誰に・何を・なぜ」提供するかということを突き詰める際に、必ず人と自分との関わりについて思いをはせることになるからです。

ただ、そもそも人との関わりを面倒だと思い、軽視する人（SE時代の自分もそうでした）を自分軸発見の場に引き出せるかどうか。

本人の意思で考え直したいというのであれば、自分軸発見支援は強い威力を発揮できる自信はあります。しかし、本人がそのような意思を持つようにすることの方が、僕には難しいと思うのです。

最初に「うまくいきたいことがうまくいくようになる」と書いたのは、このような意味です。うまくいきたいと思っていないことは、どうやったってうまくいくわけがないのです。

本人が、もうこれ以上システム開発プロジェクトで失敗したくない、いいシステムを作って顧客にほめられたいと本気で願うかどうか、それ次第です。

そんなことを願わない人がいるのか、って？ まあ、こればかりは本人と腹を割って話をしないと分かりません。本気でというよりは漠然と願っている人が多いと、僕は思っていますけれど。