Zenn
🚄

ミニマルなソフトウェア開発管理

2021/03/21に公開
マネジメント
dev
idea

何かやりたいことがあって、そのためにソフトウェアを開発したい。そのときに、技術的ではないことすべての事柄についてうまく段取りをつけて開発を進めて、そのソフトウェアに対する期待と、実際に開発されたものがズレないようにする。これがソフトウェアの開発管理だ。わたしも何だかんだでキャリアが10年を超えてしまい、いろいろなソフトウェアの開発管理を見てきたが、上手くいったときの体験を思い出して、最低限これだけやっとけばいいんじゃないかというポイントが見えてきたように思う。世間にはいろいろな管理手法が提案と実施されているが、どれも大袈裟だと感じていた。上手くいくために最低限必要な要素を押さえて、30分くらいで理解と実施ができるミニマルな手法をここでまとめてみたい。

前提

  • 1人〜数人くらい
  • 要素技術の検証は済んでいて技術的な実現性は見えている or 枯れた技術しか使わない
  • リーダー的な人が一人くらいはいる
  • 内製のほうがやりやすいと思う
  • メンバーがOSのスケジューリングの仕組みをなんとなく理解している

計画編

  • リリースしたいものを決める（開発のスコープ、ビジネス要求、解決したい課題的なやつ）
  • そのために必要なタスクをリストアップする。タスクの種類はおおまかに設計、実装、テストがある
  • 必要なら基本的な設計もしてしまう
  • 個別のタスクについて見積もりをつける（プランニングポーカー）
  • 見積もりを積み上げて、リリースのETAを予測する
  • 気に入らなければスコープとタスクを調整する
  • スコープから外す場合は、次期開発に入れるなど

慣れているメンバーだと半日から丸一日くらいで終わる。あんまり時間がかかる場合はそもそもの企画のスコープが大きいのではないかと思う。

実施編

タスク一覧を見れるようなツールがなにかあればよい。GitHub Issues がレポジトリ等との連携がよいので便利だろう。いわゆる看板 はあってもなくてもいいが、あるとよい。リモートでもレビューできるようにするため電子がよい。

看板上のチケットの状態はOSのタスク管理を参考にして、以下の４つ。

  • Running - メンバーの誰かが手を動かしている状態のタスク。横取りしない。
  • Runnable - いつでも手がつけられる状態のタスク。手が空いた人はここから拾っていく。
  • Wait - 何か外部要因で待ちが発生している状態。もしくは開発が進むと開放されてRunnableになるタスク（結合テストなど）。待ちがおわるとRunnableに移動する（優先度が高ければ誰かが拾ってRunnableにする）。外部との調整待ちなんかもここ。
  • Zombie - メンバー同士で完了確認する前のやつ。全部をやらなくてもよいが、重要なものは確認しよう。Doneにしないのは末期に欄が溢れないようにするため。

タスクの優先度は、以下の順にする。まず重要なところから作っていく。細かい仕様もその過程で決まっていくと思うので、テストは必要に応じて最低限でつけていく。

  • コア機能の実現、実装（UIがコア機能というならそれを優先）
  • ユーザーに影響があるインターフェースや機能の実現、実装、早期テスト
  • リリースしたあとに問題がでそうなところのカバー
  • …などなど柔軟に

週一回程度sync meetingでタスクレビューをする

  • タスクはカジュアルに追加、分割、削除、改変をする
  • タスクには完了条件は明記する、できれば予想工数も書く
  • このときにETAをアップデートする。↑の「気に入らなければスコープとタスクを調整する」を再度やる
  • 中くらいの問題、わからないことなどはこのときにまとめて議論する
  • 大きな問題はいつでも即メンバーに相談しよう
  • 開発スコープの変更があった場合は適宜追加や相談をする。できればASAP

その他

  • テストはなるべく自動化するが、APIやUIが枯れていなくて揺れそうなとき（とくに開発初期に多い）は最低限にしておく
  • タスクは最初は粒度が荒くてもよいが、開発が進むにつれて実施可能なサイズに分割していくのが望ましい。最終的にcloseされるときには1~3日くらいの見積もりなっているとよい。
  • フルリモートよりは週1,2回は集まった方がよい。これも今は難しいけど、まあ実際よいのだから仕方がない
  • 毎日は集まらない方がよいが、 Daily sync として15分くらい毎日話す機会をリモートでも作るのはよいかもしれない。

アレンジ編

  • 必要に応じてすきなようにアレンジする
  • ツールも特に規定していないので好きなものをつかう。気になっているのはGerrit
  • 性格が細かい人は、時間があるときに一人タスクレビューをする。個別のタスクに感謝の気持ちをこめてメンテナンスしていくことでタスクが美しくバランスのとれた状態になる。問題を早期に発見できたり、忘れてたことを思い出したりするので、これはけっこう効く。
  • 継続的にソフトウェアを開発するような場合は、リリースしたらまた次を同じように始める
  • Issue closeの流速からETAを自動で計算してくれる triage-party 1.3 のKanbanが個人的に熱い

めちゃくちゃ要点をしぼると、最初の計画を見積もりつきでたてましょうというのと、週一回のミーティングで計画（ETA）と進捗状況をアップデートしましょう、ズレていたら随時解決しましょうというだけの話だ。

注意深く読んだ方はわかるかもしれないが、これはアジャイルとかウォーターフォールとか、ああいったフルスペックの開発手法のいずれもわたしの考えたミニマルの要件を満たすように規定されている（と思う）。

参考書籍

Discussion