【共通フレーム２００７第２版】正直な告白：「開発」と「保守」の使い分け

Ｐ７において「（注）本書においても、『第３部　共通フレームとガイダンス』を除き、『開発』と『保守』という用語を使い分けておらず、もっぱら『開発』を使用している。しかし、個々の文中においては、『開発』を『開発又は保守』と捉えてよい場合が多いため、適宜、そのように読み替えていただきたい。」という記述がある。

正直にこれを書いたことは、評価すべきであろう。

しかし、「『開発』を『開発又は保守』と捉えてよい場合が多い」および「適宜、そのように読み替えて」の記述からは、著作者も、どの箇所で「開発」を「開発又は保守」と捉えてよいか分かっているということなので、ちゃんと記述すべきであろう。

「適宜読み替えよ」という言葉は、モデルにおいては使うべきではない。
「以後、常に読み替えよ」ならば良いが。

この記述、初版では無かった。
だれかに指摘されたのだろう。
しかし、その指摘に対し、このような対応で済ますのは、「横着」と言われても仕方がないだろう。初版でもどこかに書かれていたのならば、「横着」には当たらないが、「適宜読み替えよ」はやはり良くない。

【共通フレーム２００７第２版】「第２版刊行にあたって」における自己評価

viiページ「第２版刊行にあたって」において「共通フレーム２００７で取り決めた『契約の変更管理プロセス』が、２００８年３月に発行されたソフトウェアライフサイクルプロセス改訂版(ＩＳＯ／ＩＥＣ　１２２０７：２００８)に採用されました」とある。
これは確かに日本発の世界への誇るべき貢献であるといえよう。

しかし、ここで止めておけばよいのに次の文が続いてしまう。
「これは、国際規格をベースに日本の産業界で修正して作った共通フレーム２００７が、今度は、国際規格への改訂・強化に貢献できるほどの内容であることを意味しています」。

これでは共通フレーム２００７全体が「国際規格への解読・強化に貢献できるほどの内容である」ようにとれるが、検証されたのは「契約の変更管理プロセス」部分だけである。
一部が評価されたから全てが素晴しいものであると自ら言っているように取れるが、共通フレームの性格上、そのようなことは言い切れないはず。

故にこの文は蛇足だ。

どうしても言いたいのなら、「共通フレーム２００７で取り決めた内容が、ＩＳＯに採用されたのか…すごいな、共通フレーム２００７は、国際規格への改訂・強化に貢献できるほどの内容なんだ」と読者が自発的に想起できるような文にすべきであった。自ら書いてしまうと、ミスリーディングと言われても仕方がなくなる。

著作者としての気持はわかるが。

さて、共通フレームの本質とは関係の無いところから始まりますが、新しくなった「共通フレーム２００７」についてこれから見ていきます。

「共通フレーム２００７第２版」というより「共通フレーム２００９」で良かったと思わなくもないですが…と、これまた本質とは関係の無いところを突っ込みたくなるのですが・・・。

【定量的管理雑話】定量的管理を信じない人が定量的管理推進を命じられたら

Ｑ：
定量的管理を信じないのですが、上司にやれやれ言われています。どうすればよいでしょうか？

Ａ：
簡単です。
有名どころのコンサルに頼みましょう。アドバイス業務として。
そして自分の疑問を徹底的にぶつけましょう。質疑はすべて記録してください。録音しておくことがベター。

で、あなたが納得できたら…、
おめでとう、あなたは定量的管理を始められますね。
納得できなかったら…今迄の記録をまとめて、上司に報告しましょう。もしくはコンサルの終盤に入る頃に上司も一緒に参加してもらいましょう。

しかし残念ながら定量的管理実施が自分の上司レベルではなくもっと上からの「命令」ならば頭を使うしかない。
きっと活路は見出だせる。

自分で解決できなければニーズを満たすコンサルを探せ。
先のコンサル結果を示した上で受けてくれるコンサルを。

こういう課題を提示した時に「具体的に見ないとわからない」というコンサルとそんなことに言及しないコンサルがいると思う。
前者は慎重であり信頼できるというよりも、汎用的な解を持っていないと「明言」していると考えた方が良いです。
後者は汎用的な解を持っている可能性もあるし、逆に何も分かっていない可能性もある。

