mhlyc -presentation

僕が書きたいことをひたすらに書き綴る、自己満足のブログです。

SQuBOK V2をクオリアちゃん(仮名)と読んでいこう 第5話

前回までのあらすじ

mhlyc.hatenablog.com

 


今日はお休みなので続き書きます!

 

登場人物紹介

※絵は書けないので、キャラの姿は想像で補ってください。

伊敷 孝男(いしき たかお)

意識高い系。口癖は「まあ、俺のモットーは"高品質"だから」。人の話は一応聞く。

 

佐藤 大輔(さとう だいすけ)

伊敷の同僚。いつも伊敷の尻拭いをやらされている。すぐ怒る。

 

クオリアちゃん

突如、伊敷の部署に配属された中途採用の女性。本名は不明だが「クオリア」と名乗っている。見た目は女子大学生。品質の話になると語りだす。ツンデレ

 

第5話 「アジャイル入れればいいってもんじゃないのよ!」

「あのさ」

伊敷は神妙な面持ちで佐藤に話しかけた。

「なに?」

アジャイルってどう思う?」

「どう思うって… 聞いたことはあるけど、正直よくわかんないかな」

「俺はさ!今のプロジェクトとかまさにアジャイルでやればいいと思うんだよ!」

伊敷は熱く語り出した。

「どうしたんだよいきなり…アジャイルサムライでも読んだのか?」

「ああ!俺は気付いたんだよ。俺たちは今まで色々な成果物を納品してきたけれど、お客さんの立場で考えたらいらないものばかりだった。動くソフトウェアを提供してこそ、価値を提供することになるんだよ!」

「まあ、それはわかる。わかるよ。けどさ、いますぐアジャイルに切り替えるってわけにもいかないんj」

「何言ってるんだよ佐藤!いまのやり方で本当にいいと思ってるのか?お客さんにいくら立派なドキュメントを納めたって、本当にお客さんにとって価値ある成果が提供できなきゃどうしようもないんだよ!」

「だからさ、伊敷の言うことはわかってるよ。けど…あ、クオリアちゃん」

「おつかれ。なに、アジャイルの話してるの?」

「そうなんだよ。佐藤がいくら言ってもわかってくれなくて…」

「だからわかってないわけではないって」

「じゃあなんなんだよ!」

伊敷がヒートアップしている。

「はいはい、落ち着いて。伊敷くん。そもそも、ソフトウェア開発におけるプロセスモデルにはどういうものがあるかわかる?」

「えーっと…アジャイルでしょ?それからウォーターフォール、プロトタイピング、スパイラルモデルとかかな…」

「そうね。他には反復型開発プロセスとかもあるんだけど、今は置いておくことにするわ*1

 「けど、それがなんなんだよ?実際、よく使うのってウォーターフォールじゃないか」

「いい、伊敷くん。確かに伊敷くんがこれまで経験してきたプロジェクトは全部ウォーターフォールだったかもしれないけど、実際は色々なモデルが使われているの。ウォーターフォールアジャイルの要素を取り込んだハイブリット型のモデルもあるのよ」

「そうなんだ…」

「そして、伊敷くんは『アジャイルを入れれば全て解決する』って思っているかもしれないけど、それは間違いよ」

「え!なんで!だってウォーターフォールよりアジャイルの方が絶対お客さんのこと考えてるって!」

伊敷はかなり戸惑っている。

「伊敷くんは二つ誤解しているわ。一つ目の誤解は、モデルそのものには得意不得意こそあれ、絶対的な優劣はないということ。伊敷くんは気づいていないかもしれないけど、ウォーターフォールモデルには利点もあるの」

ウォーターフォールモデルの利点…?」

「そう。実際にアジャイルを入れたらどうなるかっていうと、まずお客さんに『アジャイルな計画づくり』をすることを理解してもらわないといけない。ウォーターフォールモデルでは基本的に固定金額かつ固定期間で契約できるからお客さんにも受け入れられやすいけど、アジャイル開発では計画や要求事項は変更されるものとして扱うから、お客さんにとっては契約もしづらいわ。だって、プロジェクトがいつ終わるか、最初に厳密なコミットメントが取れないということだから。実情として計画通り進まないとしたって、お客さんにそもそも受け入れてもらえなければ開発をスタートすることもできないわ」

「確かに…」

伊敷は納得した表情で聞いている。

