アジャイル手法

アジャイル手法があることを知る

最近、ソフトウエアーの開発手法にアジャイル手法なるものがあることを知りました、しかも、この手法、私がかねてからやってきた開発手法と非常によく似ています。
私は正式にプログラミングを学んだことがありません、好きで趣味でずっとプログラムを作ってきました、好きが高じて会社のシステムを作るようになり、そのまま今にいたります。（詳しくは無法プログラマーを読んでください）
だから私の開発手法は我流です、システム部門の開発手法とものすごく違います、だから「我流＝素人」のやり方とよく言われました。
でも私の開発手法もあながち間違とは言えないようです、これからは、この方法はアジャイル手法なのだと主張できます。

私は我流です

無法プログラマーにも書いたように、私は好きで会社のシステムを作ってきました、システムの作り方はまったくの我流です。
システム部門に配属になった時、正しい開発のやり方を学ぼうと思ったことがあります、しかし正しいやり方は驚きの連続でした、こんなやり方でよくシステムが開発できるものだと感心したりあきれたりで結局もとのやり方に戻しました。

一番驚いたのは、システムを設計する人とプログラムを組む人が別れていることです、SEが設計しプログラマーがコーディングするとなっています、しかしプログラムは考えなければ組めません、考える人と作る人が別々になっているなんて信じられません。
二番目は、開発前に仕様が確定することになっていることです、そんなことってありえるのでしょうか、もちろんものすごく簡単なシステムならありえるでしょうが通常は不可能だと思います、みなさんは本当にそんな超人みたいなことが出来ているのでしょうか？

当時の上司とは随分と喧嘩をしました、私は自分のやり方を譲りませんでした、結局システム部門から追い出されましたが、私のアジャイル的手法はまったくの見当外れではなかったと今わかって心強く思っています。

ウオーターフロー手法とアジャイル手法との違い

従来のウオーターフロー手法とアジャイル手法との違いを一言で言えば、開発前に仕様が確定するか否かです。 ウオーターフロー手法では開発前に仕様が確定することを前提としていますが、アジャイル手法では仕様は開発中にどんどん変わる事を前提にしています、ここの違いだと思います。
私は何が何でもアジャイル手法が良いと言っている訳ではありません、開発前に仕様が確定するのであればウオーターフロー手法が良いと思います、しかし仕様の確定が難しそうであれば仕様が確定しないことを前提とした開発手法でやるべきです、また現実の開発は仕様が確定しないことの方が圧倒的に多いように思います。

私の主張するアジャイル手法

これから私が主張する私のアジャイル手法について説明します、これをアジャイルもどきと呼びます。
アジャイルもどきでの開発で肝心なことはプログラムの組み方です、アジャイル手法の本を読んでもあまりこの事には触れられていませんが、ここが一番肝心な所です。
ウオーターフロー手法でも結局は仕様変更があり、そのためプログラムの変更作業は結局発生しており、そしてプログラムの変更は簡単ではありません。読者の皆さんは、アジャイル手法でも結局プログラムを変更するなら同じ事ではないかと思われると思います。
そうです、問題はプログラムの組み方なのです、修正に強いプログラムを組む必要があります。
アジャイルもどきでは、仕様が頻繁に変更されるとの前提を置いたのですから具体的に仕様変更に対する対策がなければなりません、それがプログラムの組み方なのです。

プログラムの組み方

プログラムの組み方のテクニックを文書で説明するのは大変に難しいことです、私が若い頃からプログラムを組んでいて自然に身に付けたもので、かなりの熟練が必要です、私はプログラマーは職人だと思っています、ちょうど大工と同じです、若い大工が師匠について腕を磨きやがて一人前になって、さらにまた若い大工を育てるのと似ていると思います。
私は趣味でプログラムを作ることが多かったので、作りながらどんどん発想が広がって、そのためプログラムがどんどん変化するようなプログラムを作っていました、そんな作り方をしているうちに自然と簡単に修正できるプログラムの組み方を身に付けました。システム部門に行くまでは他のプログラマーもこんなやり方をしていると思っていたのですがシステム部門に行って始めて私のやり方は異端だと気が付きました。
この方法を文書で説明するのは難しいのですが、それでも少しノウハウを書いてみたいと思います。