そして、コンサル料は、先のコンサルより格段に高いでしょう。
・・・というより、これを受けることができるコンサルは日本に何人いるのだろうか。

【定量的管理雑話】言い訳のネタ集めとしての定量化

定量的管理は言い訳のネタ集めとして割り切ると先が開けてくる。

散々仕様変更飲まされたのに期限にバグが多かったり間に合わなかったりしたら叩かれる。しかしその変更依頼日や内容、プロジェクトへの影響が記録されていれば大丈夫。対抗できる。

しかし実は定量的データ集めの実務メリットはそれだけではない。

次からの見積もり時に、仕様変更の多さ等のプロジェクトに影響を与える特性を最初から加えることができる点だ。ここを平和的にまとめることができれば、次からはプロジェクト中の説明さえ減らすことができよう。

しかし、これはおそらく「便宜上」の定量管理であって、真の意味での改善につながる定量化ではないだろう。

【定量的管理雑話】「測る企業は成功率が2倍に」をもう少し考える

「測る企業は成功率が2倍に」で重要なのは組織文化と大括りで言えると考えたが、個別にみると、定量的管理をすれば説明責任を果たしやすくなるという面は確かにある。

６００ケースもテストしたんだよと言うより今回のテスト密度はこれこれなので過去データから見て十分と言った方が顧客や上位管理層も納得する＝つまり「成功」に近づく。
何かあっても、でも今まで通りちゃんとやったんだから不可抗力だよとなる可能性も高まる。

プロジェクトの成功とは失敗の烙印を押されないことである。だれに？顧客や上位管理層に。ならば口頭の定性的説明だけでは失敗の烙印を押される場合でも、信頼度成長曲線みたいな手法を使って相手が納得すればそれは失敗ではなくなる。「測る企業は成功率が2倍に」はそういう意味なら納得できる。

この場合相手が納得することが一番重要。厳密であるが難しい式見せても納得しないような人でも、直感的に納得できる説明なら満足するケースは多い。例えば信頼度成長曲線。これは開発現場では賛否両論あるが上記のような人には抜群の効果を示す。その理論と結果の両方が直感的かつ簡単に理解できるから。

しかし、直感的に理論が理解できて適用結果判断も直感的にできるようなものは、開発現場ではわざわざグラフ化しなくとも体感しているはず。いや、そう思っているだけで厳密には違うかもしれないからグラフ化は必要という方もいよう。しかし信頼度成長曲線に限れば体感の方に軍配をあげたい。

しかし説明責任を果たす場で抜群の効果を発揮するならそれは「有効」である。テスト密度も一緒。品質の維持改善に使う分にはこのような定量的管理は意味があると考える。

【共通フレーム２００７第２版】マイナーバージョンアップ

新しい共通フレーム２００７について見て行きます。どこがどう変わり、どう変わらなかったのかを中心に考えていければと思います。
１１月より更新していきます。

それにしても、これはマイナーバージョンアップというのだろうか。
共通フレームとしてはマイナーバージョンアップでも、共通フレーム２００７としてはメジャーバージョンアップといえそうであるし。

共通フレーム２００９としなかった点からみればマイナーともいえるが、２００９年も終わりに近づいた今、２００７というのもインパクトに欠けるのではないだろうか。

【定量的管理雑話】測る企業は成功率が2倍に・・・これ自体定量的にいかがなものか

「測る企業は成功率が2倍に」という日経コンピュータの記事（２００８年１２月１日号）
http://itpro.nikkeibp.co.jp/article/COLUMN/20090128/323651

これの意味するところは何か。
「そうか・・・では我々も定量的管理をしよう。しかし負荷をかけたくないしよくわからないから上手くいってる組織の管理項目を聞いてそれを実践しよう」という考えは是か否か。

もうひとつ記事を。
子供の学力は親の年収に比例する傾向にあるそうだ。ただ年収が低くとも、ニュースについて語りあったり読み聞かせしたりする家庭の子は学力が高いらしい。
http://www.yomiuri.co.jp/kyoiku/news/20090805-OYT8T00352.htm

