いきなりコンサルタントに抜擢されたSEが読むべき5冊

　上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。

• システム開発チームのメンバーまたはリーダー
• 顧客の御用聞きを「コンサルティング」だと思っている　←これ誤り
• McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった

　これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。

■最初に結論

　コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持っているだけでなく、そうした手法を馬鹿正直にあてはめている（←これ重要）。きれいなプレゼンや立て板に水の弁舌は、おまけに過ぎない。

　問題へのアプローチも決まっている。こんなときはこう調べろ、考えろ、といったパターンは決まっており、あとはいかに適用・加工するだけ。数学のチャート式解法やった人ならピンとくるかもしれない。あの「例題」が彼らの後ろに控えているイメージ。壁にあたったら振り向けばいい。

　こうやって書くと簡単そうだが、その手法を適用することがとっても大変。現実はあやふやで、姿を変えてしまうもの。だからこそ、手法を厳密に適用し、ロジカルに仮説を立てなければならない。なぜなら、その説が見込み違いだったときに、状況が変わったからなのか、間違った手法を採択したのか、分からなくなるから。

■いきなり「コンサルタント」になったSEの場合

　いきなり「コンサルタント」の肩書を貼り付けられたSEは、そんなこと知らない。そもそも、問題にアプローチするための「手法」があったり、仮説を考え抜くための決まった「思考様式」があるなんて、思いも及ばない。

　だから、自分がこれまで重ねてきた経験に基づく思考・調査方法を使おうとする。うまくいくかどうかはバクチのようなもの。もっと悪いことに、そのやり方で失敗したのかうまくいっているのか、チェックしてフィードバックする方法が分からない。

　そのいっぽう、一緒に仕事するコンサルティング・ファームの人は、問題解決・構想設定の修羅場を幾度も潜っており、「キャリアを積む現場のひとつ」として取り組むだろう。彼らに伍することは不可能なので無理をするのは止めよう。

　その代わりに、彼らの手法を自分のミッションに適用するための予習をしておく。「いきなりコンサルタント」にされるようなSEは、経営戦略課題のうち、ITシステム化の前提条件と効果・リスクをアセスメントするような役回りだろう。その仕事＋コンサル手法を彼らから盗み出すために、役に立つ書籍をご紹介。

■まず基本「問題解決プロフェッショナル――思考と技術」

　基本。コンサルテイング会社の中の人は、「問題」に対してどのようにアプローチしているかが手に取るように分かる。実は、「問題」を与えられて「解決策」を考えるなんて思いつきでだってできる。しかし、与えられた問題を「検証」し、その原因への調査→仮説思考をくり返し、対策の有効度までロジカルに導き出すには、相当の訓練が必要。本書では、その基本的なツールが紹介されている。

• ゼロベース思考
• 仮説思考
• MECE
• ロジックツリー
• ソリューション・システム

　名前だけは有名だし、「ロジカルシンキング入門」と銘打った雑誌やネットの紹介記事はあるが、読んでもイマイチ使える気にならない―― なぜか?

　それは、そうした書き手が本で知った「ロジシン」の要旨を書いているから。そいういう記者は実務でやったことのないため、いつまでたっても「入門」から抜け出せない。本書を読めばこれらのツールを身につけることができる。時間がない方なら、特に2章の「MECE」と「ロジックツリー」だけを押さえておくだけでも劇的にモノにすることができる。読めばすぐに使いたくなるだろう（←これ重要）。姉妹本の「問題発見プロフェッショナル――構想力と分析力」まで読みこめば鬼棒だろうが、まずこの道具を使いこなせるように。

■書くこと＝考えること「考える技術・書く技術」

　ロジカルな文章とは、「理屈っぽい文章」ではない。むしろ「納得しやすい」「入りやすい」文章のことをいう。フレームワークはシンプルで、テーマの深度は抽象→具象の順番に進み、トピックの幅は「A and B and ...」あるいは「A or B or ...」でモレダブリは排除されている。

