2019年01月12日

CMMIに沿った開発計画の書き方と進捗管理について少し書いてみようと思います

また、長いことブログを放置してしまいました。
新しくコンサルティング会社を作って、1年半が過ぎました。
いろんなお客様とお仕事させて頂いている中での気づきなどを少しずつ書いていこうと思います。

最初のお題は開発計画と進捗管理についてです。
1回では書ききれないので、何回かに分けて書くことになると思います。

お客様といろいろと会話していると、プロジェクトが計画通りに進まない、プロジェクトの終盤になって大幅に遅れていることが判明するなど、QCDのD(納期)に関する問題を良く聞きます。
納期遅れは開発期間の延長によりコスト(C)も増大しますし、無理に納期に合わせてリリースしようとすると品質(Q)にも影響します。
言い換えれば納期問題がコストと品質の問題に少なからず影響しているということです。
ですから、納期問題を回避または軽減することが効果的な改善活動となります。


進捗管理の方法をだれも教えてくれない
進捗管理の方法をきちんと教えてもらったことがある開発者はどれくらいいるでしょうか?
先輩が使っていたEXCELのスケジュール表をもらって、納期から逆算してガントチャートを書いて、担当者を割り当てる。
週一回の進捗会議では、担当者は今週の作業を報告。「今週はここまでできました!」という感じで。
「ちょっと遅れていますが、残業して挽回します」という報告もあるでしょう。

進捗会議はやったことの報告だけではダメ
進捗会議では担当者はこの一週間でやったことを報告します。
しかし、重要なのはやらなかったことの報告です。
つまり何らかの理由でやると決めていたことができなかったことを報告すること。
そして大事なのはどんな理由で出来なかったか。
すでにリリースしたソフトで問題が起こったので対処したなど、「もともと予定していなかった作業が発生した」のようなことです。
この場合は予定していなかった業務を他の人に振るなどして、作業者の時間を確保してあげないと、この先どんどん遅れるだけです。

進捗会議ではプロジェクトの進み遅れを見る
進捗管理で重要なのはプロジェクトが予定より進んでいるのか、予定通りなのか、予定より遅れているのかを把握することです。
現在までに終わっている作業が計画に対して進んでいるのか、遅れているのかを評価します。
作業を進捗率で表してみると分かり易くなります。
例えば、機能設計は予定では10月1日に始まって10月31日に終わることになっています。
今日が10月20日だとして、進捗率が50%なら機能設計は17%程度遅れていることになります。
つまり、機能設計の期間を100とすると、現在は67%の時間が過ぎているのに50%しか作業ができていないので、その差が遅れとなります。

進捗率とは何か?
進捗率はアウトプットを作成する作業がどれくらい進んだかを計る指標です。
機能設計なら、アウトプットは機能仕様書ということになるので、機能仕様書の予定ページ数に対して作成済のページ数が進捗率となります。
コーディングなら予定ステップ数に対して作成済ステップ数。
しかし、予定のページ数やステップ数の見積精度が低いと、進捗率はあまり当てにならない数値になってしまいますので、最初は進捗率を担当者の裁量で自己申告してもらった方が現実的かもしれません。
見積精度を向上することに関しては、また別の機会に説明したいと思います。
(PMC SP1.1 SP1.6)

プロジェクトの遅れの原因を管理する
予定と進捗率から現時点でのプロジェクトの遅れがわかるようになります。
この対処を担当者任せにしてしまうと、結局は前と何も変わらないことになってしまいます。
担当者が残業を増やして遅れを挽回するとか、担当者が手伝ってくれそうな人を自分で探すとか。。。
担当者は人・モノ・金を動かす権限がないので、結局は自分で抱え込んでしまってプロジェクトの終盤でさらに悲惨な状況になってしまいます。
そこで、プロジェクトの問題管理表作成し、進捗管理上発生している問題を一括管理します。
問題管理表は誰がいつまでに対応するかを記載し、対処が完了した時点でクローズします。
人・モノ・金を投入しなければならない場合はプロジェクトマネージャが上層部と交渉します。
こうすることで担当者は期限までに対処することに専念することができます。
(PMC SP2.1 SP2.2 SP2.3)

