"アジャイル プラクティス" Venkat Subramaniam & Andy Hunt 著

本屋で、前記事の「アジャイル レトロスペクティブズ」の隣に陳列されていたので、ついでに買った。「Practices of an Agile Developer」という言葉になんとなく惹かれる。優秀な方々の習慣は気になるものだ。本書は、人生にリズムとバランスの大切さを改めて教えてくれる。その証拠に、各章には気分とバランス感覚という文字が鏤められる。酔っ払いにとって気分とリズムほど大切なものはない。

アジャイルとは、より良いソフトウェア開発方法を解明しようとするものであり、その重視する項目は以下のようなものだという。
・プロセスやツールよりも、- 人と人との交流を
・包括的なドキュメントよりも、- 動作するソフトウェアを
・契約上の交渉よりも、- 顧客との協調を
・計画に従うことよりも、- 変化に適応することを
ここで注意すべきは、左側の項目の価値を認めていることである。それを前提として右側の項目の価値をより重視する。アジャイルの本質は、適応力と協調を重んじる人々が、きちんと動作するソフトウェアを開発することであり、結果を出すことに専念するプロの集団を前提としている。そして、チームにとってモチベーションを保つには、計画を絶対視するよりも、自然で継続的なスタイルへと変化させることが肝要であるという。なるほど、こうした本は頭の整理ができておもしろそうだ。アル中ハイマーの主な仕事は、デジタル回路のアルゴリズム開発やLSI設計である。この分野は、言語による手法が進み随分とソフトウェア化が進んでいる。また、機能検証では、実装のモデリングやテストの自動化などで、プログラム開発を要求される。したがって、本書のようなソフトウェアの分野であっても、その思想は参考にできる。

ソフトウェアの開発は、そのライフサイクルが継続する限り続く。ユーザが使い続ける限り、本当の意味での完成はないのだろう。継続的なフィードバックは、もはやプロジェクト期間など意味をなさないように見える。技術習得、要求変更、製品展開、ユーザのトレーニングなど、すべてにおいて活動は継続される。これがアジャイルな開発スタイルだという。開発のプロセスは複雑で、些細な問題を放置すると、やがて状況は悪化し手に負えなくなる。問題にうまく対処する方法はただ一つ、システムに対してエネルギーを継続的に注入するしかないという。これがソフトウェア開発のエントロピーというわけか。人間社会にも多くの類似したケースを見つけることができる。混乱と危機に陥る前に継続的に監視し問題が小さなうちから対処するのが、アジャイルの本質のようだ。ここで注目したいのは、アジャイル開発で最も信頼を置くのは人であることを強調しているところである。

おいらがプロジェクトを担当する時、リーダをさせられることが多い。単に年齢によるものであろう。そこでは、必ず自ら設計するモジュールを持つことにしている。それがどんなに小さくても。それも設計者の気持ちを忘れないためと言い訳しているが、実は設計も楽しいのだ。最近では、検証環境を作る方がおもしろいので、立場を利用して環境構築を担当する。回路設計を言語で行うといっても、その記述方法は実装の制限に見舞われる。その点、検証モジュールは機能のモデリングや環境の自動化など、その手段において制限に見舞われることはあまりない。顧客によっては使う言語を指定してくる場合もあるが、手抜きをする方向でなければ、交渉でだいたい誤魔化せる。
ドナルド E. クヌース曰く。
「新しい分野のシステムを担当する設計者は、実装にも全面的に関わらなければならない。」
ある経営者に、プロジェクトリーダは、コーディングしてはならないと言われたことがある。おいらはこの意見に否定的である。リーダも少しは設計の醍醐味を味わいたいものである。

