ITエンジニアの力の差はどこにある?

本誌をご覧のみなさんは、これまで多くの開発現場を経験する中で、どこへ行ってもひっぱりだこになっているITエンジニアがいることにお気づきだと思います。ITエンジニアになって何年か経つと、システムエンジニアやプロジェクトマネージャーとしての貢献が求められるようになってきます。そのころになると、力量に大きな差が出てきます。

優れたシステムエンジニア / プロジェクトマネージャーは何が違うのか、考えたことありますか?

優れたシステムエンジニアやプロジェクトマネージャーが引っ張りだこである理由は明らかです。それは、彼らがプロジェクトを成功に導けるからです。では、その力量の差は何で、どうすれば身につけることができるのでしょうか?

ITエンジニアの力量の差には様々なものがあります。もちろん、技術スキルはその中でも最も重要な不可欠のものですが、場合によってはそれ以上に重要になるスキルがあります。

それは、顧客との関係構築や、ビジネスの目的を理解した仕様の提案、チームメンバーの管理などのスキルです。これらのスキルは、技術スキルとは別のヒューマンスキルやマネジメントスキルに相当するものですが、これらの有無によってプロジェクトの成功が左右されるのです。

彼らは自然とコンサルティングテクニックを使っている

実は、優れたシステムエンジニアやプロジェクトマネージャーは、顧客との関係構築や、ビジネス目的を理解した仕様の提案、チームメンバーの管理のような仕事を行うときに、意識している / していないに関わらず、コンサルティングのテクニックを利用しています。彼らはコンサルティングのテクニックを使って、顧客の満足度やチームのパフォーマンスを最大化しているのです。

筆者は現在、ユーザー企業に入ってIT企画やシステム開発のコンサルティングやプロジェクト推進の支援を行なったり、新規ビジネスや業務刷新のための先端的システム開発を行ったりするITコンサルティング会社に所属しています。もともとはユーザー企業の情報システム部門にいて、そこからITエンジニアとしてキャリアをスタートさせ、そのあとシステム開発会社で10年以上、システムエンジニアやプロジェクトマネージャーとして活動してきました。

振り返ると顧客との関係構築やチームメンバーの管理などでは毎回苦労をしていました。その当時は、しゃにむにやっていただけで、そこにノウハウやテクニックがあることなど考えもしませんでした。

どちらかというと時間があれば、顧客とコミュニケーションを取るために、技術書や業務マニュアルに関する知識を深めることばかりを考えていました。しかしながら、現在の会社に移り、ITコンサルタントの立場で多くのプロジェクトに携わってきて、顧客との関係構築やチームメンバーの管理にもノウハウやテクニックがあるということを学びました。

コンサルティングテクニックの具体例

今回は、できるITエンジニアが、システム開発で使っているコンサルティングのテクニックとはどのようなものなのかについてお話します。

皆さんの中には、ロジカルシンキングという言葉を聞いたことがある人がいるかもしれません。このロジカルシンキングも、できるITエンジニアが使っているコンサルティングテクニックのひとつです。

ロジカルシンキングは、外資系の戦略コンサルタントによって紹介されている手法で、解説書も多数出版されています。その中では、MECE(ミーシー)やロジックツリー、仮説検証、フレームワークとかいった方法が、経営上の問題解決や戦略立案のためのテクニックとして紹介されています。こうした本を読んで、これらは上流のコンサルタントが使うテクニックであって、システム開発の現場ではあまり関係ないという理解をされているかもしれません。

しかし、これらは開発進捗の報告、プログラム不具合の修正、打ち合わせ資料の作成、顧客への説明など、システム開発のあらゆる工程で日常的に行われるコミュニケーションでも活用することのできるテクニックなのです。

顧客の信用を失うマズイ例

例を使って解説します。例えば、顧客に対して次のような事情を説明することを考えてみましょう。

技術チームから、現状の設計通りに進めるとレスポンスの低下が懸念される、という報告が入っています。

これは単に技術チームから報告を受けたという事実を説明しています。このまま、顧客に伝えるとどうなるでしょうか? 「それは最終的に性能が出ないということですか?」、「設計をやり直すということですか?」、「手戻りが発生するから遅れるということですか?」、「いったい何が言いたいんですか?」と質問攻めをされることになります。

ちょっと言い方を変えて、次のように報告するとどうなるでしょうか?

技術チームから、現状の設計通りに進めるとレスポンスの低下が懸念される、という報告が入っていますが、今回は手を打たずに進めることにします。