ここまでに説明してきた進捗率や問題管理表など、さらに詳しい話はコンサルティングの中で具体的に説明しています。もしご質問などあればコメント欄からお願いします。
次は開発計画の立案について説明したいと思います。




cmmi_husa at 14:38|PermalinkComments(0)

2017年07月21日

コンサルティング会社をつくりました

ずーっとブログを放置してしまいましたが、久々の更新です。

突然ですが、長年勤めた会社を辞めてコンサルティング会社を立ち上げました。
業務内容はもちろん、CMMIを実践する開発部隊をサポートすることと、なぜなぜ分析によるプロセス改善の取り組み支援です。

3月に会社を辞めて、法務局で登記申請。
5月30日に設立となりました。

会社名はクオリゲート合同会社。

ホームページはまだ立ち上げたばかりで不十分ですが、これから充実していこうと思います。

http://www.qualigate.co.jp

ホームページは製造業向けとなっていますが、システム開発会社向けのサービスも行っています。

スタートキャンペーンとして、8月から12月まで無料セミナーを行いますので、ご興味のある方はお気軽にご相談ください。

y.ichihara@qualigate.co.jp

cmmi_husa at 09:16|PermalinkComments(0)

2015年07月04日

型にはまった「なぜなぜ分析」

同じテーマについていくつかのグループでなぜなぜ分析を行うと、ぜんぜん別の方向に行ってしまうことがあります。
それぞれ別の切り口で分析されていて方向が違うのならば、最後になぜなぜ分析とDAR(決定分析と解決)のやり方で採否の決定を行えばいいのですが、そもそも分析の進め方が迷走してしまっている場合も少なくありません。
慣れるまでは分析の仕方をもっと型にはめた方がバラツキがなくなるんじゃないか?という話もあったのでなぜ1からなぜ3までをスムーズに行うための以下のような型を作ってみました。

なぜ1:誤った行動
なぜ2:誤った判断
なぜ3:判断の根拠

例えばこんな風になります。

なぜ1:誤った行動
担当者は変数に誤ったパラメータを設定した

なぜ2:誤った判断
パラメータにセットする値を前回と同じで良いと判断した

なぜ3:判断の根拠
詳細設計書にパラメータに関する情報の記載がなかった


なぜ3まではこんな感じで型にはまった分析を行って、なぜ4以降で詳細設計でなぜ抜けたかをプロセスの観点で分析すれば良いわけです。
まあ、何でもかんでもこの型にハマるとは思っていないので、迷ったときに覚えておいた方が良いくらいの感覚で頭に入れてもらえれば、そのうちに役に立つことがあると思います。



cmmi_husa at 23:03|PermalinkComments(0)TrackBack(0) なぜなぜ分析 

2015年06月08日

目標未達をなぜなぜ分析する

なぜなぜ分析は基本的に業務上のミスを分析してプロセスの改善策を導き出すものです。
しかし、セミナーの受講者の中には目標未達のような問題をなぜなぜ分析しようとしてハマってしまう人も少なくありません。
では、こういったテーマをなぜなぜ分析するにはどうすれば良いのでしょう?

QCDの目標未達、品質目標やコスト目標、納期の未達といった問題は目標達成を阻害する複数の要因から引き起こされている場合がほとんどと思います。このよう場合にいきなりなぜなぜ分析すると、なぜ1にたくさんの原因が出てきてしまって混乱してしまいます。まずは、どの阻害要因を優先的に対策していくかということを整理してから分析を始めるとうまくいきます。
品質問題であれあ不良要因別の発生数、コスト問題であれば費目ごとの費用といったように分類し、それぞれの定量データについてパレート図を作成し、上位の要因を優先的に対策していくわけです。
目標未達の80%は20%の要因で占められていると言われます。つまり、上位20%の項目を対策すれば80%の要因について対策したことになるのです。
もうちょっと簡単に言うと、10項目の阻害要因があった場合、パレート図を描いた結果上位2項目の要因をなぜなぜ分析して再発防止策を実施すれば効果的であるということです。

