エンジニアがビジネスを理解する技術

「エンジニアリングマネージャやVPoEの実体験を通じ痛感したことと感謝」という記事にエンジニアがビジネスについて深く理解することの必要性について、書かれていて、非常に共感を受けたので、理解する技術を掘り下げて書いてみた。

エンジニアリングマネージャーやVPoEの実体験を通じ痛感したことと感謝 - Qiita

エンジニアチームのパフォーマンスに影響を与える要素
意思決定の精度（事業、業務理解の促進）・・・どれだけ自分たちで正しい意思決定ができるか？
そのために必要なことは？
エンジニアがビジネス（お客様、市場、競合、自社）について深く理解することが必要だと思います。

なんでビジネス理解が大事なのか？

背景

・エンジニアはどうしても、ビジネスサイドから依頼を受けて、仕事をしがち
・エンジニアが直接売上を上げることは事業会社だと難しいため、コストセンターとみなされがちで、プロフィットセンターである営業の方が相対的に立場が強いことが多い

課題

・エンジニアとビジネスサイドが受発注関係になって、やらされている感、作業者感を感じてしまい、エンジニアのモチベーションダウン
・ビジネスサイドがエンジニアに対し、作業者として見るようになると、要件、仕様をガチガチに決め過ぎてしまい、よりよい改善案があったとしても受け入れられにくくなる
・ビジネスサイドが要件、仕様を伝える際、知っていて当然と考えている暗黙知、前提を話さないで伝えられ、仕様から漏れる
・納期、品質に対し、ビジネスサイドから押し切られてしまい、勤務のブラック化につながる
・あいまいな要件、仕様に対し、エンジニアが案を作ったり、詰め切れたりできず、効率が悪い。ビジネスサイドの言いなりになってしまって、システムの複雑性を生んで、技術的負債になる

ビジネスサイドとエンジニアが対等に仕事ができるようにしたい

そのためには

ビジネスを理解する
ビジネスを理解するためには、3C分析のフレームワークで考えるのがよさそう。ビジネスサイドの共通言語なのと、きちんとしたビジネスサイドなら、3C分析をすでにやっているはず。
https://cyber-synapse.com/dictionary/en-all/3c-analysis.html

Customer
クライアント（社外・社内のエンドユーザ）を理解する。特に、何に困っているのか、何が大事なのかという価値観を理解することが大事。けっこうこれができるだけで、ビジネスサイドのスジが良くない意見をはねのけられる。営業は売上目標を持っているので、自社視点になり、クライアント視点になりきれないことが多々ある。最終的にクライアント視点と自社視点のバランスを取った落とし所をエンジニアが提案できれば勝ち。

やること
①業界・市場を書籍等で理解
　業界についての書籍を読む。ささっとすぐわかる系の書籍を読むとよい。まずは、これを読んで、全体像を把握。その後、必要に応じて、業界雑誌、業界新聞、サイト、メルマガを読んで、最近、何が問題なのか、業界で何が流行っているのかを理解する。あとは、業界に研究所があれば、レポートを出していることが多いので、読むとエビデンスを元にした課題、今後の業界の流れを把握することができる。

②twitterで業界の情報発信者、エンドユーザをフォロー
　雑誌、サイトだとタイムラグがあるという点と生の声が聞きにくいので、twitterで情報を取得すると、リアルタイム性がある課題把握、施策に結びつけることができる。

③クライアントヒアリング
　社内のクライアントのヒアリングはしやすいが、社外のヒアリングの機会がちょっとハードルがある。機会が無いなら、事業責任者に相談して、作る。

④クライアントと飲みに行く
　ヒアリングだけで、言いにくいようなホントの価値観聞き出せる？
　ヒアリングで綺麗事を言っていたとしても、例えば、お金のことは言いにくい


Competitor
競合を理解する。業界、競合の規模によっては情報が少ないため、打ち手が少ないのが悩みどころ。「競合のあのサービスみたいなの欲しいんだけど」みたいなことをビジネスサイドから相談された時に、競合のことをよく知っているとビジネスサイドから信頼感を得やすい。

やること
①競合サイトを見る、分析する
　ターゲット顧客層、製品、サービス、価格、売上、ポジショニングあたりを調べるとよい。競合が上場しているとIRの決算資料として、上記を投資家向けにわかりやすく書かれているので、読まない手はない。
・競合の社名 評判 クチコミで検索 競合のエンジニアに会う 競合のエンジニアに会う　サービスの比較サイトを眺めるのもよい。ただし、アフィリエイトで恣意的な内容なことも多いので、そのまま信じず、参考程度にするのがよい。

②競合のサービスを使っているユーザに会う

③競合のエンジニアに会う 競合のエンジニアに会う
　ミートアップとか、機会はたくさんあるので、遠慮せず行ってみる。意外と社名を明かして応募しても、参加させてもらえる。競合の方が魅力的に感じてしまい、ミイラ取りがミイラにならないように注意。それはそれでいいのかもしれないが。

Company
自社を理解する。会社レベル、事業部レベルのビジョン、売上、コスト、利益とか、強み、弱みとか。SWOT分析までビジネスサイドが落とし込んでいる資料があるとよいのだけど、無かったら、なんで作ってないんですか？戦略無いんですか？と伝えてもいいかもしれない。自分は、事業責任者に売上目標だけではなくて、ビジョンを示して欲しいと繰り返し言っていたら、作ってくれた。

やること
①会社全体、事業部の戦略を知る
　全社総会、事業部総会に出て、しっかり戦略の説明を聞く。総会、戦略の説明が無いなら、社長、事業責任者に聞く！戦略が無いとか説明しない会社ってあるのかしら？会社の共有フォルダを漁ると、けっこう見つかることがある。

②週1程度でビジネスサイドの席で仕事をする
　ビジネスサイドでやり取りしている会話から、何に困っているかが分かる。ビジネスサイドから気軽に相談されることになるし、逆にエンジニアから気軽に相談しやすくなる。デメリットとして、ビジネスサイドは電話のやり取りが多く、うるさくて、集中してプログラミングすることの邪魔になる。そのため、週1程度が落とし所かなと考える。

③ビジネスサイドのメーリングリスト、ミーティングに加えてもらう
　追いかけるのが面倒だが、機能要望、問い合わせの際に、背景がわかりやすくなったりする

④ビジネスサイドとランチ
　具体的には、事業責任者、営業とランチに行く。週1とか定期的に頻繁に行くのが重要で、ビジネスサイドの日々変わる課題、優先順位を把握できる


自分がコンサルティングファームから医療系Webサービスの事業会社に転職して、ビジネスを理解するために上記のようなことをやってきたのだけど、エンジニアが技術のキャッチアップもしながら、これらを全部やるのは、多分厳しい。なので、コスト、重要度を踏まえて、3Cそれぞれで優先順位をつけて書いたので、①をひとまずやることがおすすめ。