仕様変更の常識(3)-アジャイル開発の仕様変更の性質

2018年8月23日木曜日

システム開発

t f B! P L
 厳密にはアジャイル開発という開発手法は存在しない。
 アジャイルに該当する開発手法は「スクラム」「XP」など複数存在しそれぞれ開発手法は違う。それら全てに共通しているのが「反復開発」と呼ばれる固定した反復期間(イテレーション)ごとに完成したソフトウェアをリリースしユーザーのフィードバックを受けながら機能追加と修正を繰り返していくという手法だ。
 「アジャイル」という名はそれら似通った反復開発手法に付けられた「総称」でありカテゴリ名称である。

 システムを外注する非情技の人には細かい「スクラム」や「XP」「FDD」...といった知識は必要ない。ただ反復開発のルールだけ知っていれば良い。だから「アジャイル」という総称にまとめているのだろう。

 今回はアジャイル開発の仕様変更について語りたい。

 <図1:アジャイル開発>


 アジャイル開発はシステム構想を練った上で大筋のシステム企画を立て、詳細な要件は定めずにシステムの設計開発に着手する。開発は反復期間(イテレーション)と呼ばれる「一週間から一ヶ月程度の固定期間」の中で「設計・開発・テスト・納品」まで行い、反復期間ごとに「動くソフトウェア」を納品する。
 ユーザーは納品されたソフトウェアを検証して「次に作りたい機能要望」を定義する。この要望をここでは「目標定義」と呼ぶ。「目標定義」は一般的な呼び名ではない。

 正確にはユーザーが「要望定義」を情技師に提出し、情技師がシステム的技術的に正しい形に修正し「目標定義」にまとめる。「目標定義」はユーザーの承認を受けた上で「次の反復期間」に投入される。

 反復期間は何度も繰り返す。反復期間が二週間で開発期間が半年ならば、13回反復開発を繰り返す。(通常は最初の一回目の反復期間だけは共通部を開発する為、一ヶ月から三ヶ月など長期の反復期間を取る)

 反復期間の中はウォーターフォールなので反復期間の中での仕様変更は出来ない。

 アジャイルでは仕様を定めるのは一つ前の反復期間にユーザーと情技師(プロダクトオーナー)が相談して「目標定義」を定める。
 定められた「目標定義」は次の反復期間に投入される。

 仕様を定めるのが反復期間の直前なので開発途中で仕様変更したことにならない。反復期間内の仕様変更は禁止で「新規仕様は次の反復期間に投入する」ので、アジャイルには「仕様変更が無い」ということになる。

 しかしユーザーは「反復期間の節目ごとに目標定義を提出する」ルールを守れば自由に仕様変更が出来ることになる。

 アジャイル開発は情技師にとっては「仕様変更要求に対応しなくて良い」、非情技にとっては「作りながら試行錯誤をして仕様を変更ながら開発できる」という一石二鳥な開発手法だ。
 欠点は「試行錯誤による開発の繰り返しの分だけコストと時間がかかる」点にある。

反復期間ごとの目標定義の遷移


 「アジャイルではドキュメントを書かない」と言われているしアジャイルの教科書にもそのように書かれている。しかし私は文書を書かないことに反対だ。それは法的な理由によるものである。
 システムの発注にはトラブルが付きものである。発注側受注側どちらから訴訟が起きても不自然では無い。
 過去のシステム訴訟にアジャイルに関連するものがある。

