Posted at

アジャイルとは何か?の理解に向けての備忘録

More than 1 year has passed since last update.


前書き

ソフトウェア開発の世界では、アジャイル型開発という言葉が注目されています。従来、ソフトウェア開発の主流にあったのはウォーターフォール型開発と言われる手法で、それに対する新時代?の開発手法として注目されているわけです。ですが、アジャイルとはなんですか?ということを聞くと「アジャイルは思想だ!」という人が現れたり、アジャイルの解説本を読もうとすれば大量の資料が出てきたりと、理解し難かったです。そんな中、知人と議論していて一つの自分なりのまとめが出来たので、何かの参考になればというわけで晒すことにしました。

この文章では、最初に開発手法を左右する4要素を述べて、次にウォーターフォール型開発との違いをその四要素を使って説明します。最後に理解を深めるために自問自答した幾つかの疑問を解決していきたいと思います。


開発の4要素

開発を左右する要素は、大きく分けて4つの要素があります。


  • ゴール:開発すべき機能

  • 人的/金銭的リソース:開発を実施する人、お金

  • 時間:開発を完了させるまでの期間

  • 品質:出てきたものをどのクオリティで仕上げておくべきかの取り決め

ゴールは、開発する機能そのものです。顧客の要求そのものと言い換えても良いです。重要な事実は、要求は開発途中に変化していきます。時代の進展が激しくなり、当初考えていたビジネスが成り立たなくなったパターンもあるでしょうし、逆に顧客が自身の要望を深く理解していなかったパターンもあるでしょう。

人的/金銭的リソースは簡単です。そのソフトウェアを開発することができる人の量や、投入することの出来るお金の量です。一般的にはゴールに設定できる機能の量や品質とトレードオフがあります。

時間はその名の通り、納期や、スケジュールです。時間的リソースとしてリソースの中に含めるという考え方もあるでしょうが、アジャイルを考える上では少し重要なファクターに見えているので期限は別の要素として定義しています。

最後に品質ですが、これは「ソフトウェアの機能をいかに満たすことができたか」の他にも、バグをどれだけ取り除くことができるか、などに関する取り決めです。「取り決め」という言葉を使っているのは、他の3項目と違って品質を直接的に証明することは難しいので、テストを実施して品質を満たしていることを確認することを意識しています。


アジャイルとウォーターフォールの違い

では、この要素を使ってアジャイルとウォーターフォールは何が違うのかについて解説していきます。端的にいうと、この2手法は開発を始める前に固定させておく要素と、開発の中で変化することが予想されるために管理すべき要素が違います。

開発手法
開発前に固定する要素
開発の中で管理する要素

ウォーターフォール
ゴール
リソース、時間、品質

アジャイル
リソース、時間、品質
ゴール

ウォーターフォール型開発においては、ゴールは開発前に決定され、変更されることはありません。ゴールを達成するためにリソースと時間と品質を天秤にかけながら、計画が破綻しないように管理する必要があります。ゴールが明確なため、手戻りはすなわちミスを意味します。開発の一つ一つの工程を完璧にこなせる状態を維持する管理手法をとります。

一方、アジャイル開発では、リソース、時間や品質を固定します。短い開発期間を設定し、リソースも足らなければ逐次投入というわけではありません。品質も短い期間で出来る物を設定します。ただ、短い開発を何度も繰り返すために、ゴールをその都度設定できます。この性質を利用して、短い開発が積み重なった際の全体的なゴールを管理、調整するのです。


理解を深めるための自問自答集

上の定義で考えると、アジャイルやそれを取り巻く、いろいろな疑問に関して答えが出てくると思います。個人的なQ&Aは以下の通りです。


アジャイルってなんで短い開発サイクルを繰り返すの?

目標に追随するための手法だと思うのが自然かと思います。目標がころころ変わりうるなかで、長期間の計画は簡単に破綻します。それに対応するために、管理スパンを短く区切ることで、計画の破綻に対するリスク管理をしているのでしょう。短い開発スパンを繰り返したいのが先なのではなく、目標の変化に対応する修正計画をどんどん出していくのが目的の手法と理解しています。


開発が早くなるって本当?

嘘です。同じものを作るなら、同じような時間がかかるでしょう。アジャイルで開発時間が減るのだとしたら、元のウォーターフォールでも設計が悪いのでしょう。アウトプットの見え始めが早いだけです。見え始めが早いため、ゴールの再擦り合わせを何度も実施することが出来ます。


