状態遷移のAction設計してます？

一ヶ月ブログ更新せずにほったらかしになってしまいました。
ほとんど”やるやる詐欺”ですな。

今日の記事は、前回の「状態って、どうやって抽出します？」の続きにもなります。

状態遷移図で設計した場合、Actionの設計ってどうしています？

むかしの私は、状態遷移図に処理の概要だけをちょこっと書き込み、そのまま実装で作りこんでいました。
そうすると、各状態Action同士の関係をコード上で考えることになってしまいます。簡単な振る舞いならば、それでも良いのですが、システム構造の上位の方で状態制御をしている場合、気がづけば下位の処理間が複雑に絡み合っていた... という困ったことになったこともありました。

『リファクタリングして、直せばいいじゃない』　とも思いました。
しかし、そもそもActionを設計していないので、リファクタリングするときにも、再考する機能構造を表したものが無かったのです。これじゃぁね．．．なるべくしてなった結果かもしれません

リアルタイム構造化分析を、再勉強したときに、「あ～、CFD（制御フローダイアグラム）の分析って、こういうときに有効なのね」と、後から理解しました。

前回Blog記事の状態遷移図と対となる、CFDがこの図です。

右上にある、黒棒が制御バーと言って、制御の集約場所を表します。この中に、状態遷移図が入っていて、このダイアグラム上の処理を統括していることを表しています。
このように、振る舞いと機能分割をそれぞれ別の図に表し、関係性を表せるのが、CFDの良いところです。
状態遷移のActionにあたる部分が、分割したプロセスとして登場します。
こうして、Actionを設計するモデルを残しておけば、下位の処理を検討するときにも、それぞれの機能分担の中で、重複するところ、統合して再構成すべきところ etc. を考えることができるわけです。
また、制御フローが状態遷移を起こすトリガになるため、どこで遷移を起こす要因を作っているかも、モデル図から見て取れます。

状態遷移図で設計する際、別の角度からActionを設計するモデル図を作る。
結構大事なところじゃないかな... と思っています。

今になっては、CFD というと、松尾谷さんの提唱する 原因流れ図（CFD：cause flow diagram） の方が有名かもしれません。 これとは、まったく別物ですので、ご注意ください。

※　関連記事：　Interface 2011年8月号

状態って、どうやって抽出します？

だいぶ以前から”書く書く”と言っていた、状態遷移図についての話が、Intreface誌の連載第8回でやっと載せました。

この記事でとりあげた例は、UARTの通信制御の状態遷移図です。
UARTで受信するパケットのフォームに応じた状態を設けて、一連の受信制御を行っています。

状態遷移図って、お馴染みの方は割と多いと思います。
では、その皆さんに質問です。状態ってどうやって抽出します？？
状態遷移図を良く使ってはいても、この本質的な問題って、結構難しいと思います。

この記事の本編では、こんなことを書きました。

同じ入力データであっても，事前に何があったかによってプロセスの対応が異なる場合があるのです．このような振る舞いのことを，「順次処理コントロール」と言います．この順次処理は，DFDだけでは表すことが出来ません．このような場合には，状態遷移図を用いてプロセスの振る舞いを捉えたモデルを作成する方が適しています．

今回の例（UART制御）や、画面遷移のように、状態遷移させるイベントの元が明確であり、それらをどう扱うかを切り替えるための”状態値”は割と考えやすいでしょう。
世の中にはそれ以外のモデルも沢山あると思うのですよね。
よく使われている電子ポットの例で考えると．．．
　● 保温中・沸騰中 といった、ユーザから見たシステムの稼動状況で状態を捉える
　● 蓋OPEN ・ CLOSE といった、モノの物理的状況（＝センサの感知状況）などを状態として捉える
というのがあります。

他には、どんな状態抽出の考え方があるのでしょう。
これって、前々から考えていることなのですが．．． 何か文献などあれば、知りたいなと思うのです。
ぜひ、皆さんコメントにて教えていただけると嬉しいです。

最後にクイズ
Interface誌掲載時と、上記の絵には違いがあります。さてどこでしょう？
（紙面を持っている方だけが分かる ... )
あっ、アクションが記入されていることではありませんよ。

※　関連記事：　Interface 2011年8月号

コード解析にDFDを使う？

