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

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

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

資格なんて価値がないと言えるエンジニアは誰か

例えば情報処理技術者試験のような資格がある。メンバが目標管理の中で取りたいというなら奨励する。本人が勉強したいというのだから止める理由はないし、個人の時間で勉強するのだからあれこれ言う権限を持ち合わせていない。

資格を持っているエンジニアを見ると2つのパターンに分けられる。その資格を取って仕事に生かしているかどうかだ。実務で経験知を積み上げ実力があるエンジニアが資格を取るパターン。もう一つが資格は取るが、試験勉強の知識だけしか持っていないエンジニアだ。後者が決してダメということはない。業務しかせず勉強をしないエンジニアよりは向学心があっていいじゃないか。だからと言ってそれ以上でも以下でもない。

前者のエンジニアと後者のエンジニアの違いはないかというと、取った後に違い出る（仔細に話せば、取る前から違いがある）。それは資格保有者のコミュニティやアライアンスのような活動に参加しているかどうかだ。

資格を取った後も、資格維持に相応しいアップデートをしているかどうか。

後者はタイトルコレクターのように資格を持っていることが多いがそれだけである。要は、現場で戦力にならないことが多い。なぜなら、机上だけの知識で現場経験がないからだ。アサイメントの都合あるが、是非にと保有する資格を活かすようなwillをいうわけでもない。

ところで、資格を全く取らないエンジニアもいる。資格の話題になると資格なんて価値がないというケースまである。資格に対する価値観はエンジニア夫々だろうからどう思っていても良い。ただ、そう言う発言をするのは中堅以降のエンジニアである。

では、資格は価値がないエンジニアはどうなのかといえば、やはり2つに分けられる。ただ、比率がだいぶ違う。資格は取らず、アサインされた仕事だけをしているエンジニアと、専門分野の界隈でプレゼンスがあるエンジニアである。後者は極端に少ない。

前者の場合、技術的に中庸である。プロジェクトが立ち上がればアサインされるがそれだけである。後者は口が悪いとかうるさいとか特徴があるが、面倒臭い仕事はするし、新技術を押さえている。それより、外部で活動して名前がそれなりに売れている。

別の切り口で資格の見方がある。実務で経験した成果を資格の形に残す、と言うものだ。これはなるほどな、と思った。実務での経験を実務の実績だけで示すのは第三者からすれば知識量だとか技術レベルだとかエビデンスをどう取るかが悩みどころだ。実務ではロールと担当範囲で知ることができるが、形式知のレベルは判断が曖昧になる。それを資格で示すと基礎的な知識は持っていることが第三者の資格として可視化される。

もう1つは、希望するアサイメントにリーチできない場合に、アサイメントするマネージャに訴求する手段として使う。第三者が知識を持っていると言っているのだから、そう言うエンジニアの人材を使わないマネージャの目は節穴か、と迫るやり方である。

これは自分が使った手法なので割と効果的である。

資格に価値がないなんて言えるのは、実質資格認定団体が求めるような課外でのアウトプット活動をしているエンジニアだけではないか。

絵で見て学ぶ　基本情報処理試験　絶対合格の教科書＋出る順問題集

【Q】エンジニアとして影響を受けた書籍は何か

そんなお題があって、「エンジニアとして影響を受けた書籍かー。えっとなんだっけ」と影響を受けた書籍がパッと思いつかない。

影響を受けるというのだから、何らかの作用を受けて読書後のエンジニアとしての所作に変化が起きた、という結果を残した書籍になるのだろう。

唸っていても仕方がないので、カテゴリを設け、そのカテゴリの中で印象に残っている書籍を思い出してみよう。

プロマネ関連

 これを読んだからといってプロマネになれるわけではない。プロマネが使う用語を知ることができるというだけだ。それにこれはフレームワークで、実コードにあたるhowtoは一切ない。よく間違えている人はこの本をシステム開発の本だと思っているケースがあるが、これはプロジェクトマネジメントの本で、経営者がプロジェクトをモニタリングするための仕組みだ。だから、システム開発手法が別に必要になり、PMBOKのフレームワークと同期する必要がある。

A Guide to the Project Management Body of Knowledge

マネージャ関連

これは影響を受けたというよりは、マネージャとして実践していた経験知が形式知として書かれたのでやたらと同意した印象がある。howtoではなく、指針のようなものだから、これでマネージャ業ができるようになるわけではない。 

