現チームで育ってきた開発プロセスについて
はじめにお断りをしておきますが、今回のエントリは「マネージャが作った」というよりも「チームがいつの間にか作ってた」開発プロセスの話です。マネージャがチームを引っ張って、こんなに良い開発プロセスを作ったんだみたいなエントリを期待されている方がいれば、ご期待には添えませんのでそっ閉じしていただければと思います。
開発プロセスについて思っていること
\個別最適サイコー/
と言ってしまうと色々と語弊がありそうですが、このくらい乱暴に表現してしまった方がいいでしょう。もう少し正確に言うと「チームのメンタルモデルに最適な開発プロセスを採用する」のが一番良いと思っています。
開発プロセスは、メンタルモデルを矯正する助けにもなってくれますが、あまりにもアンマッチが激しい場合は邪魔にしかならないと思うのです。また、チームのメンタルモデルはメンバー個々の力量や性格、背景やおかれた状況なども絡み合って構築されています。開発プロセスはこうだ！という感じで押し付けるよりは、ふりかえりなどでそれらのいい面や課題を可視化しつつ、チームで採択する方がいい結果になると思っています。
実際のところ、無からプラクティスを作るのは大変なので、様々うまく行っているプロセスを参考にはしています。ただ、教条的にやろうとすることはほとんどありませんでした。
ざっくりどんなプロセス？
広義のチケット駆動開発と言ってしまって良いかな、と。redmineを中心的に使って、プロジェクトのすべての情報が集約されるようにしています。
ここに落ち着いたのは次に挙げるようないくつかの背景がありました。
redmineの運用ノウハウは割とある
プラグインをがんがんいれたりとかはしていないのですが、リモートチーム同士が作業していた関係上、私がチームに入る前からBTSとしてredmineは割と使い倒していました。具体的にはワークフロー管理やカスタムクエリ、ロードマップあたりをどうやって活用するかというノウハウです。情報を一元化して把握するという意識についてもredmineの活用の中で持っているようでした。
ツール面ではredmine一択です。というか、ここまで把握していてツールを変えようとする人がいたら見てみたいですね。
マネージャ「俺は複数のファイル見ながら管理なんてできない」
このマネージャ、頭が弱いせいかすぐにファイルをどこに置いたか忘れます。資料が一元化されていないとすぐにパニックになってしまうんですね。3つも資料を見ながら仕事しなきゃいけないとかもう最悪です。仕事になりません。
また、品質状況が極端に悪いプロダクトを引き継いだので、不具合の発生状況が安定しているとは言えません。唐突に今進めているプロジェクトのどのタスクよりも優先度の高い不具合が入ることもあります。そのときにタスクが迷子にならないようにしてリリース計画を立て直したりが必要になるため、一元化しておく必要がありました。
というわけで、マネージャが必要な情報については一カ所に集めてもらうようにしました。マネージャが不出来だとチームは大変ですね。。。
受託だけど(だから)割とプロセスの押しつけは緩い
一括請け負いなので、契約時の打ち合わせと中間報告、受け入れ判定が決められている程度です。具体的な開発プロセスや成果物のフォーマットなどは思ったより自由度があります。求められている資料以外については、効率の良い方法を採用していっても怒られることはなさそうだったので好き勝手にやることにしました。
マネージャがプロダクトについて一番知らない
プロダクトに携わり始めた順番からすると、チームメンバーが先でマネージャは後からです。というかテストもやっていたので、プロダクトのことについてはだいたいメンバーが知っています。もうこの時点でマネージャは雑用決定です。メンバーの知見がちゃんと見えるようなプロセスになるようにしなければ成り立ちません。
具体的なプロセス
というわけで具体的なプロセスです。世間様に発信されているかっこいいプロセスとはほど遠いので、言葉を話し始めた孫を見る祖父母のように生暖かく見守っていただければ幸いです。
プロセスは大きく分けて4つのフェーズで構成されます。
- リリース計画フェーズ
- 見積もり、計画フェーズ
- 設計、実装フェーズ
- リリースフェーズ
一つのリリース単位をプロジェクトと見なして上記フェーズ1周することが一回の開発プロセスです。
1.リリース計画フェーズ
スケジュールについてはチーム主導ではなくクライアント主導です。
定期的にある案件の場合は、カスタマイズ案件の予定もふまえて、クライアントから希望のリリース時期と予算を伺います。それをベースに大まかな予算感に合う現実的にリリース可能な機能の見積もりをしてリリース計画を調整します。
不具合が発覚した場合は、希望のリリース時期を伺った上でリリース計画を調整します。このとき、まだリリースしていないプロジェクトへの影響が有る場合は、そちらも調整します。
どちらの場合も、やるかやらないか決まる前からチケットとして登録しておきます。予算感と合わなくてやらないことが決定したものについては、それがわかるように「今はやらないことリスト」として使っているロードマップに登録します。
実際に計画を立てるのはメンバー全員でやっていますが、仕事のほとんどは調整だったりメールをやり取りすることなので、マネージャ主導で動いているフェーズです。この時期はだいたい前のプロジェクトのリリースフェーズだったりするので、メンバーがやることないとかそう言うタイミングではないです。
2.プロジェクト計画フェーズ
リリース計画時点である程度設計というか方針はチーム内で合意できているのですが、クライアント側でやることが決まりチームにそれが伝わった時点でもう一歩踏み込んだ視点で設計や計画について議論します。
ここで具体的な設計についてチームで合意した上で、粒度が大きすぎるようであれば子チケットを発行します。問題に対する疑問点をクリアにして、扱いやすい大きさにしていくフェーズです。チケットが出そろったあたりで対象チケットをロードマップに登録して、プロジェクトの進捗を把握できる状態にします。
個別のフェーズとして扱うか役割が微妙なところですが、チーム内のキックオフに相当するので区切りとして意識しています。
3.設計、実装フェーズ
ここからがチケット単位でチームが動くフェーズになります。チームが一番かっこいいフェーズです。
ちなみに、このフェーズでやっていることに対して私がトップダウンで決めたことはほとんどない気がします。ふりかえりで課題を出しながらチームでコツコツと改善していった結果です。やっている内にチーム内で固まってきたルールがいくつかあるのでご紹介します。
完了基準を決める
チケットだけではなく、チケットのステータス遷移も同様です。完了基準を明文化することで、進捗状態の把握が非常にやりやすくなりました。
例えば、チケットのフェーズである「対応完了」は「単体テストまでやって(必ずしもテストコードではない、後述)コードレビューが済んだ状態」ですし、チケットそのものは「対応した人とは別の人が検証した結果が残っていること」を完了基準にしています。
なお、進捗の把握は完了しているかどうかのみです。どのくらい終わっているかは見込みとして聴くことはありますが、管理対象にはしていません。
議論はチケットのコメントに残す
質問や確認事項などがある場合はチケットのコメントとして残します。メールだと絶対埋もれます。チケットにトピックがひもづいて展開されている議論の方が圧倒的に見やすいです。
定期的な棚卸し
週一回プロジェクトの進捗状況の確認も含めてチケットの棚卸しをします。
- チケットの対応内容で共有が必要なこと
- 手つかずのチケット
- 進捗が止まっているチケット
を特に確認し、マネジメントレベルで何かやらなきゃいけないかどうかを確認します。
このときに手つかずのチケットについては、アサインしていきます。
機能もタスクもバグもすべてチケット
とりあえず、何かチームでやらなければならないものはチケットにします。チケットあげて、ロードマップさえはっきりさせておけば保留していったん忘れることも可能です。棚卸しで見落とすことを防ぐために、現ロードマップに含めないといけないことかどうかは判断する必要がありますが、その判断さえ済んでしまえば今やるべきことに集中すべきです。
4.リリースフェーズ
設計・実装フェーズのチケットが一区切りついたら、関連アプリケーション(別会社)との連携テストをしてリリース準備に入ります。この辺になると、私が受け入れ判定に使う資料やデータを集めながらメンバーにリリースの準備をしてもらう感じになります。
残念ながら納品という儀式がありますし、リリースするサーバは業務上直接我々の管理下にないものがほとんどです。そのため、かなりマンパワーに頼る定型的なタスクが発生します。これらの定型タスクを事前に作っておき、リリースフェーズになったらコピーするというのがいつの間にか出来上がってきた流れです。
やったこと
マネージャとして気をつけてきたことを幾つか。
「プロセスは変えて良い」という意識付け
便利になること、効率が上がること、品質に寄与することであれば、前にやっていたやり方に固執する必要がないことをふりかえりを使って意識づけるようにしました。どういう解決策を取るかも、ふりかえりの中でメンバーに出してもらっています。ふりかえりはこの手の意識付けにも非常に有効だと思います。
ドラスティックに変えない
まあ、マネージャである私が一番自信つけたかったというのもありますが、今のチーム体制になるまでの経緯もあって、チームに「俺たちはやれる」という自信をつけてもらうことがまず第一だと思っていました。そのためには全てチャラにして手探りでやるよりも、自分たちで取捨選択して少しずつ変えてもらう方が良いので、変化がドラスティックになりすぎないように気をつけました。
チケットの粒度にこだわらない
redmineにはチケットの親子関係を管理する機能があるため、チケットの粒度にはあえてこだわりませんでした。チケットの棚卸しや計画フェーズで粒度については親子関係を持って表現されるので、粒度を最初から保つよりもやらなければならないことが雑でも良いから表現されている状態を保つことを優先しています。
やらなかったこと
チームにとって良くないと思ったので、宣言してやらなかったことを幾つか。
コミット時に該当箇所のテストコードを書くこと
必須にしませんでした。引き継いだ時点でお察しなコードでしたし、チーム全体でテストコードを書く文化がない中でのスタートだったので、必須にするとテストを書くためのリファクタリングでほぼ全ての時間を費やすことになることが目に見えていました。いや、ほんとに泣きたくなるくらいテスト書きづらいコードがあるので。。。
ただし、チケットの完了基準で単体テストをしていないとコミット禁止にしているので、代替として手動でやったテスト項目は完了時に必須としています。また、テストコードのサンプルを書いて、メリットについて説明した上で強く推奨したので、なるべくテストコードを書いてコミットをするという文化は根付いてきたと思います。
明確な個人の役割分担
機能ベースの担当や工程ベースの担当を決めてしまうと基本的に待ちになってしまうので、役割を明確に決めることはしませんでした。そもそも分業制にしてメリット出るほど人がいないですし。せっかく朝会とふりかえりでフォローしあうチームにしていく方向性ができつつあるのに、その流れに逆行してしまいます。
今後の課題
もちろんまだまだ満足していません。ステップアップしていきたい箇所が幾つかあります。
redmineのノウハウをもっと
定型タスクのコピーなど、プラグイン使うと幸せになれそうなタスクが幾つかありそうです。プラグインについての情報をもっと集めて、redmineを便利に使えるようにしていきたいです。
また、Git、Github、jenkinsなどのツールとの連携についてもノウハウをためていきたいところです。チケットのフェーズ移行にあわせて手作業でしているコミットなど、ツール間の作業はもっと楽にできそうです。
進捗の管理などで定型的なところがredmineでサポートされるようになったことで余裕が出てきたので、人がやらなくても良いところはもっと積極的にツールでサポートする方向に、というのは考えています。
もっと効果的なレビュー
レビュー観点票みたいな運用はしたくないのですが、個人の知識に頼り切ってしまう今のレビュープロセスも何とかならないかな、と思っています。私のこの辺りに関する知識が足りないこともあって完全に手探りですが、少しずつ改善していきたいと思います。形になったらまた別途エントリに起こします。
