いきなりコンサルタントに抜擢されたSEが読むべき3冊
この記事のまとめ。また長文エントリごめん。“IT”コンサルじゃない、「ファーム」のコンサルタントと一緒に仕事をするハメになったら読む本。
- 「問題解決プロフェッショナル」を読めば、コンサルタントの土俵で話ができる
- SEとしての分をわきまえるなら「RFP＆提案書作成マニュアル」で準備しておく
- SEには、コンサルタントに無い視座がある。その強みを生かす「業務システムのための上流工程入門」
コンサルタントは、知識経験ないけれどキャラとハートがおおまかカバーすることはぶっちゃけありえない。そうなったらどうしようと思い悩む前にメモをどうぞ。
このblogは「それを知らなかった私にとって有益なもの」になるように心がけてる。つまり、その記事の知識・情報を知らなかったとして、「あ、こんな記事を見つけてラッキー」と思えるようなネタ。
で、この記事は一年前の私が見つけたなら「お、タイムリー」と思えるような内容 → いきなり「来週から客先でコンサルタントとして働いてもらう」と断固かつ容赦なく言われたとき、来週までに読んでおきたい3冊を挙げた。
工程を上流下流と分けるのはヘンなのだが、その言葉を使うなら水源地というか震源地。結果システム化したりするが、システムありきではない。CIOや経営層を巻き込み、そもそもそこにカネをかけようとする動機付けがミッションで、要求仕様を決める前の段階。海のものとも山のものともつかない状態。
だから、“IT”冠のなんちゃってコンサルタントではなく、McKinsey & Company のようなガチガチのファームを想定してほしい。彼らは切れ者で、おそらくあなたよりも学歴も収入も上だ。ディベートが得意で屁理屈も理屈だと言い切る。
そういう連中と伍する（というよりもついていく）ために必要な知識があるのよ。知らないと会話を成立させることすら困難。もちろん連中は丁寧に教えてくれるはずはないし、そもそも「来週コンサルタントになれ」なんて言う上司は、そんな知識が必要であるということすら知らない。
1冊目、「問題解決プロフェッショナル」、四の五の言わず読め、と断言できる。なんちゃってMECEやなんとなくHOWツリーを二度と書かなくなる。「コンサルの仕事は正解がない」と言われるが、それは「どんな解でも正しい」ではないし、「解が存在しない」という意味でもない。問題への銀の弾丸なんて無い、という意味。
問題に対し有効な解決策を導き出せ、優先すべき打ち手を論理的に導出することができる（←これがミソ）。ファームの連中が口だけ野郎ばかりだとしても、その論理には一点の曇りもない。これはスゴいことだ。口だけ星人はマネしなくてもいいが、この思考方式は大いに盗むべし。
第1章 2つの思考→「ゼロベース思考」「仮説思考」
第2章 2つの技術→「MECE」「ロジックツリー」
第3章 1つのプロセス→「ソリューション・システム」
時間がないなら、2章だけでも繰り返し読むべし。ロジックツリーは全ての基本。その進化形「HOWツリー」が分かったときはちょっと感動できるかも。昔、「UMLモデリングのエッセンス」を繰り返し読んで書いて、UMLで何が見えるようになるのか（何を書かなくてはいけないのか）に気付いたときと同じ感動を味わった。
具体例で「痩せるために何をするべきか」のHowツリーが挙げられている。馴染みやすく分かりやすいのだが、キレイにまとまりすぎている。最初からこんなにまとまって書けない。もっと何度も書いては直しの繰り返しで出来てくる。紙数の関係上、数度のレビューで完成しているが、本当はスクラップ＆ビルドの繰り返しが必要。
「MECE」「ロジックツリー」は記法だけ学んでも無意味。UMLと一緒。どう使われるか、何を見えるようにするか、を念頭において、読むべし！そして、読むだけでは身につかない、実際に手を動かして、書くべし（ここもUMLと一緒だね）。
2冊目。コンサルタントの肩書きを背負ったSEが求められるものは何か？それは「受注へつなげ！仕事獲ってこい！」に尽きる。経営層まで食い込めば高確率でポケモソゲットだぜ！従ってカッコつき『コンサルタント』の成果はRFP。
これがファームのコンサルタントだと、「業務改革アクションプラン」と銘打った分厚な資料を作りたがる。しかし、SEとしては分を守るべきだろう。経営者が力を込めなければ動かない“アクション”プランよりも、予算さえ獲得できれば得意分野になる田んぼへ引水すべき。
端的にいうなら、「このRFPならウチがNo.1の名乗りをあげられる」というやつ。
いや、故意にそうせよ、誘導せよというわけではない（それやったら反則）…んが、規定・契約に触れない範囲でのRFP執筆は許される（と信じる、でないと泣く）。というわけで、RFPの究極の一冊はコレ→「RFP＆提案書作成マニュアル」。なぜ究極かというと、RFPを出す側と受ける側、即ち発注と受注の両方の視点から書いてあるから。例えはアレだけど、セックスのハウツー本に雄サイドと雌サイドの両方が書いてあるようなもの。
この本を読むと、「良いRFPは良いプロジェクトにつながる」という著者の信念が伝わってくる。言い換えると、酷いプロジェクトはデタラメなRFPから始まっている。だから、発注者も受注者もお互いの手の内を充分に知り尽くした上で、仕事の土俵に臨め、という理屈。
目からウロコを以下に挙げる。あるいは、自分がいかに無知だったかの恥さらし。
- ユーザ研修費用、マニュアル作成費用は、見落とされがちだが、無料ではない
- ベンダーとしての自社だけでなく、ユーザ側のプロジェクト体制表を記載する
- プロジェクト完了日だけでなく、プロジェクト開始日も明記する
な、なんだってー！ΩΩΩ
いつもリリース直前になって「ごめん、たのむ」の二言で突貫してた「サービス」が有料オプションだったなんてorz …ま、費用の形で見せる/見せないはおいといて、エラい人がソロバンを弾いていることを祈るのみ。また、ユーザ側の体制がハッキリしていれば、責任者が曖昧なため仕様も曖昧に決まってしまうリスクも免れる。さらに、プロジェクト開始を先送りする（でも尻は不動）ことで工数をケチる悲劇に全米が泣いた、なんてこともなくなるだろう。
ダメプロジェクトの芽はRFP・提案書にあることが、まざまざと見せ付けられる一冊。
3冊目の紹介の前に、コンサルティングのお仕事についての「違和感」を吐き出してみる。
この仕事はハードだがものすごく面白い。ロジックを組み立てたり、プレゼンテーションしたり、論理の土俵でやり込めたりするのは、これまでの仕事と違って脳が面白く働いてくれる。わたしが考え抜いたロジックを、偉い人がさも自論のように吹聴しだすのを耳にすると、かなり爽快な気分になれる。
しかし、慣れてきてからずっとある「違和感」に付きまとわれている。その違和感はこういう疑問でやってくる→「本当にこれでいいのか？」。何か大事なものが足りないような、考える基盤から抜けているような違和感。
それは「データ」だということに気付いた。
ぶっちゃけ、コンサルの提案なんて、3つしかない。無くすか、替えるか、効率を上げるかだ。どんなに飾って理論武装しててもこの3つから出ない。違和感を感じているのはその対象だ。連中はプロセスにのみ着眼し、そのプロセスを無くすか、替えるか、効率を上げるかしか考えない。そのプロセスがどんな「データ」を扱っているかは考慮しない。
プログラミングをするとき、引数や参照に気を配る理由は、データを加工してアウトプットを出すことがプロセスの本質だと理解しているから。つまり、データの受渡し・参照のやり方如何によっては、性能がものすごく変わってくることを理解しているからこそ、データの扱い方に気を使うのが“自然”になる。
プロセスだけではなく、そいつが扱うデータもセットで考えるのがあたりまえの世界で仕事をしてきた。そのためプロセスだけをどうこうすることで結果を出そうとすることは、半分どころか本質ですらないような気がする。例えばこうだ。
「ボクの書いたプログラムが遅いんです」
『それなら簡単、次の3つ打ち手が有効だ、即ち
1. そのプログラムを消す（コメントアウトする）
2. もっと優秀なプログラマに書いてもらう
3. もっと速いCPUでそのプログラムを動かす
以上だ』
ふ ざ け ん な 、といいたくなるが、コンサルの本質はこんなもの。
ありがちな「遅い」理由は入出力のとこか演算対象のデータの扱い方がまずいかだろう。どちらもデータ（情報）を扱っているところだ。コンサルタントはそこに踏み込まずに表層を議論しているような気がしてならない。
なぜか。答えは簡単。踏み込むためにはその世界を知る必要があるから。参照呼出しなのか値呼び出しなのか（なぜそれにしたのか）、おかしな変数を宣言してないか、妥当な演算子なのか… 実装はjavaだから、Cなら… といった、「中身」に踏み込んだ分析が必要で、そのためには文字通り「言語」を身につける必要がある。
しかし、コンサルタントはそんな暇はない。速くするために、「はじめてのC」（えっちなタイトルだが名著）を読むことなんてしない。無くすか、替えるか、性能を上げるかしか考えない。
コンサルタントは、プロセスばかりに着目しており、プロセスが扱っている「データ」は軽視しているか、無視している。プロセスはチェーンという絵にしやすい。プロセスラインを集めたり組替えたり、まるでレゴのブロックのように扱える（ように見える）。あたりまえだ、その絵にはプロセスが扱う「データ」が描かれていないのだから。
コンサルタントの言う「データ」とは、業務量、生産性、リソース、リードタイムといった、現場を定量的に表現する数値のことであって、現場の人々が扱っているデータではない。コンサルタントは現場の人々が扱うデータを見ようとすらしない。
そこで3冊目。SEやってるヒトならあたりまえなのかもしれないが、「業務システムのための上流工程入門」を読むと、業務分析をデータ中心に進めている態度に非常に共感を抱く。
なぜか。
それは、プロセスなんて、コロコロ変わる（変えられる）ものであり、ひょっとすると「ヒトが違うので別のやり方」が存在することを知っているから。そんな不確かな業務フローを詳細に追求する前に、そのインプットとアウトプットをきっちりと押さえにかかるから。データとプロセスを分離し、プロセスを「そのデータをどう扱うのが正解か？」という観点から再定義しているから。
その結果、次のような悩み（?）にぶち当たったことがあるだろう。本書より引用する。
「シンプルすぎるデータ構造」は「複雑すぎるデータ処理」を要求します。どうもデータベースシステムには「複雑さの保存則」のようなものがあって、何かをシンプルにすまそうとすれば別の何かが複雑化してしまうようなのです。どうせ何かが複雑になることが避けられないのであれば、「お金がかからない部分」を複雑にすべきです。ソフトウェア開発においては、プログラミングにいちばんコストがかかることを考えると、テーブル構成をシンプルにするという戦略は的外れです。
たいていのシンプルさのトレードオフは、石（CPU）を替えたりメモリを積んだりする前に、正規化やインデックスキーの張りなおしでなんとかしようとするはず。データ構造設計がきちんとなされていれば、プログラミングで処理性能をなんとかするハメには陥らない（はず）。
しかし、コンサルタントが提案していることは、データ構造に目を向けずに、プログラムを消したり替えたり、メモリを積んだりして、性能を上げようとしていることと同じ。それらの打ち手によって、一時的にプログラムの速度が上がったように見ても、本質的な部分（＝データ構造）がそのままなので、データの増加、リクエストの増加により簡単にに遅くなるだろう。
レゴのブロックのように組替可能に見えた「プロセス」が、その本質（データ）が見落とされたまま簡略化され、代替されると、どうなるか。一過的に生産性が上がるかもしれないが、続かない。すぐにシワ寄せがくるだろう。どんなシワ? それは、省略されたプロセスが担っていた「データの加工・蓄積」というシワ。
コンサルタントのご宣託どおり業務プロセスをカイゼンしても、一時的な効果にすぎない原因はここにある。コンサルタントは間違っていない。コンサルティング方法論を正しく適用した打ち手だから。ただ、正しい打ち手を間違った部分に施しているだけなんだ。この事実はコンサルタントは気づかない（というより、認識できない）。なぜなら、コンサルタントはそういう泥臭いデータの扱いに悩んだことがないし、これからも踏み込むことがないから。
最後に。コンサルタントに「抜擢」と書いたが、わたしの場合は「テメェは現場では使えねェから、客の使いッ走りでもやってな！」と脳内変換して切歯扼腕してる。コンサルティングは非常に面白いが、コンサルタントは大嫌い。
捲土重来を期して。がんばれオレ、もっとがんばれ。
| 固定リンク
コメント