前回エントリから１ヵ月以上空いてしまいました。
多忙と試験勉強が言い訳なのですが。。
このシリーズエントリは先が長すぎて、No.50とか平気でいきそうなので、きりのいいところでpdf化した内容を一括ダウンロードで終わりにしたいかな、、と考えているこの頃です。

ではプロセス改善のNo.14をどうぞ。

品質確保に効果のあった派生開発プロセスの工夫#14

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part3)

対処検討プロセスを順に解説していく。今回は「1.2.2 要求仕様の特定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.2.2 要求仕様の特定

1.2.2.1 プロセスの目的・概要

要求仕様の特定プロセスの目的は、システムやソフトウェアの構成要素が特定できる形まで、要求コンセプトをブレイクダウンし、適切な作業スコープを設定することである。

要求コンセプトは、「トランザクションの同時受付数を５０００まで拡張する」とか「機器の障害発生時に、アクティブ系の機器が存在しない状態を３０秒以上継続させない」などといった、システムの構成要素や設計・プログラム構成要素を特定しにくい表現になっている。

この表現を、「Ａ機器管理処理ブロックにおいて、○○通知を受信した場合は、□□の動作を行う」といったシステムやソフトウェアの構成要素の振る舞いがわかる程度の詳細度にブレイクダウンしていく。このブレイクダウンされたものを要求仕様と呼ぶ。
(さらに…)

品質確保に効果のあった派生開発プロセスの工夫#13

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part2)

対処検討プロセスを順に解説していく。今回は、1.2.1 要求コンセプトの明確化から解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.2.1 要求コンセプトの明確化

1.2.1.1 プロセスの目的・概要

要求コンセプトの明確化プロセスの目的は、派生開発における欠陥是正要求や変更要求に含まれる真の目的をあぶり出し、作業スコープを最大限に拡張することである。

スコープを広げることで、欠陥是正要求や変更要求を実現する際に、同時に対応しなければならない派生的な要求事項を見逃さないようにする効果が得られる。

派生開発におけるスコープの幅は、本プロセスで最大になり、以降のプロセスを経るに従い次第に具体化され縮小していく。

要求コンセプトの明確化が効果を発揮するケースは、ソフトウェアの具体的な欠陥是正要求が到来した場合である。

欠陥是正要求は、実際に発生している個別具体的な欠陥事象やその発生原因をふまえて発行されるため、はじめの要求時点から、かなり具体的な対処方針や修正内容を含んでいる場合がある。

例えば、「対向システムの回線障害検出論理を変更するため、○○処理の□□動作を、△△へ改修する」といった内容である。要求内容が具体的であればあるほど、担当者はすぐに具体的な修正内容の検討に着手しようとする。

その結果、同種の原因による他の欠陥が潜在していないかを水平展開して洗い出す作業が漏れたり、そもそもの要求で依頼された内容に誤りがあったりすることを見逃しやすくなる。
(さらに…)

品質確保に効果のあった派生開発プロセスの工夫#12

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群

今回からは、当派生開発プロセスを１つ１つ詳細に見ていく。説明は、

・プロセスの目的・概要
・プロセスフローの説明
・要素成果物の説明
・個々のプロセスの説明

の流れで行う。

個々のプロセスの詳細な説明になるため、現在位置が分からなくなることもあると思う。その時は、全体プロセスを参照し、現在地を確認しながら参照してもらえるとよろしいかと思う。

今回は「対処検討プロセス群」について解説を行う。

対処検討プロセス群

●プロセスの目的・概要

対処検討プロセス群は、派生開発における欠陥是正要求、変更要求を受け付けて、要求への対応方法を十分に検討し、関係者と協議し、決定を下す一連のプロセスで構成されている。

対処検討プロセス群の目的は、漏れのない対処検討を行うことを保証し、その結果として高い設計品質を確保することである。

対処検討プロセス群には、派生開発プロセスの４つのプラクティスの全てが含まれる。
(さらに…)

品質確保に効果のあった派生開発プロセスの工夫#11

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（本記事が該当）

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（２）派生開発のプラクティス、プロセス

前回までは派生開発のプラクティスを見てきた。今回からは、このプラクティスを組み込んだプロセスについて見ていく。

２．２　派生開発のプロセス

本節では、以上までにみた４つのプラクティスを具体的に実行するためのプロセスを説明する。最上位のプロセスでは、大きく３つのプロセス群に分かれている。