マネジメント[エッセンシャル版] - 基本と原則

育成関連

 可能であれば、部下を持つより先に自分の子を持ち、自分が考えるように子は行動しないことを身を以て体験してから部下を持つ方が部下との接し方でいい関係を作れると思っている。逆でもいいが、どちらを実験とするかの差だ。

子どもは成人するまでは養育の責任があるので 接し方をやりっぱなしにはできなところが悩ましい。その点、部下は自分が上司である間に限って責を負うが、やはりいい加減にするわけにもいかず。

この書籍が良いのは、性格の受け止め方を学べることである。経験知的にわかっていたことが「やっぱりそうだったのか」と裏付けを取れたのことと、性格も生まれ持った性格か、経験で学習した性質かを分ければいいということだ。

１０代の子をもつ親が知っておきたいこと

カンバン関連

 これも外せないか。無駄の排除を学び直すというか、カンバンを学び直すために読んだ…気がする。

トヨタ生産方式――脱規模の経営をめざして

仕事の仕方関係

何でここで池波正太郎なのかというと、池波のエッセイには作家としての仕事の念持のようなことも書かれている。どんなにペンが進まないときにも、しんどくても1日2枚の原稿を進めると決めたら、2枚書くことをしていた。

資料を作る、面倒な問題など、そうした気が進まない状況になっても、エッセイを読み、実際に自分で手を付けないと時間だけが過ぎ、何も残っていないということがわかっていれば、兎に角1文字を打ち込まなければならない。

そうしたことを学んだ。 

男の作法 (新潮文庫)

アマゾンでの購入履歴から見繕ってみたが、それ以前や書店で買ったものは当然出てこないので、そっちで影響を受けたものがあるかもしれない。

思いつくのはワインバーグだが、それほど影響を受けたとは思えない。

アジャイル開発系の本ではどうかと思うと、書籍よりコミュニティやスライドなどまぜまぜの知識になっているような気がするので、これという本が思いつかない。

可能であればブクマのコメントにエンジニアとして影響を受けた書籍を書いて教えて欲しい。

若しくは　#エンジニアとして影響を受けた書籍 　で教えて欲しい。

マネージャは50代になったら現場に戻そう

ずっと前から思っているし、結果的に自分もそれをしているのでそうした方がいいと思うことに、

「マネージャは50代になったら現場に戻せ」

という考え方だ。

なぜ、そうしたことを思っているかというと、マネジメント、中間管理職が硬直化するからだ。

所属する組織のマネージャの顔を思い出してみよう。ずっと同じ顔ぶれではないか。マネージャも1年過ぎれば1歳年寄りになる。顔ぶれが変わらなければ、ずっと古い成功体験だけを引きずり、古い価値観だけで意思決定を続けるのだ。

デメリットはそれだけではない。マネジメントの次世代が育たないのだ。50代のマネジメントの空き席が出来なければ、一切更新されないし、空きができてもプレミアチケットのようなものだ。そしてその席も暫くは空かない。

現場に戻すマネージャになにもプログラムを書けとまでは言わない。大規模プロジェクトの支援役（という名のアドバイザでも顧問でも助言者でもいい）や、複数のプロジェクトのプログラムマネジメントでもいい。もちろん、プログラムを書いてもいい。

もし、50代で今更現場なんてと思うようなマネージャが上司だとして、現場に戻れないというマネージャの下でエンジニアが働こうと思うのだろうか。

いや、若しかしたら50代になって現場に戻られると嫌な方はエンジニア側なのかもしれないが。

スーパーエンジニアへの道―技術リーダーシップの人間学

計画を立てないという負債

何事もことを成すには『計画づくりが大事だよ』ということについて反論する人はいないはずだ。殊更、エンジニアがプロジェクトを立ち上げ、プロダクションシステムなり、Webサービスなり、APIなりをリリースするなら当然である。

ところが実際はどうか。

ひどい話になると計画をろくすっぽ立てなかったり、それを計画と呼べるのかという程度の自称計画がまかり通っているのが現状ではないか。

だいたいそういった計画とは呼びたくもない計画を作っているエンジニアは計画を作らない理由ばかりを並べる。ひどいエンジニアになると

「アジャイル開発なんですよ」

などとアジャイルを知っているエンジニアからマサカリが雨あられの様に投げ込まれても文句を言えない様なことをいう始末だ。

計画を作らないことは負債を作り込むということを理解すべきだ。

