それではチームは失敗するリスクを始めるときから抱えている

ITSSに+が足されてITSS+となったらしい。先日の+Messagerだったか、+が好きなんだな。単純にITSSv5とかすればいいのに。

 

www.ipa.go.jp

 

バージョンを明確にして誤謬を避けるのはISOなどのマネジメントシステムの基本何ですけどね。次に新しい技術領域を増やすことになったら、ITSS++とかにするんでしょうか。その次は#ITSSITSSシャープ)とかですかね。

 

さて、気になるのが「アジャイル開発の進め方」です。ページをめくっていくとP5にryuzeeさんのこれが出てくるのは安定感ありますね。カンバンを導入する際にスライドを活用させていただきました。もう6−7年前くらいかな。

 

f:id:fumisan:20180412074322p:plain

 

さて、気になるところはこのページではなく、ここです。

このスライド、P16の右のレーダーチャート。何度かエントリで書いていますが、この図はちょっと誤解を生むのでは、と。多分、不夜読みしすぎているだけなんだと思いますが(やんわりと退路を確保)。

 

 

f:id:fumisan:20180412074659p:plain

 

気になるのは、実際はそうなんですがというところが、チームメンバのスキルをORしたメンバの全部のスキルの面積は確かにチームの今持っているスキルです。

こう書いてあるなら、そだねーと思うんですよ。

あるチームがあって、メンバが4人いて、6つの軸のスキルがそれぞれを上図のようにレーダーチャートにプロットすると下図になりますね。

 

 

 

 

f:id:fumisan:20180412075130p:plain

 

チームの「今の」スキルを表現したいならこれでいいです。異議なし。

チームはエンジニアを招集してチームを編成し、継続的な(価値に対して予算がつく限り)開発をするわけですが、ビジネスですからビジネスの要件がある。それを実現するには実現するための技術的な要求があるわけです。

プロジェクトに必要な技術要素が。

それが表現されていないことが気になるんですよ。

例えば、赤線のチャートがプロジェクトを成功させるためにチームに必要な技術スキルだとします。

 

 

f:id:fumisan:20180412075554p:plain

そのチームに必要なスキルとチームメンバのスキルをORした今のチームのスキルとの差分をどうするかを企てる必要があるのです。

OJTで埋めていくのか、OFFJTで埋めていくのか。

何れにしても、チームが計画的に教育計画を作らなければならないのは必須です。出なければ、その差分に落ち込んだ課題は必ずトラブりますから。

なお、スキルマップは、領域(面積)だけではなく、スキルのレベルも考慮しないといけないことを忘れずに。