最近すっかり、ブログすっかりご無沙汰しておりました。なんと、6月入って初ネタとは... いかんっすね。

さて、今日のお話はリバースモデリングネタです。
このブログでは、リバースのお話するのは初めてですが、実は前から、コードを読んでアーキテクチャ解析をするところに非常に興味を持っています。（．．．というか、ぶっちゃけお仕事も）

2011年6月17日(金)に、派生開発カンファレンス2011というイベントがありました。この講演プログラムの2番目に、
　「完全無知権プロジェクトにおける、変更要求仕様書の作成手法」
といった発表があったのです。
ここで言う”無知見”とは、派生開発元のプログラムについて知見がなく、開発ドキュメントもないような場合（例えば、外注で開発したソフトを扱う場合など）を指しています。つまり、派生開発する際のベースは、コードから読み解くしかないような場合です。
この発表では、コードを読み解く際の調査資料として、階層化DFDとAFD(*)、それとシーケンス図を用いるというものでした。

この方法では、コードから、最初に階層化DFDを作ります。
．．．ん？？　ここで疑問が．．．
コードを読んで、DFDは描けるのか？ コード上のオブジェクト間の関連性は、DFDになるのか??

発表資料をよく見ると、コードからデータフローを読み解き、変更要求仕様の階層化記述に使われています。
どうやら、コード上の構造を表すのではなく、コードを理解した結果の”機能”をDFDで表現したもののようです。
なんとなく、納得です。

DFDを使ったリバース方法については、XDDPの生みの親、システムクリエイツの清水さんが編み出したようです。
とっても気になる方法なので、今後も追跡してみたいと思いました。

(*) AFD：アーキテクチャ・フロー・ダイアグラム(?)
　　下記の本にて登場するモデル図のようです。私も、このモデル図については確認取れていません。
　　リアルタイム・システムの構造化分析　～リアルタイム・システムの仕様書作成手法～
　　Derek J.Haltley (著), Imtiaz A.Pirbhai (著), 立田 種宏 (翻訳)

「静的×動的視点で分析する」を書いてみました

ちょうど明日(5/25)発売のInterface誌7月号、いつもの連載記事でこんなサブタイトルの内容を書きました。
　　連載：強いプログラムを作るテクニックを学ぶ
　　サブタイトル：静的×動的視点で分析する。

UMLなどで、モデル図書いて設計しているひとには、「また、当たり前のこと。。。」と思われるのではないでしょうか。
そうなんです、ソフトウェアを設計するには当たり前なのですよね。

ソフトウェアの論理設計を考えるとき、よく機械や建築の設計図に喩えて説明されます（私も連載最初の方で使いました）。しかし、機械や建築物と性質的にまったく異なるのは、ソフトウェアは”動く”のです。そして、作った構造物（もしくは部品）はいつも同じ動きをするとは限らず、時間や環境などによって、まったく別の動きをすることもあるのです。
これって、実生活のモノにはとても喩えることができない特徴ではないでしょうか。
ソフトウェアの開発って、そんな小難しいものを作っているのです。
それを、頭の中だけで形作れるわけはない．．．と、凡人の私なぞは思います。

その”動く”という特徴を分析しなければ、ソフトウェアの設計としては片手落ちです。静的な側面、動的な側面をそれぞれ考え、両方が上手く一つの構造物で実現できるように考えるのが、設計なのですよね。

さて、最近ではソフトウェア工学書籍の出版数も増え、設計についての色々な考え方の本があります。UMLで静的モデルと動的モデル、それぞれの特徴に会った図が用意されたこともあり、静的×動的の両面を考えることも、だいぶ浸透してきていると思います。
しかし、本連載で取り上げている構造化分析・設計について、そのような説明をしている本を見かけないと思うのです。

この連載記事執筆の話をいただいたときに、「構造化で、静的×動的って話を絶対に書かなくては。」 と思っていました。順番に書き進み、第7回にしてやっとここに辿りつけた次第です。
この回は、何かの方法論に基づきというのではなく、自分の考えるままに書いたものです。
よければ、皆さんのご意見をお聞かせいただければ、嬉しいです。
私のtwitter ID：Yuko_Ski 宛てにコメントでもOKです。ぜひ、よろしくです。

p.s. その１
構造化設計で、動的分析を一緒に説明している本などあれば、ご紹介ください。

