はじめに

こんにちは、Technology Innovation Group所属の久保です。

自分が担当した業務でのアジャイル開発での失敗について反省したいと思います。選定したアーキテクチャとアジャイル開発の相性があまりよくなく苦労しました。これはアジャイルの本にはなかった知見でした。

アジャイル開発ってなに？

Wikipediaにはこのように書いてありました。

ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。

引用:アジャイルソフトウェア開発

アジャイル開発のメリットと落とし穴

メリット

上記の様にアジャイル開発では短いスパンでアプリをリリースしフィードバックを頂きながら開発を進めるというものです。

メリットとして短いスパンでフィードバックを貰うことで顧客の求めるものと出来上がるもののイメージがあまりブレず、手戻りなどが少なく開発を行えるという点があります。そのためアジャイル開発は仕様変更に柔軟に対応できる開発方法と言われています。自分のプロジェクトでは2週間に1回アプリケーションをリリースしフィードバックを頂き開発をしていました。

ユーザー要望でデータ表示条件の増加

ではなぜアジャイル開発で失敗したのか？自分の失敗を話したいと思います。私が作ったシステムはIoTデバイスで取得した日次のデータをKVSに格納しアプリケーションに表示するというものでした。

開発初期から表示するデータの要件定義は以下のように変化していきました。

取得したデータを閲覧できるようにする
取得したデータをソートして閲覧できるようにする
取得したデータをソートして閲覧できるようにする。IoTデバイスがデータの取得に失敗した時は失敗したことがわかるように表示する
取得したデータを状況毎に表示を変えソートして閲覧できるようにする。IoTデバイスがデータの取得に失敗した時は失敗したことがわかるように表示する

４は少し分かりづらいですがIoTデバイスが故障している場合や電池切れ、電源が入っていないものは「IoTデバイスの状態」を表示するという仕様の追加でした。

落とし穴

今回使ったKVSではソート条件を追加するにはインデックスの追加が必要であり、これはコスト増加することに繋がります。またKVSでは検索条件の追加やソート条件の更新を行う度に、データマイグレーションが必要となります。日次データを取り扱っている為、データ量が多くデータマイグレーションを行うこと事が非常に大変でした。

このようにフィードバックを受ける度に要件が増えることで工数がどんどん増えていってしまいました。

初期の要件定義の時点ではユーザーストーリーなどの仮説が荒く、詰めきれない場面が多く追加要望が来る度に仕様の変更を余儀なくされていました。一次情報保存先のKVSとは別に、閲覧用にデータ分析用のRDBMSを追加するなど、要件変更に耐えうる構成などもできましたが、コストの増加の面から採用を見送りました。

初期の段階である程度仕様を詰めたり、途中のフィードバック時に仕様を落とし込めていれば工数はもう少し下げれたと考えています。

最後に

自分のアジャイル開発での失敗談を書いてみました。

DBMSのアーキテクチャやデータマイグレーションが変更の容易さに与える影響など、クラウド時代に増えてきた特徴の強いDBMSを活用する場合に、ある程度変更の範囲を予測するなり、事前に合意するなりする必要があると感じました。
同じようなミスで苦しむ人が少なくなりますように。

次の失敗談をテーマにした連載は、岸下さんのGoogleWorkspace SDKのAPIリクエスト間隔は気を付けましょうでし・

ユーザー要望で要件が増えてく〜アジャイル開発での落とし穴〜