ハート軍曹と指示待ちエンジニア

プロジェクトマネージャにも色々とリーダーシップのスタイルはあるが、所謂、トップダウン型のプロジェクトマネージャの例を挙げると、先日無くなった「フルメタル・ジャケットハートマン軍曹や「愛と青春の旅立ち」のエミール・フォーリー軍曹なのかもしれない。

役職的には、ちょっと下すぎるけどイメージとして。

 

news.yahoo.co.jp

 

あるとき、まだ若手エンジニアがリードする会議の予定があって、その会議の準備状況を聞いてみたら、まあ、案の定、ほとんど無垢というか、そんなので大丈夫かレベルで。

この状況での選択肢は、問い掛けをして何が足らないとこちらが思っているかを考えさせながら会議の準備をしてもらう案とあれこれと指示をするマイクロマネジメント的な案の二つ。

若手エンジニアの勉強にもなるのでもちろん前者を選ぶわけですが。

やってというのは簡単

 冒頭の軍曹スタイルのリーダシップは簡単だし、楽なんですよ。決まったやり方(若手エンジニアの会議準備の場合はこちらが考える会議運営)をその場で説明して、その通りに準備させ、会議の進行もその通りにやらせる。

全部、指示してやらせる。

その指示には若手エンジニアが考える余地はなく、こちらが考えた台本通りにオペレーションするだけ、です。

台本からずれれば間違いを指摘し、間違わなく出来るようになるまで(時間があれば)繰り返し練習をさせればいい。

ほんと、オペレータなんですよ。軍曹の。

指示通りに出来ることも大事

 ただ、こうした指示してその通りやらせるのも全くダメというわけではないですよ。

軍曹が候補生が技術を身につけるまで繰り返し指導するのは、最悪、候補生たちが死んでしまう可能性があるため、そうならないように基本を教え込んでいるんですね。

システム開発でもそうです。システム更改で移行作業での本番切り替えは手順書通りにやらないといけないし、手順書と違う現象が起きた時点で作業を止めてプロジェクトマネージャの指示を仰がなければならないです。現場のエンジニアが勝手に判断してはいけない。絶対。なぜなら、異常を無視して続けて作業をすることで本番環境に影響を及ぼしてしまう可能性があるから。

ただ、弊害の方が大きい

 命に関わるとか操業に影響が出るなど決まったやり方をやらないとまずい現場もあります。

ただ、いつも指示ばかりしていては、指示をされる側のエンジニアは命令を待つことが仕事になってしまうのですよ。

ここがまずい。

軍曹なプロマネがいつまでもいるとは限らないし、組織の中ではいつかいなくなるものです。

 そのとき何が起きるかと言えば、口を開けて指示を待つエンジニアです。雛のまま大きいお友達に育ってしまい、自ら考えることができなくなってしまったエンジニアがあなたの周りにゴロゴロいませんか。

エンジニアだって気をつけないと。自分で考えて行動できないエンジニアになってしまうとキャパ超えて指示され、パンクしますしね。

どうやるつもりか教えてもらう

 冒頭の若手エンジニアにどう接したかというと、どうやるか教えて、と。ひたすらどうするつもりかを根掘り葉掘り聞いていく。

時間配分、段取り、想定問答、セッションごとの目的(=ゴール)。

まあ、何も考えていませんね。大項目、つまり、議題だけ並べているだけです。そこをどう進めていくかを質問をしながら考えさせる。

自分で考えないと自分で作った台本にならないので。

練習をさせる

このくらいで準備はいいかと思えるくらいまで具体化できたら、同じ時間を使って、声を出して一人で練習をするように言います。言いました、か。

実際、声に出してみないと本当の時間配分が実感できないですし、アドリブで話そうなんて思っていたら、その場面にならないと頭真っ白になりかねないですし。

手間ですよ

 ほんと、手間です。でも、こっちの選択肢の方があとが楽です。独り立ちできるので。

 

 

フルメタル・ジャケット [Blu-ray]

フルメタル・ジャケット [Blu-ray]

 
愛と青春の旅だち [Blu-ray]

愛と青春の旅だち [Blu-ray]

 

 

 

プロマネの心理的不安と学び

