その「ふわっとした仕事を具体的なタスクに落とし込むスキル」とはどちらですか

facebookで数人のお友達がシェアしていて、何だろうなと思って読んでみたら、なーんだ、自分の仕事のことか、と思った。はい。

blog.tinect.jp

ただ、その上で頻繁に話題になるのが、「タスクをちゃんと具体化・詳細化出来る人マジ少ないよね」という話です。

引用　同上

エンジニアのマネージャやプロマネやスクラムのコーチ界隈でもこうした話を時折耳にするし、実際、メンバの仕事ぶりを見ていると『そうだよね』と首肯してしまう。

プロフィールを読むとSEとなっているので、多分、ITのプロジェクトで話しているのではないか、と一旦設定する。

なぜ、そう想定するかと言うと『ふわっとした仕事を具体的なタスクに落とし込むスキル』はエンジニアに対して求められているのだろう、と思ったからだ。

こう思ったのも、また自分が暗黙で前提を置いているからでもある。それはエンジニアが属する組織が自社で事業をしているかSESや受託かで変わってくるからだ。

下図を参照して欲しい。自社で事業をしていないと1段目は存在せず、2段目（それも事業によりスタート位置が違う）からになる。

想定を置いたのは、2段目での話なのだろうと言うことだ。

この1段目か2段目での違いは大きい。何が違うか思いつくだろうか。それは、担当者であっても1段目は事業を担わなければならない。2段目は、IT化プロジェクト（の全てもしくは一部分）を受託するだけに過ぎない。1段目と2段目では負う責任範囲が違いすぎる。

では1段目と2段目で適用するスキルの違いの例を確認しよう。

先に、エンジニアに馴染みのある2段目から説明すると、見たままで、成果物を作成する成果物分解力、つまりWBSを作成するスキルが必要になる。

引用しているエントリでは、ここ（提案以降）を念頭に話をしているのではないだろうか。

1段目では、経営課題（例えば中期経営計画や突発的な事業課題）から自分の仕事を作るスキルが必要になる。そのために仮説（経営課題から課題の抽出とゴール設定をイメージ）するスキルが必要になる。そうした課題を組織内のステークホルダと利害関係や協力関係を押さえながら上申していくスキルも必要になる。もちろん、事業化すればプロジェクトのエンドユーザ側のプロマネとして担当しなければならない。

これだけ違いがあるので、そうである場合（そうでなくても同じなのだが）、ふわっとした仕事と言ってもふわっと加減は1段目ほどではない。1段目の方がふわっとの加減が希薄過ぎる。図を見て感覚的にわかるかどうかはあるが、レベルが違い過ぎる。

実際、1段目をやってみると初めてわかるが、やって見ないとわからないことが多いし、やり始めてみると思ったように行かないことが多過ぎる。

だからこそ、ウォーターフォールでなんかやってられず、アジャイル開発で『パッと見せてよ』としたくなるのだ。

希薄度合いのレベルが輪を掛けて違うので、事業化してしまうと意思決定のスキルが弱い担当者は判断に迷ってしまいなかなか決められないループに陥ってしまう。SIerやコンサルがハマるのはこうした担当に当たってしまったときだ。

ちょっと一呼吸して、もう一度、1段目と2段目での違いを考えてみると、1つだけあげるとすると、

「（欲しいものが何だかかわからないけれど今は）これを作って欲しい」

なのだろう。2段目では『（欲しいものが何だかわからないけれど今は）』はありえない。なぜなら、提案の段階で『これ』が欲しいのだろう、と契約を結ぶからだ。

さて、何が言いたいかというと、2段目は訓練＝何回も経験をさせることと、それに必要なスキルを手順化して覚えさせればいいと思っている。

だが、1段目を指して言っている（冒頭の仮説と違う）ならちょっと事情は変わってくる。まあ、事業をしている組織からみれば、そんなことは言ってられず、ひたすらOJTでやるしかない（組織の意思決定プロセスが根強く絡むので外部研修は無理）のだろうが。

 事業会社で困っているのならオファーしてくればいいのに。

マンガでわかる! 幼稚園児でもできた!! タスク管理超入門 impress QuickBooks

社内プレゼンの資料作成術