自己紹介

2018年4月新卒入社、TIG所属の関です。

現在、私は大手メーカー様の社内システムを対象に、アジャイル開発を行っています。
基本的には、プロダクトの全体設計に加えてコアや複雑な部分を担当する開発者として参画していますが、改善提案やPOの補佐的な役回りをすることもある立ち位置です。

このプロジェクトには2年弱入っていますが、開発したシステムは利用ユーザも増え、さらなる拡大を狙う企画も出てきているため、このプロジェクトとしては成功しており、ありがたいことに複数の別プロダクトも担当してもらいたいとの声もいただきました。
2年程度の期間、継続してそれなりの成功を収めることができているため、アジャイル開発をテーマに記事を書くことにしました。

この記事では、アジャイル(ソフトウェア)開発とはそもそも何なのか？ どのような時に採用すべきものなのか？ といったことについて述べたいと思います。

今後も不定期にアジャイルについての記事を出していきたいなと考えており、今回はその第一弾です。

また、当社では私以外にもアジャイル開発に取り組んでいるメンバーもおり、そこで得た知見はJFPUGオープンセミナー2021 DX時代のプロジェクトのあり方で登壇しました などの”アジャイル“タグのついた過去記事で取り上げられております。アジャイルはチームを単位として機能し、各々のチームが置かれた状況によってアプローチも変わってくるため、見比べてみても面白いかもしれません。

アジャイルが注目されているのはなぜか？

実際の定義に入る前に、なぜ注目されているのかを軽く触れておきましょう。

“アジャイル”という言葉が注目されるようになって、しばらくの期間が経っているように思います。
実際、アジャイル経営、アジャイル組織、アジャイル型製品開発、etc.ソフトウェア開発以外にも様々な文脈で”アジャイル”が取り上げられることも増えているようです。
なぜ、”アジャイル”が注目されているのでしょうか？
昨今のビジネス環境は急激に変化しており、それに対する変化対応力が大きく問われています。
この変化対応力に大きな価値を置くのが、”アジャイル”になります。
その起源はアジャイルソフトウェア開発で、そこから輸入される形で様々な分野で取り入れられるようになっています。

アジャイルソフトウェア開発とは？

アジャイルソフトウェア開発宣言にで示された価値観に基づき実践されるソフトウェア開発のことです。具体的には、「下記の4つに価値を置く」という価値観です。

• 個人と対話
• 動くソフトウェア
• 顧客との協調
• 変化への対応

具体的な開発プロセスや手法ではなく、あくまでこれらの価値観に基づくものであるというのが重要です。
また、これらの価値観にはそれを支える12の原理・原則が存在します。

これらの価値観は、アジャイルソフトウェア開発宣言（ないしアジャイルマニフェスト）として、原理・原則はアジャイル宣言の背後にある原則としてまとめられており、日本語を含む各国語に翻訳されています。原理主義的ではありますが、アジャイルソフトウェア開発宣言がアジャイル開発の起源、原典、聖書であるため、この記事を読み進める前にリンクに飛んで目を通していただけると良いと思います。

アジャイルソフトウェア開発宣言はどのような経緯で生まれたのか？

アジャイルソフトウェア開発宣言が生まれた会議の発起人の一人であり、誕生の瞬間の立会人でもあるRobert C.Martinが著した書籍: CleanAgileによると、概ね下記の経緯で生まれたようです。

• 1970年代前半から30年にわたり、ソフトウェア開発プロセスはウォータフォールが主流であった。
• ウォータフォールは、コマンド&コントロールを基礎とするトップダウンな科学的な管理法である。
• 科学的管理法が適するのは、「変更コストは高くてもよい代わりに、目標が具体的であり、明確に定義された問題」である。
• しかし、ソフトウェア開発はそうではなく、(少なくとも著者の周りでは)うまくいってなかった。
• ケントベックのエクストリームプログラミング等に刺激を受けた筆者を含む2名が「軽量級プロセスのサミット」を開催。
• その会議にて、宣言に記載された価値が特定された。

アジャイルソフトウェア開発宣言は「事前に詳細な分析を行い計画を立て、それをもとに入念な設計を行い、それに基づき実装する」というウォーターフォールに対するアンチテーゼとして生まれました。

アジャイル開発を成功させるには？

アジャイル開発を成功させるあたって、考えるべき問題が2つあります。

• そもそもアジャイル開発を採用すべきか？
• どうやってアジャイルの価値を具現化するのか？

この記事では、「そもそもアジャイルを採用すべきか？」をどう判断するかをメインに書きたいと思います。

そもそもアジャイルを採用すべきか、どう判断したら良い？

先ほど見たように、アジャイルは具体的な手法に基づくものではなく、アジャイルソフトウェア開発宣言で述べられた価値観に基づき行う開発です。
まずは、今やろうとしている事に対して、アジャイルの価値観がマッチするかをよく考えましょう。

価値観と対極にあるものが求められているのであれば、ほぼ確実に失敗するでしょう。それでもアジャイルで進めるというのであれば、まずはプロジェクトの責任者、開発者が価値観を理解し、責任者はステークホルダからの理解を得る必要があります。
より具体的には、下記が求められるのであれば、まずはその要求自体を排除する必要があります。

