【考察】アジャイル開発を維持し続ける方法

開発手法の一つに「アジャイル開発」というものがあります。
直訳すると「俊敏な」「素早い」という意味の単語を用いたものです。

この「アジャイル開発」を採用していれば、何でも早く出来上がる…というわけではありません（残念ながら…）。
ただ、その誤解を与えてしまうということも事実です。

では、「アジャイル開発」を採用したとして、どうすれば順調に、ちゃんとした「アジャイル開発」ができるのか。
ある程度進めている状態ですと、その習慣からの脱却は難しく、そのための軌道修正・リカバリーの時間も必要になると思います。
ですので、最初から手を打つために、考察していきたいと思います。

触れない内容

• 開発手法の詳細
• スクラム開発に関する内容

手法として何があるのか

あくまでも作業(開発)を進めていくための手法の一つとして「アジャイル開発」があります。
他にもどういう進め方があるのかを知っておいた方が、より良い方法を考えることができると思うので、簡潔にですがまとめます。

1. ウォーターフォール開発
   • まず最初に、全部準備する。終わったら作業を全部実施。最後に全部、確認をする。
   • 都度修正することもあるが、前提が変わった場合、最初の準備からやり直しになる。
2. プロトタイプ開発
   • 準備もそこそこに、最初に全体の試作品を作成する。試作品に対して何度も意見をもらいつつ、完成に近づける。
3. スパイラル開発
   • 細かい単位(機能ごと)で試作品を作成し、できたタイミングで意見をもらいつつ、完成に近づける。

では、表題のアジャイル開発を見ていきます。

アジャイル開発

上記のページに記載されているのがマニフェスト、根幹となる考え方になります。この内容を読んで思うことは、

• 「関わる人全員で協力」し、「対話を活発」に行い、「資料よりも実物を確認できる」状態にすること。
• 「計画は計画として、情勢や環境などの変化に対応できる」状態になること。

が大事なのではないかと思います。

つまり、 短い期間 で逸早く 誰もが実物を確認できる・触れる 状態になるように公開し、 一定の品質を常に維持し続けながら作業 を行わなければならない。
これを満たすための仕組みがないといけません。

何が必要か

「短い期間で一般公開（リリース）」するために、短い期間での計画が必要です。また、その期間内でどうやって作っていくのか、どこまで作るのかを考える必要があります。

そのために用いられるのが、「イテレーション/スプリント」の考え方です。

また、「一定の品質を常に維持し続ける」ために、「自動テスト」を取り入れます。その自動化されている範囲によって、常に担保できる範囲も異なりますので、その点には注意が必要です。

開発手法で共通すること

様々な手法を見比べた時、異なるのは取り組み方のように思います。ということは、どの手法を採用したとしても、やることは変わりません。

1. 何を作りたいのかを明確にする ⇒ 要件定義
2. どうやって作る/どうやって動くのかを決める ⇒ 設計
3. 実際に動くものを作る ⇒ 実装
4. ちゃんと要件通りか、セキュリティのリスクなどが発生しないのかを確認する ⇒ テスト
5. 作ったものに問題がないかを確認する ⇒ レビュー

つまり、どの手法を取ったとしても、最低限実施しないといけない作業量も変わらないですね。
その作業に対してどのぐらいの時間を使う(完成度で実施する)のか、どのぐらいの頻度や規模でフィードバックをもらうのか、その違いしかないようです。

何が大事か

やらなければならないことが変わらないのであれば、どれに重きを置くのかが大事になりそうです。
「要望を叶えたもの」なのか、「完璧さ」なのか、「スピード感」なのか。

どの手法が良いということはなく、目的に沿った手法を選ぶのが良いと思います。

考察

では、どのようにすればアジャイル開発を効率良く進められるでしょうか。
ここから先は、アジャイル開発としては定義されていないため、その時々によって異なる進め方をしていると思います。
しかし、この進め方次第で効率良く進められるかが決まるため、少しだけ具体的な考察をしていきたいと思います。

何か開発をする時、必ず、「どうしたいのか = 要件」が存在します。
「何か解決したい目的」が存在しているわけですから、その内容を明確にする作業(=要件定義)が必要です。
この始まり方は、どの進め方であっても、動かすことができません。

①要件定義

• どういう不便/問題があるのか。
• どういう風にしたいのか。