空き時間があったので、前にプロマネの事例紹介をオファーされていて、いくつか候補は選んでいたのだけれど、そろそろなと思い2つ目のテーマをノートに書き出してみた。

書き出してみると、1/3はプロジェクト概要、2/3はプロジェクトの経緯になっていて、やっぱりスライドはいきなり書き始めるものではないな、と改めて思う。書き出したことはページのコンテンツになることは変わりはないが、オファーを受けた場の期待と開かれる場の目的がプロジェクトの経緯という武勇伝や俺すげえ系の独り舞台ではないからだ。

一通り経緯を書き出した後、冒頭のスペースに場の目的から要約的な箇条書きを書き込んで、それを軸にしようと取り敢えず仮設する。

 

事例を振り返ると、プロマネというプロフェッショナルな業務は面倒臭い職業だと思う。

 

技術に長けていて、顧客を巻き込んでリードできるエンジニアの資質を持っていたらプロマネなんてしていなかったかもしれないな、と。現実にはそれはないのか、単にまだ見つけられていないのかは不明だがこうやってプロマネを続けている。

事例を見返すと、あのプロジェクトをあそこまで出来たものだと思う。端的にはトラブっていたプロジェクトチームをチームとして機能するように立て直した案件だ。

プロマネとして前任からろくに引き継ぎもあるようでないようで、その中でいきなりリリース計画があって、案の定の結果になって。

まあ、あのリリースした日の酷さと言ったら、過去に経験がないほどひどくて。これをチームの中だけで閉じておくことは逆に現状を知らせないことになると判断して、役員まで巻き込んで中途参画した立て直しプロジェクトの現状の酷さを突きつけた。

どこの組織においてもプロジェクトは成功するもので、プロジェクトはプロマネがなんとかしてくれるものだと思っている節があるが、現実の世界はそんなことはありえない。

一から計画を作り、チームを成果が得られるチームへ作り込みながらプロジェクトを進められるならそう言った期待も答えれるように腐心することもするだろう。

ただ、それは自分が計画を立てた主役だからだ。成り行きで頓挫しかけたプロジェクトを立て直すのは話は別である。

そうしたプロジェクトでのプロマネには心理的不安しかない。立て直せなければ叱責され、前任者の失策を含めて責任を取らせられかねない。計画的に初めていれば様々なリスクのなかで最悪のケースを想定しつつ、大らかな気持ちで取り組むこともできるのにその余裕が一切ないところでのプロジェクトステータスのスイッチを期待されるのだ。

この事例では、当たり前のことを当たり前にできるチーム作りという基本がプロジェクトチームを助けるという学びがあった。もちろん、誰の当たり前かと言えば、それはプロマネの当たり前である。それを実現するためにはプロマネの期待を期待通りに遂行できるチームのマインドを刷り込み直すことと結果を評価することである。

当たり前のことを当たり前にできるエンジニアのチームになったとき、チームから解放されたのだった。

 

 

 

 

 

 

 

ソフトウェア開発に正しいとか正論は何も解決しない

要件は仮初めで変わるものなのだから、それに変化できるようにプログラムを作るのが当たり前じゃないか。要件が変わって容易に修正できないアーキテクチャやコードは…

 

TLに流れてきたつぶやきなんだけれど、どれだけひどい経験をしたのか、と不憫に思えなくもない。

不憫ではあるのだけれど、どこのレベルで言っているのか前提がわからなくて。何かとても狭い世界で毒を吐いているように思えるんですよ。

要件が変わる

ここは同意するんですよね。どうしてかというと、発注者であるオーナ自身が現物をみてこれを作って欲しいと言ったわけではないので。

RFPにしろ発注仕様書にしろ調達仕様書にしろ、 机上での話であって実際に動くソフトウェアを元に業務委託なんぞしていませんから。

こんなことを「実現したい(はず)」で発注しているので。受注側も「これを実現するんですね」と「はず」を前提に見積もっているんですから。

発注者側が実現されるシステムに対して確信を持って発注なんてしていないのです。ここが後から見れば要件が変わる、の1つ目になるのです。

受注側も「実現したい(はず)」を受注者の経験を参考に解釈して提案するのでここも解釈のずれから要件が変わったように思えるわけです。

要件は変わっても対応できないのはダメなのか

