ソフトウェア・シンポジウム 2022 in 盛岡

プロセスモデルの補完方法 -モデル・ノウハウ・人阪井 誠
株式会社 SRA
sakai @ sra.co.jp
要旨
本稿では，モデルを補完してソフトウェア開発プロセス（以下プロセス）を成長させる方法について議論する．プ
ロセスはモデルだけでなく，実践するノウハウや人が必要であり，モデルに不足するノウハウを議論することで，新しいプロセスに追加すべきものを明確にし，プロセス改善に役立てるのである．この提案を通して，プロセスの議論が，どのように改善し，成長させていくかといった前向きでオープンな議論に発展することを期待する．

する理解不足もあるが，ソフトウェア開発に共通するプロセスモデル以外の要素があることを示している．基本的な技術や業務知識など，開発で考慮しないといけない点はモデルに関係なく共通点も多いからである．アジャイル開発を始める際に，守破離という言葉を使って厳格な実践が求められる場合もあるが，本当にそれだけでよいのだろうか？それが本提案のきっかけである．
プロセスの成熟にはモデルのほか，多くのノウハウや経験に基づく様々な工夫が必要で，チーム内だけでなく社内外の情報を利用して成長させる必要がある．

1. はじめに

2. 新しいプロセスへの移行の問題

良いプロダクトの開発には良いプロセスモデルだけでなく，実践に必要なノウハウや人が必要である．これまでプロセスモデルやマインドセットの議論が多く行われてきたが，これらはプロセスの理解に役立つものの，より良いプロセスに成長させるには不十分であった．過去のソフトウェアシンポジウムにおいては，プロセスは文化だと言われてきた．組織内のノウハウや人を無視して，プロセスを単純化したモデルや，その実現に必要なマインドセットを議論しても移行後のプロセス改善にはつながらない．
アジャイル開発を例に挙げると「ウォーターフォールでもしっかり開発出来ないのにアジャイル開発なんて出来るわけがない」[1]という議論がある．アジャイル開発に対図 1 に新しいプロセスへの移行を示す．従来のプロセスモデルで開発を行う中で，うまく適応するための工夫からルールを追加するなど様々なノウハウが生まれ，人と組織は成長する．しかし，モデルの問題や，実践が簡単ではないノウハウがあると，それらの解決が期待できる新しいモデルと新しいノウハウに移行される．
従来のノウハウは新しいモデルやノウハウに取り入れられるものもあるが，廃棄されるノウハウもある．また，廃棄されたノウハウを知っている経験者が新しいプロセスに参画できない場合もある．こうして古いプロセスモデルと共に文化が失われてしまうのである．
新しいプロセスモデルでの文化はすぐには成熟しない．
開発チームなどの学びはあるものの，人の入れ替えや，プラセボ（偽薬）のように新しいものは良いものであるとの思い込みから失敗するまで守りに入るからである．
この様な例としてアジャイル開発を取り上げ，新しいプロセスモデルに不足するノウハウの補完法を議論する．

3. アジャイル開発ケーススタディ
3.1. 実現が難しいノウハウとアジャイル開発「アジャイル開発は，ソフトウェア工学の正統な進化形」[2]と言われる様に実現が困難だったノウハウをアジャ

図 1新しいプロセスへの移行

105

SEA

ソフトウェア・シンポジウム 2022 in 盛岡

イル開発はモデル化している．スクラムで解決した問題
例を以下に示す．
・「現地現物」はプロジェクト管理のノウハウだが，従来は成果物，特に実装を確認するまでに時間がかかり，実装確認後のフィードバックが難しかった．スクラムにおいては繰り返しのスプリントごとにレビューを実施することで，適切なフィードバックが可能になっている．
・ハンフリーはソフトウェア開発に「自律的なチーム」やで，コミュニティや書籍，経験者の知恵を借りることで，より良いプロセス改善することが可能になる．
例に挙げたリスクに関しても，リーンソフトウェア開発の「決定をできるだけ遅らせる」プラクティスなども参考になるだろう[7]．また業務固有のリスクなら，社内外の知見者の意見は大いに役立つと考えられる．このように収集したノウハウを組織に合わせて取捨選択し，モデルと組み合わせて補完すればプロセスを成長させられるだろう．