今度はきっと、「それで本当に大丈夫なのか?」、「どうして手を打たなくてもいいんだ?」、「理由を説明してくれ」といった質問を受けるでしょう。こうなると、顧客からの信頼はどんどん低くなって「報告も満足にできない奴」というレッテルを貼られてしまいます。

「SoWhat? / WhySo?」を使うと、このように改善

ここで使えるのがロジカルシンキングのテクニックのひとつである「SoWhat? / WhySo?」です。

このテクニックは、コンサルタントが何かを主張するときに使用するものです。具体的には、「その主張の行く着く先は何になるのだ(SoWhat)」とか、「なぜそういう主張になるのか(WhySo)」ということについて繰り返し仮説を練り上げ、考えをまとめていきます。

実は顧客への説明にもこの手法が使えます。何か顧客へ報告をしようとする際に、その報告内容について報告した結果、「何をしてもらいたいのか(SoWhat)」、「なぜそう考えるのか(WhySo)」ということを自問することによって、顧客が気にする点や顧客の反応をいろいろな角度からシミュレーションすることができます。例えば、上の例でも顧客に質問攻めにあう前に「SoWhat?」と自問することで、報告の仕方を変えていくことができます。

技術チームから、現状の設計通りに進めるとレスポンスの低下が懸念される、という報告が入っています。しかし、現在の要件下では、このレスポンス低下が生じるケースというのは非常に希なものです。設計をやり直すことで遅延を招くのを避けるため、このままの方針で進める方が賢明です。ただし、将来のシステム拡張を検討する際には重要になるので、システムの制約として明確化しておくことにしましょう。

このように整理をした上で報告をすると、顧客から「このITエンジニアはいろいろ考えている」と信頼を得ることに繋がります。

"できるエンジニア"へ、遠回りしないために

ここまでを読んで、「なんだ、このくらいのことはこれまでの経験から気を付けるようにしているよ」と思われた方もいるかもしれません。上で説明したように、できるITエンジニアは、こういったコンサルティングのテクニックを無意識に使っているので、当然かもしれません。

顧客の気にする点について先回りして考えておく必要があるということを分かっていて、「こう説明したら顧客はどう反応するか(SoWhat)」、「どう説明すれば顧客は納得してくれるか(WhySo)」について考えているので、自然と対応できているわけです。

経験で身に付くのを待っていては遠回り。そのテクニックを学び、一足早く上のステージへ行きましょう

「どうせ経験から身につくのであれば、学ぶ必要はないのではないか」と思われる方もいるかもしれません。しかし、それでは非効率です。

ロジカルシンキングに代表されるコンサルタントのテクニックは、結局は実践を通した経験の中で作られたノウハウをまとめたものです。だからと言って、皆さんも同じように経験を通じて蓄積していくというのは遠回りです。システム開発のスピードがどんどん上がっている現在では、これらのスキルを意図的に早く身に付けていくことが重要になります。

本シリーズでは、筆者と同じようにシステム開発の現場で活躍しているコンサルタントから、現場で使えるビジネススキルを紹介してもらいます。ロジカルシンキングのように一般的になっているものもあれば、そうでないその人独自のテクニックもあります。

最初のテーマには「コミュニケーションスキル」を選びました。同スキルに関わるテクニックを、筆者をはじめとした8~10名のコンサルタントにより連載形式で解説していきます。その後も、タイムマネージメントやリレーションシップといったビジネススキルを新たな連載で解説していく予定です。

ITエンジニアという職務を全うするうえでは、システム企画、要件定義、システム開発、運用保守といった全ての領域で、多くのステークホルダーと考えがぶつかります。もちろん、その都度合意形成を得ていかなければなりません。こういった活動のためにどのようなコミュニケーションスキルが必要なのかについて次回以降ご紹介していきたいと思います。

(イラスト ナバタメ・カズタカ)

執筆者紹介

小林博(KOBAYASHI HIROSHI)
- ウルシステムズ コンサルティング第1事業部 シニアコンサルタント


ユーザー企業の情報システム部、開発会社を経て、2006年より現職。企業内システムの全体最適化や基幹システムリプレースなどの大規模ITプロジェクトのプロジェクトマネジメントに関するコンサルティングに多く携わる。IT企画や要件定義、システム開発の領域でユーザー、情シス部員、開発者の3者がプロジェクトに積極的に参画するためのコミュニケーション方法や開発プロセスの構築を目指している。