フリーランスで在宅ワークをやっていて、いわゆる「アジャイル型」の開発をすることが多いです。大きなプロジェクトへの参画ではなく、中小規模プロジェクトで、開発自体も基本一人で賄えるレベルのプロジェクトなので、進め方もこちらでコントロールしやすいのがアジャイル方式だったりします。ただ、自分では自分のやり方を「アジャイルっぽい開発スタイル」と言っていて、本来の、と言うか提唱されている各種のアジャイル方式とは違ってはいますが、できるだけアジャイル型開発の良いとこどりをしている、と自分では思っています。
そもそも、「アジャイル」とは何か、ということについてまとめてみたいのですが、自分のスタイルについても本当に今のままでいいのか、という検証を含めて、定義や方法論についてきちんとまとめてみたいと思います。
アジャイル開発とは
そもそもの定義は何か、と言うと、
迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群
なのですが、では、どのような手法なのか、というと、いろいろと種類(流儀)があるようです。実際の開発フェーズにおいては、短期間のイテレーション開発の繰り返しで機能の実装をし、機能レビューをしている段階で他のイテレーション開発サイクルを回すことができる、というのがキモだと私は理解をしていて、だからこそ私自身が開発の仕事を請け負う際はそのスタイルを踏襲しているつもりです。
特に、私はXP(エクストリームプログラミング)の手法を参考にしているので*1、チーム開発を前提としているスクラム開発手法とは相いれない部分すらあると思ってはいますが、根底には、「アジャイルソフトウェア開発宣言」に基づく開発スタイルがあります。
アジャイル開発は「銀の弾丸」ではない
ソフトウェア開発の業界で「銀の弾丸」、いわゆる特効薬的なモノは存在しない、と言われています。
アジャイル開発もその例には漏れず、「アジャイル開発を採用すればすべてうまくいく」ということではないし、あとで述べますが「アジャイル」を曲解してしまっている人たちがとても多いため、むしろ「アジャイル」を採用したことで開発プロセスが滅茶苦茶になってしまうケースも散見されます*2。
ウォーターフォール開発の反意ではない
simplearchitect.hatenablog.com
この方の投稿がとにかく的を射ています。
と言うか、ウォーターフォールという「大きな流れ」に対する真逆の方法論として、ウォーターフォールで行われている製造までにとてつもなく時間がかかるやり方ではなく、とにかく動くコードを、みたいな意味でアジャイルをとらえている人は多いんだろうな、と思います。
マーケティングの世界でよく言われる、「ドリルを買いたい人が欲しいのはドリルではなく『穴』」の格言に似ていて、お客様が欲しいのは動くソフトウェアであって、開発手法がどうであっても構わないのですが、それを「ソフトウェアがすぐに動く」という言葉に引っ張られて、すぐにソフトウェア開発をするならアジャイルで、みたいなことを考えてしまっているようには思います。
アジャイルにおける「勘違い」
既にいくつか紹介をしている勘違いですが、結局、言葉を表面的になぞっていて、都合のいい言葉ばかりを引用してしまっていることが原因です。
先に挙げた「アジャイルソフトウェア開発宣言」ひとつをとっても、都合のいい耳障りの良い言葉が並んでいますが、あくまでも今までやっていた他の開発手法でうまくいかない理由を考えたうえで、「こっちも重要でしょ？」という言い方をしているのがアジャイル開発宣言なんだと思うんです。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
全文引用をしましたが、中段の、「〇〇より××を」、のくだりは、その下の2行にもある通り、〇〇に価値がなく、××に価値がある、ということではなく、どちらにも価値があるし、今までの開発手法ではより「左記(〇〇)」に価値を置きがちではなかったか、というアンチテーゼととらえることができるわけです。
ウォーターフォール型開発を例にアジャイル開発宣言を検証
一般的には大規模開発に向いていると言われているウォーターフォール型の開発手法の場合、
要件定義→設計(基本→詳細)→コーディング→テスト
というそれぞれのフェーズがあって、前のフェーズが完了しないと次のフェーズに動けない、という問題をはらんでいる、と言われます。プロジェクトマネジメントで言えば、要件定義がきちんと終わっているかどうかは、以降のフェーズでの出戻りの発生に関わることなので、ここで要件ができっているのかどうかをきちんと確認する必要があります。各フェーズで抜け漏れがないことがプロジェクトを成功に導く鍵、とも言えます。そのためのプロセスであり、ツールがあるわけです。
しかし、多少の出戻りが発生してもよい環境であれば、既定のプロセスを飛ばしてでもコミュニケーションを密に取っていれば「もしかするとこの辺りは要件が変わるかもしれない」と開発を柔軟に行うことも可能だったりします。オブジェクト指向的に言えば、わかっている要件だけで抽象クラスやインターフェースを実装しておいて、実際の動きは子クラスを作ればいいや、というような手法で、手戻りを最低限にとどめることも可能なはずです。
そうやってプログラムが先にできることを「ドキュメントよりソフトウェア」と言っているのであって、すべてを仕様書に落とし込まなければソフトウェアの開発に入れないウォーターフォール型のデメリットに対してのアンチテーゼと考えられるわけです。
左辺は疎んじて右辺のみに価値を見出すか
では、ドキュメントとソフトウェア、どちらが大事なのでしょう。同じように、4つの「比較された価値」はどちらかが本当に大切だと言えるのでしょうか。
プロセス・ツール vs 個人との対話
開発で陥りやすい罠で、コミュニケーションの欠如が挙げられます。特にプロジェクトが大きければ大きいほど、お客様と開発者の間に大きな溝ができていきます。コミュニケーションという観点で言いかえれば、お客様と開発者の間に、いろいろな人たちが介在し、意思疎通が難しくなっていくことになります。いわゆる伝言ゲームが始まるわけです。
そのために、ウォーターフォール型ではドキュメントを多用し、意思疎通の簡便化を図っているわけですが、そうは言ってもドキュメントは作成するのにも時間がかかるし、それを読まないで仕事をすることも当然できるわけです。だったらコミュニケーションを密に取ろうよ、というのが「個人との対話」です。
しかし、これは私のコロナ禍での経験の一つではあるのですが、密にコミュニケーションをとりたくても、遠隔地での会議や作業を強いられる中でFace to Faceのコミュニケーションはとても難しくなりました。気軽な話もしにくくなったりしましたし、本当にコミュニケーションをとり続けることが難しい、と感じています。
だから、目的がコミュニケーションなんだよ、という理解で、ツールを使ったりする必要があるのではないのかな、と思うのです。ドキュメントを作ることで意思疎通ができるのであればドキュメントを作って共有すればいいし、ちょっとした会話程度ならチャット等のツールでいいし、最終的にそれでコミュニケーションが取れて、意識の共有ができていればそれでいいわけです。
ドキュメント vs ソフトウェア
上記で一部答えを書いているようにも思いますが、成果物として最初に必要なのはドキュメントではなく、お客様に納品し、使ってもらうためのソフトウェアなはずです。ソフトウェアを完成させるためにドキュメントは必須ではない、というのはその通りなのですが、だからと言って、ソフトウェアを作るためにコミュニケーションをとらないで勝手に作るのも問題です。そのためのドキュメントは必要でしょう。
特に、要件定義の「ドキュメント」に関しては、アジャイルだろうがウォーターフォールだろうが、絶対に必要なモノです。一番最初に要件定義ができていなければ開発なんて入ることができないんです。もちろん、ウォーターフォール型のように、抜け漏れを防ぐためにドキュメントをきちんとそろえる、という方法もありますが、アジャイルの場合は一部の要件が決まっていればそこだけ作ってみようぜ、というやり方が取れなくはないので、要件をまとめつつソフトウェアも動かしつつ、みたいなことはできますが、だからといってドキュメントもなく、要件もあいまいなままで開発に入るのは無理です。
契約交渉 vs 協調
対お客様、という視点で見ると、開発のコストがかかればそれだけお客様に対して交渉をしなくてはなりません。制限事項も設けなければ開発そのもののコストは青天井になります。ウォーターフォール型でなくとも、アジャイル型開発で、ずっとお客様が要件を出し続けていれば、確かに動くものはできていてもお客様が満足するものはいつまでたってもできない、ということになるわけです。
がんじがらめにお客様を縛り付けて、開発側がコントロールしやすいのは確かにウォーターフォール型だったかもしれません。こういうやり方でやるからね、と流れを説明しやすいです。が、それではお客様にとっては流れの最初と最後しか見えない、ブラックボックス化された状態なので、より、お客様とのコミュニケーションをとりやすいやり方がいいよね、という意味ではあると思います。
ただ、「がんじがらめ」に対する「協調」は、ともすれば『お客様にコントロール権を渡してしまい開発側ではコントロールしない』というとらえ方にもつながりかねません。あくまでも「お客様との協調」であって、お互いに主張するところはして、お互いにより良いものを作っていこう、という態度が必要なんだ、とここでは言っているのだと理解をしています。
計画 vs 変化への対応
「計画」を「プロセス」と読み替えてもいいのですが、今までのプロセス内でやってきたことは絶対だ、という考え方はとても危険です。プログラムに関係がないですが、これはコロナ禍で人類が直面したことの一つだと思っています。計画が絶対、という考え方をすることで、最悪命の危険が迫ってくることになってしまう、という事例は2020年に起こった出来事だけでも枚挙にいとまがないでしょう。
計画を変更するには大変な労力が必要です。だからこそ、計画を変更するための労力を惜しまないようにしよう、というのがこの言葉の意味だと思っていますが、だからといって、計画をしなくていい、ということでは決してないわけです。
よくある「どうなるかわからないから後回し」なのは結構なのですが、「どうなるかわからないからとりあえずコレでやってみて、あとでいろいろと変更してみようぜ」という、どちらかといえば行き当たりばったり的な、そしてこれを「臨機応変」という言葉に置き換えてしまうようなやり方はどのような開発手法をとったところで好ましくはありません。
臨機応変に対応するコトは大切ですが、それは無秩序とは違います。
(で、結局)アジャイルとは何か
ウォーターフォール型開発がプロセスであり、ツール群であり、開発の方法論・思想であるのと同じく、アジャイル型開発もプロセスであり、ツール群であり、思想である、と言えるのでしょう。
私が感じている限りでは、「アジャイル」という言葉は若干独り歩きをしすぎていて、本来意味しているところから乖離してしまっている気はしています。アジャイルの専門家でも何でもないのでこういう言い方はすごくおかしいのかもしれないですが、ウォーターフォール型開発の不都合な部分を解消してくれる、と言えば聞こえはいいですが、不都合な事をしなくてもいい、と言う免罪符として「アジャイル」という言葉を使って開発を進めようとしているだけなのではないかな、と思うのです。
先に挙げた「メソッド屋」さんの記事にもあったのですが、アジャイル「型」がウォーターフォール型に取って代わられているわけではなく、方法論以前、「型」以前にある、目の前の『課題』を解決するための一つのやり方(方法論)でしかない、ということなんだろうな、と思うのです。
もちろん、「このやり方はウォーターフォール型は向いてないよね」とか、「アジャイル向きかなぁ」という議論はなされていいのですが、ウォーターフォール型が向いていないのでアジャイルで、という二極化ではないし、少なくとも向き不向きがある開発手法の一つでしかないということを理解すべきなんだろうな、と思います。