それでどこかの教授が、「低所得でも親の心がけ次第で学力向上につながる」とかなんとか間抜けなコメントをしていた。なぜ間抜けか。

持たざる者は工夫で乗り切れと言っているのだ。
所得による教育格差が小さな差であればそれは可能であろう。
しかし、本当に工夫で乗り越えられるのであろうか。
敵戦闘機に対して竹やりで頑張れみたいなことを言っていないか？

まあ、確かに大学受験のために塾に行ったり家庭教師を雇うのにお金はかかる。
だからそれをお父さんお母さん方が代わりに教えれば金はかからない・・・というのならば納得はできる。しかし、大学受験のための勉強を教えられる父母がどれだけいよう。

読み聞かせしたりニュースについて語りあったりする家庭は、それだけしているわけではない。親が子に何をすべきかを考えて色々行っているのだ。その一例が読み聞かせ等であるにすぎない。だから読み聞かせやニュースについて語り合うことだけすすめても意味がない。

ポイントは、読み聞かせたりニュースについて語り合う家庭環境にあるのかだ。この環境が家庭内になくても、親の年収があれば塾や習い事で補われるということではないだろうか。逆に親が今の生活に精一杯ならば、読み聞かせ等はしたくてもできない。結局、一義的には親の年収が重要だと思われる。

しかし年収はそれほど多くなくとも読み聞かせやニュースについて語り合うことができる家庭はあろう。ここで間違えてはいけないのは読み聞かせとニュースについて語り合うことだけ実践すれば良いと考えることだ。この二つは親の年収に関係なく成績が良い子をあぶり出す単なるパラメータに過ぎない。

これが必要十分条件ではない。要は読み聞かせやニュースについて語り合おうという家庭内の文化があるか否かがポイントなのだ。しかしこの文化をマニュアル化することは難しい。勢い読み聞かせをすすめる某教授みたいなことになってしまう。

教育の専門家ではないのでこの件はこれくらいにして、ソフトウェア開発組織の定量的管理に戻る。ポイントは同じ。定量的管理を行う組織のプロジェクト成功率が高いのは定量的管理を行っているからと短絡的に考えるべきではない。定量的管理を行おうと思える組織文化が成功率を上げていると考えるべき。

だから開発が上手くいかない組織が定量的管理を始めたからといって成功率が上がる保証はない。というか個人的には必ず下がると言いたい。定性的にやることやらずして定量的管理はできないだろうから。定性的に見つけられることをわざわざ定量的に発見して嬉しい組織は別だが。

長々と書いたが、要は定量的管理を行う組織の成功率が高いからといって定量的管理を始めるのはナンセンスだということ。そんなことを言い出す上位経営層がいたら「花さかじじい」を読み聞かせると良い。表層的な形だけマネた隣りのじいさんがどうなったか教えるために。舌切り雀でも可。

以上のように考えれば、この「測る企業は成功率が2倍に」という記事自体が、定量的に怪しいのではないかと検証されるべきだと思う。
詳細に分析したら、「測る企業は、測らない企業より多く成功率向上のための他の施策を行っていることが多い。このため、実は測ることは成功に何の因果関係もないが、他の様々な施策の結果により成功する確率が高いのである」という結果になったりして・・・個人的にはこれは十分あり得る話であると考えている。

まあ、雑誌の記事なのでキャッチーな方が良いとも言えるが、これを見て「測る企業は成功率が2倍だそうだからうちも測ろう」という人が周りにいたら、「ちょっと待て」と言ったほうが良い。昔の記事だし、もう始めているかもしれないが。

バナナダイエットでバナナだけしか食べなかったらきっと病気になります。
一方、神に感謝する生活をしていれば、本当は神などいなくとも幸せに暮らせるでしょう。
何か変なたとえ。

【定量的管理雑話】パラメータ追加でメトリクスの精度を上げることについて

品質系カンファレンスの経験発表においては、今後の改善策として、測定するパラメータの追加でより詳細に計測し制度を上げていく…というパターンが昔からある。

このパラメータ追加でメトリクスの精度を上げようという試み。
気持ちは分かる。
しかし、そもそもなぜメトリクス管理を行うか振り返るべきである。
複雑で混沌としたソフトウェア開発プロジェクトの状況を、特徴的に表すパラメータに着目して人が認識できるようにしようというのが、定量的管理の元々の目的のはず。

