こちら南関東地方は蒸し暑い日が続いています。先週の肌寒さから一転、残暑厳しい秋となりました。出張に出るのにどんな服装をすればいいのか、選択が難しいのが最近の悩みの種です。
前回から新テーマに挑戦しています。
前回、ウォーターフォール型のシステム開発について簡単に触れました。今回は、大局的な位置づけにあるアジャイル型の開発について説明します。
10年程度前まで、アジャイル開発というと何か胡散臭いものか、当たりもの好きが関心を持つつ特殊なものという感覚が、IT開発業界にはありました。また、その手法が予算の確定が難しいものであったため、請負で開発するSIerが顧客を説得するのが難しいく、忌避されていたように思います。
ところが、この５年位まえからはアジャイルという考え方を取り入れた開発を意識せざるを得なくなりつつあると感じます。
アジャイル型開発に対するキットPMの捉え方は、ITシステム開発業務における要件定義の曖昧さを解消するための一つの手段であると考えています。
要件定義は、ユーザーが実現したいと考える機能を聞き出して、理解し、まとめる作業です。こう書いてしまうと簡単そうな気がしますが、実はこの作業はITシステム開発のプロセスで最も難しく、不安定なものとなります。
多くの失敗プロジェクトはこの要件定義フェーズに問題があると言っても間違いはありません。
したがって要件定義の品質を上げることが、プロジェクトの成功には欠かすことのできないものであるとの認識から、これまで様々な手法が考え出されてきました。
日本ITシステム開発業界のように、ユーザーから請負で開発業務を行う専門業者であるSIerがいて、要件定義から設計開発までSIerの責任で実行するというちょっといびつな構造を持っていると、いくら手法を工夫することで不安定な要件を確定しようとしても、そこには限界があります。
どうして限界があるのか簡単に説明すると、開発するシステムに対する要求を持っているはずのユーザーが、自己の要求に対してとてもいい加減であるということがあります。
いい加減という表現が問題であれば、自己の業務に対する分析が不十分であると言い換えることができます。「経営
これは別にユーザーである一般企業を貶めていってるわけではなく、ユーザー企業に自社の業務内容と、それが社会と関わる意味や、影響などについて分析し、課題を抽出し、問題解決を図る機能がないということです。
いやいや、うちには立派な経営企画という部署があり、そこで会社の経営について様々な課題を取り上げ、対策を考えいるよ、という方もいらっしゃるかもしれませんが、本当にそのような視点を持って動いている部署であれば、それは素晴らしいことだと思います。
ただ、実態はどうかというとどうでしょうか？キットPMのこれまでの経験から言うと、なかなか難しいというのが正直なところではないでしょうか。
次回もアジャイル型の開発について続けて考えて行くことにします。