要件を確定させずにドンドン進める

なんとも曖昧なタイトルですみません。こういうのだとnoteの達人の方から言わせると「タイトルだけで概要が分かるものにしないと」と言われそう（苦笑）

それはさておき、少し時間の取れる今だからこそ、ちょっとずつPMBOKの知識を洗い直そうとしているところです。ちなみに私は３版あたりで習得が止まっているグータラ人間なので、それ以降に変わったところが理解出来ておらず、特にアジャイル開発との関係性が気になっています。

以下、そんな私なので、理解が誤ってるところあれば、"優しく"コメントを頂けると幸いです。

ウォーターフォール型？アジャイル？

PMBOKの基本的な考え方って、要件定義～設計～開発～テスト～リリースという各工程をそれぞれ１つずつ終わらせていく、ウォーターフォール型の考え方がメインだと思ってます。なので、各工程の終了タイミングで検証を行うだったり、WBSの作成についても工程完了を意識した考えなのかなと。

一方でアジャイル開発って、ようは「ひとまずプロト開発でもなんでもいいから、ちょっとずつ作成して動かしてみて、ダメなら要件の見直し。その上でまた修正してみよう」的なノリ。なので事前にやるべき作業は見えず、要件の優先順位を確定させる人の決定事項が決まらないとダメ。となると当然「今の進捗は妥当？」っていう確認は出来ず。そんな開発手法とPMBOKって相性良くないんじゃないかな？と。

アジャイル開発を体験してみた時の感想

当時私は諸事情により親会社に出向していてユーザ側のIT関連のサポートを行っていました。そしてその際にWeb系システムのうち１システムをアジャイル開発で行うので、ユーザ側の立場で参加してとの依頼を受けました。

なおこの時のIT側の担当者は、自社の同僚たち。なので良く知ってる相手だし、レベルも理解出来ていたのでやりやすい環境ではありました。

ただ私自身が「アジャイルとはなんだ？」なレベルで、"設計書の修正は後回し"、"要件は聴くには聴くけど、後回しにするものはあり"といったノリについていけず、何度も意見を交わしました。
また一方でユーザ側のリーダが常に曖昧で、人の意見に流されるタイプだったので、本当にこれがユーザとしての優先順位なのか？とよく戦ったものです。ま、私のような立場の人に言われるのも辛そうでしたが。。。

IT側はそのような状況の中で、自身で優先順位を提案していき、今週達成できそうなチケットを報告したりなど、前向きに作業していたのが好感もてました。

ただこれがアジャイル開発の成功例なのか？というと少し違和感。もっとユーザ側の意見をもとに開発をリードするような形が本来あるべき姿なのかな。でもそうなるとユーザ側でも、事前に社内調整を行う、また事前に仕様案を作っておくなど、作業負荷はあがってきそうです。
そう思うと、アジャイル開発を行うには、IT知識の有無は別としても、もう少し作業工数をユーザに与える必要があるのかなと思いました。もちろん、その「もう少し」というのがどの程度必要なのかという匙加減は必要ですが。

PMBOKとアジャイル

あ、話が脱線してますね。
とりあえず最新のPMBOKガイドを購入して読んでみるしかないかな。でもあれって無駄に？ボリュームがねえ。以前は版数があがったタイミングで外部研修を受講して、その差分をレクチャしてもらってたんですけどね。ま、少しずつ調査してみたいと思います。