無料ブログはココログ

« 2014年10月 | トップページ | 2014年12月 »

管理強化はプロセス問題を解決しない(こともある)- アドベントキャンドル1本目 -

20141130_183136

アドベントカレンダーのようには毎日書けないので、ソフトウェアプロセスの話題のアドベントキャンドル(注参照)を灯していきます。最初の話題は、「管理強化とプロセス問題」です。

管理強化が有効な場合

管理強化する場合に想定するプロセス問題は以下のようなものです。

  • プロジェクトの遅延はソフトウェアの信頼性が低いからだ
  • ソフトウェアの信頼性が低いのは管理されていないからだ
  • 仕切り直して厳密に管理しよう

多くの問題プロジェクトでは、構成管理や進捗管理、品質管理がいい加減です。問題が発覚した時点で残作業を棚卸しを行い、それなりの管理をすればそれなりにプロジェクトが進むようになります。

管理強化がうまくいかない場合

しかしプロジェクトによっては、管理強化は必ずしも成功しません。そもそも難しいプロジェクトだと、それなりに管理をしていても問題は起きるからです。

例えば、法律の改正、フレームワークのバージョンアップや品質問題、設計の前提となる処理量が変わった場合などです。これらは想定が困難ですし、影響が大きいのでプロジェクトでは解決できません。

このような問題は、あらかじめ一般的なリスクの定義である「確率×影響」を見積もっていれば、統計的には組織としての問題がありません。組織の予算から問題を解決すべく人を投入し、管理を強化すれば解決するはずです。でも、必ずしもうまくいきません。

うまくいかない理由はプロセスを管理しているだけで、支援していないのでスケジュールがよりタイトになるからです。タイトになったスケジュールをどのように解決すべきか、その代表としてリリースを間に合わせる方法を題材に、次回はプロセスの分割方法を説明します。



アドベントは日本語で待降節とよび、クリスマスの4周前の日曜日からクリスマスまでの期間のことです。カトリックの教会ではリースの中心に4本のロウソクを立てたアドベントクラウンが飾られます。立てられたロウソクはアドベントキャンドルと呼ばれ、日曜毎に1本灯されます。4本すべてが揃うといよいよクリスマスです。

このエントリーをはてなブックマークに追加