p.s. その２
今月は掛けませんでしたが、状態遷移についても、この後記事かする予定です。（．．．ってさりげに宣伝？）

DFDモデル お勧めできない例（その3）

前回に引き続き、DFDのアンチパターン紹介第三段です。

今回お見せするモデルは、Interface誌連載第7回のコラム用に当初書いたものでした。が．．．、共著者とレビューの結果、没ネタにしました。そのモデルがこれです。

さて、これはどこが問題か．．．
まず、目につくのは真ん中にデータフローの集中しているプロセスがあるところです。
入出力を制御する足回りのプロセスを置いて、変換処理部分は一つのプロセスにまとめてしまっている。これは、分析不足に多くみられる例です。

プログラムが複雑化して、絡み合ってしまうのは、複数の変換部（ここでは ＝機能）が同じデータを使用していたり、出力するために振る舞いによって必要なデータが変わったりするからです。つまりは、この真ん中の変換部が複雑化していきます。なので、このハリネズミ型の症状が現れたら要注意！
その中は、肝心な変換部が分析されておらず、その中にはたくさんの役割が隠されているでしょう。

もうひとつ、この図で軽く注意をしてほしいのが、”メイン”部という名称です。
プログラムを作っていると、『メイン関数があり．．．』 から考え始めてしまいます。でも、システムの担う役割で考えたときに、”メイン”って何ですか？？よ～っく考えてみましょう。
それぞれの役割分担が解るように、分析により分割・階層化を考えているのに、ＴＯＰレベルに何しているかわからないプロセスがドーンと構えているって、とっても変です。このところ続けて言っている ”ＷＨＡＴ” でちゃんと考え直してみましょう。

※　関連記事：　Interface 2011年6月号

DFDモデル お勧めできない例（その２）

# ゴールデンウィークで、先週更新をサボったので、今週は記事二つUPにしました。

またまた、DFDモデルで見たお勧めできない例です。
今回のモデルは、こちら！

何がお勧めできないポイントかといえば、プロセス間で受け渡しているデータ（青点線で囲んだ所）を見てください。
”ｘｘｘ完了” って具合のデータが行き来しています。

WHATでプロセスの分割だけを考えると、こういったデータは出てきません。
プロセスの役割分担を表すのではなく、実行順序を示そうとすると、プロセス間に無理やり何か渡そうとして、このようなデータが出てきます。

DFDでは、プロセスの実行順序は表しません。
あくまでも、各プロセスの役割と、プロセス間のデータの流れだけを表しています。
各プロセスは、その○に流れ込むデータを使って、○から流れ出るデータを出力する処理（役割）が成り立てば、他のプロセスとの実行順序がどうでも、 ”知ったこっちゃない” というのが、原則なのです。(*1)

この例のように、ｘｘｘ完了 とか ｘｘｘ指示 といったフラグっぽいデータ名が出てきたら、要注意です。
また、そのデータを入力されたプロセスの中を考えてみると、役割を果たすためにはそれは必要ない。たんなる起動のきっかけになっていることで多いでしょう。

繰り返しますが．．．
DFDは、フローチャートや、アクティビティ図ではないので、処理の順序は表しません。
この例のようなデータが現れてきたら、やはり HOW で考えてしまっている兆候なので、お気をつけくださいませ！

(*1)
どうしても、プロセス間の実行順序を表現したい場合があります。
そのために CFD（Control Flow Diagram）という表記法がありますが、これは難しいので今回は触れていません。

※　関連記事：　Interface 2011年6月号

DFDモデル お勧めできない例（その１）

今回のお話は、ちょっと前回のつづきになります。
前回のblog記事：WAHTで考える練習

未だ構造化設計の認知拡充を図る私としては、WHATのモデルとしてDFDによる分析モデルをちょいちょいご紹介しています。UMLが浸透した今となっては、すっかり忘れ去られた表記法かもしれません。でも、丸と矢印だけで、プロセス（処理のかたまり）の関係を表すこの表記法、とってもシンプルで好きなんです。
忘れ去られるのも悲しいので、コレ使いつづけてます。

さて、Interface6月号では、LEDキューブシステム(*1)のDFDによる分析モデルの例を載せました。
(*1) 開発対象物［LEDキューブシステム］の仕様については、こちらあたりをご覧下さい。
　過去blog：組込みソフトウェア開発者にとっての要求仕様書