全く対応できないことって現実にあるんでしょうか。その点においては対応できないアーキテクチャもコードも存在しないのではないかと思うのですよ。そこがソフトウェアの特徴でしょう、と。極論を言えば、オーバーラップする新しいコードで旧コードを亡き者にしてしまえばいいのですから。極論ですけど。

でも現実に不要となった機能を削除することなく、残置する行為は発注者側と協議して残すことは見かけますね。監査対応ぽいですが。

 

それで、コードを直すのが容易かどうかか、それはあるかもしれません。でも、その容易かどうかってどんな基準なんですかね。

まず、それが疑問。いちゃもんを言っている割には定性的なんですよね。それも個人に依存しているのでどーでも解釈できるし、言っている側のポジションが一見正しく見える。

世の中で一見正しく見える意見は、全く価値のない暴言だと思わないこともないです。つまり、思っているのですが。

一見、正しいことを要求していても、じゃあ、それどう解決するのかと返せば、それはお前たちが考えることだ的な物言いになるやつ。

そっちの方がゴミですね。問題なら解決しないと。

 

確かに、保守性が良いアーキテクチャ、コードの方がいいに決まっています。それに対してどこまで求めるかというと制約がつくんですよ。

 

スタートアップなら、そんなことは言わずにまずは動くソフトウェアをリリースしないとスタートアップ自身が絶命するんですから。お金がなくなって。そこに、柔軟に要件が変わっても対応できるアーキテクチャにしろとか、コードを書けというのかということです。大事なことはお金がショートする前にリリースして投資資金を回収しろってことです。

 

これが大規模開発になるとまた別の例で同じようになるんです。例えば400人/月のSEにアーキテクチャやコードを書かせるのに柔軟性のあるコードを書けと言ってどれだけ目が届くかってことです。

これの大前提に400人/月としないとオーナの要件が実現できない(時間制約的にとかで) からオーナも受注者も合意してプロジェクトを始めるわけです。

このとき、何が重要になるかを考えればわかることですが、400人を同じ作業品質で同じ要求品質の仕様もコードも求められるんです。

それに必要なのは少人数でアーティスティックでエレガントなコードではないのです。エンジニアリングとしてしてのコードです。

もちろん、大量のコードが作られる(1700ステップ/月*6ヶ月*400人だったら40,800,000ステップですよ)のですから保守性の良いコードを書け、って言いますよ。エンジニアリングの観点でも。

正しさ、正論は役に立たない

 まーコンテクストが見えないとこのケースは考えているの事案になって面倒なだけですけれど、正論をいうのは教科書の中だけでいいです。

エンジニアの私たちは、少なくとも自分はオーナの課題解決をその課題解決に対する制約を考慮して合意した上で対処するだけです。

それが現場で求められるプロとしてのイズムですから。

正しさ、正論なんてそれこそ肥料にでもしてしまえばいいんですよ。

 

 

 

 

 

ランフラットタイヤの予約

この冬にスタッドレスタイヤに履き替えたとき、夏タイヤが消耗していたのでどうしようかと思い倦ねていて先週末から動き出した。

市内の南の方に個人商店のタイヤ屋さんがあって中古タイヤがメインで扱っている(もちろん、新品も扱っている)というので興味を持ってのぞいてきた。サイズとかランフラットだというと新品の見積もりしますね、と。

そりゃ都合よくランフラットなんて中古であるわけないかと思って新品を取り寄せしたらいくら位になるかを教えてもらうことに。

純正のアルミホイールは冬タイヤを履いているので、ホイールとタイヤで出してもらったらこんな感じ。

A店

アルミホイール MSW85 ¥55,300- 4本
タイヤ ブリジストン REGNO RE050 ¥98,000- 4本 

 うーん、想定はしていたけど15万越えかー。

こんだけするならとコストコに。

いやー、平日夜のコストコの電話繋がらないわ。タイヤコーナーで接客していたら取らないというか取れないもんねぇ。

で、コストコといえばタイヤフェア。行ってみたら、ミシュランのタイヤ祭り中。

順番に待って、サイズとランフラットで値段を聞くと、メーカーを確認されることなく、ミシュランのカタログを取りに行って端末で探して、取り寄せとのこと。ええ知ってます、毎回です。一瞬、インチアップして扁平率上げるかと思ったけど、同じサイズで。

ザクっと

