この記事で書きたいこと
タイトルについて、以下のようなことを私なりの見解としてまとめていきたいと思う。
- システムも技術もツールも手段である
- お客様は自分たちが何に困っているか必ずしもわかっていない
- スコープは無限に拡大できるし、なんなら自分で決められる
エンジニアの方々の中にもこれからのキャリアとして
プライム案件で上流をやっていきたい、コンサルティングをしたい
提案をしてみたい、などよりお客様に近い立場でのポジションを望むことがあると思うので
そのようなキャリアを描くうえで役に立つかもしれない考え方についてまとめてみた。
システムも技術もツールも手段である
当たり前のことですが当事者になると忘れがちなこととして
以下のようなことはお客様の課題解決にとって単なる手段の一つでしか無い。
- Salesforceを導入する
- AWSを活用して高い可用性のあるインフラ基盤を構築する
- モダンなJavaScriptのライブラリを使ってアプリをつくる
- Flutterを使ってクロスプラットフォームでスマホアプリをつくる
- アジャイル開発する
とかである。
これらはすべて何かしらの課題解決を行うために最終的に選択される
一つの手段でしか無い。
そしてお客様は基本的にITへの解像度が我々のようなシステム開発会社と比べて低い(はず)
ため自分たちなりに検討された課題解決の方針の結果として上記のようなアクションを想定していても
「必ずしもその選択がベストとは言い切れない」 し、むしろ 「そうではない可能性のほうが高い」 と考えて然るべきというのが私の基本的な考え方だ。
そんな中お客様の考えた 「手段を実行するためのパートナー」 としての活動に終始した場合、
付加価値が低いので収益が下がるであるとか
他社と比べて競争力が落ちるであるとか
そういったネガティブ要素も発生することがわかりやすく想定されるが、それよりも一番残念なことは
その手段が課題解決の間違った手段であった場合、
お客様は対価を支払ったにも関わらず成果が得られず、その活動にアサインされた貴重なIT人材の時間が非生産的な活動に吸い取られ、我々には後ろめたい若干の売上だけが残る。
ということだ。実に悲しいが、しばしば横目に見かけることでもある。
これは受け売りだが、我々プロフェッショナルとお客様との関係は医者と患者に似ている。
患者が自分で勝手に診断した結果飲みたい薬を処方しても、治らないどころか無用な副作用に苛まれることだってあるわけだ。
お客様は自分たちが何に困っているか必ずしもわかっていない
ここまでの話に近いことではあるが少し違うこととして
お客様はパートナーに対して、正確に今何に困っているかを伝えられているケースは少ないと思っている。
例えば何か新しいサービスに付随するアプリケーションの開発を検討するにあたってそれなりにそのサービスの業務面の整理や、それを実現するための開発の方向性、採用技術/ツールなどをまずは検討してみると思うのだが
各パラメータに対する自信は大体以下の通りだとおもう
- 業務面の解像度：当事者なのでそれなりに高い
- システム化実現可能性：よくわからない
- 妥当工数/工期：よくわからない
- 採用技術/ツール：よくわからない
- 経済的合理性：よくわからない
- 必要スキルセット：よくわからない
せめて上記のクライテリアの3つか４つくらいに自信が持てれば
ベンダー選定についても、内製で開発を進めるにしても
自分たちでアテがつけられるというものだがそうでないことが多い。と思う。
この状態でも、仕事を進めるにあたって相見積を取ったりすると思うが
ここの解像度が低ければ低いほど各ベンダーからの見積もりにはばらつきが出ると思う。
客観的に見てこういうコンディションのお客様向けの提案の際に
その中でなんとかコストを合わせて提案するということが
お互いにとって どれだけ不幸になる可能性を秘めているかはご理解頂けるかと思う。
但し、お客様の予算が限られていることは普通にあることなので
予算を無視して超安全なとっても現実的なプランだけを提案せよという意味のない理想論を語るつもりはない。
重要なのは提案の際に、上記の様なクライテリアの解像度を上げる努力を
こちら側がするべき、それがプロフェッショナルとしての提案の形だというマインドセットを持ち
お客様がわかっていなさそうなことを我々が理解/想像し、そのGAPを埋める ための提案準備をすることが寛容である。
日本のITを押し上げるのは、日本のようにシステム開発会社が分業されているような業界構造である場合、それは発注元であるお客様の責任ではなくて、システム開発のプロフェッショナルということで存在意義を得ている私達の責任なのだ。
スコープは無限に広げられるし、なんなら自分で決められる
これも上記までと地続きの話になるが、お客様に対しての提案スコープ(オポチュニティ)というものは引き合いの時点では実は確定していないと思っている。それが我々のような無形商材を扱うコンサル会社の醍醐味だ。
レベルの高いコンサルタントが提案を担った場合、お客様の当初のお引き合い内容を遥かに超えて、お客様の課題を１段階、２段階と抽象化していくことでよりインパクトのある、より広いスコープに対しての提案に変異していくのだ
例えば
「モダン技術開発、例えばReactの開発経験３年目の人を３人提案してほしい、単価は100万」
というような引き合いも
何を作ろうとしているのか
なぜ３人だけ集めているのか
その人数でそもそも足りるのか
なぜ我々の会社に声がかかったのか
当社のどの部分を期待されているのか
それ以外に開発全体の課題はないのか
そもそもなぜそのアプリを開発しようとしているのか
そのアプリは経営的な目標の何に紐づくのか
など焦点を抽象化させていくことでみるみる提案可能な範囲は広がっていく。
単なる人出し提案は冒頭の整理の通り単なる手段中の手段で、負け戦の可能性だってあり、それは日本の貴重なIT人材の無駄遣いであり基本そのまま提案してはならないのだ。
上記の解像度をどのように具体的に上げていくのかはそれはそれでいくつかの記事にできてしまうので割愛するが
極端なことを言えばお客様の代表取締役社長と同じ視座と解像度にまでたどり着くことができれば、物理的にはその会社のほとんどのことに提案が可能と言えなくはない。
先程の例も、ヒアリングを工夫すればこれくらいの情報には現実的にたどり着けるはずだ。いや本当に。
「すでにあるB2Bのウェブアプリケーションは、他社に強豪の製品があるが若干機能面で劣後しているところがあり、すでに開発ベンダに委託しているが技術面で当初の期待値に達しておらず、改善のための開発なんてもってのほかで、開発ベンダの変更すら考えている。が、今は単純に株主に宣言している改善後のリリース日がきまっておりそのタイミングに間に合わせるためだけに頭数を増やそうとしていたのです。」
ここまで聞ければ、当初の３人Reactエンジニアの人だし提案から全く提案のコンセプトが変えられることがすぐに分かると思う。
例えば今起きている機能面の不足をもう少し掘り下げて、我々が既存開発ベンダをリプレイスしてより良いシステム開発の体制を提供してあげるためのステップを提案差し上げる、だとかだ。
この時点で提案の自由度と範囲は一気に上がっており、またお客様が自社の製品をより良いものにして生産性を上げる可能性が向上し、そのサービスに当社に努めている優秀なエンジニアがアサインされることで、日本国内のIT業界における開発リソースのアロケーションが数ミリパーセントほど最適化され、日本のITが若干ほどアップデートされて嬉しいな。 と私たちは考えている。
謝辞と蛇足
偉そうに言っていますが、上記のような提案は現実的には
優秀なエンジニアが社内にいてこそ成り立つものであり
すべての会社で上記のような自由度の高い提案ができるとは断言できない。
ただし、当社ではできる。当社は日本のITを手の届く範囲ではアップデートし続けていると確信している。
なので営業としてはやりがいしかなく感謝してもし足りない。
足りないけどします。いつもありがとうございます。
そしてもしこの記事を読んで、若干なり当社に興味を持った
エンジニア、コンサルタント、営業方がいたら是非当社へ、ご連絡お待ちしております。