あくまで個人的な意見です。仕事仲間にはまったく別のことを考えている人もいますし、自分達の仕事のすべてを以下の要素で説明できるわけではありません。最近この説明しきれない部分についても考え始めたことがあるので、後日機会があればそれもご紹介したいと思います。（そんなことばかり書いている気もする）
今回ここにまとめる内容は、新卒2ヶ月目くらいの時に自分なりに整理した内容がほとんどなので、その程度の薄っぺらさだと思って頂けると幸いです。でもまだ自分の子供たち（小学校3年と1年）にうまく説明できるところまでシンプルにもなっていないのですが･･･
意識は高くなくとも
ざっくりとコンサルタント、それも外資系出身、と言われた時、どのような人物像が想像されるでしょうか？ 英語が喋れて、切れ者で、メンタルが強くて、ハードワーカーで、向上心に溢れている、なんてところでしょうか。いわゆる意識高い系という言葉に付随する揶揄のニュアンスや、押しが強くて近づき難い感じとか、抜け目なさそうなところとか、拝金主義的なイメージもあるかもしれません。あとは、頭が良いアピールがうざいとか。概ね正しい気もするのですが、（他の多くの職業と同じく）全部が全部そのイメージ通りでもなく、実際には色々な人がいます。例えば私の場合は、英語はIT絡みならなんとか、切れ者に見えるかどうかはともかく、メンタルは弱いし、ハードには働けないし、知識欲はあっても向上心は半端です。意識はさほど高くないと言えるでしょう。（頭が良いアピールには余念が無い方だと思いますが）
そんな私であっても、十数年も続けていればコンサルティングサービスに対する一家言と言いますか、地味は地味なりに職業倫理みたいなものを抱えていてもおかしくはありません。ということで、今日はそういう話。
よくある説明
私が新卒の頃も、コンサルティングには個人の知識や経験を売るグレイヘアードのコンサルティングとファームに所属してチームによる組織力で問題解決を図るコンサルティングがある、だとか、戦略系・会計系・人事系などのファームの色やサービス領域による分類などはよく語られていました。ITに絡むところだと、多重下請け構造のトップに「プログラマ」「システムエンジニア」の上に君臨するポジションとして「コンサルタント」と書かれていたりもします。ITに絡むところと、絡まないところでは、「コンサルタント」の定義や位置づけは変わるのでしょうか？
プログラマはプログラムを書き、システムエンジニアは仕様書を書きます。「コンサルタント」は？ 要件定義書？ RFP？
「プログラマ」と「システムエンジニア」は（下請け構造があるにせよ）顧客からみると商流上同じ会社の下に入っていることが多いのに対し、コンサルタントはそうでない場合がままある（というかその方が多い？）ので、それが違いだという説明もあります。
何故そうなるのか。企業のとるアクションを意思決定から遂行に川の様に流れるものとして見た場合、上流の方があいまいでリスクが高い領域であると考えられます。そこで、そこを担当するコンサルタントがより顧客に寄り添ったポジションにいたり、リスクを見込んで高単価であったりというようなことも考えられそうです。また、あいまいさが大きくなればなるほど、ITに絡まないコンサルティングで求められているとの共通点が色々と見えてくるということもあります。
以上のことから、私は個人的にも「エンジニア（システムエンジニアおよびプログラマ）は最終成果物として動くものを納品するという責任の取り方がある。コンサルタントの仕事にはそれがない」という話をよくしています。
では何を売っているのか
リスクがある領域で勝負しているから単価が高い。というのは、コンサルティングの仕事の性質をある程度反映した説明であると思います。ただこれは、その仕事、働き方を選択する人間の側からの説明であって、顧客が高いお金を払う理由にはなりません。果たして我々はどんな価値を提供しているのか。意識高くないコンサルタントとしては、卓越した問題解決能力みたいなことはあまり言いたくありません。恥ずかしいので。では、何を売りとしているのか。私は、第一にお客様のプロジェクトの成功確率を上げる（リスクを低減する）ことだと考えています。
どのような企業にも通常業務と呼ばれる仕事、収益を上げるための活動があります。ルーチンワークと言っても良いかもしれません。そして、基本的にその作業量はその組織に所属するメンバー全員の稼働の限界に近いところで回っていることがほとんどです。そのため、例えば法律が変わったとか、新しい事業を始めたいが社内に適切な経験をもった人材がいないとか、競合会社の新戦略に対抗する施策を打ちたいとか、っていうことを考えたときに、落ち着いてそれら問題に対応できるだけの人的な余裕がないわけです。（その種のピーク時にあわせた雇用をしてしまうと、通常時に収益性が落ち込むことになります）
そこで、それらの本来の業務ではない仕事をプロジェクトとして、期限付きの仕事として定義し実行します。このプロジェクトのチームに参画し、その成功確率を上げることがコンサルタントの主要な価値である、というのが私の主張です。
注）もちろんそれだけがコンサルタントの価値であるわけではありません。知識・経験に十分な市場価値があり、それを展開していく形で活躍されている方もたくさんいらっしゃいますし、問題解決力に特化して「考えること」の価値をマネタイズできているプレイヤーもいます。
プロジェクトの成功確率と論理的思考力
通常論理的思考力というのは、問題解決力あたりと関連付けて語られることが多い「能力」だと思います。しかし、実際にはブレイクスルーを起こすために求められる思考であるとか、イノベーションに繋がる発想だとかというものは、それほど純粋に論理的なものではないように思います。（論理と感性のバランスが必要、というような話は右脳左脳と結びつけてあちこちで語られています。右脳左脳の論に非常に強い抵抗を感じることもあり、ここでは詳細は割愛します）思いついたことを、他の人にも理解できるように形にしていく過程においてはもちろん論理的な思考が必要とされるでしょうが、突破力のあるアイディアを引き出すまでの過程は必ずしも論理的であるとはいえないでしょう。（そもそも論理的である必要がありません）
ではなぜ、世の中ではコンサルタントには論理的な思考力が必要とされているのでしょうか？
論理的な思考とは、同じ前提条件を並べられれば同じ結論を導ける、ということを保証するものだと、私は考えます。プロジェクトワークは、多くの不慣れな、あるいは、不完全な意思決定の積み上げによって行われます。作業を進めていく中で新たな事実が判明し、それまでの作業が無駄になる、ということも珍しくはありません。（それをミニマイズするための仕事の進め方を方法論という形でまとめ、活用することも大事ですが、ゼロにはなりません）
いわゆる「手戻り」の発生です。その時その時の影響範囲にもよりますが、手戻りが発生したからといって、毎回その時点まですべての作業を巻き戻していては到底スケジュール通りに成果を上げることはできませし、何より、手戻りの発生はメンバーに混乱をもたらします。誰の責任でこの手戻りが発生したのか、という犯人探し（個人的には、そういうのは犯人探しではなくて、魔女裁判の類だと思いますが）が始まってチームが瓦解しかねません。
だからこそ、各意思決定の時点で、どういう前提条件が見えているのかを把握し、その上で選んだ結論であるということを意識し、記録に残すことが重要になります。後で手戻りが発生するというのは、その前提条件に間違いや不足があったからであり、そこが変化したら結論がどう変わるべきかもクリアに見通せるようになります。こまめにセーブをすると被害が大きくなりづらい、ということですね。
この、細かい意思決定の積み上げ時の前提条件の確認・把握と、その記録というのは、あまり華々しい前向きの仕事ではありません。インタビュー時に会議の勢いを削ぐかもしれないような細かい質問をし、確認を求め、議事録などの文書に残し、関係者の意識から漏れないように注意を払う、というような地味な作業によって成り立ちます。こうしたセーフティネット的な作業をどれだけ、勢いを殺さずに実施できるか、必要十分なレベルをキープできるか、というのはプロジェクト慣れと同時に、前提条件と結論の論理的な関係を見失わない能力がダイレクトに求められる領域なわけです。
だからこそ、コンサルタントには論理的思考力が求められる。これが、意識の低いコンサルタントが論理的思考力を馬鹿にできない理由です。
本当はソースコード管理と継続的インテグレーションみたいな話と結び付けたいところなんですが、ちょっと話が散らかってしまったので、続きはまた今度。（本当にこんなことばかり書いている）
（文責 石井昭紀）
