それではチームは失敗するリスクを始めるときから抱えている
ITSSに+が足されてITSS+となったらしい。先日の+Messagerだったか、+が好きなんだな。単純にITSSv5とかすればいいのに。
バージョンを明確にして誤謬を避けるのはISOなどのマネジメントシステムの基本何ですけどね。次に新しい技術領域を増やすことになったら、ITSS++とかにするんでしょうか。その次は#ITSS（ITSSシャープ）とかですかね。
さて、気になるのが「アジャイル開発の進め方」です。ページをめくっていくとP5にryuzeeさんのこれが出てくるのは安定感ありますね。カンバンを導入する際にスライドを活用させていただきました。もう6−7年前くらいかな。
さて、気になるところはこのページではなく、ここです。
このスライド、P16の右のレーダーチャート。何度かエントリで書いていますが、この図はちょっと誤解を生むのでは、と。多分、不夜読みしすぎているだけなんだと思いますが（やんわりと退路を確保）。
気になるのは、実際はそうなんですがというところが、チームメンバのスキルをORしたメンバの全部のスキルの面積は確かにチームの今持っているスキルです。
こう書いてあるなら、そだねーと思うんですよ。
あるチームがあって、メンバが4人いて、6つの軸のスキルがそれぞれを上図のようにレーダーチャートにプロットすると下図になりますね。
チームの「今の」スキルを表現したいならこれでいいです。異議なし。
チームはエンジニアを招集してチームを編成し、継続的な（価値に対して予算がつく限り）開発をするわけですが、ビジネスですからビジネスの要件がある。それを実現するには実現するための技術的な要求があるわけです。
プロジェクトに必要な技術要素が。
それが表現されていないことが気になるんですよ。
例えば、赤線のチャートがプロジェクトを成功させるためにチームに必要な技術スキルだとします。
そのチームに必要なスキルとチームメンバのスキルをORした今のチームのスキルとの差分をどうするかを企てる必要があるのです。
OJTで埋めていくのか、OFFJTで埋めていくのか。
何れにしても、チームが計画的に教育計画を作らなければならないのは必須です。出なければ、その差分に落ち込んだ課題は必ずトラブりますから。
なお、スキルマップは、領域（面積）だけではなく、スキルのレベルも考慮しないといけないことを忘れずに。