この分析手法は開発や製造の現場というより、マネジメント側で使える手法だと思いますので、実践してみて下さい。
重要なことは必ずパレート図を描いて優先度を評価するということです。定量データを示すことで、再発防止策の有効性の裏付けになりますから。。。

cmmi_husa at 21:48|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2015年06月07日

なぜなぜ分析のポイント:開発のバラツキを考える

以前、なぜなぜ分析とQPM(定量的プロジェクト管理)なぜなぜ分析のポイント:スキルや経験にバラツキがあるのは当然でも書いていますが、問題が発生する要因として開発のバラツキというものがあると思います。
開発のバラツキとは、要するにアウトプットの粒度にバラツキがあるということです。よく、「あの人の仕様書は細かいところまできちんと書かれているけど、こっちの人はずいぶんざっくりだな〜」と言うようなことはないでしょうか?これは仕様書を書くにあたって、どれくらいの深さまで書くとかどのように書くかということがきちんと規定されていないため、もしくは規定されていてもそれを守っていない為開発者が自分で好き勝手に書いているということです。
このような状況であれば、スキルのバラツキを埋めるために教育も必要ですが、もう一つ重要なのは仕様書の粒度を揃えていくような改善を実施することです。

改善の例としては仕様書作成のガイドラインを作成し、仕様書のテンプレートを作って型決めするというのも一つの方法ですが、ソフトウエアに限って言えばUMLのような手法やツールを導入するというのも一つの方法です。UMLは私も経験したことがありますが、10年選手と2年目の若手が同じロジックの設計を行った時に、アウトプットが同じになってちょっと驚いたことがあります。その時、この手法はとても有効だと感じました。
回路設計なども似たような考え方で、たとえばタイミングのシーケンスをタイミングチャートを描くとかUMLにもある状態変化をステートマシン図で表現するというようにツールを使うと下流の開発者との意思の疎通が取りやすくなります。意外と回路設計ではタイミングの問題があって、開発者に聞いてみると頭の中で考えて回路に落としました。。。というようなことが多くあるようです。
構造設計だと3Dシミュレーションを行うとか設計変更の時はDRBFMの考え方を導入するといった対策もあると思います。

設計の粒度にバラツキがあるという場合は人に頼った対策になりがちですが、プロセスの改善案として積極的にツールの導入を検討し、安定したプロセスを構築していって下さい。特にCMMIのレベル4以上を目指す組織では必須の活動となります。

cmmi_husa at 02:20|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2014年06月06日

なぜなぜ分析と特性要因図

いろんな人のなぜなぜ分析を見ていると、事実の部分がよくわからないまま分析しているケースをよく見ます。
例えば、ソフトウエアに潜在バグがあって何らかの条件が重なって障害を引き起こした場合、ソフトウエアを開発してからかなり時間が経っており開発者も既に組織にいなかったりする場合があります。
それでも原因究明し再発防止策を報告しなければならないケースというのはあると思います。
この時、想定されるすべてのケースについてなぜなぜ分析を行うのか、それとも何か一つのケースについてなぜなぜ分析を行うのか迷う所です。

このような場合は、まずは特性要因図を書いてみるというのも一つの方法だと思います。
ところで皆さんは特性要因図というのをご存知でしょうか?
QC7つ道具のひとつで、ある問題に対する要因を挙げて、その要因を引き起こす要因を考えていく分析方法です。
なぜなぜ分析と違うのは、原因分析ではなく要因分析である点です。
つまり、問題を引き起こした誤った行動を深堀するのではなく、引き起こす可能性のある要素をすべて挙げていくという点で違っているわけです。
ここでは特性要因図の書き方の説明はしませんが、分析結果が魚の骨に似ているためそのまま「魚の骨」と呼ぶこともあります。

魚の骨が描けたら、引き起こす可能性の高い要因やリスクの高い要因をピックアップしてそれについてなぜなぜ分析を行っていきます。
つまり、数ある問題を引き起こす要因の中から分析の対象とする要因を選択するのにも、きちんとロジカルに考えて分析の対象を選択しましょうということです。