1.対処検討プロセス群
派生開発特有の課題に対応するために、開発工程の前に設けた事前検討を行うプロセス群。４つのプラクティスの全てが含まれる、本派生開発プロセスで特に重要なプロセスである。

2.開発プロセス群
一般的な開発プロセスである。本書ではウォーターフォール・モデルのプロセスを前提としている。ただし、本書は開発プロセスを規定する意図を持たないため、組織やプロジェクトにおいていずれの開発プロセス・開発モデルを採用していても、本派生開発プロセスを適用することが可能である。４つのプラクティスのうち、１つのプラクティス（ドキュメントのトレーサビリティ強化）が含まれる。

3.検証プロセス群
一般的なテスト工程を定めるプロセスである。検証プロセスについても、本書では特段の規定をする意図を持たない。組織やプロジェクトにおいていずれの検証プロセスを採用していても、本派生開発プロセスを適用することが可能である。

プロセス群のうち「2.開発プロセス群」と「3.検証プロセス群」は、理解度向上のために参考までに記載したものであり、本書は開発プロセスや検証（テスト）プロセスを規定するものではない。各プロセス群はさらに詳細なプロセスに分解される。
(さらに…)

知的体力とは？

いつも参考にさせて頂いているブログ「タイムコンサルタントの日誌から」に、以下の内容が記載されていた。

コンサルタントに必要な頭の良さとは、分析力よりも、問題解決案を考える能力だというのも、重要な指摘だ。とくに、著者が『知的体力』と呼ぶ、（正解のない問題を）何時間でも何日でも考え続ける能力は、ほとんどの人が見落としている、大事なポイントだと思う。

知的体力、という言葉は初めて目にした（耳にした）が、たしかにこれは誰しもが持っているスキルではないと思う。

コンサルタントに必要な水準かどうかは別にしても、このように答えのなかなか出ない問題を何日も考え続ける、という体験なら当方にもかなり思い当たることがある。

ただし、当方がいつもぶち当たっている問題とは、

「世の中の誰が考えても解決が容易ではない問題」

ではなく、

「世の中のエキスパートが考えれば答えは比較的容易に出るが、自分にとっては未経験の分野・未知の分野を含む問題」

といった問題である。

自分にとっての未知の領域を含む問題の特徴

この問題は、自分にとっては未知の知識がある、つまりインプットすべき知識が不足している、ということが問題解決を難しくしている大きな要因になっている。しかし、だからといって知識さえあればいいわけではなく、その知識を応用することが実務ではたいてい求められるので、インプットすればすぐに答えが導けるものではない。知識をベースに応用する余地が残されている。

たとえば、自社の戦略の方向性を考えたり、自分たちのチームの抱える生産性低下という問題の原因分析と対策の検討を行ったり、ＩＴシステムの設計において、未知の設計指向を採用しなければならない場合、といったような問題である。経営戦略については、経営管理・戦略論などのインプットが必要だし、生産性向上のためにはIEやオペレーション・マネジメント、プロジェクトマネジメントなどのインプットが必要になるだろう。

一般的なビジネスパーソンにとっては、こうした「自分の知らない領域を含む」問題のほうが、「誰が考えてもな答えが出にくい問題」よりは、日常的に遭遇しやすいだろう。

また半年や数年といった長いスパンでの解決が必要なものではなく、１週間～数カ月程度の比較的短いスパンで解決をしなければならないため、緊急性がやや高く、ほうっておいて忘れるに任せる、といったあいまいな態度では避けては通れない問題でもある。

なのでこうした問題へ対応しなければならない方々も多くいるのではないかと思う。

当方は、そういった問題に遭遇した時に、何日も考え続け、夢にも出てきて、あるときに不意に解決策を思いつく、といった経験は何度もしている。

だいたい共通しているのは、思いついた解決策は、ほんとうに「当たり前」のことのように感じる点だ。

初めからその解決策を提示されていれば、「あーなるほど」程度ですんなり理解できてしまうものである。もちろん、やや発想の転換が必要なものもあるが、それほど奇抜な解決策ではない。

ここでは、こうした当方の知的体力に関する経験から、「自分の知らない領域を含む問題」に遭遇した時に、どのようにすれば比較的効率的に問題解決ができるのかを振り返っまとめてみたい。
(さらに…)