このLEDキューブシステムを分析したコンテキストと、第一階層のDFD０はこんな感じになります。（雑誌掲載済み）

これらは、何度か描きなおして、出来上がった結果のDFDです。
この形におさまるまで、4, 5回は、機能の分割、グループ分け、再統合．．．を繰り返しています。

6月号には、もう一つアンチパターンとして、こんなモデルを載せました。

この例は、HOWで考えてしまった典型例なのですね。
どこがって．．． 左上にある 「100msタイマ割り込み処理」 があるところです。
これって、
　どうやってプロセスを順番に動かそう．．．、
　どうやってアレと、コレ同期させよう．．．
どうやって．．．（＝HOW) を考えないと、この タイマ割り込みドリブン な分割にはならないのです。

手続き型の言語によるプログラミングになれた人ほど、これはやってしまいがちです。

タイマ割り込みプロセスをDFDモデルに登場させないというのは、タイマ割り込みを使ってはいけないということではないですよ。
プロセス分割した結果、それらを動かす仕組みとして、タイマ割り込みを使うのはOKなんです。でも、タイマ割り込みはあくまでもプロセスを動かす仕組みであり、それ自身が要求仕様に紐付いた役割を担ったものではないということに、注意しましょう。

Whatによる思考に慣れない場合、まずこのタイマ割り込みドリブンを頭に思い浮かべずに、機能分割してモデルを書いてみる。　そんなところから、初めてみるのも、一つ手だと思いますよ。

※　関連記事：　Interface 2011年6月号

WHATで考える練習

プログラムの設計を勉強していると、”WHAT” と ”HOW” という言い方を、よく見かけます。
　WHAT ： 何を　　HOW ： どうやって
プログラムのアルゴリズムを考えるのは、”HOW”。 ですから、プログラムを作ると、必ずHOWは考えます。 しかに、それが ”何を” 実現する目的で作られているか、設計者がそこに注目して思考し、アウトプットしなければ、 WHAT は 見えるモノ として残りません。

連載の2回目の「”いきなりプログラミング”は危険だ」では、　”仕様との関係性が読み取れないコードは危険” といったことを書きました。　HOWでプログラムを作ってしまうと、全体の構造が ”仕様との対応が理解し難い入り組んだ構造（≒スパゲティ状態）” になりやすく、またそうなってしまっていることも気づきにくいのです。

仕様との関係が解るプログラムにすると何が良いのか？
　・ プログラム構造が理解しやすい
　・ 後々、そのプログラムは保守しやすい
　・ 再利用できる場所を考えやすい
2番目以後は、理解しやすいからこそ、使いやすいという二次効果になります。

「イメージ的には解かるけど、本当に？」と思われるかもしれません。
HOW で作ったプログラムと、WHAT で作ったプログラムがどう違うか、システムテスト以後で何か障害が見つかった場合の対策方法を例として考えて見ましょう。

● HOWで考えると．．．

出来上がったプログラムが、HOWで考えられた構造になっている場合、設計図は実装をそのまま絵にしただけなので、「コード見たほうが確実だよ！」といったことになりがちです。そのため、障害が起きたときにも、事象から「コードのどの辺が怪しい」と、開発者は頭の中で辺りをつけて、コードを直接調べているでしょう。

それで、問題箇所が見つかった後も、コード上で修正方法を考えます。そして、他にどんな影響があるのか、工程を遡って、全体を調査するような作業が必要になります。また、修正結果を確認するためにも、修正したコードから必要なテストがどれかを調査し、沢山のテストケースを実行しなければならなくなるでしょう。
といった具合に、調査・修正・確認 のすべての工程がコード基点での考え方になってしまいます。

● WHATで考えると．．．

WHAT で考え出来上がった構造は、仕様からどうプログラム構造に展開したか、さらにどうやって詳細に実装したかが、設計図に残っています。障害が起きたときにも、仕様の中のどれに絡んでその事象が起こっているかを考えれば、自ずと原因調査としてどこにプログラムのどこに焦点を絞るかが考えやすくなっています。

また、それで原因箇所が見つかれば、それに影響を受ける箇所も、またそれらの再確認のためのテストケースがどれかも、仕様を基点として、考えられるでしょう。
それは、WHATで思考した結果、仕様と実装とのつがなりが、設計図として残してあるためです。