最初に説明したようなケースでは、なぜなぜ分析の中で特性要因図を作って締まっている場合が良くあります。
なぜなぜ分析と特性要因図の違いをよく理解し、事実確認が困難なときに組み合わせて使えば分析もやりやすくなると思います。



cmmi_husa at 12:39|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2014年05月31日

なぜなぜ分析のポイント:技術的な課題はなぜなぜ分析の前に解決する

問題が発生した際、その再発防止策を検討するときに、技術的な課題をなぜなぜ分析しているケースがよく見受けられます。
そもそも技術的な課題をなぜなぜ分析で解決することはできるのでしょうか?

例えば、ソフトウエアの障害について技術的な原因を見つけるには、実際のデータを流してみるとか、パラメータを監視しながらソースコードを1ステップずつ実行するとか、そういった対応が必要です。決して机上のなぜなぜ分析で技術的原因がわかるものではありません。ハードウエアでも同様で、オシロスコープで波形を見るとか、顕微鏡で破壊したチップの断面を見てみるとか、なぜなぜ分析とは違うレベルの調査が必要です。

なぜなぜ分析はあくまでもプロセス上の根本原因を見つけて再発防止策を導き出すためのものなので、こういった技術的な原因調査とは違ったアプローチをとる必要があります。

順番から言ったら、技術的な原因調査が先で、なぜなぜ分析があとになります。まずは技術的な原因を調査し、ソフトウエアならパッチを提供するとか、ハードウエアなら対策済みの基板と交換するとかといった処置が必要です。そのあとに、設計の進め方やレビュー、テストのやりかた等の開発プロセスについての根本原因分析を行い、プロセスの改善を実施します。

ここを分かっていないと上手に分析できないので、是非意識して分析を行ってみて下さい。

cmmi_husa at 12:35|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2014年05月28日

なぜなぜ分析のポイント:スキルや経験にバラツキがあるのは当然

開発者がなぜなぜ分析を行っているのを見ると、根本原因に「スキルに差がある」とか「経験値が人によってバラバラ」というようなことを書いて、再発防止策に「教育を行う」というような分析を行う人がたくさんいます。
確かに教育でカバーできるレベルのものもあるでしょうが、そもそもスキルや経験にバラツキがあることは良くないことなのでしょうか?
入社してからずっと同じプロジェクトで仕事をしている同期ならそれほどスキルや経験にバラツキがでないのかもしれません。しかし、入社年度も違うし、他の部署から移ってきたり中途入社の先輩もいるかもしれません。
要するにそれぞれの開発者が経験してきたことや、いままで経験した仕事が違うわけですから、スキルや経験が違うのはむしろ当たり前のことなのです。そして、このようなスキルの差というものは、何かの教育で簡単に埋まるものではないと考えています。
では、なぜなぜ分析ではこのような場合、分析をどのような方向に持って行けば良いのでしょうか?

考え方のベースはやはりプロセス指向です。つまり、スキルや経験の差を埋めるものがプロセスであると考えるのです。
スキルが高く、経験豊富な先輩のやり方を標準プロセスとして定義し、そのやり方を守って他の人も開発を行っていけば、アウトプットの品質は自ずと安定してくるはずです。
もちろんその中に教育も入ってきますが、改善の中心は手法や開発の粒度を合わせるところに焦点を合わせた方がより効果的です。



cmmi_husa at 21:33|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2014年05月11日

なぜなぜ分析の前に5ゲン主義で事実を把握

なぜなぜ分析を始める際の最初のステップは事実を把握するということです。ここを疎かにすると、真の原因に辿り着けないばかりでなく、間違った原因に辿り着くこともあります。つまり、なぜなぜ分析のプロセスの中でもっとも重要な部分と言えます。
しかし、意外とこの「事実の把握」が疎かになって、予測した状況をもとになぜなぜ分析を始めているケースをよく見ます。
きちんとミスをした現場でヒアリングを行ったり、仕様書の内容を確認したり、メールのやり取りを確認しながら事実を正確に把握して分析する必要があります。