要求に関して、たくさん会話し、文化や風習を知り、不明点を取り除き、 明文化 します。
ただ結論だけが残っているのではなく、ある程度の経緯も箇条書きであったとしても、残しておいた方が良いと思います。

スモールスタート

この時点でどのぐらいでできそうか、見積もりをしてほしいという依頼があるかもしれません。
ここで大事なのは、「どこまでの内容をいつまでに欲しいのか」を会話しておくべきことかと思います。

依頼者としては「完璧なものをできるだけ早く欲しい」になります。当然ですね。
開発者としては「まだ始めてもいないものを計算したとして、その見積もり通りに作れたら奇跡」な気持ちです。実際よりもかなり長い期間を提示するかもしれませんし、希望に沿う形で無理をしてでも完遂するスケジュールを提示するかもしれません。

長い期間であれ、短い期間であれ、どちらもしんどいです。今まで面倒だったものを楽するために作ろうとしていたのに、実際に使えるようになるのが遅いのであれば意味がない…。となるかもしれません。また、頑張れば何とかなるような開発期間は、開発者が無理をするため、疲弊していきます。

まずは、 今一番抱えている問題を解決するために、最低限何が必要 なのか。また、
今後完成させていくうえで、 どこまでを作った方が効率的 なのか。

それを見極め、会話し、できるだけ少ない量を現実的な期間で作り上げていく、スモールスタートが大事かと思います。

気を付けたいこと①

規模を縮小(スモールスタート)にするのは、実際に「ここまで作りましょう」を決める時だけに止めましょう。構想やアイデアは、止めてはいけません。
一緒に戦略を考え、どうやって成長させていくのか、どうやって売り出していくのか。共有できる状態を作り上げていくことも大事だと思います。

気を付けたいこと②

話し合いをしている時点で、用語/単語 の意味を確定させ、論理名と物理名を決めておいた方が良いと思います。つまり、 索引化 です。
話を重ねていくと、その時に使う単語やその意味も段々分かってきますが、初めて参画した人からするとよく分からない状態になります。
初めてその単語を聞いて、その時に「どういう意味だろう？」と思ったタイミングで書いておかないと、どれを管理して補足した方が良いのかが分からなくなりがちです。
これは要件定義に関わらず、開発中であっても、単語の論理名と物理名をマッピングさせる習慣にし、同じ単語なのに別の表現になってる…といった事態を防ぐ対策をすることも大事だと思います。

気を付けたいこと③

どちらの立場も「優位になってはいけない」ことです。あくまでも、「開発者」と「依頼者」の立場に上下はなく、一緒に作り上げていくものです。開発者優先で作り上げられたり、依頼者の意見優先で作り上げていく進め方は、「アジャイル」ではありません。会話をし、お互いの意見を取り入れ、より良いものを作れる環境が大事です。

また、「実際に作業する開発者の意見」も無視してはいけません。見積もった期限に対して、もしかしたら遅れることも、ちゃんと会話をする必要があります。「依頼者」としては関係各所との戦略や調整がもちろんありますから、動かせないことの方がほとんどでしょう。ですが、実際に作業する人が疲弊、倒れてしまっては、完成することはできません。また、会社に属している場合、有給休暇を取得する可能性もあるでしょう。そういった部分をちゃんと考慮・会話し、随時進捗を共有することも大事かと思います。

要件が決まり、期限が決まったら、開発期間に入ります。
着手する作業によって様々かと思いますが、「サービス設計」→「要件開発」→「詳細開発」の順で進める方法が良いと思います。

②開発作業

少し長くなりましたので、別の投稿としてまとめています。
よろしければご覧ください。

気を付けたいこと①

「要件開発」の時点で頂いた「依頼者」の意見を、全部取り入れないように注意が必要です。
段階的に作り上げていくことをお互い常に意識し、どのタイミングで取り入れるかを明文化しましょう。せっかく出た意見を、無駄にしないようにします。また、採用を見送った意見とその理由も明文化しておいた方が良いと思います(歴史は繰り返しますし、前提としていた環境が変わる可能性もあります)。

⑤テスト

開発が完了したら、非機能面での試験や業務観点を踏まえたシナリオテストなど、テストの期間に入ります。
基本的には、「詳細開発」で確認できていない箇所だけを実際に確認することになります。また、
「シナリオテスト」であれば、今後成長させていくことを踏まえ、自動化するのも一つの手かもしれません。

まとめ

補足も加筆しつつ、まとめます。

