コンサルなら

久々に書くのに、開発技術のことじゃなく、コンサルタントのことだというのはつまらんが・・・

コンサルタントで、エクセル表で課題管理をして、要件つめるのに、エクセル表上でやっている人がいるってのは、にわかに信じられなかった。別にパワポがいいってわけじゃなく、エクセルは、費用を計算したり、いろんなデータを簡易的に分析したりするのに使う。エクセル方眼紙の話は、システム開発の現場でいわれるが、コンサルが、エクセルを本来の用途以外で使ったら、それは違うんじゃね？と思う。
システム開発の要件定義ぐらいまでなら、十分パワポでいけるんだし、要件定義あたりって、別にシステム担当じゃなきゃ書けないって話じゃない。なぜなら・・・　要件定義は、委託業務で、お客様の支援をします、要件定義はお客様のものでしょう？っていうじゃん。つまり、それって開発技術者だけのものじゃないってことでしょ。だったら、コンサルが入って要件定義しても、なんら不思議ではない。（もちろん、要件つめる上では、技術者の支援なしにはできないだろうけど）。
一番気に入らないのは、パワポの一覧性というか可読性というか、なんというんだろう・・・要するに一枚で要点を表現しきる（というある意味制約の中でまとめる）から、わかりやすいという特徴があるわけじゃん。プレゼンツールだから。要件洗い出しをするまではエクセルでもいいけど、それらをまとめて、要するにやりたいことってこういうことで（要求）、こういうことが達成できればいいんですよね、（要件）って形で一度整理するには、パワポいいんだけどな。
単純に纏めなおすだけでしょ、無駄な作業じゃん、ってよく言われるんだけど、逆にこのプロセス（パワポで要約する）を省くから、要求変更や要件変更のときに、なぜそれをすべきか、どう判断すべきか、ということができなくなる。
要件定義って、開発工程じゃないと最近思っている。設計・構築・テスト・導入の前工程。上流でもなんでもない。流れがあるわけじゃないし、なんか価値転換しているわけでもない。
ま、それはそれとして、肝心な論点や整理において、パワポ２−３枚も用意しないコンサルなんて、コンサルじゃねーし。コンサルタントにもいろいろな人がいるから一概に言えないけど、単に口がうまいだけ。論理とかロジックとかっていいながら、話すだけで進めるやり方って、相手を煙にまくやり方にしかみえないし、相手をやりこめる、だけの手法でしかない。
せいぜいファシリテーター、独自の論理を口だけで展開する、独断ファシリテーターってところか。

ここでは、こういった人たちに向けて、さんざんないいようをしているけど、特定の人を指しているわけではなく、経験上、そういったコンサルファームの人やその他、リサーチ系会社とかいろんなところにいる人に接してきたので、ふと、そう思っただけ。

とにかく、ショットショットで、パワポの１，２枚ぐらい作ってよ。何が決まったんだか決まらなかったんだかわかんないから。