ある発注元企業がシステムを外注した。
受注したITベンダーはアジャイルで文書を残さずシステムを開発した。
納品されたシステムに発注元は満足できず「要件を満たしていない」理由でITベンダーを告訴した。
ITベンダーは「顧客の要件は満たしている」として否認した。
裁判の結果は「ITベンダーの有罪」で発注元企業へ損害賠償の支払いを命じた。
理由は「顧客の要件を記述した証拠の文書が無い」からである。

 要件を満たしているかどうかを確かめる文書を残さないのはITベンダー側の責任である。そいう意味で私はアジャイル開発においても要件を記載した文書は最低減記述し残すべきだと思う。

 記述すべき文書は二つである。
 発注元の要望をそのまま記述した「要望定義書」、非情技の業務担当者が作成する。
 情技師が「要望定義書」の提出を受けて、その内容を精査し技術的にも現用システム的にも間違いの無い要件に修正して文書に記述したものが「目標定義書」である。
 これを記録に残しておけば発注側にとっても受注側にとっても明確な「要件の記録と証拠」を残せるので訴訟に備えることができる。

 「要望定義書」と「目標定義書」は一つでは無い。
 それぞれ「互いに影響の無い」単位で細かく分割して個別の「要望単位」に文書を分ける。「要望定義書」も「目標定義書」もA,B,C,D,Eという用に複数に分かれる。作成するタイミングも別に全部を一度に作成する必要は無い。思いついた先から作っていけば良い。どうせ目標定義をシステム開発に投入できるタイミングは「次の反復期間」なのだから。
 次の図は目標定義書を反復期間に投入する様子を図案化したものだ。「要望定義書」については記載していない。要望定義を作成するのはユーザー(発注元・業務担当者)であり開発者は直接関与しない(助言はする)。システム開発に関係あるのは「目標定義書」だけだからだ。

 <図2:アジャイルの目標定義遷移>

 繰り返すが「目標定義」は互いに影響しない単位でできるだけ細かく分割する。
 上図のように「目標定義A」「目標定義B」「目標定義C」...という具合に実装する機能ごとに分ける。

例として、

 目標定義A → 取引先会社の検索機能に「工場・地域」の検索フィルターを追加する。
 目標定義B → 原材料別の集計機能に「原材料費の合計」を集計する機能を追加する。
 目標定義C → 原材料の調達先を変更した場合のシミュレーション機能を追加する。

という感じだ。(どこの大手製造業だ)

 ウォーターフォールでは「要件を満たす」ことを最優先にする。納期までに全ての機能を実装できず要件を満たせない場合は「納期を延長」してでも「要件を満たす」。

 しかしアジャイルでは「期日の反復期間の末尾日に動く製品を納品する」ことを最優先にする。その為なら一部の「要件を満たせない」としても納品・導入を優先する。
 目標定義は反復期間の末尾の納期に間に合わないなら一部実装を諦め、次回の反復期間に実装を試みる。つまり目標定義は「実装の先送り」が許される。

 要件定義は一つの契約に一つだが、目標定義は一つの反復開発に複数用意する。

 「アジャイルの目標定義遷移」図で描いたように、
「反復期間1」の目標定義はA,B,C,Dを達成目標にしている。
しかしA,B,Cまでしか達成できず、Dは未達になる。
この目標定義Dは次の「反復期間2」の目標定義に加えられる。
「反復期間2」の目標定義はD,E,Fを達成目標とする。
そして目標を達成する。Gが未達になっているがこれは目標外なので未達でも良い。
反復期間に余分な目標定義がある。
反復期間1の目標はDまでだがEがある。
反復期間2の目標はFまでだがHまである。
反復期間3は余分が無い。

余分な目標定義があるのは、予想より早く終わった場合に、人的資源を遊ばせるの無駄なので余剰能力で実装できる機能は先に実装しておく為だ。

 発注元(業務担当者)は毎回の反復期間ごとに目標以上の目標定義(要望定義)の作成を行わなければならない。かなり忙しくなるはずだ。

アジャイルの仕様変更


 アジャイル開発における発注元(業務担当者)と受注者(IT担当、ITベンダー)の共同作業はちょうど反復期間一周期遅れて進められる。

