プログラミングにおける「繰り返し（イテレート）」の重要性
ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。
https://ja.wikipedia.org/wiki/アジャイルソフトウェア開発
プログラミングにおいて「ウォーターフォールモデル」ではなく「アジャイルモデル」を採用しよう、と様々な場所で声が挙げられている。
何故ウォーターフォールモデルではダメなのか、またはアジャイルモデルにすると何が良いのか？
先ほどの wikipedia の引用で最も重要な単語は、「繰り返して」の部分であると私は考える。
プログラミングはトライアンドエラーの連続である。
- コードを書く
- コンパイルエラーが出る
- エラーを直す
- ランタイムエラーが出る
- エラーを直す
- 新しいコードを書く
- ...
このような繰り返しが続いていく（コンパイルはない言語もあるだろう）。
プロダクトは「素早く（期日以内に）完成させること」が求められる場合が多い。つまり、「繰り返す回数には限界がある」と言い換えることも可能だ。
つまり、エンジニアは 「限られた期間で繰り返す（＝イテレーションする）回数を最大化する」 能力が重要となる。
そこで挙がった手法の一つが「アジャイル」ではないだろうか。
私自身はアジャイルを体系的に学習し実践したわけではないが、一般論としてアジャイルは「イテレーションを重要視する」と考えられる。今まで「完成するまで繰り返す」だけだったものを、「この日までにこれだけ繰り返す」という目的を定量的に明記し、それが実施出来たかどうかを振り返り、次の「繰り返し（イテレーション）」をより改善しようとする。
アジャイルはチーム開発の手法として存在するが、この考え方は１機能のプログラミングにも適用できる。
- コードを書く
- コンパイルエラーが出る
- エラーを直す
- 実行する（ユニットテストやモンキーテストなど）
- ランタイムエラーが出る
- エラーを直す
- 実行する
- エラーが出ないことを確認する（フィーチャーテストやモンキーテストなど）
- 新しいコードを書く
これがプログラミングの一般的な「繰り返し」ではないだろうか。この「繰り返し」をいかに高速に実行するかが、生産性に直結する。
例えば、コンパイルが 1 秒で終わる環境と 1 分かかる環境では、明らかに前者の方が生産性が高くなる。ユニットテストが 1 分で終わる環境と 10 分かかる環境でも同じだ。繰り返しは早い方が良い。コンパイルはないが、代わりにモンキーテストで問題が見つかった場合、前に書いたコードを直す必要があるため、繰り返しはさらに遅くなってしまう。
プログラミングには様々な言語、ツールチェイン、フレームワーク、ライブラリなどの選択肢があり、エンジニアは常にその多岐にわたる選択肢の中から現在の要求に適切なものを技術選定しなければならない。この選択肢は日々更新されていくので、先月最適だと思った選択肢が今月そうではなくなることもある。
この技術選定が、プログラミングの「繰り返し」の速度に大きく影響を与えるのは言うまでもないだろう。
- コンパイルがあるかどうか
- コンパイルが高速かどうか
- エラーが分かりやすいかどうか
- 要求されている機能が既に実装されているかどうか
- AI による支援が受けられるかどうか
- 型などの制約を加えられるかどうか
- モジュール化が出来るかどうか
- linter, formatter, tester が存在するかどうか
他にも要件は無数にあるが、ここで重要なのは「今（または今後）関わるメンバーのイテレーション速度が最大になる」選択をすることである。
例えば、 formatter が存在せず、コードレビューの段階で他のメンバーから「フォーマット(インデントやカッコの位置など)の問題」について指摘され、修正するのはイテレーションが遅いといえる。
「わからないことがあったらとりあえず悩んで、調べて、AIに聞いて、それでもわからなかったら同僚に聞く」といった時間を経験したことはあるだろうか？私は大いにある。
最初から同僚に聞く、というのがベターな改善案として提案される場合もあるが、私は「そもそもわからない状態にならなければ最速なんじゃ？」と考えている。
最近はコードを１文字打つごとに裏でサーバー処理が行われ、すぐに型の不一致や未定義の変数などのフィードバックが得られる。現在は機械的に判断出来る項目のみそういったフィードバックがあるが、今後は AI による自動生成提案の比率が上がっていき、人間は「正しいかどうか判断する（またはそのためのテストコードを書く）」だけになるかもしれない。
「とにかく繰り返しを早くする」ことを意識してプログラミングを続けるのが、スキル向上に大きく貢献する考え方なのである。この心がけを踏まえて、日々の技術選定や実装、知識習得を進めよう。
Discussion