アジャイル開発について

Question

###ご挨拶
お世話になります。
アジャイル開発についての質問をさせていただきます。
質問に対し、自分なりにそれぞれ２通りの回答を考えてみました。どちらの方がより正しい認識でしょうか？
少々長い文章となりますので、まず内容を列挙します。

###本文の構成は以下の通りです。
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の「不可能」ケースの逆を行えば可能。工数見積もりの不確実性を排除するために、最低限実現したい業務の定義〜利用するテーブルのレイアウトまでは各スプリントの一番最初に決めておく。

以上となります。何卒よろしくお願い致します。

Answer 1

アジャイルに関しての質問になっていますが、根本的な課題はそれでは無いように見受けられます。
リーンも視野に入れてと書こうかと思いましたが、そんな状況じゃないですね。

顧客の強い立場に押し切られ、コントトールのできるマネージャが不在な為、各々の判断で進めているプロジェクトという印象です。

どんな開発技法であれ、最低限のドキュメントやマイルストーンによるタスクの管理ができていないようでは破綻します。

顧客が開発に必要な役割を担ってくれないなら、その役割を肩代わりしてそのコストを請求する。
営業が顧客に良いことだけ言って取ってきた仕事だとしても、再度全体を見直す位の強い推進力が必要な状況だと思われます。

Comments

[Mimiga]

ご回答ありがとうございます。
まさに、開発手法どころではないですよね。
数週間前に客先マネージャーとブリーフィングをした際、作業の進め方やその段取りについて質問したのですが、回答の言葉尻が土石流のように濁っていたので、悪い予感が当たったという感触です。
実際プロジェクトの進め方自体について、先方に意見具申を考えている最中です。

「ドキュメントはなるべく作らず」という先方の言葉を、「つまりアジャイルみたいな事するのか？」と勝手に想像したのはまずかったです。
「アジャイル手法を学習するチャンス？」とスケべ心があった事も否定できません。スケべはよくないですね。

Answer 2

アジャイル的アプローチで業務システムの開発を行うことは可能か？

顧客がアジャイルの正しい認識をしていれば可能ですが、おそらく失敗します。
理由は、一般的に顧客はシステムの要件を最後まで固めたくないはずです。
顧客は要件追加、仕様追加、機能追加できるだけやりたいと思っています。
要件が固まらないとアジャイルにしろウォーターフォールにしろ先の工程に進みません。
顧客のアジャイルのイメージが、
「仕様決定の先延ばしが可能」とか「機能追加が容易」という偏ったモノであった場合は確実に失敗します。
ウォーターフォールより圧倒的に短いスパンで、確実に仕様を決めていける顧客であれば期待できなくもないですが、
質問2が出てる時点でダメです。
OSやDBや言語やライブラリの選定など一番最初に確実に決めないといけないことも多々あります。

アジャイル的アプローチで業務システムを開発する際、DBのテーブル設計をコーディングと並行で進めることは可能か？

不可能ではないですが、
コーディング（業務ロジック）で直接ORマッパーを呼んでいたりすると、面倒ですね。
ORマッパーと業務ロジックの間に何か別のwrapper入れるとか考えないといけません。
またプロジェクト全体で考えると
テーブル設計が出来てないと、運用設計（通常業務、マスタ登録など）も出来ないので、
そもそもコーディングにはいるべきではないと考えます。

3.質問の背景

アジャイルでもチェックポイントがないのはダメです。
ストーリーテスト（ちょっと昔はDoneの定義）って言って
受け入れのチェックポイントがあります。
ちなみにドキュメントが不要ってもの嘘なので、
ちゃんと設計書書いてもらってください。

あとアジャイルって工数を見積もらないはずですが、、、
ポイントって概念でやってるはずです。
契約も請負ではなくて委任ですよね。

システムの最終的な構図って誰かイメージしていますか。
どう考えているか確認していないと、
アジャイル開発やる方向性もあらぬ方向に向かってしまいます。

Comments

[Mimiga]

ご回答ありがとうございます。
システムの完成図・システムで何をしたいか、それを客先の人々が自分たちの事としてちゃんと考えているのか、それこそが今、自分が一番懸念しているところでもあります。

現に、画面の見た目以外は我々外注に投げっぱの進め方
これは、都合のいいたたき台から作ってもらおうという、お客の諦めを表した態度ではないかと、
正直な所、自分は今そう受け取っております。

Answer 3

1.質問1
可能。
ただし、費用の支払いなどには十分に打ちあ合わせが必要。
会社間のトップ同士はどう思ているのか？

2.質問2
可能か不可能かでいえば、可能。
ただし、相当無茶な気がします。

本当に危険な匂いがしますね。。。

Mimigaさんの立場やポジションはわかりませんが、例えば、あくまでも期間契約で、システムの完成ではなく、あくまでも作業時間で費用を請求できる契約なら、まだ救いはありますが、プロジェクトがうまくいっていないと、いろいろとばっちり受けそうですからね。。。

ただ、その状況は興味深いです。
一体、誰がそんなやり方にすることに責任を持っているのでしょうか？

Comments

[Mimiga]

ご回答ありがとうございます。
実際、きな臭くて仕事上がりには毎日喉が痛いです。

先方のプロジェクトは某なんちゃってデータベースで作成された、旧い業務システムを .net でリプレースするという案件で、自社内製なので、コスト面などある程度融通がきくのかと考えています。
客先にはシステム部門が存在し、一応 SIer 出身の中途入社の人がプロジェクトの進行を仕切っている、、、状態です。本当なのかな。

自分は昨年より独立した自営業で、そのプロジェクトにプログラマ名目で参加しています。参加の仕方自体は、派遣会社の正社員時代と変わらないので、時給でお金の請求ができますが、先行きは不安ですね。