質問: ### ご挨拶 お世話になります。 アジャイル開発についての質問をさせていただきます。 質問に対し、自分なりにそれぞれ2通りの回答を考えてみました。どちらの方がより正しい認識でしょうか? 少々長い文章となりますので、まず内容を列挙します。 ### 本文の構成は以下の通りです。 1.質問1 2.質問2 3.質問の背景 4.質問1 への想定される回答 1 5.質問1 への想定される回答 2 6.質問2 への想定される回答 1 7.質問2 への想定される回答 2 ### 以下本文です 1.質問1 アジャイル的アプローチで業務システムの開発を行うことは可能か? 2.質問2 アジャイル的アプローチで業務システムを開発する際、DBのテーブル設計をコーディングと並行で進めることは可能か? 3.質問の背景 当方、最近新しい案件にて客先業務システムの設計・開発に関わっております。 ウォーターフォールでの業務システム開発ばかりやって来た身です。 当該客先でのプロジェクトの進め方に現在疑問を持っております。 根拠 概要設計→詳細設計→コーディング→単体テスト→結合テスト と作業ごとのチェックポイントを用意していない。 業務部門がスケッチした画面イメージと簡単な説明を参考にいきなりコーディングを始めています。 設計が無いので当然テストも存在しません。 また、存在する資料が画面スケッチだけなのでテーブルレイアウトも存在しません。 テーブルはコードを書き始めて「必要だと判断したものを作る」というスタンスです。 アジャイルならこの進め方で大丈夫なのか?そこが一番の疑問です。 そもそもこの進め方はアジャイルなのか?という疑問もありますが、論点が分散してしまうので伏せさせてください。 4.質問1 への想定される回答 1 不可能 根拠 : http://www.nec-solutioninnovators.co.jp/column/01_agile.html にある通り、「当初計画された機能が100%完成することは困難」なので契約締結が不可能 5.質問1 への想定される回答 2 限定的に可能 根拠 : https://japan.zdnet.com/article/35003680/3/ にある通り、発注側と受注側の利害調整を織り込んだ契約を締結する。加えてプロジェクトの進行自体も下記7の通りリスクヘッジを行う。 6.質問2 への想定される回答 1 不可能 根拠 : テーブルレイアウトを考えないことはつまり、当該業務システムのインプット及びアウトプットの関係を意識しないままコードを書き始めることに他ならないと考えられる。よって、何ができればこのプロジェクトが成功かを判断することができず、プロジェクト完了までの工数見積もりが不可能。 プロジェクト自体に予算制限があるので、その制限を無視できるほど小さなプロジェクトであるか、もしくは際限なく予算を拠出できるほど経営体力のある企業でない限りアジャイルで業務システムを開発することは不可能。 7.質問2 への想定される回答 2 限定的に可能 根拠 : 上記6の「不可能」ケースの逆を行えば可能。工数見積もりの不確実性を排除するために、最低限実現したい業務の定義〜利用するテーブルのレイアウトまでは各スプリントの一番最初に決めておく。 以上となります。何卒よろしくお願い致します。
回答: > > アジャイル的アプローチで業務システムの開発を行うことは可能か? > > > 顧客がアジャイルの正しい認識をしていれば可能ですが、おそらく失敗します。 理由は、一般的に顧客はシステムの要件を最後まで固めたくないはずです。 顧客は要件追加、仕様追加、機能追加できるだけやりたいと思っています。 要件が固まらないとアジャイルにしろウォーターフォールにしろ先の工程に進みません。 顧客のアジャイルのイメージが、 「仕様決定の先延ばしが可能」とか「機能追加が容易」という偏ったモノであった場合は確実に失敗します。 ウォーターフォールより圧倒的に短いスパンで、確実に仕様を決めていける顧客であれば期待できなくもないですが、 質問2が出てる時点でダメです。 OSやDBや言語やライブラリの選定など一番最初に確実に決めないといけないことも多々あります。 > > アジャイル的アプローチで業務システムを開発する際、DBのテーブル設計をコーディングと並行で進めることは可能か? > > > 不可能ではないですが、 コーディング(業務ロジック)で直接ORマッパーを呼んでいたりすると、面倒ですね。 ORマッパーと業務ロジックの間に何か別のwrapper入れるとか考えないといけません。 またプロジェクト全体で考えると テーブル設計が出来てないと、運用設計(通常業務、マスタ登録など)も出来ないので、 そもそもコーディングにはいるべきではないと考えます。 > > 3.質問の背景 > > > アジャイルでもチェックポイントがないのはダメです。 ストーリーテスト(ちょっと昔はDoneの定義)って言って 受け入れのチェックポイントがあります。 ちなみにドキュメントが不要ってもの嘘なので、 ちゃんと設計書書いてもらってください。 あとアジャイルって工数を見積もらないはずですが、、、 ポイントって概念でやってるはずです。 契約も請負ではなくて委任ですよね。 システムの最終的な構図って誰かイメージしていますか。 どう考えているか確認していないと、 アジャイル開発やる方向性もあらぬ方向に向かってしまいます。