欲しいシステムを作るためのあがき

あんたも仕事でシステムを使っていたりするかい？

ITが生活の中にまで浸透している現代で、システムと全く関わりを持たずに生活するってのは不可能に近いくらいの話だよな。

極端な話、あんたの目覚まし時計すら電波時計っていう世界的なシステムによって維持されているわけだもんね。

俺たちシステムエンジニアは日々そう言うシステムを作る仕事をしているわけだけれども、ここ最近になって流行っているキーワードがある。

アジャイル開発ってやつだ。

妻にその事を話したら「なにそのアジャ・コング開発って？」と問われた。
#アジャ・コングさん元気かなぁ ？

仕事上、アジャイル開発ってやつに携わるかもしれないので、ちょっと調べてみたところ、結構なパワーワードに出くわした。

今回はその言葉が指し示している事実について考えてみる回だ。

ちっとおっかないことになるかもしれないけれど、付き合ってくれよな。

アジャイル開発ってなんですっけ？

まずはこのアジャイル開発って言葉についてだよな。

あんたもたまに聞くキーワードかもしれないけれども、それが何なんですっけ？って問に答えるのって実は至難の業だ。

アジャイル開発ってのは従来から行われている開発のやり方であるウォーターフォール開発の問題点を解決しようとして考え出された開発方法なんだよね。

なに？まずウォーターフォールってなんだって？

そらそうだよな。
そもそもシステム開発ってどうやるんだっけ？って話からになるんだけれども、スゲーざっくり説明すると、以下のような順番でシステムを作ることになる。

(1)要件を決める
(2)要件を設計する
(3)設計に従ってプログラムを作る
(4)テストする
(5)リリースする

で、ポイントなのが、(1)の仕事はシステムを使うヒト。つまり俺たちシステムエンジニアにとってのお客様がすることなんだよね。

「こんな機能が欲しいっす！」って言ってもらって、俺たちシステムエンジニアが「じゃあ具体的にはこう言う項目が画面に出て、こんな入力項目で結果としてこんな帳票が出ればいいっすよね」って設計をして、その設計に従ってプログラムを組んでくれるように頼んで、それが設計通り動くかテストするってわけだ。

こう言うふうにお客様→システムエンジニア→プログラマー→テスター→保守担当ってふうに仕事がまるで「水が流れるがごとくに」流れていく開発方法。

そいつがウォーターフォール開発ってっわけだ。

ところが、このウォーターフォール開発にはちっと問題が有るって言われている。

開発に時間がかかるんだ。

何しろ、要件として「こんな機能が欲しい」って決めるのに時間がかかる。設計として具体化するのに時間がかかる。
設計された内容で目的を達成できているかをシステムを使うヒトが判断することに時間がかかる。
要するに「何をどう作るのか」を決めるのにベラボーに時間がかかるんだ。

そこで、「だったら時間を1ヶ月とかに区切って、どんどんプロトタイプ作って動くもので行けるか確かめたほうが良くね？」ってのがアジャイル開発なんだ。

極端な話、最初の1ヶ月はログインとメニューしかできないかもしれない。
でもログインのユーザー情報の管理方法とかが1ヶ月で確立するんなら、その先の開発もスムーズになるし、その時に必要な機能から作り込んでいけるんだから良いじゃん？って話ね。

ヒトは「要件」を決められない

このアジャイル開発ってやつを調べていくと、結構なインパクトの有る言葉に出くわすんだ。

すなわち「顧客は「要件」を決められない」ってやつだ。

この「要件」って言葉が結構なヒトを惑わしているんだよな。
「要件」と「要求」は違うって言われたら、あんたはピンとくるかい？

実際問題、この言葉の違いを説明できるシステムエンジニアってあんまりいないかもしれない。

「要件」は「実現したい機能」。
「要求」は「実現したいこと」なんだよ。

日々の締め作業を60分で終わるようにしたい→「要求」
日々の締め作業で売上データの集計作業を自動化するために集計仕様を○○方式に変更したい→「要件」

って感じかな。

でね？
あんたの会社で使っている業務システムでも同じだと思うんだけれども、システムって複雑に絡み合っていて、機能を変えるにしても、「こっちを変えたら、あっちも変わっちまう」ってことが起きるわけよ。

そうなってくると「おいおい、そっちを変えたら俺達の仕事が変わっちまうだろうが」的なことがガンガン起きる。

更に言うなら、その機能を変えることが本当に役立つことなのかってのは、実際に使ってみないとわからないってこともいっぱいある。

なのにウォーターフォールでは「これを作ってね」って端から決めて行かないとならない。
で具体的に設計してみて使ってみたら「思ってたんと違う」ってことが普通に起きる。
何しろ「これを作ってね」ってやつからして具体的な機能を想像することが困難の極みだからだ。

なのでアジャイル開発ではそもそも「要件定義」をしない。
その代わり「ユーザーストーリー」という「あんなこといいな。できたら良いな」って「要求」を一定のお作法に従って表現して、それをいきなり開発チームとディスカッションして「こんな機能っすね？」って共有ができたらそれを作っちまう。

で、実際にその機能を運用して、課題が見つかったら更に新しい「ユーザーストーリー」を作り上げていく。
これを繰り返すことで「ユーザーストーリー」はどんどん具体化していく。
結果として有機的に変化し続けるシステムが出来るってスンポーだ。

ただ、このアジャイル開発も万能じゃない。
実に様々な課題を抱えている開発方法なんだよな。

ただ、その辺を書き始めるといくら書いても終わらないので、それはまた別の機会な。

さて、あんたはどう思う？

俺たちは俺たちの欲しいシステムを手に入れるためにどんな開発の仕方を選べばいいんだろうな？