パルカワ2

PerlとRubyとイチャラブ

開発スピードをあげるには

「開発スピードをあげろ!」と言われる事は多々ある。

実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず!」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。

開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。

例えば、「仕様決め」の問題点は

  • 仕様が決まらず、MTGの時間が長い
  • 仕様を決める人がいない
  • 誰かに確認する事が多い
  • 開発者自身が新しい仕様に必要な現状の仕様の理解をしていない

解決方法は、「機能に関して誰が責任持って決めるのか決める」「機能に関する責任者がいない場合はMTGしない」「必要なこと・不要なことをまず最初にまとめる」など。

「コードを書く」の問題点は

  • 各開発者が、一人で考えこんで必要以上に悩んでいる
  • リファクタリングから始めて、機能開発の着手が遅れる
  • プルリクの目的から逸れたことも同じプルリクでやってしまい、マージが遅れる

解決方法は、「プルリクを分ける」「機能開発してからリファクタリングを行う」など。

「検証」の問題点は

  • 開発者が行う検証に時間がかかっている
  • 開発者がテスト項目書を作っていて時間がかかっている

解決方法は、「QAチームに委譲する」「自動テストの充実化」など。

これらはただの例で、フェーズの中でなにが問題になっているのか・それらの解決方法は、チームや個人によって違う。

まとめ

「開発にかかる時間」を分解し、それらのどこで問題が起きているのか、1つ1つ理解して対応していくことが、「開発スピードをあげる」事につながっていくと思う。

ライト、ついてますか―問題発見の人間学

ライト、ついてますか―問題発見の人間学

という日記が、Day Oneにあったので公開します。