「その最大限の能力を最大限発揮できるようメンバーを動機付け，コーチし，後押しする」ことが重要だとしたが[3]，規律に基づく組織では困難な場合もあった．
スクラムではスクラムマスターがチームを支援する奉仕者であり，真のリーダーとなっている[4]．
このように従来は困難だったノウハウがスクラムのプロセスモデルでは解決されている．
3.2. スクラムにおけるプロセスモデルの補完
ベームはリスク管理されていることをリスク駆動と呼び，スクラムに対してマネジメントプロセスは制約の源泉として完全に適用できるが，リスク／機会は制約として適用できるのは部分的とし，強いリスク駆動とはされていない[5]．
プロダクトバックログ（PBL）につけられた優先順位に応じてストーリを実現する仕組みだからである．
これに対して，ジェフサザーランドは，プロダクトオーナ
ー研修で「PBL は価値最大，リスク最小で優先付け」と説明し[6]，スクラムのモデルを補完するノウハウを示している．また，開発チームにおいては妨害リストが管理されるなど，ノウハウでプロセスモデルを補完してリスクが管理されるようになっている．
その一方で，イテレーティブな開発を「はじめに小さく失敗する」と説明し，小さな単位で開発することであたかも全てのリスクが減るように表現されることもある．また，リスクに関して記述の少ない書籍も多い．これはプロセスが未熟というよりは，業務によって必要性が異なるからと考えられる．モデルに組み込まれていないノウハウは，業務などによって取捨選択されている可能性がある．

5. おわりにCMM ブームの後，TQC を懐かしむ声を聞くことがあった．新しいプロセスを導入した際に，それまでに積み上げてきた文化を無くして移行してしまったからである．単に捨ててしまうのではなく，重要なノウハウを利用してプロセスを成長させていくべきである．今回の提案を通して，どのように改善し，成長させていくかといった前向きでオープンな議論に発展することを期待する．

参考文献[1] アジャイルよろず相談室, 「ウォーターフォールでもしっかり開発出来ないのにアジャイル開発なんて出来るわけがない」という言い方をどう思いますか？ ,https://qr.ae/pGLjdc, Quora, Inc.
[2] Yasuharu NISHI, ちなみに僕のスタンスは，アジャイルはソフトウェア工学の正統な進化形だというものです．進化がアンチテーゼを必須にするというなら，アジャイルは一度ソフトウェア工学を否定しなきゃいけないんでしょうし，それも含めて正統な進化形です．, https://twitter.com/YasuharuNishi/status/1164336449967099904, Twitter, 2019[3] 阪井, デブサミ運営事務局・SEshop.com 編集部編,
リーダーに求められる大切なこと, 100 人のプロが選んだソフトウェア開発の名著, pp.20-21 , 翔泳社,
https://www.slideshare.net/MakotoSAKAI/ss-16581244,

2012[4] Ken Schwaber, Jeff Sutherland, ス ク ラ ム ガ イ ド ,https://scrumguides.org/docs/scrumguide/v2020/2020-Scru
m-Guide-Japanese.pdf, ScrumGuides.org, 2020

4. 議論

[5] バリー・ベーム,アジャイルと規律, pp.205-210, 日経BP 社, 2004
[6] Sukusuku Scrum, スクラムプロジェクト準備(公開用)
No.31, https://www.slideshare.net/SukusukuScrum/no31-13338313/41, p.41, 2012[7] メアリー・ポッペンディーク, トム・ポッペンディーク,リーンソフトウェア開発, pp.79-109, 日経 BP 社, 2004

ここではスクラムという汎用的なプロセスをリスク管理で考えたが，各企業のプロセスにおいても，プロセスモデルだけでなく，それを補うノウハウの議論が必要であろう．
プロセスは，プロセスモデルだけでなく，ノウハウや人を含めた文化であり，モデルを忠実に実践するだけでは成熟が困難な場合がある．社内外の知識の利用が必要

106

SEA