ミスター流暢と。今日は仕事終わりか？はい終わりました、今夜の予定は？ジム通いを再開したのでレッスンの後行く予定です、とか手短にスモールトークが終わってすぐレッスンへ。初期のミスター流暢っぽい流れ。そして今日は彼の部屋の照明の色の関係かいつも以上に白く映っていた。
Lesson 6 の内容をおさらいしつつ Try の 2 から。他部署へ異動させる際のリスクをどう manage する？という話に、できるだけ avoid するために training を〜、と言ったら「トレーニングするということはリスクを control するということだぞ」とツッコミが。なるほど。正直この辺の四つの risk management の考え方とかはあんまりピンときてない、ちゃんとわかってない自覚がある。日本語でもろくに勉強したり教わったりしてない分野なので。この Try のやりとりはミスおすすめが割と細かく進めたのに対してミスター流暢はサラッと進める感じだった。
Lesson 6 の Act で「ブレストのレッスンではどういう問題をテーマに話し合ったんだ？」と聞かれて、慌ててブログの過去記事を見て話した内容を思い出した。書いててよかったビズメイツ日記。しかし「新サービス開発に使う技術を〜」という話は前提を長く話した後に「ちょ、待て、それで問題は一体なんだ？」と言われてしまい、「使い慣れているが廃れつつある（は言い過ぎなのだが）技術を採用し続けるか、経験はないが将来性のある技術に挑戦するか」「古い技術を使い続けると将来の採用活動にも響く」などと説明し、「結論として、そのプロジェクトは実験的な位置付けだったので技術的にリスクの高い選択をしても問題ないと考えて accepting the risk した」と説明したらようやくある程度腑に落ちた顔をしていた。
（余談だが、そのプロジェクトはビジネス的には実は実験的でありつつも戦略的に非常に重要な位置づけで、失敗のリスクを取るべきではなかった、というのが後々わかった、という裏話がある。今振り返れば、典型的なビジネス側と技術側で意思疎通が十分に取れてない失敗パターンだった。技術的には得るものも少なくなかったし、技術選択ミスが理由でプロジェクトが失敗したというほどの悪影響はなかったが、不慣れな技術で試行錯誤しながらシステムを開発し、大幅な作り直しなども強いられて開発スピードは遅かった。これを開発側は受けいれられるとみなしていたが、ビジネス側の本音では、技術的なチャレンジは他の機会にしてこの重要プロジェクトは速度最優先で進めてほしかった、というのは大いにあったのではと思う。まあ、そんなこと言うとどの新規プロジェクトもビジネス的には重要で技術リスクは取りたくないわけで、そこをどうにか通すのが engineering leadership の仕事であり腕の見せ所なのだが、しかしあのプロジェクトはそれに相応しかったか？といえば反省の余地はあったと思う）
Lesson 7 もサクサク進んで Try まで終わり、Act を残すのみ。ここもミスター流暢サクサク進むので、予想外に進んだ。事前にギリギリ予習しておいてよかったけど予習のストックがなくなった。次は Lesson 7 の Act から。ちょっと別の problem at work を考えておかないと。明日は初めての女性トレーナーを予約してみた。お気に入り陣の予約がイマイチな日はなるべく新規開拓を躊躇せずやっていくようにしてみたい。
- calculated risk
- RISK
- 1.Lack of required skills
- 2.Mismatch skills
- 3.Lower productivity
- 4.demotivation
- 4.Employee turnover
- space = venue/location
- financial support
