ある特定の条件下に向けて書いているが、まあどこでも適応できそうなのでメモ代わりに残しておく。
- 設定（架空のものですｗ）
- ターゲット
- 特定の商品のソフトウェア開発
- 人員（１０人程度）
- ディレクター
- 既存チーム員
- 新規チーム員
- 状況
- ターゲットはマネジャーと既存チーム員にはターゲットをある程度理解している人がいる。
- 開発手法はウォーターホール
- ターゲット
昔ながらの開発手法のチーム向けに、なるべくコストを低く、AgileやScrumなんかを知らなくても導入できる。（手法は使うけどね）
重要やることは３つで、「用語の統一」、「理解の最低ラインをそろえる」、「報告できる状況を作る」。
- １．用語の統一
抽象度の高い言葉を使うと互いのコミュニケーションコストを下げることが出来る。
だが、反面ちゃんとその用語を理解していないと相互に物事の理解に乖離がでる。
要するに、言われたことが理解できなくて、無限ループしたり、見当違いの事をやりはじめたりする。そういうことが起きにくいようにするために用語の統一の必要性がある。
- ２．理解の最低ラインをそろえる
対象となるプラットフォーム全体の概要、個々の大雑把な機能、実装する機能の概要と担当者をチーム全員が理解するようにする。
なぜ、プラットフォーム全体の理解が必要かというと、実装する機能はプラットフォームの複数機能にまたがる、またオーバーレイすることが多い。
そのために、どこの機能とどこの機能がつながっているかを知ることで、問題が出た場合に確認しなくてはいけない場所の判断が早くできる。
また、その機能の担当者（一番理解している人）は誰かを知っているということで問題点を発見した場合相談する相手がわかる。
スケジュールに関しても、全体の概要やその中での実装機能を理解することでどの程度のリスクがあるか推測しやすくなる。
- ３．報告できる状況を作る
全員社員で垣根がないという状況は作りにくいと思う。（もちろん、そじゃない場合もあるよ）
そのため、報告して現状を早めに（主に）問題点を共有出来る状況を作る必要がある。
さて、この３つのやることをどのように日々業務の中に入れるか。
運用方法することは２つ、週１回、１時間の勉強会。１日１５分の朝会。（＋その後の調整時間）
- １．週１回、１時間の勉強会
「用語の統一」、「理解の最低ラインをそろえる」を行う時間。
１回目は、ディレクターや既存チーム員の1人が全体概要とスケジュールを説明・共有する、最後に質問の時間を取る。この時、議事録を既存チーム員が取る。
既存チーム員が議事録を取るのは、最低ラインの議事録レベルを規定するため。
２回目以降は、既存チーム員がコアになるような部分から中心に仕組みなどを解説していく。４回目ぐらいからは新規チーム員が担当するモノを入れていく。
議事録は、新規チーム員に持ち回りでやってもらう。（回数により既存チーム員が行ってもよい）
開催スケジュールは１回目にだれが何に関して話すかを伝える。１回目と２回目は、はじめる前にだれがやるか決めて下準備しておく。
開催日のお勧めは、月曜日など割り込みが入りにくい日の１１時など昼１時間前に行う。昼になる前にはかならず終わらせる。
議事録に関しては、その日のうちに配布して、次の日の午前中までには確認してもらうようにする。質問などがあれば、メールに書いて送る。
- ２．１日１５分の朝会（＋その後の調整時間）
「報告できる状況を作る」を行う時間。
要するにScrumの朝会。
１５分で、全員の昨日の作業、今日の作業、現状の問題点（心配点）を上げる。（１０人だと１人１分強ぐらい）
司会は持ち回りで、週１回勉強会の１回目にでもくじ引きで順番を決める。
司会といっても、朝の挨拶と自分の報告、次に誰が喋っていくかを決めるだけ。（時計回りとか、５０音順とか）
ポイントは、現状の問題点（心配点）で、スケジュールなどはディレクターへ、機能的なものは担当者へ、朝会後に相談させてくださいということ。朝会が終わった後すぐに問題点をどのように進めて解決するかを決める。
「用語の統一」出来ていると最低限の言葉で報告が出来る。
「理解の最低ラインをそろえる」が出来ていると、誰に何を聞けばいいのかが把握できる。
やることや運用方法がわかったところで、この仕組みを強く運用すると思う人達が進めないと成り立たない。（なんでも、仕組みはそんなもんだと思うが）
運用者は、ディレクターががなるのではなく、既存チーム員の中から１人この仕組みを運用者を決め、その人がメインで運用する。（ディレクターは助言やサポートに回る。メインの人が休みの日などは変わりに運用する）
仕組みの運用者は、現状を理解し、何が重要で、何はやらなくてよいのかよく考える必要がある。（ディレクターや既存チーム員と相談して）
また、運用者がやる気のない態度で行うと伝搬して、あまり意味のない作業になり無駄なコストになるだけなので注意する必要がある。
本来は、５人程度のチームで、この運用方法を理解しているディレクターがいると上手く回るんだけど。そうそう、そういう状態は無いだよね。
これ以外に、チームメンバーの能力とか、モチベーション（ストレス）マネージメントとかあるけどそれはこれ以前なりのによるので。。。
以上、おしまい。
追記
新規チームや新メンバーが入るとは、コミュニケーションを取らないやコミュニケーションロスなんかが一番時間を取る。
開発序盤の、わからないことを聞かないで無駄な時間をかけること。開発終盤になり、連携が必要なところでチームとしてのコミュニケーションがスムーズに行くと問題解決が早くなる。
メンバーの能力アップは対象となる個人が自ら学習しないと上がらない。もちろん、周りの人間がお勧めの本や、わからないところを教えてあげること話可能。だが、あくまでも助けるだけである。（コミュニケーションが円滑に回っていればフォローする部分の負荷も減るしね）
メンバーのモチベーション（ストレス）管理、チーム内での円滑にコミュニケーションが出来ていれば。自分の能力を超えていて難しい作業、チームメンバー、作業環境、外的要因の使用追加辺りだと思うので、マネージメント層がフォローする範疇になる。
。。。読み直して、楽観的すぎじゃねというところもあるがでもこんなもんだよねと思う。
