1.概要
ソフトウェア開発を改善する上で、プロセスの改善は最も基本となる活動だと思っております。今回はそのプロセス改善の基本となる考え方や、進め方を記載したいと思います。
2.なぜプロセスを改善するのか
改善活動は大きく2つの活動に分かれると思っております。
- プロセス改善（手順書を作る、運用フローを作る、ドキュメントフォーマットを作るなど）
- プロダクト改善（新しいフレームワークを導入する、技術者に勉強会に参加してもらうなど）
このうち基本となるのがプロセスです。なぜプロセス改善が大事かというと、改善することで以下のような効果があるからです。
- 一度作れば何度でも使える
- 誰か一人ではなく複数人に効果があるので、費用対効果が高い
- フォーマットがあればすぐに導入可能（即日実施可能）
そのため、コンサルタントが改善を行う場合、目に見えて効果が表れやすい「プロセス」から改善していくことが多いです。
ただ、私の考えでは「プロセス改善は赤点を取らない方法」だと考えております。
そのため、どんなに改善しても最大で100点満点中40点ぐらいしか取れず、もっと改善するには必ずプロダクト改善が必要となります。
⇒（プロセスは一定の手順を実施するので、一定の品質しか担保できない。。。）
3.プロセス改善の進め方（基本編）
プロセス改善は大きく2つの進め方があります。
- ボトムアップアプローチ（課題から改善していく）
- トップダウンアプローチ（あるべき姿から改善していく）
この中で最も取り入れやすいのがボトムアップアプローチです。ボトムアップアプローチの進め方は単純で、以下のように進めていきます。
- 各現場の課題をヒアリングし、課題一覧にまとめる
- 課題から改善すべきプロセスを考え、改善を行う
- うまくいったかどうかをヒアリングしPDCAを回す
目の前の課題がどんどん解決していくので、目に見えて成果が出てきます。そのため、現場の協力を得やすくなり、さらなる改善へと進めることができます。
また、トップダウンアプローチの場合は以下のように進めます。
- あるべき姿のモデルを調査する（CMMi、PMBOK、TPI-Next@など）
- モデルが決定したのち、そのモデルと現場とのギャップを分析する（モデルと現場の運用フローを比較する）
- ギャップがある部分について改善活動を行う
- うまくいったかどうかをヒアリングしPDCAを回す
こちらはベストプラクティス集から改善を行うので、うまくいけばボトムアップより大きな成果を上げられる場合があります。ただ、あるべき姿なので理想論となりやすく、現場が受け入れてくれない場合もあります。
4.プロセス改善のあるある失敗事例
以下プロセス改善中に起きやすい失敗談をまとめます。
- 大きく改善しすぎて現場から締め出される
改善を無理に進めるあまり、一気にすべてを変えてしまおうとすることがあります。この場合、大抵その変化に耐えきれず、現場から総スカンを食らいます…
改善は小さく初めて協力者を作ることを心がけてください。
- 知らない人から中止命令が出る
プロセス改善を進めると話したこともない人から、いきなり中止命令が出て終わることがあります。これは、プロセス改善が複数人に影響がある＝ネゴを事前に取っておかなければならない人が多い、という意味でもあります。
そのため、事前に影響力のある人をリストアップしておき、改善する内容については事前に交渉しておく必要があります。
- 作ったものが使われない
いいフロー、いいドキュメントフォーマットを作っても、1回だけ使いすぐに使われなくなることもあります…。これは、作ったものが間違っていたか、推進者がいないことによって使われなくなったかのどちらかであることが多いです。
特に重要なのは推進者の方で、必ず改善を始める前に誰が今後運用していって、誰が修正していくのか、は決めておくべきだと思います。
5.まとめ
ボトムアップ、トップダウンが一般的ですが、双方を掛け合わせたような方法も行われています。つまり、課題一覧をまとめあるべき姿と比較することで重要なものから改善していく、ということです。
■参考文献
[あなたに捧げる～
TPI Nextを活用したチームメンバーの問題意識から始めるテストプロセス改善
【導入時：改善計画立案編】リターンズ」]
http://www.jasst.jp/symposium/jasst19tokyo/pdf/D2.pdf