計画を作るということは、ガントチャートやWBSを作るという様な、見た目の話ではない。

計画を立てるとということは、計画を実行するまでに次の3点をしなければならない。

1. 情報収集
2. 分析
3. 準備

情報収集は、自らのことに関すること、他のことに関することについてデータを集めることを言う。分析は、それらを定量的な情報として分解する。準備は、計画として組み合わせる。ここまで出来て初めて実行に移せる。もう少し、噛み砕くと次の5項目があげられる。

1. 目的（ゴール）を明確にすること
2. チームの実力（as isのスキルセット）を客観的に把握すること
3. 影響を与える外部の因子（ステークホルダ）を明らかにすること
4. 客観的で定量的な情報（諸元）を収集すること
5. to beのスキルセットへ教育すること

逆に言えば、計画を作らないということは、次の様に言い換えることができる。

1. 目的がモヤっとしている
2. 誰が何をできるか誰も知らない
3. 自チームの独りよがりで考える
4. こうなるだろうと勝手に期待だけする
5. チームが頑張ってくれる

 一番いけないことは、計画を作る立場のエンジニアが自分ではない別の誰かがいい様にしてくれると言う根拠のない期待を抱くことだ。

計画を立てない負債の根源の全てはこの考えが根っこにある。

人を使い、自分で足を運び、情報を収集し、その情報の確からしさを確かめなければならない。

なぜなら、計画は仮説でしかないからだ。

計画が仮説だと認識できれば、計画は1つだけではありえないことに気づく。情報の分析で分解するのは組み合わせ、ケースを知るためでもある。

骨格となる軸は、様々なパラメータを動かしても計画の本質は変わることがない。ただ、状況の変化で対応を変えられる柔軟性を持ち合わせられる。

こうしたことを考え、チームが実行できる様に準備をするのが計画を作ると言う行為なのであれば、それをやらないのは最初から、自らハンディキャップを負うと宣言する様なものだ。

[まとめ買い] あそびあそばせ

あそびあそばせ 7巻 アニメDVD付き限定版 (ヤングアニマルコミックス)

調達 ヒカリ (Hikari) 咲ひかり金魚 育成用

ヒカリ (Hikari) 咲ひかり金魚 育成用 沈下 1kg

若手エンジニアが成長に必要なもの

自分のことで話をするとプログラミングのスキルが必要だった。本当にセンスはないし、本を読んでも頭に入ってこなかった。

多分、もっと写経をした方が良かったんだろう。

不思議なことに、得意と思っている若しくは苦手意識のないことは本を読んでも理解できるし「自分が今参画しているプロジェクトを当てはめるとこんな風になるな」と妄想も自然と出来る。

全くもって不思議だ。

よく、スキルをレーダーチャートにプロットして得手不得手を可視化して見せられることがある。直感的に表でスキルを○や×で列挙されるよりレーダーチャートのグラフを見る方が『わかった』気にさせられる。

実際には、得られる情報量も質も同じなのだが。

目標管理の中でメンバの目標を設定させるときに意識的にしているのは、メンバ自身がなりたい将来像（それ自体あまり考える機会がないので都度の思いつきか前年の継承なのだろうが）になるために必要なスキルの項目を自分自身で選ばせている。

ここは一切、口出しをしない。

なぜなら、彼彼女の人生だからである。彼彼女のエンジニアとしてのリソースを使うのだから、自分で悩んで決め、試行錯誤しながらピボットを続けて欲しい。

そう思っているし、そうするようにしているので、どのスキルを伸ばすか設定するときには得手不得手のどれを選ぼうと構わない。

得意なスキルを楽しみながらさらに伸ばすのか、不得手なスキルを無理して引き上げるのかは、好きにしたらいい。

どっちだったかと言えば、自分は結果的に得手を伸ばしてきたのだろう。そうすることで余裕が出来たからか、得手とは違う、でも関心を持ったスキルや、次のロールを担うために必要だと思ったスキルを身につける準備をしてきたのだから。

そこに置いてきぼりとなったのはプログラミングだ。これは相変わらず野ざらしにされたままだ。

ただ、60歳くらいになったらもう少し時間ができるだろうから、そのときにでもやろうと思っている。そのときの流行りの言語で「Hello World!」をしているかもしれない。

そうなったら、それはそれで面白い風景かもしれない。

Webプログラミングが面白いほどわかる本　環境構築からWebサービスの作成まで、はじめからていねいに