ミシュラン Primacy 3 ¥96、x00

ぽい。ただ、コストコだとフェア中なのと、前回のスタッドレスを買ったときのプリペイドカードのキャッシュバック分がるのでそれで少し安くんる感じですね。

1週間から10日くらいでと言っていたので、そうなんだーと。

面倒なんでその場で注文。

さーて、ホイールを探すかなー。

 

コストコミシュランのタイヤフェアは連休までぽい。

 

 

 

 

1440分の使い方とここ20年くらいで学んだライフスタイル

 たまたま知った本が割と考え方が同じで、実際やっていることも同じだったので感想とか、自分の振り返りとか。

1440分の使い方 ──成功者たちの時間管理15の秘訣

1440分の使い方 ──成功者たちの時間管理15の秘訣

 

 スケジュールを埋めることが嬉しかったとき

2010年あたりは仕事的にも前のめりというか多忙であることとプロジェクトやビジネスをリードしていると思っていた時期で、それがスケジュールが予定で埋まっていく感じがある意味、自分が求められているのだという承認要求を満たしていたかもしれないな、と思ったりしたのです。

今は逆に如何に自分の作業をする時間を確保するかの方に価値があると思っていて、会議によっては出たくない(=会議目的がはっきりしないので出たくない)と宗教替えをしたような感じになっているのです。

我ながら面白いと思うのは自分の価値観が変わりやすい人間なんだなと。 

優先順ではなく優先順位

 優先順の高中低やHMLは全くの意味のないことは、それを実務で使っていて迷った経験を思い出すとそのやり方、システムに間違いがあると自ら気づければよかったけれど、実際に間違いだと気づいたのは、優先順位をつける(=1番から順位を振る)ことに意味があると経験をしたから。

それはアジャイル開発系の本やスライドで知り、実際に例えば課題管理表などでどれからリソースを割り振るかとか着手するかとかで順位をつけないと兵站が分散し、伸びきってしまうと実感したからなのです。

今、こうして書きながらもあのときにもアジャイル開発系の本を読む前でも順位づけを無意識にしていた、つまり経験していたことが本で形式知と融合して納得感が生まれたのかもしれないなぁと、良い思い出をつなぎ合わせてみたり。

朝の価値

早朝の冬なら真っ暗な時間帯に電車に乗り、さっとソーシャルをチェックして、席に座れれば仮眠し、開店したばかりのカフェの隅に陣取り、書き物をしたりやろうと思っていたタスクをこなしたりするようになったのは、誰にも邪魔されない時間を確保することの価値を見出してから。

これが夜だとさっぱりダメで。

あ、某ブルワリーだと、パイントのクラフトビールを2杯飲みきるまでに校正をしようとか、書き始めの書き物を進めるとかはパフォーマンスは出ないけれど、腰が重くなりがちなことを始めたり、ことを終わらそうとする気付には悪くはないかな。

ToDoよりタスクカード

 仕事を忘れる人が仕事を忘れないためにはToDoリストを進めることもあるけれど、いや、メモしたかを聞くくらいかな。今は。

自分のは、付箋に作業名と期限を書いて、ノートに貼っておくパターンが多い。時間をブロックすることも目的にするならスケジュールに入れてしまうのがいいのかもしれないけれど、今の所はそこまで可視化して他人がスケジュールを割り込んでくることを防止する必要性がないくらい時間をそこそこ確保できているから、ということもあるかもしれない。

また、仕事の内容が変われば、スケジュールをブロックする意味合いを持たせる必要性が生まれるかもしれない。

先延ばししない=すぐやる

 これはある時期からやっていて、特に他人から割り込んできたものは即返す=ボールを握ったままにしないという考え方を持っている。

自分の仕事は時間を確保していればどうにでもなるが、他人のリソースを当てにするのがプロマネやマネージャの仕事でそれに慣れていると、依頼されたものは先に片付けておくとか思ったりもする。

まあ、どっちかというと今やらないと忘れてしまう危険性があって、それをやってしまうと忘れたことに気づかされてそれがどんなに価値のない作業であっても返す義務がある場合、重要な作業をしかかって中断したくなくても中断せざるを得なくなるので、すぐるやるようにしている、はず。

罪悪感なく定時に退社する

