今プロジェクトが抱えている課題を、
ツールを使ってどうにか改善できないかと考えてみました。
概要
現在所属しているプロジェクトのメンバーは皆熟練のメンバーで、
今のシステムをもう何年にもわたって保守しています。
彼らが継続して行けばこのチームは安泰でしょう。
しかし、プロジェクトの情報の殆どは彼らの頭のなかにあると言っても過言ではありません。
同じメンバーで永遠に回せるプロジェクトはありません。
いつかメンバーが入れ替わる日も来るでしょう。
そうなった時に別の人にすべての情報を引き継ぐことは困難です。
現実的に、メンバーのうちの一人が入れ替わった際、
そのメンバーが担当していた領域の引き継ぎは十分ではなく、
多くの情報は失われ、現在その領域を十分把握している人はいません。
メンバーが変わるたびにこれを繰り返していけば、いつかプロジェクトが破綻の危機にさらされることでしょう。
そうならないために、どんな準備が出来るか、プロジェクトをどう変えていくのが良いかを検討しました。
検討
現在のプロジェクトはいくつかの潜在リスクを抱えています。
人に依存した体制であるがゆえに、人の増減に対応が難しくなっているのです。
・人の入れ替えに対応出ない
プロジェクトに関わる知識の多くがメンバーの頭のなかにあります。
作業依頼時などは話が早くて助かるのですが、人の入れ替わりがあると多くの情報が失われてしまいます。
引き継ぎを十分すれば良いと思うかもしれません。
作業手順や、資料の場所などは引き継げるでしょう。
しかし、問題が起こった場合の対処法や、どんな問題が起こった時に具体的にソースコードのどこをいじればいいのか、通常取らない方法で実装してある場所がどういう経緯でそうなっているのか、などの情報は往々にして失われてしまうのです。
全ての情報を限られた時間で引き継ぐのは現実的に不可能です。
事故や病気など、場合によっては引き継ぎを行えない可能性もあります。
・人を育てる準備がない
人を育てられない環境とは思いません。
ただ、育て方が一昔前の、人が指導しながら覚えてもらうという教え方なのです。
私は、「１度聞いたことをその場で完璧に記憶して、２度同じことを聞くな」という考えを否定しています。
最近はそういった考えの人も増えてきて、「覚えられるまで何回聞いてくれてもいいから」と言う人も多くなりました。
ただ、そうは言ってもらえても何度も聞くのは心苦しいものです。
それにコストもかかります。人に聞くということは、聞く人、教える人の両方の時間を使います。教える人の集中も解けてしまいます。教わる人もひとりではないですよね。
プログラムでさえ３回使うなら共通メソッドを作りましょうというぐらいなので、人を育てる手順なども資料化しましょう。
１度教えて、わからなくなったらここに必要なこと全部書いてあるからという資料があると理想的だと思います。
・情報の共有が十分でない
開発や修正、その詳細が作業者とレビュー者の間でしか共有されていません。
会議の資料は基本的にその場限りのもので、どこかに整理されて保存されているわけではありません。
作業の詳細な途中経過がわかりません。
上記の２つと関係するところでもありますが、
その開発や修正に関わっていなかった人に、その情報を伝えるのに大きなコストがかかります。
属人化の問題点のひとつは、人を動かせないことです。
他のチームが困っている時に人を送れない。
膨大な作業量を抱えてしまった時、他の余裕のあるチームから人を借りても育てるコストが無くて使えない。
結果的に担当者は残業や休出など大変な思いをして作業をこなさなければならない。
会社も余計なコストを負担することになる。
閉塞的な属人化はメリット以上のリスクをはらんでいるのです。
対策の方針
- メンバーみんなが現状をいつでも知ることが出来るようにする
- 後から遡れるようにする
- プロジェクトに参画するのに必要な情報を一箇所にまとめておく
この３点が実現できれば、属人化によるリスクは大きく軽減出来るかと思います。
使用するツールとその運用方法
Wikiの使い方（redmine付属）
プロジェクトに参画するのに必要な情報を書いておく
- プロジェクトごとに分ける
- プロジェクトを開始するに当たって必要なことを書く
- 資料の保存場所
- リポジトリの場所
- パスワード類
- プロジェクトに必要なルールを書く
- 複数のwikiを見なくてはならない状態にはしない
gitの運用
状況をいつでも把握出来るようにする
後から遡れるようにする
- ローカルではredmineのチケット単位でcommit（混ぜると後から追いづらくなる）
- commitやpushは必ずエラーの出ていない状態で行う
- ある程度まとまったらpush、１日が終わり帰る時には必ずpushをしてから帰る
- （管理者やリーダーはこれを見て途中経過のレビューを行うことが出来る）
redmineの使い方
開発や修正の経緯をまとめておく
関わる資料をまとめておく
- １つのチケットでは１つの課題を解決する。複数の課題を１つのチケットに載せない。
- こまめに追記する
- 口頭やミーティングで確認したことも必ず追記する（情報の集中化）
- 口頭やミーティングで確認した際はその旨を記載する、また、コンタクトを取った相手の名前を記載する
- チケットには必ず終了条件を記載する（ペンディング中のチケットが増えてくると）
- リーダーは以下を把握しておくこと
- 当面の課題一覧
- 現在進行中のチケット
- 各メンバーの登録内容
- チケットの完了は必ずリーダーが行うこと。メンバーが勝手に完了していることが無いようにする
- 基本的には複数のチケットを同時に進行しない。複数同時に進行する場合は必ずcommit、pushは分ける
- redmineに記載したら、そのこと、その内容を担当者に改めて口頭で確認、説明してもよい
jenkinsの使い方
リリース用リポジトリを明確にする
ビルド環境を開発者個人のPCに依存させない
- ビルド・デプロイ用
- ビルド後自動テスト
- ビルド用のリポジトリにpushされたソースコードを自動的にビルドしデプロイする
- リリース用のリポジトリが明確になる
Slack（チーム内Twitter）の使い方
コミュニケーションの潤滑化
助け合い
リーダーの負荷軽減
- 仕事プライベート分けずになんでも記載（コミュニケーションの潤滑化）
- 困ったことはすぐ記載（リーダー経由ではなく、メンバー同士での助け合い。リーダーの負荷軽減）
- こまめに見る（１時間に１回程度は。見なければコミュニケーションも出来ないし他の人も助けられない）
導入の仕方
順次導入が望ましい
※一度に全てのツールを導入するのは難しい（覚えることが多いと往々にして利用されなくなっていく）
最優先で導入するもの
- git
- redmine ※gitとredmineはそれぞれ連携すること
運用の仕方
- redmineはこまめに更新する
- 問題に対してどうアプローチしたのか
- 他の人とどういう会話をしたのか
- gitとredmineは連携する
- gitとredmineへの投稿で、どんな経緯でどのような修正を加えたか追えるようにする
- redmineと連携しないcommit、pushは基本的にしない
- gitは必ずエラーの起きない状態でpushする
- 帰る時は必ず途中経過を（エラーの無い状態で）pushする
- 途中経過をpushしづらいような規模の修正の場合ブランチを切る
この他のツールは慣れてきてから順次導入していく