<図3:アジャイルの仕様変更>

 上図は上の段が「発注元(業務担当者)」の仕事で、下の段が「IT担当、ITベンダー」の仕事です。
 最初の「企画・構想」は別として、「反復期間1」の成果物であるソフトウェアを検証するまのは「反復期間2」の発注元(業務担当者)です。
 「反復期間2」の発注元の作成した要望・目標定義を実装するのは「反復期間3」の「IT担当、ITベンダー」です。
 「反復期間3」の成果物(ソフト)を検収するのは「反復期間4」の発注元(業務担当者)です。
 「反復期間3」の要望・目標定義を実装するのは「反復期間4」の「IT担当、ITベンダー」です。

 発注元(業務担当者)の視点から見ると、要望が成果として返ってくるのが二周期後です。
 IT担当、ITベンダーの視点で見ると、成果物に対するフィードバックが要望の形で返ってくるのが二周期後です。

 「フィードバックは二周期後」これは常識として把握しておいてください。

 アジャイルでは反復期間前に要望・目標が確定する。また、反復期間中に要件の割り込みは「絶対禁止」である。
 このルールでは原理的に「仕様変更は存在しない」ことになる。

 しかし現実には最初に「システム構想企画」の段階である程度の方向性は定義しているので、企画の変更が反復期間ごとに発生する。
 アジャイルにおける仕様変更とは「システム構想企画」の変更である。

 「アジャイルの仕様変更」図の、赤色で「仕様変更」と書かれた部分を見て欲しい。
 「仕様変更」の内容は「目標定義」に反映する。システム開発者は「目標定義」を受け取るだけなので作業手順は変わらない。(もちろん目標定義策定段階で情技師は参加しているので非現実的目標定義は策定されないし、かりに策定されたところで永遠に未達になるだけである)
 この図を見れば分かるように「仕様変更」するのは発注元(業務担当者)の仕事である。(繰り返すがここには情技師も参加している)

 ここで発注元(業務担当者)の反復期間に参加している情技師の位置づけがわかりにくいと思うので解説しておく。

 アジャイルの複数の種類の中に「スクラム」という開発手法が存在する。

 スクラムでは最小で三人、最大で九人のメンバーで開発チームを編成する。
 役割は三つ、プロダクトオーナー(一人)、スクラムマスター(一人)、メンバー(一人から七人)となる。
 プロダクトオーナーは発注元(業務担当者)と相談して「次の反復期間に何を作るか」を決める役割である。この人がシステムの構造に責任を持つ「アーキテクト」を担当する。
 スクラムマスターはシステム開発チームのマネージャである。開発の障害(ボトルネック)を解消する任務を持つ。
 チームのメンバーはプロダクトオーナーの提出する目標定義(タスク)を取りに行って自己管理で開発を進める。

 発注元と相談して目標定義を書いているのはプロダクトオーナー一人だけであり、他はシステム開発に専念している。

アジャイルのルール違反


 これは既に書いたが、アジャイルにおいては反復開発の途中で仕様変更(追加も含む)の割り込みは「絶対禁止」である。
 反復開発の初めに確定した「目標定義」は変更してはならない。新しい仕様を投入したければ「次の反復期間まで待つ」しかないのだ。
 「次まで待てない」のなら反復期間の長さの設定が間違っている。一ヶ月待てないのなら二週間にすべきだし、それでも待てないのなら一週間にすべきだ。
 ちなみに短くすればするほど発注元(業務担当者)は忙しくなる。それは覚悟すべきだ。
 システム開発をITベンダーに丸投げにして自分の役割もロクに果たさない発注元にはアジャイルの導入は無理だ。


最後に


 長々と発注元が知るべき「仕様変更の常識」について説明してきた。
 かなり厳しいことも書いてきたが、世の中のシステム開発トラブルの多くが発注元のシステム開発についての無知と怠慢から発生しており、その損害を被っているのが発注元企業自身という笑うに笑えない現実があるからだ。
 多重請負を初め、自ら損害を受けなければならない業界環境を作っておきながら、そのことに自分で気づかないという間抜けな状況もある。

 問題の根が深すぎるので、手の付けようが無いぐらいなのだが、
取りあえず「仕様変更ぐらい正しくやってくれ」という思いをこめて仕様変更の作法を説明した。

 とりあえず「もう少し上手くやってくれ」。
 以上。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