なのにパラメータ増やしたらまた混沌とするのではないか。
バグ密度測るのに１００個のパラメータ計測するか？
所詮は、発見バグ数を開発規模で割るだけならその程度のものと文字通り割り切るべき。

まして１つのメトリクスだけで評価するのではなく複数のメトリクスを見て判断すべきだとか、管理限界を超えた値も一概にダメと決めつけずその原因を追求すべきと予防線をはる定量的管理などは、労多くして…となりかねない。

大量のパラメータからなるメトリクスデータをこれまた大量に手に入れたとして、それをどうするのか。
結局はプロマネやチームで総合的に判断することになるのでしょう。しかし、その判断は恐らく定性的に行われる。ではわざわざ計測した意味はどこにあるのか。

定量的管理の使い方を間違っているのではないだろうか。
定量的管理は何をするために行うのか今一度よく考えるべきである。

「レビュー指摘率が高いけれど○○○の理由から問題なし」「レビュー指摘率が低いけれど△△△の理由から問題なし」というような定性的分析を都合よくくっつけることで、全ての定量的アラームが、問題なしとして何も対応されないのであれば、手間をかけて定量的にデータ収集をする意味がない。

【定量的管理雑話】ロジックの理論的裏付けの弱さを収集・管理ツールで補うことはできない

工業製品の製造は組立ラインの速度といったペースメーカーがあるので人の作業が関与しても生産性を把握しやすい。逆に、如何に人の作業を速くするかで速度が決まる面もある。
究極は全自動化。

一方ソフトウェア開発にはこのようなペースメーカーはない。
計画はあるが流れ作業ではないので緻密な管理はできない。
やはりよく言われるようにソフトウェア開発には直接測れる物差しが今のところ発見されていないことと人起因およびプロジェクト毎の要件のバラツキが大きくかつ避けられないことが、定量的管理手法を難しくさせる、というかうさん臭くさせる。

このあたりを解決しようとする場合に、現行の管理ロジックはそのままで、早く・精緻で・簡易に算出するような改善を考えることよりも、開発手法自体や管理ロジック自体を論理的裏付けに基づいて変えないとダメなケースが多いのではないかと思う。

自動で欠陥密度が分かり過去データとの統計的比較からプログラムの品質がわかるようになりました…っていわれても、そもそも欠陥密度の算出方法はどうなの？それで良いの？…ということを考えた方が良いことがあると考える。

【定量的管理あれこれ①】ソフトウェアの定量的管理とPMBOKとの両立

ソフトウェアの定量的管理とPMBOKというかプロジェクトマネジメントは両立するか。
マネジメント能力に開発の成否が左右されるなら定量的管理など意味がなくなるはず。

このあたり整理が必要。

プロマネは計画を立てて管理するのであるが、実際のところソフトウェア開発において失敗プロジェクトがあとをたたない。ここに定量的管理を持ち込めば成功するのか。
それとも定量的管理を既にしていてダメなのか。定量的管理ができない分野があって、かつそこが成否のキーなのか。おそらく一面では全てが正しいであろう。

生産性…、頑張る時もあればサボるときもある人の特性を含むこの活動を、定量的に把握するためにはどのような統計的？もしくは算術的？処理をすべきか。

考慮すべきパラメータはざっとみても沢山ある。やる気、残業時間、個人差、プロジェクトの状況や時期、要件変更の頻度や時期…キリがないが、どれも生産性に大きな影響を及ぼすように思える。

そして一番厄介なのはやる気。プロジェクト初期は余裕持って臨んで、末期に徹夜してなんとか間に合ったなどという組織に生産性のメトリクス管理は早い(とはいえ現在の多くの組織がそうである気もするが)。

まずは定性的管理をしっかり行う。
ＰＭはこのあたりに重点を置いて作業を平準化してメンバーを導くことがプロジェクト管理と定量的管理の共存点かもしれない。

以上のような書きぶりでは、全然うまく伝えられていないと思うが、このあたり既にどなたかが整理されているのだろうか。