「だから、一概にどのモデルが悪いということはないの。アジャイル銀の弾丸ではなくて、あくまでどんな開発スタイルで進めるかはそのプロジェクトの特性やお客さんの文化とかに合わせて検討する必要があるのよ」

「なるほど…」

「二つ目の誤解は、ウォーターフォールモデルに対する誤解よ。ウォーターフォールモデルを紹介したものとして最もよく引用される論文はロイスが1970年に書いたものだけど、そこではすでにウォーターフォールモデルが危険であり失敗を招くリスクがあることが指摘されているの。改善点としては顧客を巻き込むことなどが挙げられているわね」

「そうなんだ…」

「知らなかった…」

伊敷も佐藤も驚きを隠せない様子だ。

「ロイスの提唱した方法論では、ウォーターフォールモデルを想起される図を示してはいるけれど、同時にフィードバックループも考慮しているわ。つまり、今知られているウォーターフォールモデルは、ロイスが提案した方法論のうち『逐次的に開発が進む』という考え方のみが一人歩きしてしまったものなのよ」

「お客さんが開発初期に全ての要求事項を述べるというのは現実的に難しいわ。これに対してアジャイルでは要求が変更されることを前提としているけど、別の対処法だってある。例えば、要求仕様の記述法であるUSDMでは、要求の理由を考えることで要求をより明確に捉えようとしているわ」

「実際に動くソフトウェアを入手できない問題に対しては、先に述べた反復型開発プロセスだったりスパイラルモデル、プロトタイピングなどが解決策として存在する」

「どうしても発生してしまう手戻りを防ぐために、様々なレビュー方法も考案されているわ」

ウォーターフォールモデルを単に逐次的に進む開発と捉えてしまうと、失敗は避けられない。プロセスモデルにはそれぞれ利点と欠点があって、欠点を補うように色々な施策を打たないといけないのはたとえアジャイルを選択したとしても変わらないことよ」

クオリアちゃんはスイッチが入ってしまったらしく、ひたすら喋り続けている。伊敷はすっかり意気消沈した様子だ。

「でもね、今の開発をよくしたいという気持ちはわかるわ。そういう時はね、アジャイルのプラクティスを導入するという方向で考えてはどうかしら」

アジャイルのプラクティスって…TDDとか?」

「そう。伊敷くんが読んだであろう、アジャイルサムライではユニットテストリファクタリングテスト駆動開発(TDD)、継続的インテグレーションの4つが『問答無用で実践すべき』と紹介されているわ。ここでユニットテストというのはテストコードを書くことを前提としていることに注意が必要ね」

「これらのプラクティスはもちろんセットで導入できればいいけれど、単独で入れたとしても成果が出ると思うわ。すでに導入しているプロジェクトもあるだろうから、どうやって導入していったか話を聞くといいかもしれないわね」

「なるほど…」

アジャイル銀の弾丸みたいに見えてしまうのは私もよくわかるわ。今の開発スタイルで改善されていない問題点も多くあるし、アジャイル開発の話を聞くととてもやりがいを持って仕事できそうに思える。けれど、本当に大切なのは『アジャイルであること』ではなくて、お客さんに素晴らしいプロダクトを届けることなの。そのためにアジャイルを入れる必要があるなら検討するべきだし、それがすぐには難しそうならアジャイルのプラクティスを徐々に入れてみる。大きな変化は抵抗が大きくて進めづらいかもしれないから、少しずつ良い方向に変わっていけたらいいんじゃないかと私は思うわ」

「なるほど…ありがとうクオリアちゃん!」

アジャイルサムライ読み直してみるよ!」

 

ー第6話に続く

 

参考文献: 「ソフトウェア品質知識体系ガイド(第2版) SQuBOK Guide V2」, 2014

参考文献: 「[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?」, 2010

参考文献: 「アジャイルサムライ−達人開発者への道−」, 2012

 

 

あとがき

 

アジャイルサムライ読んでたら書くの遅くなりました。

お待ちしていた方々ゴメンなさい!

 

クオリアちゃんは色々言っていますが、個人的にはアジャイル開発は一度くらいやってみたいな〜と思いますね!

*1:SQuBOKのプロセスモデルの章では、これらの他にプロダクトライン開発(SPL)や派生開発に特化したアプローチであるXDDPも取り上げられているわ。 - クオリアちゃんより