　つまり、一番いいたいことは冒頭で言い尽くされており、各トピックで具体化・詳細化される。それぞれのトピックの中も、「主張・結論」→「それを支える仮説・事実」の構成となっている。さらに、同階層のトピックは「部分-全体」を成している。

　読む方もラクだ。「要するに何?」はドキュメントの冒頭を読めば分かるし、論点はそれぞれパラグラフごとに柱を成している―― これも言うは易しというやつで、実際に書くとなると難しいもの…では、方法はないのかというと、ある。それが本書で示されている「ピラミッド原則」。何のことはない、MECEだ。それがライティングに適用されると、スゴいツールになる。

　書くことは考えることであり、適確に書けているということは、すなわち適確な思考ルートをたどって目的（ここでは主張・結論）に至っていると言える。「書く技術」「考える技術」「問題解決の技術」の三部構成となっているが、第一部が全てのエッセンスといってもいい。「考えて→書く」んじゃないの? とツッコミが入るかもしれないが、第二部の「考える技術」は、自分の思考を「ロジカルに、相手に分かるように」表出できるようになった次のレベルの話。「相手」と便宜上呼んだが、自分も含まれる。この方法で書いてみて、はじめて本当に言いたいことにたどり着いたことがあるから。

■実際は泥臭い「情報システム計画の立て方・活かし方」

　次は実践。事業戦略の策定にあたり、コンサルティング・ファームの人がどのように仕事を進めているかが全部書いてある。ダンドリ8分というが、その段取りが100パーセント紹介されている。

　「じゃぁ、そいつをコピペするだけか」というと、そうではない。ものすごーく泥臭い作業が待っている。「あるべき姿」と「いまの姿」が洗い出されていれば、後は間違い探しになるが、現実はそんなに甘くない。そもそも、

• 経営課題が把握できていない
• システム構築以外も含めた取り組みが網羅されていない
• 現実的なスケジュール感覚でプロジェクトが進められていない

何から手をつけていいか分からないところがスタート地点なので、やるべきことは分かっていても、やるべき作業は膨大かつ地味だ（←そしてこれが実態だ）。その作業を、ひとつひとつ、ひもといている。コンサルタントのマニュアルかもしれないけれど、近道ではない。

　では経営者が全く無「脳」無策なのかというと、そうではない。彼らにも「やりたいこと」「あるべき姿」があって、それを実現したいと願っている。ただ、現実に即していなかったり、即しかたも分かっていないだけだ。彼らは、コンサルタントの話を聞きたいのではなく、現実に裏打ちされた「自分の考え」を「自分で分かるように」したいんだ。したがって、経営者の考えをロジカルに展開し、予実データとともに「見える」ようにするのが最終目的。そのシミュレーションとして本書はものすごく有効なり。

　おそらく未経験者がこれを読むと、あまりの退屈さに投げ出してしまうかもしれない。しかし、それが現実だ。「MECE」や「仮説思考」を正直に愚直に展開し、ロジック（ここまでくると「つじつま」と呼んだほうがピッタリ）の整合性を完全にする。これこそがコンサルティングの本質なのだから。

■武器を増やす「組織の現場力を高める問題解決メソッド」

　実際の作業が分かった上で、今度は「武器」を増やしたい。基本装備だけでも使いこなせば充分だが、やっぱり見栄えというか訴求力を高めるために、様々な切り口を要することも現実。そのために、どんな仕掛けが必要かが分かるのが本書。

　一行目から「問題解決力は、個人のスキルではない」で始まる。強く反発するが、続く文で納得できる。スキルそのものは個人レベルで身に付けられるかもしれないが、そうしたスキルを展開し、実際に解決していくのは組織において他は無いという。確かに。

　本書は、問題解決のための「具体的手順」にとどまらず、組織のメンバーが実際に動き出す「しかけ」も併せて紹介している。道具をそろえて切りさばくのは個人スキルかもしれないが、その道具そのものを伝えるためには、個人（というか役職）の枠組みを超えた仕掛けが必要。