定時であろうが、中座であろうが、それをする必要があるときにはさっさと出ますね。これは定時前に出勤するようになってからするようになったけれど。

確か、その時は外部団体での活動もしていて、それの会合の都合からも早く出る必要があったから、だったからかもしれない。

今は、定時だからピンポンダッシュ、ではないけれど、定時になればシャットダウンして、机の上はほぼ何もない状態で帰る。

罪悪感なんて覚えるのは最初だけだし。

というか立場的にもマネージャは定時で帰らなければならいと思っている。もし部下が残って入れば何時までやるのかを聞いて確認するし、あとで周りに聞けば(結果的に嘘になって)長時間仕事をしていてもわかるし。もちろん、勤怠に入っていなければ指導するし。

それよりは勤務時間内に終わる作業計画を立てるように指導している。そうしないと続かないので。

ノートを取る

 備忘で取る感じが多いか。今は。アイデア的にメモを取ることもある。それ、ビジネスになる鴨とか。

部下やプロジェクトチームのメンバには、いきなりスライドを作るな、と言っているのですよ。スライドにしてしまうとアイデアや何を伝えるかより、クリップアートやたくさん知っていることを書くことが目的になってしまうので。

だから、A4かA3のコピー用紙かノートに描いて、頭の中で知っていること、書きたいことを全部出し切ってから作業としてスライドに転記する様に言っている。

なかなかわかってもらえないが。

メール

Webメールになるとどうも検索でなんとかできてしまうので受信トレイに入れっぱなしになってしまう。

でも、以前はフォルダ分けしていて、処理したらフォルダに移していた。Webメールでそれもできないものは、勘弁的にタグ付けするルールを作っておくこととしかできないが、それはそれでフォルダに移すことと論理的には識別の観点で同じなのだろう。

ミーティング

 基本的に自分が主催のミーティングでは連絡はほぼ皆無。リマインダ的に数分でおしまい。

あとはチームの共通の活動に全て当てる。ある意味モブミーティングであり、モブチーム活動である。

チームの目標をバラバラでやる意味はない。とは言え、集まって議論をしていても何も生まない。

チームのメンバに、チームの目標をどう仮説を作り、計画を立て、やるのかに時間を使う。

noという 

 いや、Yes,butだな。コンプライアンス上問題がなければ、プロのイズムと不整合がなければ。

ただ、作業の割り込みは、自分がつけた若しくは協議した優先順位があってそこに割り込むので、どうするかは決めなければならない。

その割り込みをすることは可能だが、優先順位をつけたバックログは順送りになるし、もちろんそれぞれの納期は繰り下がるが、よろしいか、と。

ここまで言い切らなければ、ただの都合の良いエンジニアでしかなく、この調整をしないエンジニアは切られる。単なるリソースの駒でしかないからだ。

パレートの法則

これまでのエントリに書いてきたとおり、20%にリソースを割かなければならない。プロジェクトも人材育成もビジネスも。

怠ける

エンジニアのある時期から、プロマネであるなら、マネージャこそ、怠けるために、楽をするためにどうしたらいいかを準備し、実践し、改良する。

まさに継続的改善の実践である。

ただし、怠けるのが妥協ではいけない。

今日のテーマ

 今日何するか。これを片付けよう。朝、ベットから起きたときにそれが頭に浮かぶ。そうでなければ仕事なんてやっていられない。

ミーティングでもそうだ。

なんども繰り返し作業しない

 1つの作業を何度も初めから繰り返し見直したり、手を入れたりすることが非効率的な作業の仕方だ。

 このくらいでいいというのは妥協である。ここまでが慣性基準だから、ここまでとやるのが良い。

メールをビジネスで使うことがまだ多いが、尋ねるときには何度もやり取りをしない様に、尋ねたい、期待する結果を1回送信するメールで得られる様にする。でなければチャットでいい。

まあ、チャットでも聞きたいことは1回で期待する結果が得られる様にしなければならない。

メールは伝えようとしている期待値の1/10しか伝わらないことを知っておくべきだ。

不可侵時間帯

 朝の価値で書いたとおり。

エネルギー

朝摂っている食事を変えた。いわゆるバターコーヒー(完全無欠)にしたら昼食まで間食を取らなくなったし、お土産のお菓子に手をつけなくなった。

