ビジネス・業務部門はITを道具として使うことを知っているけれど、ITの最新動向を踏まえてビジネスを創造することは知りません。
デジタルトランスフォーメーション（DX）や日本産業の競争力を強化するためには、エンジニアがビジネスリーダーとして業務部門をリードしていき、ビジネスを進化・発展させていくことが望まれます。
【エンジニアがビジネスリーダーをめざすための10の法則】という書籍で紹介されている問題解決やビジネスを推進できるエンジニアとなるために必要な10の法則とは・・・。
オススメ読者
私は新人ITコンサルタント時代にシステム開発案件を経験し、その後、PMOやマーケティング戦略立案といったプロジェクトに参画するようになりました。
当時、プロジェクトやポジションの違いによって必要とされる心構え（マインドセット）の違いに悩んでいた時期がありました。
そのときに指針となった本の書評記事です。
ですので、同じような境遇にいるであろう方には是非とも読んでいただきたいです。
- エンジニアからITコンサルタントへのキャリアチェンジを目指す方
- 上司からの指示を受けているだけの自分から脱却したい方
- 企業や部署を変革したいと考えている方
通常、システム開発は様々なスペシャリストがチームを組んで行います。
エンジニアやプログラマという職業は、そのチームの中で自分の役割をしっかりと守っていきます。
バグを生み出さないように、丁寧で論理的で、良くも悪くも保守的な仕事スタイルとなりがちです。
その結果として、様々な関係者（主にビジネスサイドと呼ばれる経営企画や営業、業務部の人間）とプロジェクトマネージャーやITコンサルタントとしてビジネス視点を備えて折衝するようになったときに、ギャップに苦しむのでしょう。
著者
著者は株式会社ベイカレント・コンサルティングに勤めるコンサルタントの方々です。
デジタル分野の案件に強いようで、DXの一環としてシステム開発を行うエンジニアやプログラマ、もしくは出身のITコンサルタントが多いのでしょう。
著者の中にもエンジニアとしてキャリアをスタートさせている方がいらっしゃいますね。
以下の記事でもまとめていますが、ベイカレント・コンサルティングは2020年・2021年の2年連続で「ホワイト500」にも選出された日系の総合コンサルティングファームです。
目次
目次には章構成ではなく、10の法則が並べられています。
- 法則01 Googleに答えを求めるな
- 法則02 右脳を叩き起こせ
- 法則03 仮説で語りきれ。非難を恐れるな
- 法則04 プロセス志向から抜け出せ
- 法則05 不正確への恐怖に打ち克て
- 法則06 変更アレルギーを治療せよ
- 法則07 パソコンを閉じろ。クライアントに会いに行け
- 法則08 自分の事を話すな
- 法則09 守りから攻めへ転じよ
- 法則10 自分の母親にもわかる言葉で話せ
書籍概要
エンジニアとビジネスリーダーがマネジメント層と展開する会話を元に両者の違いを例示しています。
注意が必要なのは、あくまでこの本は、技術畑の人間が経営層・マネジメント層と会話をするうえでの異文化コミュニケーションを解消することを目的としています。
エンジニアの方や技術畑の方が行っているコミュニケーンに対する評価ではなく、異文化コミュニケーションを例示しているということを前項として読み進めてください。
日本語しか話せない日本人が外国人とコミュニケーションを取る際も、 単純に単語や文法を覚えて会話をしても、文化の違いで意思疎通が表面上のものになってしまうのと同じです。
ですので、エンジニアの方が開発チームのリーダーやプロジェクトマネージャーと会話するというシーンにおいては、むしろ適さない会話例が記載されている部分もあると思います。
私がエンジニアの役割を担っていた頃も思い出して、心に大きく残った2つの要素をご紹介します。
仮説ベースで「解くべき問い」を設定し、修正を繰り返す
私もマーケティング戦略やプロモーション施策を検討する際に、ついつい細かい技術的な観点での制約や目的を据えない数字（KPI）を考えてしまいがちです。
ですが、経営課題・事業課題を議論していく際には「そもそも、解くべき問い」は何かということを議論して設定していくことが必要です。
そのためにはネットに転がる情報やフレームワークを元にして整理していくのではなく、自分で考えて直面している課題や見えていない課題を類推して構造化することが重要です。
システム開発を行っていると直面する課題（実装上の不明点やバグなど）に対する解決策は、ネットに転がっていたり先輩エンジニアが解決策を知っていることが往々にしてあるでしょう。
誰かが同じ技術を使ってシステム開発をしているのであれば、誰かが答えを知っているのです。
一方で、経営課題・事業課題についてはビジネス環境が日々変化することもあり、唯一無二の正解があるわけではありません。
| システム開発課題 | 誰かが答えを知っている可能性が高い |
| 経営課題・事業課題 | そもそもとして「解くべき問い」は何か（絶対的な解は存在しない） |
この点が大きなギャップとして、エンジニアからビジネスリーダーへのキャリアチェンジの際に立ちはだかるでしょう。
目的志向で具体的アクションまでをプランニング
プログラミングを仕事の中心としていた方の場合、要件や設計については上級エンジニアが定めています。
その内容に沿ってプログラミングを行うことが「正しい在り方」となり、逸脱することは要件や設計を無視した実装・バグとなってしまいます。
ここでもカルチャーショックが発生します。
ビジネスリーダーを志すのであれば、自らがクライアントの目的達成に寄与するアクションをプランニングして、時にはPDCAを回して、修正をしながらプロジェクトを牽引していかなければなりません。
具体的なアクションとしてWBSが切られて、WBSの通りに開発やテストを行うというスタンスから、プロジェクトの目的と照らし合わせて最適なWBSを設定していくスタンスへの転換が求められます。
ましてや、ITコンサルタントとして多忙なプロジェクトマネージャーのブレインとして意思決定支援を行ったり、情報収集や調整を行うのであれば、指示を受けていたのでは仕事が前に進みません。
プロジェクトマネージャー側でも何をどうしたら良いのか検討が付いていない場合もあるのです。
そのようなときに、例え少し遠回りなやり方だったとしても「たたき台」としてのアクションプランを提示されると思考が一気に働きだすことがあります。
失敗や批判を恐れずに、意思表明をすることが大事なのです。
最後に
もしもあなたが、ITコンサルタントに転職をしたけれど、エンジニアとしての経験と大きなギャップを感じて苦しんでいるのであれば、【エンジニアがビジネスリーダーをめざすための10の法則】を読んで、ビジネスサイドの考えを備えたビジネスリーダーを目指してください。
現在のあなたがエンジニアとして活躍をされていて、ITコンサルタントへのキャリアチェンジを考えているのであれば、【エンジニアがビジネスリーダーをめざすための10の法則】を読んで異文化体験をしてみるのも良いかもしれませんね。
コンサル業界への転職を目指すなら、コンサル業界特化の転職エージェントであるアクシスコンサルティングに相談ｓれることをオススメします！
以下の記事で転職相談をした体験記事を載せているので、ぜひご覧ください！
今回、筆者「きつね」が実際に読んだオススメの本をご紹介させていただきました。
他にもコンサルタントとして多くの本を読んだなかで、「これは必読！」と感じた本を厳選した紹介記事も書いています！
ぜひよろしくお願いいたします！