• どの手法を採用したとしても、やることは変わらないため、作業量も変わらない
  • もしも完成時期を早くしたいのであれば、やることを減らすしかない
  • やることが減らせない場合は、複数人が同時に作業ができる状態を維持し続ける
    • どうしても同時にできない作業があることを、共通認識として持つこと(その場合、早めることはできない)
• 短い期間でリリースできる状態を維持するのが、アジャイル開発
  • 細かいフィードバックを得るために、「スプリント/イテレーション」の考え方を採用する
    • 作業量が多く、見せられる状態にできない場合は、作業期間を調整した方が良い
    • 常に一定の作業期間の方が、全員の予定調整がしやすいが、何も見せられない状態が発生するリスクも共通認識として持つこと
  • 品質を常に担保するために、自動化テストを採用する
    • どうしても手動でしかテストができない部分以外は、自動化するべき
    • 日々動かすかは置いておいて、自動化テストの作成にも 自動化の実行にも時間がかかる現実は、どうしようもないので許容するべき
• 対話が大事 = 調整ができる関係性・環境であること
  • 開発計画 と リリース計画 は、本質が異なるものなので、別物として扱うこと
    • 依頼者と開発者のどちらかが優位になった(合意の取れた調整ができなくなった)時、いずれ、仕事の品質にも影響を及ぼす
    • 祝日 や 有給休暇 など、期間によって状況は変わるため、考慮すること
  • 対話した内容は、すべて文書化すること
    • 議事録(メンテナンスしない) & まとめページ(メンテナンス必須) での管理が望ましい
    • 話をした内容の議事録を書く人が必要。会話の場の最後に、その内容を見返す時間があると尚良い
• 「初めまして」は必要最小限にすること
  • スモールスタートを心掛け、どんどん育てていく認識を、全員が持つ
    • 構想は最大限、どんどん深掘りしていくこと(情勢などによって、途中で変わることが大前提)
    • 意見の中で優先順位を明確にし、現実的な期間でどうやっていくか、一緒に構想を練っていくこと
  • 実際に動いて、触って、確認ができるものを短期間で作っていく
    • 確認して欲しい範囲、確認してもらうべき範囲を、開発者が明確にし、絞った状態で共有すること

最後に

「アジャイル開発」に何となくで参加できてしまうのも恐ろしいところです(私も、初めはそうでした……)。
何度かアジャイル開発を経験し、あじゃいるかいはつ... とゲシュタルト崩壊し、おぼろげに見えてきたものをまとめました。

アジャイル開発で奮闘している方の、少しでも力になれば幸いです。

蛇足 ～アジャイル開発で大事なこと～

一番大事なのは「期限」と「リリースする機能」が調整できることだと思います。
大きな規模になるほど、それが疎かになりますし、調整ができないことが多くなるかもしれません。
もしも調整ができない(=会話ができない)のであれば、アジャイル開発ではありません。

また、全ての要件や意見が、共有されないという状態(途中経過の共有がなく、結論だけ共有される場合)もあり得ます。
もちろん、全てを共有したり、確認する時間というのはコストになります。現実的に、その時間が勿体無い…となる可能性もあるでしょう。
しかし、そういった情報を確認できる手段がないのであれば、アジャイル開発ではありません。また、アジャイル開発であれば、そういった時間・コストも含めて、許容するべきです。
（実際には参加人数を絞るなど、発言がしやすい人数での会話の場である必要があります。可能であればそういった場に、交代で議事録を書く役割として参加し、全員が関わっていけるような工夫をすると良いと思います）

二番目に大事なのは「どこまでを自動化されたテストにできるか」だと思います。
自動化テストは、ちゃんと意図を持って、目的を明確にして作らなければ、すぐに使えないものになります。

「実際に触って実施したテスト(=手動テスト)が良い！」は、そのテストを行った人の腕が良いから、です。本来テストをするべき場所だけでなく、「ここも確認しようか…」をやってくれるからです。
自動化はそこまでやれません。「どの箇所がどうなってほしいのか」を確認する作業を、素早く、楽に、何度でもやってくれるのが利点です。
もちろん、要件や機能、業務フローが変われば、テストの内容も変える必要があります。その部分は、手動テストでも同じです。
初めのうちに、どこまで作れるのかが肝だと思います。後回しにすると、作ることはほぼ100%なくなります…(ライブラリや外部サービスのバージョンアップの作業、デグレなど、再試験をする場面が発生する可能性は高いので、作っておくべきだと思います)。