WBSのスキルをアップする思いつきイベントアイデア
一つピークを超えて、ひと段落しているのだが実際はそう甘くはなく、次から次へとさらに高い山を登らなければならないような気がするも、そう言う気にはなれない。
自分が仕事をする場合は、ある程度感覚的にこれをやればいいのだろうというイメージを掴めないとどうにも仕事が手につかない。そういった掴めないところは、ただ悶々と考えるよりは、何か知っていそうな誰かと話をしたり、聞いて回って情報を集めて形作るほかない。
そうした自分の仕事の仕方は自分ひとりなので誰にも影響を与えないが、プロジェクトチームになると作業プロセスをデザインしたり、それを雛形にWBSに展開したりする必要が出てくる。
担当のエンジニアに『WBSを作って』と依頼すると、作業プロセスのデザインや準備段階や周りとの連携を全く気にせず言われた範囲だけのWBSを作ってくる。さらに、そのWBSは日単位で作るので正味どのくらいでできるのかわからないし、全部、上手くいったらという前提付きでもある。
今どき、WBSを作る際に誰も見てあげないのだろうか。そのままでは本人が不幸になるだけではなく、周りもひどい目にあうのは見えているのだが。
WBSをただ眺めるビアバッシュの会
ということを考えながら思いついたのは、WBSをただ眺めるビアバッシュの会をやったら面白いだろうと。組織の中なら自由にやっても良さそうだが、公募イベントだと勘弁的にNDAを結ぶか、クレンジング前提でやる配慮はやっておいたほうがよさそうだ。
WBSを作るモブ
もう一つは、プロジェクトチームが工程やDoingのながでどのような作業プロセスを踏まなければならないか、最初にモブでWBSを作るワークショップをやったらいいんじゃないかという思いつき。
それぞれの目的、レベル感
前者のWBSを眺める会は、WBSを作れる人が気づきをもらいに行くレベル感だろう。後者は、WBSを作れないエンジニアをドライバーに（もちろんモブなので順番に）して作り方をスキルトランスファする感じだろう。
誰かやってみたら教えて欲しい。
エンジニアにとってコスパの良いスキル
ちょっとした事情があり、大型書店に行ってある分野の書籍を買い、読んでいるのだが、走りながら勉強（本などの情報を仕入れて）して、それまでの経験知だったものを体系立てて整理し直すのは、経験から知見に変換するプロセスとしてとても良い。
何より、自分の専門家としての経験と言うよりは、それにプラス方法論や手法、元となる法規などを引用した方が、そうした『専門性の知識を持っていない』相手に認知してもらう手段として即効性がある。特に、役職者の方に効果がある。
などと思いをつらつらとしていたとき、エンジニアにとってコスパの良い、それに相応したものがあるに違いないと思ったのである。
さて、何がエンジニアにとってコスパの良いものであろうか。
エンジニアが持たなければならない、専門性のスキル、コンピテンシは、
- 基礎スキル
- 技術スキル
がある。基礎スキルは、その人の性質に根付くスキルである。性格やそれの現れとしての行動様式も含む。気づき、意志、伝達、判断、交渉などなど。
技術スキルは、2つに分ける。
- 手法・方法論
- 技術の適用
手法、方法論は、例えば、システム開発手法などである。技術の適用は、言語、製品知識などシステム開発を行う上で、必要となるものづくりのスキルである。
基礎スキルと技術スキル。前者は普遍的なものであり、エンジニアその人に根付いている。どのような技術領域、ロールに変わってもどこでもいつでも使える。その意味では、ここのスキルを伸ばすのはとてもコスパがいい。
基礎スキルは身につけばコスパはいいのである。しかし、身につけ方はとても難しい。何が難しいかといえば、これを覚えれば実践できる、とはなかなかいかないところである。
例えば『気づき』は目標設定でよく見かける項目なのだが、じゃあ、『そのスキルを身につける（＝実践できるようにするために）どうするの』と聞いてみると『意識します』くらいしか出てこない。精神論しかない。『チュートリアルをやったので、基礎は身につきました』と言うわけにはいかないのである。
身につければとても便利なのが基礎スキルであるが、身につけるまでは人によっては真逆かもしれない。
では技術スキル、である。こちらの、技術の適用は一言でいえば、道具の使い方を覚える、である。ノミ、カンナ、ノコギリ。そういった道具を使い、ものを作るための技術である。
システム開発で適用される技術は、時代の変遷で代替わりをする。フルスクラッチで書いていたコードは、IDEの上で書くようになった。タイポすれば教えてくれる。そんな時代である。であるから、道具を置き換えていかねばならない。
もう1つの、手法、方法論は、そうした道具を使うルールである。コードを書くために、段階的にコードを書けるように情報をこのレベルで記述する、コードはこのパタンで。コードはこのテストのやり方で、と言う風に。
こちらの移ろいは緩やかである。やはり変遷があるがとても気づくエンジニアは少ない。気づけるエンジニアは、基礎スキルを活用する人であり、何が求められているかを探求できる人である。
ここまで思考を巡らせて、結局、何がエンジニアにとってコスパの良いスキルなのだろう。
思いついたら『やってみる』スキルなのではないだろうか。
『あなたの持っている価値観があなたが書くコードの品質を左右している』
『あなたの持っている価値観があなたが書くコードの品質を左右している』
さて、これを読んでどう感じるだろうか。そんなことはない、プロジェクト、プロダクトの品質要求に応じてコードを書いていると言うのだろうか。それとも、指示されたようにコードを書いているだけだから、品質は作業指示や仕様書次第だ、と言うのだろうか。
仕様書からコードにエンジニアが変換する際に、どのようなロジックで、どのような書きっぷりで日本語やモデルからコードに書き換えられるかは、それを書き換えるエンジニアに委ねられる。
そのコードが仕様を満たしているか、ケースを網羅しているかはエンジニアがどこまで仕様を読み込み、理解し、コードとして表現できるかに強く依存することになる。
なぜなら、仕様書からコードとして表現される際に起きているのは、エンジニアの主観による意思決定しか存在し得ないからである。その瞬間、誰も介入することはできない。
介入できなければ、そのコードは書いたエンジニアの考え方をそのまま映す。考え方は、情報を集め、整理し、数ある選択肢の中からエンジニアとして表現したい表現方法をエンジニアの価値観で選び、表される。
コードの品質はエンジニアの価値観で表現されるのである。
これは一人でコードを書く場合に限られる。一人でと限定したのは、モブプログラミングの存在があるからである。ドライバーがコードを書き、ナビゲーターがサポートをする役割でコードを書く場合、書いている最中にナビゲーターの価値観が割り込んでくる。
複数のナビゲーターの知見が混ざり合う中で、コードが決まっていく。コードを書きながら、あれこれとナビゲーター達の経験から予測される様々なケースを共有しながらコードに変換されていくのである。
一人ひとりのエンジニアがそれぞれでコードを書き続けるならば、コードの品質はエンジニアの価値観に依存するため、エンジニア次第で品質は左右される。
モブプログラミング でコードを書くのであれば、チームの共有されている価値観の範囲で品質がコードとして表現される。チームでどこまで価値観が共有されるかに依存するのだが。
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)
- 作者: 江渡浩一郎
- 出版社/メーカー: 技術評論社
- 発売日: 2009/07/10
- メディア: 単行本（ソフトカバー）
- 購入: 75人 クリック: 1,306回
- この商品を含むブログ (159件) を見る
プロジェクトの中で人材を育てる
自分の部下のの中で、中堅以上のエンジニアには後進の育成を課している。課しているからには、評価を行い、業績に反映している。
もちろん、育成対象者である若手や伸ばしたいスキルを持つエンジニアにも自身でどのように取り組むのか、目標設定はしている。こちらは、自分で育つスキルを自分で選ばせ、自分のやりたいようにやらせる。
中堅以上のエンジニアには、若手エンジニアは『○○させたい』と具体的にテーマを渡す。次のプロジェクトではサブリーダをやらせたいので、リーダが担うタスクのうち、いくつかを分担するかブロックを任せられるか考え、実行して欲しいと言うように。
人材を育成するのは難しい、期待する人材が育たないと愚痴を聞かない日はない。でも、育つために必要なリソースを確保しているのかどうかと言えば、怪しいものである。やり方も同じである。
育成については何度も取り上げているが、どうやって、は書いていないような気がするのでそれを取り上げる。
基本
基本は、『テーマを設定する』『動機づけする』『アサインする』『モニタリングする』『フォローする』『自己評価させる』『エビデンスで評価する』の流れになる。
何も目新しいものはない。
当たり前のことを当たり前にやる他に、マネージャの仕事のやり方はない。チートもできない。
プロジェクトの中で育てる
基本をそのまま行う。ただし、プロジェクトではチームとしてのスキルセットを満たす必要がある。ブロックのリーダやサブリーダに経験値の少ない若手エンジニアを置けばチームとしてのスキルセットが足らないのは当然である。
そこの手当てをプロジェクトマネージャやリーダにする。例えば、中堅どころのエンジニアを入れ相談役にさせる、アドバイザをおく、マネージャとしてのプロジェクトのリスク評価を上げておく（＝モニタリングのためのリソースを増やす）など、何かしらプロジェクトに対するアテンションを上げておく。
将来のために無駄なことをする
今だけで見れば、プロジェクトで必要とするポジションにそれを満たすスキルのエンジニアを置く方がマネジメントとしては楽である。
でも、それではいつも同じメンツがリーダで後進が育たない。
上述した、期待する人材が育たない理由はこれである。
面倒臭い方を取らないからあとが続かない。楽をする分、将来にそのツケが回る。マネージャ自身が、今をやり過ごしたいと考えていると結果的にそう言うアサイメントになる。
外から見たら、いつものメンバだとしても、プロジェクトの中での役割、分担内容はいくらでも変えられる。そうした経験をさせるアサイメントをしないと期待するエンジニアが実は向いていないと言う事実さえわかるのは先になってしまう。
年次でそろそろリーダをやらせないととアサイメントしてプロジェクトを失敗するのはこれが原因である。
改めて、プロジェクトマネジメントをどうアプローチすれば良いかを考えている
ひと段落ついたので、改めて、プロジェクトマネジメントへどうアプローチすれば良いかを考えはじめている。
プロジェクトマネジメントへのアプローチと言いつつ、実際は、プロジェクトを回すマネージャ（＝プロジェクトでリーダーシップを発揮する人）が何から手をつけて行けば、プロジェクトを炎上させずにプロジェクトの目的を達成することができるか、である。
ペルソナ
対象読者のペルソナはこんな感じか。
- はじめてプロジェクトのリーダ役をすることになったエンジニア
- プロジェクトを一度も独力でキャリーしたことがないエンジニア
前提条件
ない方が良いが後から書き出すかもしれない。
例えば、『言語やプラットフォームは問わないが、何かしら開発経験を持っている』などは必要かもしれない。
ゴール
プロジェクトマネジメントをできるようになることが目的ではない。ここを間違えないように。あくまでも、プロジェクトの目的を達成することが目標である。
プロジェクトマネジメントは、プロジェクトをマネージする手法である。プロジェクトマネジメントの代表的な知識体系である『PMBOK』では開発方法まで言及していないことが証左である。
知識エリア
プロジェクトをいい感じにキャリーするために必要な知識エリアは4つある。
テーラリング
前述の4つの知識エリアが必要である。全部の知識エリアは必要だがその中の知識全部は使わない。必要なものだけ使う。必要なものだけ使うから、不要なものは知っていて、且つ、使わない判断をしなければならない。
取り扱う範囲
システム開発を受託や社内開発のイメージにするとシステム開発プロジェクトになるので、システム要件が提示された以降が範囲になりそうだ。
ただ、自社サービスの開発であれば、プロダクトマネジメントの要素が入ってくるので、範囲がぐっと広くなり、何を作るかからになる。
それでも、結局は、経営課題かビジネスモデルキャンバスのソリューションに当たるところがインプットになる。
その前のシステム要件や提供価値はビジネスオーナとしておく（がそれで良いか、あとで再考するかは考えどころ）
インプット
上述から、システム要件、提供価値がインプット。いずれにしろインプットは必要。自分でプロダクトを作る、何だかよくイメージできていない段階だとしても、ペーパーでモックを作るにしても、それを作るインプット（を作りながら形作るのかもしれないが）はあるのである。
手のつけ方
4つの知識エリアのどこから手をつけるか。これはこれから考える。
