デス・マーチ or リビング・トーチ？(3)
～Which one do you like, death march or living torch?～
デス・マーチとリビング・トーチ、どっちにしますか？
前回は、経験のない新人コンサルタントがドキュメントのレビューでしごかれる様子を紹介しました。では、ある程度経験を積んだIT技術者から転身した人であればどうなるでしょうか？
◆IT技術者出身者のドキュメントは通用するのか？
システム開発の活動の中でドキュメント作成は非常に重要な作業です。お客様の要件を間違いなく実現することのできるシステムを構築するには、要求や設計を緻密で正確にドキュメントに残す必要があります。
その意味で、経験を積んだIT技術者はドキュメントの作成について決して素人ではありません。ドキュメント作成には自信があるというIT技術者も多いことでしょう。こうしたシステム開発のドキュメント作成の経験が十分ある人がコンサルタントに転身したことを考えましょう。彼のドキュメント作成スキルはどの程度通用するのでしょうか？
結論から言うと、まず通用しないと考えて下さい。自分流で作った資料を、そのままコンサルタント慣れした顧客に持っていこうものなら、リビング・トーチを起こして火だるまになるのは確実です。残念ですが、大抵の場合これがIT技術者からの転身者が直面する現実です。
肉食の世界で「焼かれる」IT技術者
◆コンサルティングで作るドキュメントは別物
筆者の所属しているウルシステムズでは、ITコンサルタントの候補として、経験豊富で優秀なIT技術者を多数採用しています。しかし、入社当初からコンサルティングの成果物に採用できるだけのドキュメントを作ることのできた人は数えるほどしかいません。その数名の例外は、前職でコンサルタント会社出身の上司にしごかれた経験があるといった特殊な事情がある人達でした。
IT技術者に作成してもらったドキュメントは、大抵は赤入れされて真っ赤になることすらありません。不採用です。その理由は、2つあります。ひとつはシステム開発とコンサルティングではドキュメントに求められる要件が全く違うということです。もうひとつは、やはりレビューの厳しさの違いです。
◇ドキュメントの目的が違う
システム開発で主に作成する要件定義書や設計書で最も重要なことは、正しい内容が漏れなく正確に記述されていることです。もちろん、読める日本語でなければなりません。ところが、コンサルティング活動で作成するドキュメントには、これら以上に大切なことがあります。コンサルティングで作成するドキュメントは、最終的に説得力のある提言や報告をするためのものです。そのため、記述している内容に論理的な主張が含まれていて、それに説得力があるということが重要になります。
技術者の書いたドキュメントで、必ずといっていいほどレビューの際に指摘されるのは、『So What？』です。『だから何？』という意味です。これは、ドキュメントから主張が読み取れないということから、このコメントがなされます。
◇レビューの厳しさが違う
システム開発において、最終成果物はなんと言っても動くシステムになります。いくら要求仕様書や提案書は重要といっても、つまりは中間成果物です。
ところが、コンサルティングの場合には、ドキュメントこそが最終成果物であり、活動内容はその出来で判断されてしまいます。そして、顧客にはドキュメントを読む義務はありません。システム開発の場合、設計書が読みにくいからと行って、良く読まずにシステムを作った場合には、読まない方が悪いといえます。
しかし、コンサルティングの成果物が読みにくいものであれば、読んでもらえず、訴求したいことが伝わりません。それは、コンサルティングの失敗を意味します。このため、顧客にしっかり内容が伝わるように、徹底的にレビューして読みやすさや見栄えまで含めてしっかりと仕上げていく必要があるのです。
1つのドキュメントに対するレビューを繰り返しても、なかなか品質は向上しませんが、ドキュメントを作成する度にレビューを受けていれば、確実にドキュメント作成スキルは向上していきます。顧客がどういう視点でドキュメントを読むのかがわかってくるので、顧客に訴求しやすいドキュメントをどう作れば良いかがわかってくるからです。これまで、筆者がお会いしてきたシステム開発の技術者の場合、内容の技術的な正しさについてのレビューは厳しく受けたことがあっても、コンサルティング会社で行われているような、顧客視点からのレビューを徹底的に受けてきた人はほとんどいませんでした。
◆IT技術者出身コンサルタントの試練
◇コンサルタントに必要な2種類のスキル
第1回で、筆者はコンサルティングの定義として、「専門知識を使って顧客の抱える課題の解決を支援する仕事」としました。これを踏まえると、コンサルタントに必要なスキルは、2種類のものに分けられます。ひとつは専門知識です。もうひとつが、顧客の抱える課題の解決を支援する力でこれをコンサルティングの基礎スキルと呼ぶことにします。
専門知識としては、特定の業界のビジネスについての知識、効率的な業務を設計するための知識、システム開発を円滑に進めるプロジェクト管理の知識、品質の高いシステムを作るための技術知識などがあります。コンサルティングの基礎スキルとしては、これまで紹介してきたドキュメントの作成もそのひとつです。その他に論理を組み立てたり、インタビュー結果を分析をしたり、顧客と合意形成をしたりするスキルが含まれます。これら2種類のスキルがあってこそ、顧客から対価をもらえる一人前のコンサルタントとして働くことができます。逆にどちらが欠けていても一人前のコンサルタントとはいえません。
コンサルティングに必要な2種類のスキル
◇半人前のコンサルタントに歯が立たない情けなさ
新卒からコンサルティング会社に入社した生え抜きのコンサルタントと他の業種出身のコンサルタントでは、スキル習得の順番が異なります。IT技術者がコンサルタントに転身した場合、このスキル習得順序の違いのために気の毒な事故が起きることがあります。
新卒でコンサルティング会社に入社すると、まずはコンサルティングの基礎スキルを叩き込まれながら、会わせて少しずつ専門知識を身に付けていくことになります。逆に、他業種の出身者の場合はその分野での専門知識を十分高めた上で、コンサルティングの基礎スキルを身に付けるという順序になります。つまり順序が逆になります。
最初からコンサルティング基礎スキルを厳しく叩き込まれた生え抜きのコンサルタントが、途中入社してきたIT技術者出身のコンサルタントの作成した資料を見ると、『話にならない』という印象を受けます。
十分な技術知見もあるコンサルタントであればIT技術者出身者の書いた内容を理解して、コンサルティングドキュメントに十分なものに組み立て直すところまでできるのですが、若手ではなかなかそこまでは達しないものです。そのため、会社によっては、それまで自分が受けてきた罵倒系、嘲笑系のコメントをぶつけるという事態が発生することがあるのです。
当然IT技術者出身者の方は、『ちょっときれいな資料が作れるだけで、技術知識は素人同然のくせに偉そうな』という不満を持つことになります。どちらも片方のスキルが欠けている一人前とはいえない同士のレベルの低い争いですが、コンサルティング会社の中ではやはり、肉食の世界になじんだ生え抜きのコンサルタントに分があります。
非常に高いレベルのITの専門知識を持っていても、基礎スキルが不足していれば、半人前のレベルのコンサルタントにも簡単にやりこめられてしまいます。IT技術者からの転身者は、コンサルティングの基礎スキルが身につくまでの間、この『レベルは低いけれどフラストレーションのたまるリビング・トーチ』にさらされることがあります。
生意気に肉食
◆乗り越えなければならない壁
これまで数回にわたってコンサルタントが直面するリビング・トーチの修羅場について紹介してきました。ただし、このような修羅場があるのは別にコンサルタントに限った話ではありません。
システム開発のプロジェクトマネージャも、トラブルを起こしているプロジェクトの説明を行うようなときには、顧客からは猛烈に叩かれ、部下からは突き上げられ、会社からはプレッシャーを受けて、まさに四面楚歌のリビング・トーチを経験します。締め切りまでにコンテンツを仕上げるような仕事であれば、直前に徹夜が続くのは珍しいことではありませんし、それが顧客の意に沿わなければ当然厳しいコメントをもらいます。
デザインなどの感覚の要素が強いものになれば、納得感が得られないときの対応に頭を抱えることになります。企画系の仕事では、プロモーションなどで上司や顧客からなかなかゴーの指示がでなくて、色々な指示を受けて振り回され、大変な目にあうことはよくあります。怒鳴ったり机を叩いたりするマネージャや経営者はどこにでもいます。営業部門であれば、成果を出せないときに罵倒されるのは日常茶飯事です。
一方、コンサルタントがこうした他の職業よりも、一層厳しいプレッシャーを受ける可能性が高いという側面もあります。それは、高い単価でのサービスを提供していることに起因します。高い単価には、それに見合うだけのバリューを要求されます。普通に解決できるような問題なら、別にコンサルタントにお願いする必要はないからです。コンサルタントを目指す方には、高いサービス単価を魅力に感じる人も多いと思いますが、それに見合う非常に高い期待と、その裏返しで非常に強いプレッシャーを受ける仕事だという覚悟は必要です。
筆者には、『だからコンサルタントを目指すIT技術者は考え直そう』と言うつもりはありません。コンサルティングの仕事は、顧客の悩みを解決するという非常にやり甲斐のある仕事です。腕に覚えのあるIT技術者にはぜひチャレンジしてもらいたいと思います。しかし、良いところだけ見ていては落とし穴にはまります。一人前のコンサルタントとして活躍できるようになるためには、乗り越えなければならない壁もあるのです。
この壁をどう考えて、どう乗り越えればよいのかについての筆者の考えは、次回以降に示していきたいと思います。
コメント
ビガー
ビガーです。
非常に共感する内容なのですが、
>筆者には、『だからコンサルタントを目指すIT技術者は考え直そう』と言うつもりはありません
私は、上記の「考え直そう」云いたいと捉えてしまいました。
たぶん、見込みのある人に絞りたいなどの背景はあるとは思いますが。
次回以降、どういう壁があってそれをどう処理するのかをお伝えいただけると思うのですが、コンサルティングに必要なメンタル的な熱意やコンサルタント自身のやりがい(基盤の高度な設計実装スキルが学べるなど)もいただけると個人的に参考になるのでうれしいと感じました。
ぶっちゃけ(汚い言葉ですいません)コンサルティングだけの魅力、個人的には理解できていません。結局モノを提供するトータルサービスに価値があると思うからです。
林
ビガーさん、
林です。いつもコメントありがとうございます。
> 私は、上記の「考え直そう」云いたいと捉えてしまいました。
突き詰めていくと主張にそれほどの違いはないのですが、私が考え直そうと言いたいのは、むしろコンサルタントに期待する役割のほうです。
価値があるかどうかは、そのサービスにお金を払う顧客がいるかどうかで決まると考えています。はたからみて意味がなさそうであったとしても、きっと存在意義は何かあるのです。
しかし、前回の議論でもあったような、構築するITの方向性を決めるところまでで去ってしまい、その実現まで責任を持ってくれないタイプのコンサルティングを、今から目指すのは止めたほうがよいかもしれません。なにせこのご時世ですし、これまでの学習効果もあるので、そこに高いお金を払う会社は少なくなるでしょうから。
一方で、ユーザ企業がSI会社との関係だけで、満足できるITを構築できているかというとそうは思えません。ここをどうにかするための枠組みの必要性は高まっているのではないでしょうか。両者を第三者的に媒介するコンサルティングというのは、そのひとつになり得ると私は考えています。まだ、認知度は低いのですがこの責務を担うコンサルタントならば、高度なIT知識を持つエンジニアが目指す価値があるのではないかと思っています。
コンサルティングを目指す壁をどう乗り越えるのかについては、次回から私の(いくぶん過激な)主張を展開していきたいと思います。