短い期間では大規模なものなんて作れないのでは?

最初に、大まかな全体の計画を立てておくことが大事です。アジャイルはあくまで、ゴールの修正を頻繁にするための手法なので、開発チェックの区切りを短くしているだけで、全体の長期計画がなくて良い、ということは一言も言っていないと思います。


ゴールを管理するって、ゴールは最初に決める物でしょ?

開発内容が変化する、ということに関して疑問が出る人もいるでしょう。しかし、顧客は自身の要求をよく理解していないことが多く、理解していると思っていてもその内容はあやふやなことも多いです。運良く顧客が要望を深く理解していても、ビジネス環境の変化が要望を変化させることもあるでしょう。ウォーターフォールの場合は、目標を最初に固定してしまうことで、その変化を受け入れない手法を取っていました。これは、ゴールの変化に関する開発へのインパクトが非常に大きかったからと予想していますが、先人の知恵と努力により様々な開発ツールが導入され、変化を受け入れやすい体制を作れたのが、アジャイル型開発というものが生まれた元にあるのだと思います。


ゴールを変更できるの?じゃあ開発側に要求変更し放題じゃん?

ウォーターフォールで同じことをすれば、コストがたくさんかかると思います。アジャイルでも同じことが起きます。ゴールはあくまで擦り合わせをする物であって、大幅な変更には同じようにリスクが伴います。「同じ物を開発するには同じだけのコストがかかる」ということを意識しなくてはいけません。そこを顧客と開発者がしっかりと意識を合わせることが重要かと思います。アジャイルでは顧客もチームの一員だ、と言われることがありますが、それはこの面を注意するための物と理解しています。


アジャイルは少人数でやるべきなんだ!という意見があるけどあれ何?

目標を調整する、というのは並大抵ではありません。人の意識を合わせることほど難しいことはないからです。なので、アジャイル型開発を語った本では「チームの人数はx人程度が望ましい」や「ステークホルダーは誰なのかを整理し、リーダーを決めること」という注意書きが多くなります。目標の擦り合わせが頻繁に起こるため、リーダーの重要性が重くなります。船頭が多く、山に登ってしまうことは防がなくてはいけません。


アジャイルは思想っていうけどあれ何?

アジャイルは目標をコントロールするため、ウォーターフォールよりもまして関連メンバーの考え方が重要になります。そういう意味で、実開発管理手法(スクラム等)と分けて思想として一つまとめるべきだという考えがあるのだと理解しています。これがさらにアジャイルの考えをややこしくしている気がするので、あえて手法としてもアジャイルという表現を使っています。逆にウォーターフォールにもウォーターフォールの思想の面と、開発管理手法としての面があると思います。どちらもアジャイルに比べて分かりやすいため、区別して描かれることが少ないのだと理解しています。


現実問題とのリンク

以上でアジャイルとは何か?に関しては終わりなのですが、もう少し現実とリンクさせたいと思います。アジャイルが向いていると思われる場面は、内製をして、なおかつ変化の激しい市場で臨機応変に戦っている場合かと思います。しかし、外注している場合にはなかなか難しい、というのが今の私の感想です。目標の変化を外注先で決めるわけには行かないので、意思疎通が大事です。しかし外注、特に請負の場合は、法的制約もあって、発注元と発注先がチームを組むというのも難しいでしょう。また、開発コストは先人の知恵によって下がっていますが、意思決定コストもアジャイルでは無視できません。ゴールをすり合わせるということは、頻繁に意思決定が起きます。ステークホルダーが多く、なかなか意思決定ができない場合は、アジャイルは厳しいのではないでしょうか。ただ、変化を柔軟に受け入れる強力なツールであることは確かだと思うので、なんとかこのあたりのブレイクスルーがあれば良いなと思います。最近ではウォーターフォールとのハイブリッドなども提案されているようです。


終わりに

まだまだ抜け漏れ、考察の穴はあると思うのですが、漠然と開発が早いんでしょ?レベルからは脱出できたような気がするのでまとめてみました。考え方にも様々なパターンがあるお話だと思うので、これが正解!というわけではないでしょうが、皆さんの理解の一つの助けになれば幸いです。何か知識アップデートがあれば、更新していこうと思います。