　その仕掛けは多岐に渡るが、まとめるなら「道具の"ねらい"と一緒に伝えよ」に尽きる。全体の中でのその手法の位置や、そもそもなぜそれを「問題」として扱うのかが明らかになる。単純に「問題解決」と言っても、本書によると、

• 発生型問題の解決 : いま見えている問題や、現実的に起きている問題のFit/Gapを解決する
• 課題設定型問題の解決 : カイゼンの視点から、ありたい姿に近づくための課題を解決する。あるいは近い将来に起きうる問題を予測し、その対策のための課題を解決する
• 構想設定型問題の解決 : 5～10年後先の組織のありたい姿や環境の変動を想定し、そことのFit/Gapを詰める

に分かれる。そして、必要な能力として3つ「問題解決力」「協働誘発力」「組織管理力」」を論じている。特に周りを巻き込むための「協働誘発力」の仕掛けが役に立った。個人の問題解決能力も、もちろん重要だが、そこから得られる策を実行し、現実に働きかけるためには、メンバーの協力が不可欠だ。

　コンサルティング・ファームが入ってくると、「ご主張ごもっとも、だがそれは経営会議の机上の空論に過ぎない」とする衝突は、必ずといっていいほど発生する。これを回避するため、例えば、「対策の"ねらい"を明示し、最終目的と連動させるようにせよ」という。この巻き込むチカラこそ、コンサルの肩書をつけたSEに必要だろう。「それはオレの仕事じゃない」と言わせない・思わせないスキル、わたしにいちばん足りないものだな。

■なぜ「コンサルタント」という肩書なのか?「RFP＆提案書作成マニュアル」

　ちょっと想像してみると、会社の意図はよく透けている。RFP→受注につなげるための嚆矢が、あなたということ。コンサルティング・ファームが作る戦略計画書には、確かに恐ろしく精緻かつ分厚なものだが、システム屋の視点からだと大穴どころか窓かドアぐらいのでかいヌケがある。

　例えば、 ハードウェア構成とその管理という概念が抜けている場合が多い。いわゆるシステムを知らないコンサルティング・ファームは、よくそういうポカミスをやる。作ればおしまいで、管理は人だけが対象だと思っている。端末・ネットワーク・サーバ・GW・UPF等は全部買うわけが無い。ランニングコストにリース料は入るし、回線もスペック見合いでえらい金額になる。

　こうした、「ランニングコストは…」「運用の現場では…」といった書き出しになるとコンサルティング・ファームは途端に弱くなる。「ケース・バイ・ケース」という無敵の捨てゼリフを打ってくるに違いない。

　いっぽう、SE出身はここから強くなる。make or buy の判断は、プロジェクトの目的に沿った形ですることや、開発期間が圧縮されればメンテナンスコストが高くつく、といったシステム屋にとってあたりまえのことが最初から議論できる。

　「コンサルタント」から「RFP書き屋」にジョブチェンジするときに強力なバイブルとなってくれるのがコレ。RFPを書く側と受ける側、即ち発注と受注の両サイドから説明されており、相手の出方がよく見える。

■コンサルタントから盗もう

　これまで指摘したとおり、コンサルタントがやっていることは「たか」が知れている。ただし、その知れている「たか」を徹底的に愚直にロジカルに掘り下げ→組上げている。論理の精緻さは凄まじいほどだ。確かに「頭の良い」人にしか続けられない仕事だとつくづく思う。

　現実から遊離していようとも、その報告書のロジックには一点の曇りもない。それを詭弁と誹るのはたやすいが、彼らの武器だけは、しっかりといただいておこう。コンサルティングの現場に入る前に、上の5冊で予習しておくと、盗める対象もぐッと広がることを請けあう。

参考
　マッキンゼーITの本質 　いきなりコンサルタントに抜擢されたSEが読むべき3冊 　いきなりコンサルタントに抜擢されたSEが読むべき4冊目