• 開発者の要求の具体例
  • 言われたことだけ、決まったことだけやりたい。
  • 自分の責任で何かを決めたくない、考えたくない、その責任も負いたくない。
  • ビジネス的にどのように役に立つのか興味がないから技術のことだけ考えたい。
• プロジェクトの責任者やステークホルダの要求の具体例
  • 計画やスケジュールは既に固定されたものなので、その遵守を必須とする。
  • 目的が忘れ去られた不要にリードタイムの長いプロセスがあり、その遵守が必須（無駄に煩雑な承認フロー、意思決定や合意プロセスなど）とする。
  • 機能スコープとスケジュールの両方は事前に決めて、削除や変更をしたくない（が、追加はしたい）
  • 最初から完璧なものができないと満足できない。

特に、最後に記載した「機能スコープとスケジュールが変更できない」という要求はアジャイルの「変化への対応」という価値観と決して相入れません。この要求を満たすことが必須の場合は、そもそもの出発点から求めていない事になるので、無理して採用すべきではないと言えます。

人間誰しも、自身が本当に望むものはわかっていないものです。明言されていないからといって要求がないわけではない、ということも認識しておいた方が良いでしょう。組織的な構造やプロセスが問題で要求が避けられない場合もあります。

例えば、直接のステークホルダにさらにステークホルダ（以降、”間接のステークホルダ”と記載）がいる場合を考えてみましょう。間接のステークホルダが、「機能スコープとスケジュールの厳格な遵守」を強く求めており、力関係が「直接のステークホルダ < 間接のステークホルダ」になっていると、「機能スコープとスケジュールの厳格な遵守」は避けられなくなります。このような場合、間接のステークホルダから理解を得られないといずれうまくいかなくなります。

また、誰しも魅力的で都合の良い部分ばかり目に入り、不都合なことは顕在化するまで気づかないものです。アジャイルの採用を検討している段階であるなら、「実は、アジャイルマニフェストの左側の価値観(計画に従う事など)の方が求められているのではないか？」は必ず疑ってみましょう。「流行っているからやってみたい」みたいな理由で安易に採用すると、組織構造などの気付いていなかった思わぬ制約に阻まれて痛い目を見るでしょう。

「よく考えたら実は不要だった」ということも往々にしてあるものです。いずれの場合でも、本当はどうなのかをよく考えて判断する必要があります。
例えば、「最初から完璧なものができないと満足できない」という要求については、多くの場合は排除して良いのではないでしょうか？「システムを導入しその恩恵を受ける」ことが目的であるなら、恩恵を受けられるようになった段階で多少の不便には目を瞑り、利用を開始することで恩恵を受け、それ以後改善と拡張を行う進め方でも問題ないはずです。

逆に、価値観にマッチするような状況であるならば、大きな価値を発揮してくれるでしょう。
これらを踏まえた上で、まずは責任者、開発者、ステークホルダの間でアジャイルの価値観を共有しましょう。プロジェクトを進めるための土台となります。

どうやってアジャイルの価値を具現化するのか？

ここまで、””価値観””という少し曖昧なものをメインで見てきましたが、どのように実践し価値を受け取るにはどうすれば良いでしょうか？
まずは、アジャイル宣言の背後にある原則を念頭に置き、可能な限り実践すると良いでしょう。
また、アジャイルソフトウェア開発は、典型的なプロジェクトの進め方、プラクティス、フレームワークが先人たちによって提唱されており、多くのプロジェクトはこれらのどれかを基礎として進めることが多いです。

しかしながら、大切なのはこれらの遵守ではなく価値観に基づき、価値を体現することです。宣言の「プロセスやツールより個人と対話」という文言にあるように、「採用したプロセスを遵守していれば良い」という類のものではないことは肝に銘じなければなりません。

これらの典型的な進め方について、踏み込んだ内容は次回以降でお送りしたいと思います。

2年弱アジャイル開発を実践して得た所感

ソフトウェアやシステム開発を自身で行うと痛感しますが、事前にわからないことは思った以上に多いです。次のような経験をしている方も多いのではないでしょうか？

• ちょっとした拡張がしたいが、利用しているライブラリに期待する機能がないから自作する必要が出た。
• （特にUIで）微調整に想像以上に時間がかかる。
• 前提として与えられた情報の誤りが判明、修正を余儀なくされる。
• 前任の書いたコードが酷く、変更に一々時間がかかるから改善してから取り組みたい。

一方で、次のような絶対に抑えなければならない項目もあります。

• 全体アーキテクチャ
• データモデル

アジャイルは、事前に入念な計画を練るのではなく、必要な時に必要な分だけ行って、実際の進行具合を見て柔軟に計画を変更することで、継続的に現実の複雑さ、変化、問題に対処し、”その時点での最大価値”を目指す考え方です。”必要な時に必要な分だけ”というのがキーワードですが、単に詰んでいるのを”必要になった!”と誤認している方もいるようです。簡単なように見えて実は難しく、意外にも準備はとても重要です。

お客様を含む周囲に恵まれたことに加えて、現実に即した考え方を好み、単純に開発が好きという自身の特性が上手く噛み合ったことで、2年弱の間、開発したシステムの価値が向上していったのではないかなと考えています。

次回以降は、自身の経験を踏まえた、アジャイルソフトウェア開発の全体の流れや、どんな人や環境がマッチするのか、”こんな時にはこう対処する!”といったもう少し踏み込んだエピソード、よくある誤解などについても記載していきたいと思います。