ＩＴの本業は「開発」ではなく「解決」

本来、システム開発は「ＩＴシステムを作る」ことが仕事ではありません。

！？

と思うかもしれませんが、"システム"というものがなんのためにあるのかを理解している人ならばわかるでしょう。そして、この業界が"サービス業"であることを把握している人ならば納得するでしょう。

昨今では「目標」ではなく「バリュー（価値）」を重視する企業が増えてきました。しかも、できれば普遍的なバリューこそが至上と考えられるようになっているのです。バリューへの注目が高まったことで、世界を牽引する大企業においてもバリュー浸透・教育が行われるようになっています。

ソフトウェア開発も、その取り組み自体に

　ミッション
　ビジョン
　バリュー

という３つの軸に分割して考えてみるとわかります。「開発する」ことそのものは、ただの手段でしかありません。

ミッション（Mission）とは

作り上げられたシステムが果たすべき使命、あるいは役割のことを指します。このミッションが無ければシステムなんて作る必要はないし、システム導入以外の方法でもクリアできるなら無理にシステムに固執する必要はありません。

システム導入はそれだけで家が（ひょっとする豪邸が）一軒建ってしまう高額商品です。買わなくていいなら、買わないに越したことはありません。

ビジョン（Vision）とは

システムが、ミッションを叶えるために何をすべきか、その目標や戦略のことを指します。どうすれば実現できるのか、段階的にどう追及していけばいいのかを考えればビジョンが見えてきます。

このビジョンがいわば目標なわけです。

システム導入を行うのであれば、「どのようなシステムにするのか」「どう作るのか」「どんな満足を与えるのか」という"結果"に紐づくものとなります。

バリュー（Value）とは

ですが、昨今ではビジョンに重きが置かれません。もちろんミッションやビジョンを実現するのは当然必須です。仕事ですから。

ですが、エンジニア一人ひとり、プロジェクト関係者一人ひとりそこに関わるステークホルダーとして見てみると、そのミッションやビジョンを実現するにあたり、その一人ひとりが日々発揮するべき価値こそが重要になってきます。

必要十分な価値を発揮できなければ、ミッションやビジョンを実現／達成することなど叶いません。当然ですよね。一度も調理したことが無い人に高級料亭の板場に立たせても、満足できる料理が出せるわけがないのです。

ミッションやビジョンを実現するには、間違いなくそれを実現できる価値あるリソース（人的、環境的）を用意するしかないのです。

システム開発ができれば価値提供できるのか？

開発する力ももちろん必要です。

ですが、それだけで価値提供…つまりミッションやビジョンを実現できるでしょうか。

たとえば、プロジェクトチームのメンバーがものすごく「システム開発」スキルに特化していても

　・お客さまの業務に対する理解が乏しい
　・ロクにコミュニケーション（報連相）もできない
　・マネジメントなんて知ったこっちゃない

なんて人たちの集まりだったらどうでしょう。

そう、おそらくＩＴ産業の仕事としては成立しないんです。チームの中で何割かは「開発のプロフェッショナル」がいてもいいと思います。でも、それしかできない人たちだけで仕事になるほど、この業界は甘くありません。

要するに「システムを開発する」というのは、仕事のごく一部でしかないんです。

元来、「仕組みを構築する」ことをシステム開発といいます。

よって、運用や手順を再構成(＝リストラクチャリング)することで解決できるのであれば、無理してＩＴシステムを売りつける必要はありません。

ですが、民法によって請負契約の制約上、モノを売りつけないとお金がもらえない（し、購入側も大金を支払う以上、何か形に残ってないと会計監査上いろいろと問題がある）ため、企業継続の観点から「作ること」や「売ること」を前提としてしまうことから、現場も見誤ってしまうのかもしれません。

また、私たちの業界がサービス業である以上、製造業と違って本来は「作ること」や「売ること」を本業とすることはやはりおかしいのです。

サービス業は「サービス」を提供してなんぼの仕事です。

この場合、お客さまは私たちに何を求めて仕事を依頼しに来るのかというと、それは

　現状(As-Is)困っていることを、理想(To-Be)通りに解決してほしい

から来るのです。解決するサービス…すなわちソリューション（Solution）することこそが、ソフトウェア開発を主とするＩＴ産業の本当の仕事です。その手段の１つとして「ＩＴシステム」を導入することが最も実現性が高いと思ったから、お客さまはＩＴ会社に仕事を依頼しに来ます。

しかし、本質的には「解決してほしい」のであって、何が何でも「ＩＴシステムが欲しい」と言っているわけではありません。

そこをはき違えるから、超上流～上流工程において、いつもお客さまの本当の要求仕様を見逃すことになるわけです。

要求仕様を見逃しているエンジニアか否かは、要件定義や基本設計工程の活動をほんの少し観察すればわかります。

　「"何を作ってほしい"のか、わからないから仕様が決まらない」
　「仕様が出てこない」
　「どう作るか」「何を作るか」　etc...

と考えているエンジニアやマネージャーがいたら、ほぼ100%はき違えていると見ていいでしょう。

たとえばコンサルタントやいわゆるフロントエンジニア等、きちんとわかっている人は

（要件定義）
　　「現状どうなっているのか」
　　「何が不満なのか」
　　「どう解決すると、お客は満足するのか」
　　「そもそもどんな利用者がいるのか」
　　「解決が求められる背景には何があるのか」

（基本設計）
　　「解決する具体的方法はどうしようか」
　　「実現可能だろうか」
　　「利用者全員が満足するだろうか」
　　「作ること以外、あと検討することはないだろうか」

と言うように"作る"こと自体には主眼を置いて考えたりはしません（もちろん作ることも考えはするでしょうけど）。さらには、仕様はお客さまが定義するのではなく、お客さまが提示した「不満」と「希望」を聞いて、仕様に昇華させ、定義化するのは自分たちだと考える傾向が強いことも特徴的です。

お客さまはいつでも、ＩＴの素人だと思っておいたほうがいいでしょう。

多少詳しいとしても、少なくとも私たちより精通していたら私たちのところに仕事を持ち掛けに来ません。ゆえにお客さまがいつも持ってくる情報で、最も信ぴょう性が高く、最も重視すべきは

　現状に対する不満

だけです。解決してほしい「理想像」などを色々検討して持ってきてくださるお客さまも稀にいますが、大抵"要求仕様"と"期待・願望"をはき違えて持ってこられるので、話半分で聞いておいたほうがいいでしょう。

ゆえに、大手ベンダーの多くはRFP(Request For Proposal：提案依頼書)をお客さまの代わりに作ってあげるコンサルタント業なども仕事にしていたりするわけです。

だからこそ、超上流～上流工程では、「作りたい」「作ることばかり考えていたい」と言う技術者としての欲求を抑え、お客さま側の一員になったつもりで、

　不満の共有
　満足するための解決方法

について注力すべきなのです。
その結果、ＩＴシステムが必要であればその道のプロとしてＩＴシステムを設計・開発してあげるわけです。"顧客満足度"は、

　「顧客が本当に満足するために必要なプロセスは何なのか？」

を理解していないと、なかなか向上しません。