なお、ひょっとしたら、みなさんもこんなやり方でプログラムを作っているのかもしれませんね。
当時の上司が主張していたようなやり方でプログラムが組めるとはとても思えません、私は当時の上司の意見がシステム業界の一般的な考え方だと思っていますが、もしそれが単なる勘違いなら笑い話ですましてください。（それでもメールで教えていただけると幸いです）

骨格から作る

プログラムはまず骨格から作ります、細かい所は後回しにして基本的な機能だけを先に作ります、また1本のプログラムを完成させてから次にかかるのではなく一連のプログラムを平行して作ります。
ちょうど塑像を作るのと似ています、まず大まかな形を先に作り少し離れて全体がうまくできているかを見ながら徐々に細かい所を作っていきます。

常に動くようにしておく

プログラムは開発のかなり初期の段階から常に動くようにしておきます、動くことを確認してから次の機能を追加していきます、このため、テスト用のプログラムを平行して作ります、テスト用のプログラムは別に作ることもあれば、本来のプログラムの中に組み込むこともあります。
動かすために必要ならダミー関数を作って見かけ上動くようにします、ダミー関数とは本来ならかなり細かい処理をしなければならない所で、その処理をする代わりに固定値を返すようにした関数のことです。
プログラムを動くようにしておくことでプログラムを修正したときに動かなくなった場合の原因追及が簡単になります、動いていたプログラムを修正して動かなくなった場合その原因は 99.999999% 修正した所にあります。

綺麗なプログラムを組む

プログラムには美的センスが必要です、美しいプログラムにこだわるべきです。とくに仕様変更で手直しをするときは絶対にその場限りの修正をしてはいけません、必ず美しく修正をします。
私は若い頃整備工場で働いていたことがあります、先輩から工具を必ず工具箱に戻せとしつこく指導されました、仕事が忙しいとついつい工具を手元に置いてしまうのです、工具箱に毎回戻すと手間が余計にかかるように感じます、しかし結局工具を探すことになるのでキチンと工具箱に戻す方が仕事が速いのです。
プログラムも同じでその場限りの修正をすると、その時は早く感じても後でだんだん大変になります、必ず美しいと感じるような修正をします。

作り直し

プログラムは作っていくと問題点が見えてきます、問題が気になりだしたら一旦立ち止まりゆっくり考えます、このまま行くか作り直すかを考えます、時には数日考えることもあります。しかし作り直すことを恐れてはいけません、作り直しは確かに手戻りです、しかし、このまま行けばもっと傷を広げるかもしれません、迷った時は作り直した方がいい場合が多いようです。

基本設計

仕様変更に対する一番の対策はプログラムの組み方ですが、次に基本設計が重要です。
想定される仕様変更を考慮して基本設計をしなければなりません、これは結構大変です、開発に入る前に考えに考えます。
プログラムの組み方は馴れです、訓練すれば誰でも出来ると思います、しかし、基本設計は多少の才能が必要だと思います。
これはちょうど将棋の手順を考えるのと似ています、頭の中であらゆる事態を想定します、そして、こうなったらこう対応する、あーなったらあー対応する、と考えるのです。

将棋の上手な人は数十手も先を考えているそうです、下手は数手先が精一杯で予想される事態になにも対処できていません。基本設計もこれと似ています、数十手先を考えるのは訓練もいるでしょうがある程度素質があるように思います。
また、もしチームーで開発しているのであればチームでミーティングをしてあらゆる事態の想定を考えると効果的です、一人で考えると思わぬ漏れがありますが考える人が多ければ漏れは少なくなります、しかし基本仕様の設計は優秀な人が一人でやります。（会議などで決めるととんでもない設計になります）

スパイラル開発

アジャイルもどき手法では開発はスパイラル開発になります、作っては見直し、作っては見直しを繰り返します、この繰り返しにははっきりとしたフェーズはありません、作りながらある程度できたら動かしてみて問題点を考え問題があればそこを修正してまた作っていきます。
ユーザーがいる場合はユーザーに見せても分からないだろうと思われる段階までは開発チーム内だけでこのスパイラルを繰り返します、そしてある程度形ができたらユーザーに動かして見せます。この時今の状態は試作であることを充分に説明しておきます、細かい所は正しく動きませんからユーザーが不良と誤解しないように充分な説明が必要です、そしてユーザーの意見や要望を聞いて修正します。
修正が基本設計の想定内ならば変更は簡単にできます、場合によってはユーザーの目の前で修正できます、想定外だとちょっと厄介です、このへんは基本設計が非常に重要だと思います。