お菓子を食べているエンジニアが痩せないと言っているのは自分の行為を計測で規定兄からだ。

1週間

朝起きる時間を一定にすること。週末にジムに行くこと。平日の夜は予定で産めないこと。自分のリズムを作り、一定に保つこと。

 

朝を変える

朝が一番価値がある。頭が冴える。夜は寝る時間だ。

 

この他にも50年も生きて入れば色々と実践している元になっているイムズも価値観もある。けれど、この本に書いていあることは外れてはいない。Kindleならお手頃だ。

 

1440分の使い方 ──成功者たちの時間管理15の秘訣

1440分の使い方 ──成功者たちの時間管理15の秘訣

 

 

作業完了の妥協はダメエンジニアを増殖させる

座席の都合、席に戻るときにメンバの横を通ることになるのだが、ときどきメンバに声を掛けて雑談をすることあるのです。大体、声をかけるときは、何かしら気になることがあって立ち寄っているわけです。

あるメンバの仕事の仕方というか、アプローチが気になっているんですね。もう、ずっと。何が気になっているかというと、仕事の終わらせ方です。

終わらせ方と言っても、定時になってスッと帰るとか、机の周りの片付けとかではありません。

作業の完了のさせ方、です。そうですねぇ、アジャイル開発風に表現すると

 

作業の完了と言っているけどDoneの定義に照らしても完了と言えるのか

 

とい感じですかね。

完了の定義

作業の完了とは何か。それを決めずに作業を始めてしまい、レビューを受けて何度もリジェクトされ、不貞腐れるケースを見たことがあります。

あー、作業の完了を理解しないでやっているからだよ、と思うわけです。 別に作業の完了基準はアジャイル開発が広く普及してから広まった考え方ではありません。

ウォーターフォール型のシステム開発でも、工程毎の成果物の作業プロセスや品質管理の品質要求などでこれらを満たさないと当該工程をexitできない、とするやり方は昔からあるので。

形式が強くなるとexitさせることが目的となって何のための完了条件だかわからなくなっているケースもあるようですけどね。詳しくは知りませんなー。

話を戻して、結局は、何を満たせば作業を終わり、と宣言して良いか、その基準が完了の定義です。

それは手続きかもしれないし、定量的な測定結果かもしれないし、審議結果かもしれない。

どれも全部、基準なんですよ。基準。

完了という根拠はどれ

基準を理解して作業をしていない、基準を設けずに作業を始めてしまうことは、その成果物を修正する必要がある場合に、作った本人はあとあと困るんですよ。

何が困るかと言うと、まず、完了と言える根拠がない。

この基準を満たしているから完了だ、と言えないわけです。

なぜか。

自分で決めたから。

でも、それは受け入れられません。チームで作業をしていればチームの作業の完了の定義があり、それを全員で守らなくてはメンバ毎にバラバラな作業品質の成果物ばかりになります。

それでプロジェクトは上手く行くかと言えば答えは決まっていますよね。

基準を満たしていないから不機嫌になる

 もちろん、自分の作業だから自分で決めるという人も出てくるだろうけれど、それは自分がスポンサになる作業だけ言えることです。

スポンサから対価をもらって作業をしている(内製でも同じですよ)のだから、スポンサの利益(=契約があるなら契約を満たせばいい)になっていないと。

自分の基準で作業を完了だと言ってしまうメンバは、自分がそこで終わりにしたい何かしらの理由があり、それは大体、本人が本来ある基準に満たしていないことをわかって自己判断しているケースばかりです。

つまり、ウイークポイントはわかってやっているんですね。

だから、そこを突っ込むと不機嫌になるんですよ。痛いところを突く、というやつです。

対策

 シンプルです。ときどき書いていますが、作業プロセスを決めて着手する前にアウトプットイメージを作業をする人に説明させて、完了基準を合意してからやらせればいいです。

ただ、作業をやっていると本人は忘れているので、何度でも基準に満たない作業はリジェクトし続けてください。

プロジェクトの推進で影響が大きいようだったら、入れ替えとしたいところですがマネージャの立場だと、覚えるまでリジェクトをする他ないですね。

 

 

 

よつばと!(14) (電撃コミックス)

よつばと!(14) (電撃コミックス)

 

 

 

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

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で埋めていくのか。

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

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