プロセスの遵守の度合いを評価の重点に置いている組織がある。そこには、定められたプロセスに従ってさえいれば、この世は全てうまくいくという宗教じみた理屈がある。失敗した時の責任逃れに絶好の言い訳にもなる。ISO9001を取得して喜んでいる組織のお偉いさんは、それで全てうまくいくと狂信している。定められたプロセスがチームに禍をもたらすケースは意外と多いのだが。プロジェクトは生き物のように絶えず変化する。体系化できるならば悩みも減るだろうが、できないのが人間社会というものである。応急処置が泥沼の原因になることは、多くのエンジニアが初期の段階で経験しているだろう。応急処置は悪魔のように誘惑してくる。だが、長期的視野に立てば自ら地雷を埋め込むようなものである。常に物事の本質を解き明かそうとすることが、プロ意識というものであろう。計画段階で、流用モジュールを使えばスケジュールが短縮できるといった意見は必ず飛び出す。流用できるかどうかの検討は慎重でなければ危険だ。そこには、政治的な思惑が絡むことが多い。既に流用モジュール設計者が辞めていて、問題が発覚しても原因すら追求できないといった事態も珍しくない。そんな事は新人君でさえ理解できそうなものだが、なぜか部長クラスのお偉いさんは政治力で捻じ伏せる。彼らには、開発の結果よりも重要なことがあるに違いない。窮地に追い込まれたプロジェクトを救うために、アジャイル プラクティスを導入することは良いかもしれない。ただし、一気に導入することは危険であろう。本書も、改革する上で、何もかも一気に変えてしまうのはプロジェクトを潰すことになるので、その導入方法は段階的でなければならないと警告している。ただ、潰れた方がためになるプロジェクトが存在するの事実である。

1. 設計は指針であって指図ではない！
設計がなくては、きちんとした開発はできないだろう。しかし、設計に縛れら過ぎてもいけないという。新しいソースの統合に伴う混乱を最小限に抑えるために、早めにビルド、こまめにビルド、定期的にリリースすることが重要だと主張している。設計には二つのレベルがあるという。戦略的設計と戦術的設計である。事前に行う設計が戦略的設計で、通常この段階では要件を深く理解できていないだろう。よって、大まかな戦略を示すことになる。早い段階で綿密な詳細に深入りすれば、本質を見失う恐れがある。一方、メソッド、パラメータ、オブジェクト間の相互作用のシーケンスなどは、戦術的設計の段階となる。設計は、正しい方向を示す道しるべにならなければならないという。また、優れた設計は正確であっても精密ではないという。そうだろう、最初から綿密に練られた計画が、その通り実行された例を見たことがない。設計とは、目的や意図を示したもので、具体的な手順を記したものではないと語られる。

2. ドキュメントの位置付け
ドキュメントの位置付けをどうするかは悩ましい。最初から詳細に明確に書ければ悩みも減る。しかし、コーディングしてみて、後からドキュメントに記載するといった手順を踏むこともある。この時、設計書というよりコード説明書という位置付けになる。いずれにせよ必要な説明書を省くべきではないだろう。ある程度の設計指針を記載できても、詳細まではなかなか固まらない。抽象レベルを下げていくうちに、逆に抽象レベルの高いところに変更が入る場合も起こる。上をいじったり下をいじったりして固めていくのが設計の醍醐味でもある。ただ、本書は早い段階からコーディングすることを推奨している。ここで注意すべきは、設計が不要と言っているわけではない。設計が、設計書によって行き詰まることのないように、という程度の意味である。設計をともなわないで、コーディングに突入することは危険である。あくまでもバランス感覚が重要で、設計者のセンスが最も現れるところでもある。また、設計書を渡せば、後はタイピストがコーディングするという方法は好ましくないと指摘している。
「まともな設計は、積極的にコードを書くプログラマから生まれる。」
おいらも自らコーディングしたい。コーディングは気分転換にもなるから。

3. フレームワークの有害
プロジェクトでやみくもにフレームワークを選ぶのは危険であろう。新しい技術やフレームワークの検討には、その採用根拠を明確にし、慎重であるべきである。職務経歴書の見映えを良くするために選択しても成功するわけがない。だからといって、避けていては技術習得の機会を失う。その按配は悩ましい。経営陣には、安易にツールコンサルタントの雄弁さに乗せられて、採用すると天国にでも行けると信じてしまう人がいる。そうしたツールはだいたいオーバースペックである。フレームワークも一種の布教活動であの世へ導かれる。フレームワークやツールは、あくまでも手段であって、それ自体が本質ではない。アル中ハイマーがツール至上主義に陥ることはありえない。酔っ払いはツールを使いこなすことすらできないから。