[#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に参加して -

品川Redmine 改め、redmine.tokyoに参加しました(全体の様子はあきぴーさんがブログで詳しくまとめられています)。

日経SYSTEMS寄稿の思い

今回はライトニングトークでお話しさせていただきました。

資料にあるように日経BP社の調査ではRedmineのシェアは拡大して、プロジェクト管理ツールの第1位、シェアも70%に迫っる勢いです。ユーザ層のキャズム(溝)を超えてマジョリティにまで広がってきた様です。

マジョリティには様々なユーザがいますから、先進的な人に向けた高度な内容だけでなく、基本的な利用方法や用途別の逆引き的な情報が必要になります。今回、日経SYSTEMSに寄稿させていただいた際は、それを意識して書きました。

普及に向けてそれなりに書籍や雑誌がそろいましたが、保守的な層を取り込むには、より具体的な事例が必要になります。そこで、わたしはコミュニティに期待しています。

tokyo.redmineの層が厚い

tokyo.redmineが、品川Redmineのころの感想がこちらです。

[#47Redmine]ユーザコミュニティが盛り上がってきた - 第5回 品川Redmine -

前回は内容の濃さとユーザの盛り上がりに驚きましたが、今回は層の厚さに驚きました。

今回はRedmineの全体討論があり、多くの方が発言されていました。知見を持った人が少ない場合に行うパネルディスカッションではなく、開場全体で実際に利用している人がそれぞれの見解を語り合って、より理解を深めることができました。

このようなユーザの交流を続けていくコミュニティがであれば、間違いなくキャズムを超えてRedmineは広く普及していくと思いました。

RedminePMについて

今回のredmine.tokyoでは、ディスカッションの元になったアンチパターンの2つのお話のほか、Redmineの最新情報、サーバ統合のお話、GitLabによる開発、最新のPDFライブラリ対応、メトリクス収集環境、ガントチャート等の高機能化ライブラリ、などの有益なお話がたくさんありました。そのような中で特に取り上げておきたいのが、RedminePMです。

RedminePMはスマートホン用のクライアントアプリで、Redmineを使う中で「欲しかった」ので作られました。日経SYSTEMS11月号にも少し紹介させていただいたようにMy TaskやWeb画面などメニューがよく考えられています。

有償でも欲しい方はたくさんおられると思いますが、これによって仕事が増えればそれで良いとのことで、広告や有償化は考えられていないそうです。お勧めです。

このようなアプリやプラグイン、運用の事例、開発への協力などによって、Redmineの層が厚くなるのだと思います。

おまけ:同人誌UAS(Ultimate AgileStories)

発表中に紹介した同人誌UAS(Ultimate AgileStories)に書かせていただいた記事(UAS1-3)は、以下で公開しています。UAS4(目次)とバックナンバーはアジャイル関係のイベントで有料頒布されますので、機会があればぜひ、入手してください。

UAS1: チケット駆動開発はアジャイル1次ブームの夢を見る

UAS2: アジャイル風の開発で集中を実現する

UAS3: アジャイルの夢を実現する–チケット駆動開発で考慮すべき点

このエントリーをはてなブックマークに追加


リリースを間に合わせる方法 -プロセスのリエンジニアリング-

納期は延ばせるがスコープとリリース時期だけは守らないといけない場合に、どのような手段がとれるかを整理しました。

見積もりを減らして無理な線を引く

作業の効率化なら良いのですが、バッファもとらずに「なんとかなるだろう」で計画してうまくいくはずがありません。詳細でなくても具体的に検討した結果で計画すべきです。方策がないままに、無理な期間で開発はできません。見積もりを減らすなら、開発する機能を減らして工数を削減すべきです。

残業を見込む

残業を見込む事でも、全体スケジュールを短くできます。しかし、残業を見込んでしまうとイザという時にトラブル対応ができなくなるほか、健康への不安が出ます。どうしても残業を見込むなら、休日出勤を計画した方がマシだと思います。休日出勤を避けようと平日の深夜残業で乗り切ろうとして体を壊してしまうからです(休日出勤と深夜残業の両方を計画する事が論外である事は言うまでもありません)。

人を増やす

問題の発覚した時期が比較的早い時期であれば、タイミングを見計らって増員すれば、立ち上がり教育や情報共有などの工数を考慮しても期間的にはうまくいくかもしれません。なるべく効率的に増員するには、その回数を減らしてなるべくトレーニングをまとめる。単純作業や汎用機能など、独立した作業を切り出す。過去の経験者に手伝ってもらって教育工数を削減する。という方策をとれば、成功の可能性を高くできるでしょう。開発の後期になるとトレーニングのコストの吸収が困難になり、単純作業もあまりなくなりますので、客先へのアピール以外のメリットはあまりなく、逆効果になる可能性も高いでしょう。

品質作業をショートカットする

CMMを提唱したHumphrey氏とKellner氏の論文に、書かれている悪い方策です。リリースのプレッシャーに負けて品質作業を省いてしまうと、結果的に良い事はありません。リリース後のバグ対応はリリース前よりも緊急度が高くなりますので、まとめて対応する事もできないので繰り返しのリリース作業が必要で、膨大なサポート工数が必要になるでしょう。あまりにも品質が悪い場合はサービスを停めざるを得ないので、補償問題も発生するかもしれません。

段階リリース

開発の後期や小規模開発では、結果的に段階リリースしかないと思っています。回数を増やすとリリースの工数がかかりますし、リリース後のサポートと本来の作業を並行に実施しないといけません。その反面、増員しないことでトレーニングや情報共有の工数がかからない方法です。

段階リリース計画時に行うプロセスのリエンジニアリング

段階リリースをすれば必ず成功する訳ではありません。計画時に合理的で実現可能なプロセスになるように、下記の作業を繰り返してプロセスをリエンジニアリングします。

(1) 全体工数を確認する
まずは、全体工数を確認します。もし、納期までの期間に入らなければ、納期の変更や増員を検討します。納期の変更は時間がかかる事もありますので、概算で納期に納まる事を先に確認しておきます。増員の場合は、単純作業を切り出せしたり、トレーニングや環境準備などの立ち上げるための工数も必要です。

(2) 各リリースに必要な作業と納品に必要な作業を分ける
見積もった作業を各リリースに必要な作業と納品に必要な作業を分けます。デプロイなど、各リリース毎に作業が抜けていないかも確認します。作業分類の際は、従来よりも細かな作業に分ける事も検討します。詳細設計しないと実装できませんが、DB設計やUIの設計ができているなら、クラス図とシーケンズ図から実装をすすめられるかもしれません。プロジェクトに合わせて実現可能な作業分類をします。

(3) 線表を後ろから引く
それぞれの作業の依存関係を考慮して、リリースや納品から担当者を決めながら、後ろからスケジュールを引いていきます。再度、(2)のリリース毎の作業を見直しても期間に納まらないなら、リリース時期の変更が必要です。

(4) 全体を調整する
担当者ごとの作業を見直して、負担の平準化をします。リスクの高い作業が特定の担当者に集中せず、能力に見合わない作業が割り当てられないように確認します。適宜、担当者にも相談しておき、緩いコミットメントを得ておくと、後の混乱を避ける事ができます。

段階リリースの効果

段階リリースはリリース工数が増えるなどの負担が増える反面、増員をなるべく避けながらリリースを守る事ができます。また、開発作業のサプリング(クヌース先生の本の選び方)でもありますので、

といった効果があります。

おわりに

前回はクリティカルチェーンと小規模プロジェクトの観点から整理しましたが、今回はプロセスプログラミングの観点で整理してみました。

プロセスをリエンジニアリングする場合、それが開発標準で許されるテーラリングできるかを確認してください。利害関係者との調整が必要かもしれません。

また、どのような作業が必要かをきちんと理解していないとリエンジニアリングはうまくいきませんし、トップダウンのコマンドコントロールでは難しいことも注意が必要です。チーム内の合意を得ながら最大限の能力を発揮して、強いチームを実現すれば、きっとうまくいくでしょう。

このエントリーをはてなブックマークに追加


クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

小規模開発の難しさは独特です。これまでも問題点の指摘と解決法が提案されてきました。

改善に書けられる工数が少ない

プロセス改善ブームの前、多くのヨレプロジェクトが予算の2倍を消費していた頃は、会社の存続を左右する大規模開発に比べて被害が少ないので、小規模プロジェクトはあまり関心を持たれませんでした。やがて、大規模プロジェクトが統計的な手法でうまくいくようになると、小規模プロジェクトの被害が無視できなくなりました。

しかし、小規模プロジェクトでは改善の工数を大きく割く事が困難で、標準プロセスを管理する独立したSEPG(Software Engineering Process Group)を作る事も困難です。そこで行われたのは、大規模システムで行われている管理手法の簡素化です。標準プロセスをシンプルにすることと、自律的な改善活動でした(VSEセンター:資料ダウンロード)。

外乱による変動が大きい

しかし、小規模プロジェクトの難しさは、改善の工数が少ないだけではありません。規模が小さいので外乱による影響を受け易いのです。

環境、実現方法、業務ドメインの未知の問題が発覚すると、プロジェクトはその対応に追われます。脆弱性対応など、外乱による問題は規模に関係なく同じように理解と対応が求められますので、知識と経験の蓄積が必要とされます。

増員が難しい

このような問題を認識しても、まだ小規模プロジェクトの難しさの本質を表現できずにいました。先日、CCPM(リンク先はWikipedia)におけるクリティカル・チェーンの定義を見ていて、増員できない事が問題を難しくする事に気付きました。

大規模プロジェクトでは、クリティカルパス法やPERT法のように「作業員を雇用することが容易」という前提を置く事が可能です。しかし、小規模プロジェクトでは

  • 増員によるコスト増加の比率が高い
  • 教育コストの比率が高い
  • 一人分の初心者向け作業を切り出すことが困難

といった理由から、増員が困難です。このことで、「作業工程上の従属関係」だけでなく、クリティカルチェーンの様に「必要リソースが限られているために発生する従属関係」の考慮が必要になります。

リソース制限による難しさ

例えば並行して実行可能な2、3、4人日の作業A、B、C、があった場合、3人で実行すれば最短の4日で完了できますが、メンバーが2人なら最短で5日かかります。これを4.5日でとりあえず動かして欲しいと言われたなら、どのような対応ができるか考えてみましょう。

増員:トレーニングに1日かかるなら、指導1日もかかるので、3、4、4日となって4日で終わらせる事ができる反面、2人日の追加工数が必要です。このようにうまく配員できるかどうかという問題もあります。

手伝い:半日分の作業をもう一人に手伝ってもらえるなら、何とかなりそうです。しかし作業に専門性があるなら、その理解に必要な時間分は、はみ出てしまいます。

共通化:まだまだ上流なら、作業や構造の共通化で何とかなるかもしれません。でも、すでにきちんと設計されていたなら、難しいでしょう。

作業をショートカット:テストを端折ってでもリリースして欲しい。というお話を聞く事もありますが、障害対応に必要な作業で他の作業ができなくなりますので、一番危険な方法です。

後回し:保守用ドキュメントはリリース後に回すなど、作業内容を精査してリリースに必要な作業だけを実施します。リリースの目的が他のモジュールとの結合テストなら、有効な方法かも知れません。

以上の方法を考えると後回しが有効だと思われますが、開発標準に抵触する可能性がありますし、全体の作業内容を良く理解していないと混乱を生じる可能性があります。

残業というバッファ

クリティカルチェーンの正攻法はCCPMのように、あらかじめバッファを確保する事、他の作業からリソースを回す事です。本当に使える開発プロセスで書かれているように、大規模プロジェクトでは理想見積もりの1.5〜2倍の予算を確保してスケジュールがきめられるので、バッファをとれるかもしれません。

しかし、小規模プロジェクトの場合は、発注側が詳細な作業内容を把握しています。このため、理想見積もりを基準に予算が確保され、スケジュールを決められる傾向があります。

そこで小規模プロジェクトでは、残業時間がバッファになりがちです。スケジュールが厳しいからと、あらかじめ残業が見込まれてしまうと、さらに打つ手が限られてしまいます。

小規模プロジェクトの難しさ

そこで、いざとなれば開発標準をよく理解して、顧客との合意が可能な範囲で作業の最適化を行い、優先度の低い作業や手戻りの可能性のある作業を後に回すといった柔軟さが求められる事になります(Win-Winプロセス(ウォータフォール編)追記)。

このような方策は作業のショートカットと紙一重です。作業間の関係を理解した上で、独自のプロセスを構築する。そのようなアクロバティックな難しさが小規模プロジェクトには存在します。

クリティカルチェーンの定義から小規模プロジェクトの難しさを考えてみました。小規模開発では、改善工数の制約や外乱の影響を受け易いほか増員が困難で、クリティカルチェーンの特性であるリソースの制約があります。そこに予算とスケジュールの制約が加わるので、独特の難しさが生じているのだと思います。

このエントリーをはてなブックマークに追加

« 2014年10月 | トップページ | 2014年12月 »