開発時間短縮のためのプラクティス10選

このエントリを書いた背景

先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。

「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。

色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。
どれもまあ、基本中の基本だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。
とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。

ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。

このエントリを読む前の前提条件

おいらは社内SEである。
システムは社内で開発される。外注はしていない。
カスタマはすべて社内のメンバーである。社外のカスタマはいない。
社内の開発プロセスはどちらかというとウォーターフォールに近いものである。*2
データベースを使った情報システムを構築したり保守したりすることが多い。
保守したり開発したりするシステムはそれほど大規模なものではない。開発チームといっても多くて4〜5人程度。

・・・とまあ、こんな感じです。
ではどうぞ！

1. はじめに

1.1. 開発時間短縮の特効薬は何か？

はじめに断っておくが、開発時間を短縮するための特効薬はない。部分的な時間短縮ができても全体から見れば焼け石に水、ということも多い。
開発時間を短縮するために必要なものは小手先のテクニックではなく、普段からの心がけやプラクティスとして語られるべきものである。
その中でも特に重要なものを以下に挙げる。

1. フレームワーク、ライブラリ、既存のコードから再利用可能なロジックを探す。
2. 重複したコードを書かない。フレームワーク化する。共通化する。
3. 開発者専用のデータベース環境を用意する。
4. 少しずつ作る。
5. リッチにしすぎない。
6. 早期にカスタマのフィードバックを得る。
7. 作業を繰り返さない。自動化する。
8. 集中できる時間を確保する。
9. 自分ひとりで解決しようとしない。エキスパートに相談する。
10. 情報は積極的にシェアする。

2. 詳細

2.1. フレームワーク、ライブラリ、既存のコードから再利用可能なロジックを探す。

プログラムを書くときは、まずプログラムを書かないで済む方法を考える。利用しているフレームワークやライブラリ、既存のコードなどを調査し、なるべく再利用するように心がける。
既存の仕組みを再利用することでロジックを記述する時間とそのロジックをテストする時間が削減できる。バグも減るのでデバッグの時間が減る。また、コード量が減り、可読性が向上するので、システム改造時の工数削減も期待できる。
事前に知っている知識が多ければ多いほど、実務で調査にかける時間を削減できる。つまり、エンジニアは言語やフレームワークに精通していることが望ましい。

2.2. 重複したコードを書かない。フレームワーク化する。共通化する。

コード上のロジックが重複しそうであればロジックをフレームワーク化または共通化して重複を排除する。
フレームワーク化や共通化を積極的に行うことで、繰り返し発生するコーディングにかかる時間を短縮できる。また、バグが減り、トラブル解決の時間を削減することができる。
柔軟で使いやすいフレームワークを作成するにはオブジェクト指向プログラミング(OOP)の特性やオブジェクト指向設計(OOD)の原則に関する深い理解が必要となる。よって、エンジニアはOOPやOODに精通していることが望ましい。

2.3. 開発者専用のデータベース環境を用意する

チームで開発する場合は開発者一人ひとりに専用のデータベース環境を用意する。一つの開発用データベースを複数の開発で共有してはいけない。
ソースコード、データベーススキーマ(テーブルやストアド等のデータベースオブジェクト、権限設定等)、データベース内のデータは常に同期していないと、正常にテストやデバッグができない。また、ある開発者の行った変更が他の開発者にインパクトを与えてしまう可能性も高い。
よって、データベース環境は開発者ごとに隔離する必要がある。また、開発期間中はデータベーススキーマやテストデータも開発者間で簡単に同期できる仕組みも必要となる。

2.4. 少しずつ作る。

コーディングとデバッグは小さい単位で繰り返す。たくさんコーディングした後にまとめてデバッグしようとすると、バグの原因を特定するのが難しくなる。小さい単位で正しく動くプログラムをインクリメンタルに作っていけば、バグの発生原因が直前に書いたコードにあることがすぐに分かる。

2.5. リッチにしすぎない。

機能が多ければ多いほどコーディング量が増え、テストの工数も増える。技術的に実現可能であっても、それほど重要ではない機能は実装すべきではない。
カスタマの要求を何でも受け入れたり、システムに過剰な柔軟性や拡張性を持たせたりしないよう、開発者は注意する必要がある。

2.6. 早期にカスタマのフィードバックを得る。

ある程度動作確認できるものができた時点でカスタマに公開し、フィードバックをもらうようにする。文書や口頭でいくら事前に確認をとっても、実際に動くシステムをカスタマに見せると要求の漏れが発覚したり、要求が変更されたりすることが非常に多い。
開発の終盤にそのようなことが起きると、大きな手戻りとなり、スケジュール遅延の原因となる。早期からカスタマのフィードバック得るようにし、こまめに軌道修正すれば無駄な開発工数の発生を防止しやすくなる。

2.7. 作業を繰り返さない。自動化する。

繰り返し発生する作業は自動化する。自動化には既存のツールや自作のスクリプトを使用する。
自動化を積極的に行うことで、何度も発生する作業にかかる時間を短縮できる。また、ヒューマンエラーが減り、トラブル解決の時間を削減することができる。
よって、開発者はツールに関する知識やスクリプトを自作するスキルを持っていることが望ましい。

2.8. 集中できる時間を確保する。

集中している状態、いわゆるフロー(Flow)状態をできるだけ多く確保する。他者の割り込みや会議による妨害を極力排除する。
プログラマはフロー状態にあるときが最も生産性が高い。よって、フロー状態にある時間が長ければ長いほど、開発効率は向上する。
フロー状態を確保するためには以下のような手段が考えられる。

まとまった時間を確保するため、会議を昼休みの前後に設定する。
他者に割り込まれそうになったら、後にしてもらうように伝える。
メールクライアントやメッセンジャーを閉じる。
会議室を一人で借りて開発する。他のメンバーの会話が聞こえなくなるだけでも集中力はかなり向上する。*3

2.9. 自分ひとりで解決しようとしない。エキスパートに相談する。

自分ひとりで解決することに固執しない。しばらく考えても分からないことは近くのエキスパートに相談する。
どのようなシステムであっても開発に必要な知識はかなり幅広いため、自分ひとりですべてをカバーすることはほぼ不可能に近い。自分の得意分野と不得意分野を認識し、不得意分野に関してはエキスパートのサポートを得ながら開発を進めたほうが速く完了する。また、独断で開発を進めると不適切な解決策を選択する恐れもあるので、そうした問題を避けるためにもエキスパートの知見を積極的に活用する。

2.10. 情報は積極的にシェアする。

チームで開発する場合、自分しか知らない情報や、便利なTips、トラブルシューティングで新たに得た知識などは積極的にシェアする。
自分から情報を発信すること自体は自分の開発効率を多少下げることになるが、チーム全体の開発効率向上に貢献することができる。また、他のメンバーが情報をシェアしてくれれば自分の開発効率が向上する。
チーム内の情報発信者が一部のメンバーに偏っている場合はチーム内のコミュニケーションスタイルを見直す。

3. まとめ

3.1. 普段から継続的に勉強し、事前に知識を蓄えておく。

冒頭で述べたように、開発工数を短縮するための特効薬はない。エンジニアは案件をアサインされてから慌てて勉強するのではなく、普段から継続的に勉強し、事前に様々な知識を蓄えておく必要がある。そのためにはまず、自分の不得意な分野や、将来必要になりそうなスキルを認識しなければならない。それから技術書などを通じて必要な知識を習得していくのがよいと思われる。
最後にシステムや言語を問わず、開発時間短縮につながるスキルの習得に役立つ書籍やWebサイトを紹介したい。