4. 早いうちにデプロイを自動化する
ターゲットマシンへのデプロイは、再現可能な方法で行わなければならないという。ほとんどの開発者は、最終段階になるまでデプロイの問題に目を向けたがらないらしい。しかし、依存するコンポーネントやデータファイルが足りなかったり、ディレクトリ構造が不適切だったりすると後戻りすることになる。おいらは、ディレクトリ構造やファイル名で最初に思いっきり悩む。夜のテクニシャンは前戯に夢中になるのだ。そして、最初からリリース状態を構築することをイメージする。後から、徐々に膨れ上がるのが見えているから、リリースプロセスは、最初から軌道に乗せておきたい。最初にリリース構造を見せておくと顧客を安心させられ、信頼を得ることもできる。また、顧客に仕様変更が容易かどうかを早めに判断させるのは、有効な戦略ともなる。もし顧客側の水面下で仕様について揉めている場合、その可能性を早めに表明してくれる。ちなみに、仕様変更が起こらない仕事を経験したことがない。相手に気を使わせるのも戦略である。どうせ顧客と揉めるなら早い方がいい。後になればなるほど殺気立つ。

5. PIEの原則
PIE(Program Intently and Expressively)とは、意図を明確に表現するコードを書くことだという。コードは開発が進むにつれ徐々に巨大な怪物へと変貌し炎上することもある。そこには、時間を惜しむために、問題の先送りという悪魔のささやきがある。適度なプレッシャーを保ちながら開発をするには、コードをいつも健康状態に保つことであろう。本書はコードの巧妙さよりも明瞭さを強調する。そして、プロジェクト期間中に留まらず、開発後においても拡張性を維持するべきだと語る。コメントを多く残すように指示する人も多いが、逆に混乱を招くこともある。これはドキュメントも同じである。ドキュメントには思想を残して、コードとセットで考えたい。あまり詳しすぎると、二重にコーディングしているようなものである。
昔、コード = ドキュメントという思想に何度もトライした記憶が蘇る。言葉をマクロ化して分かりやすい表現に置換したりと。あまり膨らみ過ぎて、特殊言語の開発をしているような気分になった。分かりやすさを追求するあまり、性能も犠牲にする。確かに、コードが分かりやすくドキュメントの地位に引き上げることができれば一石二鳥である。しかし、プログラム言語はあまり読みやすいものではない。言語仕様を知らない人間には、チンプンカンプンで議論の題材にはできない。また、いくら分かりやすく書いたつもりでも、一年後にコードを読み返すとがっかりさせられる。そこにはセンスの無さ醜さが散乱する。万能なコードを書くのは難しく、いつもトレードオフがつきまとう。適切な言葉を選ぶだけでもコードの読みやすさは格段に上がる。すべてはエンジニアのバランス感覚に支配され、継承の深さや階層の深さといった構造的センスにもバランス感覚が現れる。優秀なプログラマはネーミングのセンスが良い。こうした感覚は習慣からきているのだろう。普段から読書したりと情報収集に抜け目がない。繊細な気配りをする彼らには学ぶべきところが多い。

6. デバッグ
デバッグがスケジュール的に難しいのは、所要時間が読み辛いところである。問題もランダムに発生する。本書は、ソリューションログをつけることによって、問題と解決策を再利用することを推奨している。例外処理にはいつも悩まされる。プログラム構造には、あらゆる例外を報告させるべきであるという。そして、発生した例外は、すべて対処するか、あるいは伝播させないことだという。エラーメッセージを埋め込むにしても、そのセンスは難しい。役立つログはバグの対処に有効である。それがプログラムの欠陥なのか、環境に依存するのか、ユーザ側のミスなのか、エラーの種類が識別できる工夫も大切である。
バージョン管理システムを導入するのは一つの管理手法であろう。ただ、神のように崇めて強制する人もいる。
「バージョン管理システムを使わないことよりも悪いことは、管理システムを間違って運用することだ」
そもそも、コードの健康状態を公開することが目的であり、それを共有することに価値がある。テストが通らないものを公開しても意味がない。チーム内に一人として認識のずれた人がいると機能しない。
コードレビューは欠陥除去率が80％を超える方法であるという。おいらはチームの技術共有という意味で実施している。新メンバーの認識違いを感知するのにも有効である。ただ、スケジュール上、十分な時間を確保することは難しい。エンジニアの中には恥ずかしがり屋も多く拒む人もいる。ただ、優秀なプログラマのコードを見るのは勉強になるので、他人のコードを見ることを拒む人は少ない。説明がスムーズになされるコードは読みやすく、ドキュメントと突き合わせれば表現のチェックもできる。