分担

チームで開発している時は機能別に縦割りに分担します、担当した部分は設計からプログラミングまで一人の人がやります、プロジェクトマネージャーは基本設計をし、分担を決め、分割した相互間のインターフェースを決めます、しかし、分割した内部のことはそこを担当した人が全てを決めます。
人は全てのことを把握することはできません、プロジェクトマネージャーは全体が分かっていればいいのです、個々の細かいことはそこを担当した人が考えるのが最もいい解が出ます。

「ＳＥが設計しプログラマーがコーディングする」ようなことはしません、考えた人がプログラムも作ります。
「考えることが出来ないのに作ることだけは出来る」などということは絶対にありえません、考えられないのなら絶対に作ることはできません、それがプログラムです。
だから、「優秀な少数のＳＥと無能な大勢のプログラマーで効率よく開発ができる」という理屈はありえません、プログラムが作れるのならその人は設計もできます。

開発環境

チームで開発している時は必ず各自自分専用の開発環境を持ちます、これはサーバーが人数分必要という意味ではなく１台のサーバーの中に複数の環境を作ってもかまいません。
各自の開発環境内で全体が動くようにしておきます、つまり他人の開発した部分も自分の環境内に取り込みます、これを実現するのにCVSのようなプロジェクト管理ツールを使います。
そして分担して作っていても常に全体が連動して動くようにしておき、各自が連動して動く所を確認しながら作っていきます。

ミーティング

チームで開発している時は頻繁に（１日に１回３０分程度）のミーティングをやります、チーム間の意思疎通は文書ではなくミーティングでやります。
特に仕様変更の時は仕様変更をトップダウンで指示するのではなく、変化した状況を説明し、どの様に仕様を変更するのがいいかを話し合います。こうすることによって仕様変更に対する抵抗感が減るのと仕様変更内容の誤解を防ぐことができます。

文書

一般にアジャイル手法では文書をあまり書かないとされています、アジャイルもどき手法でも文書は出来るだけ書きません、しかし、アジャイル手法だから文書が少ないのではなく業務改善で文書を減らすのです。
私が若い頃のシステム化は業務改善と同時でした、まず業務分析をし不要な文書を減らします、ヒアリングをして各々の文書がなぜ必要なのかを調べます、そしてこの文書がなくなると何が不便なのかを質問します、その様に調べていくとかなりの文書にはその必要性がありません、殆どの場合過去に起きたトラブルがその文書の起源になっています。
このようにシステム部門は他部門の業務改善をやってきたのに、なぜかシステム部門は他部門に比べものすごい量の文書があります、一般の部門では会議で決まったことを表にして会議の参加者に配ることはありますが、会議中に何をしゃべったかを議事録にして配布しその議事録に判子を押せと言うのはシステム部門だけです。これはいかにシステム部門にトラブルが多いかを象徴していると思います。なぜその文書が必要なのかを自問し電話帳にように厚い文書を書くのはやめましょう。

文書の量と残業は関連があるように思います、私が若い頃いた部署は資料ばかり作っていました、そして遅くまで残っていました、仕事が忙しい訳ではなくただみんな残っているのです、恐らく自分の仕事に自信がないから遅くまで残るのだと思います、そして自分の仕事に自信がないと文書をたくさん作るようです。

アジャイル手法を実際にやるには

ウオーターフロー手法でも仕様変更を想定した基本設計をしている人は多いと思います、そして実際に仕様変更が起こり手戻りしてプログラムを作り直す、そんなことを繰り返すことは日常茶飯事です、それならばいっそ最初から工程表に手戻りの工程を入れてしまえばいいじゃないでしょうか、そしたら、それがアジャイル手法です。
アジャイル手法はトリッキーな目立つ面ばかりが強調されていますが、その本質は仕様変更があることを前提とする点です、仕様変更があることを前提として基本設計を行い工程を組みます、プログラムも変更されることを前提に作ります。
アジャイル手法はトリッキーな話が前面に出るために誤解されることが多いですが、地道に取り組めばそれほど難しくありません、仕様変更があると言う現実を受け入れるかどうかの問題です、一旦受け入れる気になれば自ずと道は開けます。

アジャイル手法がもっと普及することを望んでやみません。