このようになぜなぜ分析にとって非常に重要な「事実の把握」ですが、実際にはどのように行えば良いのでしょうか?
「事実の把握」のやり方として、5ゲン主義というのがあります。ご存知ですか?
5ゲン主義というのは「現場」「現物」「現実」の3現と「原理」「原則」の2原を足したものです。じゃあ、3現って何で、2原って何ですか?ということですね。真面目な解説はネットを調べれば出てくるのでそちらにお任せするとして、もうちょっと身近なネタで説明をします。

刑事ドラマで考えて下さい。
ジーパン:「矢追町3丁目で殺人事件発生!」
ボス:「ジーパン、デンカは現場に急行してくれ。ヤマさんとチョウさんは聞き込みだ!」

そう。現場検証や聞き込み調査が3現の調査です。

夕方、刑事たちが署に戻ってきて、ホワイトボードに写真を貼って捜査会議をしています。
ボス:「仏さんとその男はどういう関係だ?」
ヤマさん:「男は殺された男に多額の借金をしていて、しつこく取り立てられていたようです。」
ボス:「金銭トラブルは殺人の動機になるな。。。」

これが2原です。つまり「○○ならば△△」のような、世の中の法則です。

このように実際に起こったことを調べて3現をおさえ、2原を使って関連性を結び付けていくというのが5ゲン主義のプロセスです。なぜなぜ分析を行う際は、この刑事ドラマのやり方で事実を把握していくといいですね。

どうでしょうか?わかったような、わからないような。。。?

他にも5W1Hや4Mや3Hのような考え方もありますが、そちらは別の機会に。。。

cmmi_husa at 23:51|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI

2014年04月03日

なぜなぜ分析で真の原因が「レビュー不足」となった場合の再発防止策

なぜなぜ分析でソフトの障害を分析していると、しばしば「レビュー不足」が原因となる場合があります。
「レビュー不足」が真の原因か?という議論もありますが、今日はそこの議論は置いといて「レビュー不足」の時の再発防止策を考えてみます。
真の原因が「レビュー不足」となった場合、再発防止策として「レビューチェックシートに漏れていた項目を追加」と書かれているケースを非常に多く見かけます。
レビューチェックシートに項目を追加することで再発は防げるのでしょうか?

レビューチェックシートに項目を追加することにより全く同じ原因による障害は発生しなくなるかもしれません。
しかし、なぜなぜ分析で目指すのはプロセス改善により類似の原因による障害の発生も防止することです。
チェックシートへの項目追加も必要ですが、もっとプロセスの問題も深堀りして対策しなければならないかもしれません。
「レビュー不足」を引き起こす要因としては以下のようなものがあります。

1.レビュー時間が不足している

レビューを行う際は過去の実績をもとに1枚当たりまたは規模当たりのレビュー時間の基準を作っておきます。これに対して実際のレビュー時間がどの程度かい離したかを測定し、ある一定量以上または以下のかい離があった場合はレビューの十分性について評価します。例えば、「画面仕様のレビュー時間は基準より50%下回っていたが、これは共通コンポーネントを利用した開発でレビュー対象の差分は50%以下であったためである」のような感じです。

2.抽出されるバグが少ない

レビュー時間と同様に、仕様書の指摘数やプログラムのバグ数についての基準を作っておき、基準に対して大きくかい離している場合はレビューの十分性について評価します。

3.レビュー観点がもともと足りない

レビュー観点が足りなかった場合は、単に不足していた観点を追加するだけでなく、項目作成時と現在の開発環境の変化等にも着目し、レビュー項目の総点検を行うなどの対策が必要な場合があります。
クラウドの利用やネットワーク環境の変化、オフショアなど様々な環境の変化がレビュー観点に盛り込まれているか、再点検してみて下さい。

上記のような観点で「レビュー不足」に対する分析を行うと、これまでと違った再発防止策がでるのではないでしょうか?

cmmi_husa at 16:04|PermalinkComments(0)TrackBack(0) なぜなぜ分析 | CMMI
訪問者数
  • 今日:
  • 昨日:
  • 累計:

Recent Comments