ただ、これは開発時にも、保守時にも WHAT で考える癖がないと、途中で破綻してしまいます。
　・ アーキテクチャ設計時に ”WHAT：何を” の塊で作るように、考える。
　・ ”WHAT” で考えた結果を、設計図（＝ 仕様との関連がわかるドキュメント） に残す。
　・ 対策考えるとき、”WHAT：何を” するところに問題があるのか、考える。
　・ 修正するとき、”WHAT：何を” しているところを、どう変更するのか、考える。
　・ 修正確認は、 ”WHAT：何に” ついて確認が必要かを考える。
っと、くどくど書きましたが．．．
伝えたかったこととしては、「常日頃 ”WHAT” 基点で考える癖をつけて、よいプログラム構造が作れるようになりましょう。」　ということでした。

連載記事のほうは、今月発売の2011年6月号から、ちょうど DFD を使って WHAT でプログラムを分析する例をご紹介しています。よかったら、こちらも書店で眺めてみてください。

※　関連記事：　Interface 2011年2月号
　　　　　　　　　　Interface 2011年6月号

掲載落ちコラム：モジュール品質

Interface連載の「モジュール品質を知る」の回、ページの関係上で載せられなかったコラムがあります。せっかくですので、ここで公開しちゃいます。

～～ コラム：馬具取のつぶやき ～～
物造くんの大講演会(モジュール品質としての凝集度・結合度の解説)へのおつきあい，野比さんも読者のみなさんもお疲れさまでした．
モジュール品質は，話を聞けばなるほどと思うものの，実際に自分の設計で考えようとすると雲をつかむようなところがあります．そういう意味で野比さんの感想『わかったような気がしますが、モヤモヤした状態で～』は，誰にでもあてはまるのでないでしょうか．

まず大切なことは，モジュールの分割や組み合わせ方には良い悪いがある，難しい言い方をすると，品質を伴うということを知ることです．そして，良さの尺度には凝集度と結合度というものがあることです．
これを知っているだけで，知らないのに比べて設計に雲泥の差が出ます．その意味で，野比さんはすでに一歩スキルアップしているのです．

次には，１テーマに絞ってモジュール品質をよくしてみることに挑戦してみましょう．
たとえば結合度において，グローバル変数で結合させている方は多いのではないでしょうか．これを次の設計では，「完全グローバル変数レス」で行ってみるのは，よいテーマです．変数へのアクセスタイムが問題になるようなことは実際にはまれですし，グローバル変数をなくす設計をすることで，副次的にモジュール分割をよりよい方向に進めることができることでしょう．
～～～～～～～～～～～～～～～～

「完全グローバル変数レス」に一気に挑むのは、少々ハードルが高いですね。最初は、自分の担当範囲で一つ、二つ、選んでグローバルからの解消を試みてみましょう。
その際は、次のことを考えてみてください。

　(1) その変数の意味はなに？
　　　　→ たまに、デバッグ時の確認用に作られた変数などが残っています。
　　　　　　それらは、削除してしまいましょう！

　(2) 何のためにグローバルに置かれているの？
　　　　→　どうしても、グローバルにする必要はあるのか。
　　　　　　　理由が説明できなければ、グローバルレスにチャレンジ！

　(3) その変数に、もっとも強いかかわりを持っている処理はどれ？
　　　→　強いかかわりを持つ処理があれば...　
　　　　　　　　その処理の管理下に変数を置く。
　　　　　 複数箇所から、同等のかかわりの強さで使用されていれば...
　　　　　　　　変数の管理処理を置く。

以上のようなステップで、検討し、変更をしてみましょう。

ここで一つ注意！！

変更結果が元通り動くかどうかのテストが、絶対・絶対・絶対に必要です
グローバル変数に絡んでいたモジュールのテスト方法を予め確認しておきます。それから、修正を行うようにしましょう。これは、鉄則です。「このぐらい大丈夫...」 という安易な気持ちがデグレードにつながります。このちょっとひと手間を惜しまずに、チャクチャクと改善ステップ踏みましょうね。

いいコード残して、いいソフト屋になる。
後で振り返ると、その道のりが、結構自分の自信になりますよ。きっと

※　関連記事：　Interface 2011年4月号
　　　　　　　　　　Interface 2011年5月号

