[#seakansai] 共通フレーム2013とプロセスの方向性 - SEA関西に参加して -
IPAの後援で行われた第61回 SEA関西プロセス分科会「共通フレーム2013解説 ~経営者、業務部門とともに取組む「使える」システムの実現~」に参加しました。共通フレームワークはSLCP(Software LifeCycle Process)の国際規格の日本語版です(資料とIPAセミナーの動画はこちら)。
SLCPはCMM/Iでプロセス改善を据える際の用語集として使われることがあると聞いていました。共通フレームは単にその日本語訳として思って、正直なところあまり期待していませんでした。
しかし実際は、超上流と言われる企画プロセスや多くの説明が追加されていて、多くの内容がありました。
ディスカッションの話題
ディスカッションで興味深かったのは、共通フレームを作成されているの方々は、改善をされている方達と狙いが違う点です。
共通フレームではテーラリングに触れられていますが、それぞれの組織に応じて追加や削除をして良いとされています。何が大切で、どんなときにどのようにすべきか、は示されていません。
テーラリングは各組織で行います。全ての実施が求められる事も、ゴールに対してどのようにプロセスを構成すべきかもガイドされません。より良くするための様々な議論がある様ですが、気温的には標準を定める事が目的の様です。
これはアジャイル開発に大しても同じようなアプローチです。開発方法を規程しないのでアジャイル開発を含めて利用できるとされていますが、参考になっても効果的に使えると思えません。次の改訂ではアジャイル開発に関する記述も入ってくる様ですので期待しています。
プロセスの3つの方向性
今回のセミナーを終えて、プロセスには3つの方向性があると思いました。
(1) 協調と安定
共通フレームの様にプロセスの標準化を進めると、組織内のコミュニケーションを向上します。同じ言葉を使うことで、作業の抜けや誤解をなくて協調作業が可能になります。ここでは、共通フレームワークをテーラリングして「こうすればよい」を定める事が目的になります。
(2) 改善と最適化
これに対して改善活動は、ゴールを定めてそれが実現できる最適な方法を選びます。組織の標準は改善の踏み台であり、組織的な変更ができるように組織を標準化します。標準プロセスをもとに各プロジェクト用にテーラリングして、うまくいけば標準に組み込んで「より良くしよう」とします。
(3) 対策と成長
しかし、現場では想定外の事が発生します。標準プロセスやプロジェクト計画で考慮された問題だけではないので、新しい対策が求められます。やり手のリーダーが「まかせておけ」と腕を振るう場面です。リーダーは成長しますが、個別の対策は標準に組み込みにくいので組織の成長にはあまり繋がりません。
アジャイル開発か、CCPMか、対策か
これまで、プロセスと言うと標準化や改善が中心で、開発中の問題に対する対策はあまり研究されてきていませんでした。あらかじめ起こりそうな問題に対する回避策を標準プロセスに組み込んだり、統計的に扱える標準的なプロセスで実施する事で問題を避けようとしたのです。
しかし近年になって想定外の事象は避けられないものである、あるいは、想定外の事象を受け入れる事こそがソフトウェアに求められている、との認識から変化への対応方法が考えられるようになりました。
アジャイル開発では、繰り返し開発で解決しようとしました。変化する状況に合わせて詳細な計画を変化させるのです。これはWebサービス等のように、部分的な品質が全体の価値に影響する場合には効果的な方法です。
CCPMでは、理想見積もりと想定外の事象に対するバッファを用意する事で、解決しようとしました。組織ごとにとってしまいがちなバッファを集中管理する事で、全体最適をはかりました。全体で価値を提供する大規模開発では、生産性を向上する事ができるでしょう。
では、それが問題の対策であるかというとどうでしょうか?
変化を受け入れてはいますが、実施中のプロセスを変化させる事を避けています。これまでも標準から外れたプロジェクトは増員して管理を強化するだけで解決策は与えられませんでしたが、アジャイル開発やCCPMでも、スコープを小さくするか追加の時間が与えられるだけです。
どのようにすれば、必要なものを必要な時に提供できるか?リリースを間に合わせる方法をきちんと整理したいとの思いを新たにしました。
« [#redmineT] Redmineはキャズムを超える - redmine.tokyoに参加して - | トップページ | 管理強化はプロセス問題を解決しない(こともある)- アドベントキャンドル1本目 - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
コメント