USDMで仕様書を書いてみた

「強いプログラミングを作るテクニックを学ぶ」の連載3回目で、『要求分析の重要さと難しさ』というサブタイトルで、要求仕様の分析について取り上げました。その中で、USDM(*)という仕様書の表記をご紹介しました。
　※ LEDキューブシステムUSDM版仕様書　>> Download ： specofledcube_specusdm_v1a.xls

このUSDM版仕様書をご覧になった皆さんは、どう思われたでしょう？
私も当初は、ドキュメント形態として重くて面倒だな．．．と思っていました。その後、いろいろ試す中で、USDMを使うのも悪くないなと思うようになりました。その理由を、3つばかりご紹介しておきます。

【こんな時に、USDM作ってみてよかったと思った】

(1)　仕様理解のために使う
連載本編でもこの方法をご紹介しました。
以前から、仕様書を読んでQ&Aシートを毎回作っていましたが、それでも理解の漏れ、勘違いはあります。USDM表記法に則り、理由を考えて要求・仕様を埋める。Defaultや、異常系など、各要求項目に対して決まったルールで仕様を確認する。などにより、抜け漏れ、勘違いのフォローができました。
... 気が向いたら、Interface誌 3月号で詳細は読んでみてね。

(2)　仕様に対する確認用に使う
実は、これが一番のおすすめポイントだと思ってます。
ご紹介したUSDM仕様書、CQ出版さんのサイトからダウンロードすると、各仕様項目のところに3つのチェックボックスが点いている事に気づいた方いらっしゃいますでしょうか？　これは、後工程での確認用に作ったものなのです。

●仕様の確認で1コ目にチェック
要求元と仕様の確認ができたところで、確認済みのチェックを入れます。仕様未定の部分があれば、次工程に進めるために必要な仮仕様を書いて、チェックボックスには“未”の印をつけておきます。そうすることで、この仕様に絡む箇所は、後で仕様変更がでてくる可能性があることが見て取れます。

●設計レビューで２コ目にチェック
（基本設計などのレベルではなく、）実装目前の設計レビューでチェックを入れます。
これについては、” (3) 保守・派生開発時のベース資料 ”↓ のほうで詳しく説明します。

●テスト設計で3コ目にチェック
どの仕様に対して、テスト設計してテストケースを作成したかを確認した時点で、チェックを入れます。

(3) 保守・派生開発時の資料として使う
一旦作ったシステムも、保守・派生開発時には、システムの設計を知るための資料が必要です。それを、このUSDM仕様書に情報を付加して使えるようにしようというものです。

仕様項目の横に、設計した結果、どこでその項目が実現されているのかを、印を付けていきます。
つまり、XDDP(**)で言うところのTM（Traceability Matrix）を作ってしまうのです。設計段階でこのマトリクスを作ってしまえば、後の保守・派生開発時には、これがそのまま影響範囲分析、変更設計のための調査資料として使えます。

また、この方法で仕様と実装の関連を残していくと、凝集度の悪い設計箇所があれば、一つの機能に対し沢山の実装箇所に印が付くことになります。そういった目線で、設計結果を確認することで、設計品質を確かめるためのレビュー資料としても使えます。

USDMの仕様記述は、確かに大変です。
折角手を掛けた仕様書ですから、やはり2度、3度これを使いまわさないと、作った効果は薄いと思います。

．．．とはいえ、現状のUSDMでは、未だに気になっているところもあります。
　・EXCELはやっぱり使いにくい
　・仕様項目間の依存関係が表せない
その辺は自作でツールをつくるなど、改善策を考える必要がありそうです。

しかし、今手持ちのツールですぐに試せる方法です。設計品質をあげるにはどうしたら．．．　っと、手をこまねいて悩んでいるのだったら、お試ししてみるのもありだと思います。

最後に、
Interface誌に掲載するに当たり、USDM版仕様書の作成についてご指導いただきました清水吉男さんに感謝いたします！！　ありがとうございました。

(*) USDM ： (Universal Specification Describing Manner)　抜け漏れしにくい仕様書の表記法
　　　関連書籍　『要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?』
(**) XDDP： （eXtreme Derivative Development Process）　派生開発に特化したプロセス
　　　関連書籍　『「派生開発」を成功させるプロセス改善の技術と極意』

※　関連記事：　Interface 2011年3月号