処理の流れ図（フローチャート等）について、再考

先日、「フローチャート使用に、賛成？反対？」というタイトルで、記事を書きました。
それを見てくださった方から、twitter でこんな意見をもらいました。

『PS工程で使用する一つの手法としてフローチャートを使うのはありと思います。
PS工程で処理の流れを日本語で書いてPGではPSの内容を落とし込むだけです。その作業ができればどんな手法でもいいのかなと思います。』 （tweet原文を引用）

これについて、少し補足しておきましょう。
こちらの会社では、ソフトウェアの開発工程を次のような略称で呼んでいるようです。
　・SS工程 ： システム構造設計
　・PS工程 ： プログラム構造設計
　・PG工程 ： プログラミング
　・PT工程 ： プログラムテスト
　・IT工程 ： 結合テスト
　・ST工程 ： システムテスト
つまり、上記のtweetは、プログラム構造設計の工程で”処理の流れ”を設計書として作成するのには、フローチャートも有用ではないか。ということです。
なるほど、この方の仰る状況もわかります。

設計者と、コーディング以後を受け持つ担当者が異なる場合、しばしばこのような現場が見受けられます。
なぜ、このような現場では、処理の流れを設計書として渡す必要があるのか。
それは、次のようなケースだと考えられます。
　case 1. コーディング以後担当者のスキルが心配
　　　　担当者が、まだアルゴリズムを自作する十分なスキルになっていないため、
　　　　そのままコーディングできるレベルの詳細な処理の流れを設計書として渡す
　case 2. コーディングレビューがしやすいように
　　　　外部へ委託する場合など、コードレベルでの確認が必要な場合
　　　　依頼内容と、成果物（コード）が比較しやすいように、処理の流れを図式化する

しかし、いずれのケースでも、作成した設計書（流れ図）が使われるのは、PT工程まででしょう。その後の工程や、後の運用・保守においては、参照されることはないのではないでしょうか。

フローチャートなどで、詳細な設計書（処理の流れ図）を作成する場合、「それを作成する効果」 を、チーム内で共有しましょう。
それが使われる理由を知らずして、ただ決まりだから... で作成していては、作成する側は疲弊してしまい、受け取る側もコードへの変換者のままで成長が見られない、と思います。
今の組織の状況と、処理の流れ図を作成する意図を、皆で理解することが大切です。
そうすることで、組織として成長し、開発現場の改善への繋がることになるからです。

今回も最後に注意事項。
フローチャートのような処理の流れ図を使う場合でも、次のドキュメントは別途必要です。
　(1) より広い範囲の構造が分かる設計図
　　　　その部分が、全体の中の何処に位置し、他とどのような関係を持つのか がわかるもの。
　　　　これは、設計を管理するうえで必須です。
　　　　トップダウンで設計する場合なら、本来こちらがあり、小さな範囲の流れ図が書かれるべきです。
　(2) 担当範囲の仕様を示したもの
　　　　流れ図では、具体的なアルゴリズムしか示せず、その部分の仕様は表現できません。
　　　　　　何が入出力であり、どのような機能を実現するか。
　　　　その部分についての仕様を、明確に定義しておきましょう。

（前回からの繰り返しになりますが...）
フローチャートなどの処理の流れ図は、その性質をしり、適材・適所、適宜、使用して欲しいものです。

「社内の決まりだから...」という事だけで、ひたすら労力を使うようなことがないように、この点は節にお願いしたいものです。

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

「組込みソフトウェアギルド」への想い

2011年2月14日、有志６人によって、組込みソフトウェアギルドというグループを設立し、活動を開始しました。

このグループは、組込みソフトウェア技術者支援の相談窓口となるべく立ち上げたものです。
”ギルド” は、会社のように収益を共にする団体ではありません。
あくまでも、ギルドの活動目的 「問題解決による社会貢献と所属するメンバーのスキルアップ」 に賛同する、メンバの集まりです。
メンバは、それぞれソフトウェア技術者としての経験を積んだエキスパートです。ギルドへの相談は、個々のメンバがこれまでの知見から相談に対応するだけでなく、ギルド内での相互協力を仰ぐことで、互いの技術を補間することで、より適切な対応を行っていきます。

組込みソフトウェアギルドについて、設立趣旨、メンバ構成などは、
下記のサイトにありますので、詳しいことはこちらをご覧ください。

組込みソフトウェアギルド
　https://sites.google.com/a/embeddedsoftwareguild.com/www/

会としての総意はWebSiteをご覧いただくとして、以下には私個人としての想いを綴ります。

ギルドのメンバ紹介にもありますが、私自身は組込みソフトウェアの開発現場に十数年おりました。
大きな会社ではなかったため、体系的な教育や、整った開発プロセスがない現場でした。
その中で、新しい製品開発を続けていくためには、世の変化に合わせて要素技術（ネットワーク系や、デバイス制御 etc.）の習得、実装に追われ、プロセスの改善や、設計・テストなど開発技術の向上には手を付けられずに走り続けていました。正直、当時はそれがいっぱいいっぱいだったのです。

その後、転職をすることで開発支援する側に回り、広い世界を見る機会を得ました。
すると... 大きな会社でなくても、基本的な開発技術を習得し、しっかりしたプロセスの見地を持って開発を回している会社はあるのです。（また、大きな会社であっても、会社全体ではなく一部グループのみで、改善を行い成果をあげているところもあります。）

おそらく、自分が現場どっぷりの頃、そういう話を聞いても、
　話は分かるけど、なかなかねぇ．．　（時間がない、人などリソースが不足）
　自分ひとりじゃ、難しいよ　（相談する人、もしくは一緒に改善に挑む人がいない）
　なんだかんだ言って、大手はバックアップがしっかりしてるから～
という後ろ向きな感想を持ちつつ、実践には持ち込まなかったでしょう。

確かに、自力で改善するため、すべての技術を学び、プロジェクトメンバにも情報共有をはかり、プロジェクトで実践する。そんな、スーパーマンみたいなことはなかなか出来ません。
しかし、世の中には（ちゃんとした）”コンサルタント”という人たちがいて、その現場の事情を知った上で、できるところから改善策をアドバイスしてくれる人たちがいます。
事実、アドバイスを受けて、成功しているところは、いくつもあるのです。

このような成功の事例を知っても一つ問題が．．．
コンサルタントにアドバイスを受けるといっても、お金がかかる。
それも、高いお金が。

実は、お金をかけなくても、自分がコミュニティに飛び込むと、悩みについてアドバイスしてくれる人がいたり、自分の現場に合うような改善アイテムを教えてくれたりすることはあります。
ただし、そこまでたどり着くには、自分の信頼を得るためのコミュニティ内での活動が必要です(コミュニティはTakeだけではないですから)。 また、会社がオープンなコミュニティを嫌ったり、自身の時間が取れなかったりするため、その信頼獲得までが、また大変だったりします。

語れば、語るほど、次から次ぎへと問題にぶち当たります。
では、どうしたら前に進めるのだろう。。。 と、ここ何年か思っていました。

そんな矢先、ギルドの話を持ちかけられました。
このギルドの考えは、前述の話に出てくるいくつかの障壁
　・お金に対する問題
　・問題発生時の相談相手 （一回だけでなく、継続的な）
　・時間の問題（アドバイスを受けた＝ギルド成果になるため他に時間を使わずすむ）
を、いくらか下げられると思いました。

この活動に加わることで、開発現場で頑張っている人たちの、一助ができるかもしれない。
また、成果として”役に立った”という対価を得られ、自分自身にとっても、次へのモチベーションがアップできます。
そう思い、ギルドメンバとして参加して頑張ってみよう！ と思った次第です。

組込みソフトウェアギルドは、まだ目を覚ましたばかりです。
これから歩み始め、その軌跡を積み重ねていきます。
ソフトウェア開発の現場の役に立てるよう、小さな相談でも真摯に対応していきたいと思います。

組込みソフトウェアギルド お見知りおきください。
　よろしくお願いいたします。　

フローチャート使用に、賛成？反対？

最近 Twitter で、知り合いがこんな事をぼやいていました。

『フローチャートって最初に教える図表として本当に正しいのか？個人的にはDFDの方が絶対いいと思う．
だって何を処理したいのか整理せずにどう処理するか考えるのって順序違うでしょ．だからコード書いたときにI/Fがおかしかったりデータ構造がおかしかったりして書きなおすハメになる．』

私もその通りだと思います。
Interface誌の連載２回目「"いきなりプログラミング"は危険だ!」でも、フローチャート（下図）を載せ、似たようなことを書きました。

ここで、改めてフローチャートの良し・悪しを考えてみました。

■ 良いところ
(１) なんといっても、認知度が高い。一般的な業務フローとして使用されていることも多く、プログラミングを知らない人でも理解できることも多い。
(２) 処理の順序を表すものであり、アルゴリズムが図で表現できる。

■ 悪いところ
(１) ある一つの処理の順序しか表せない。そのため．．．
　-a) プログラム内に複数並行に動く処理がある場合、他の処理との関係が示せない。
　-b) また、プログラム全体像を、俯瞰したものにしにくい。
(２) アルゴリズムの表現であるため、その処理の意味・役割が見え難い。

組込みソフトウェアの開発で考えた場合．．．

シングルタスク（割込みもなし）で動くようなシステムがあれば、フローチャートでプログラムが表現できます。
しかし、そのようなシステムは極々わずかでしょう。
ということは、殆どのシステムは、フローチャートだけでは、表現できないということです。

ソフトウェアを設計する場合、
　・いくつのタスクが生成され、どのタスクが何の役割を担っているか。
　・タスク間は、どれとどれが関係し、どのようなインタフェースを持つか。　
などを重視すると思います。
これらが表現できないと、設計書としては役割を果たせないのです。その意味では、フローチャートは不適な表現です。

設計時に重視する、上記の点がフローチャートには書かれておらず、それらをプログラムコードに噛み砕いた状態で描かれている。そのため、前述の”ボヤキ”にもあるように、書き直すはめが増えてしまうのです。

と、ここまで、フローチャートは使えないということを主張してきました。

かといって、フローチャートの使い道が無いなんてこともありません。
前述の通り、フローチャートは処理手順の表記図なのです。つまりは、アルゴリズムがわかり難いところは、フローチャートを使用する意味も出てくるでしょう。
例えば、ハードウェア周りのドライバのような、複数のステップがまとまって一つの意味をなすようなものは、コードより少し抽象度を上げた処理を、図に示すことで理解しやすくなります。

だたし... 絶対にやめてほしいことは、プログラムコードそのままを、フローチャート図にすることです。
コード読むのと何が違うのでしょう。　こればっかりは、図にする意味は無いと思ってます。

ちゃんと、フローチャートの性質を知り、必要な場所にだけ、使うことにして欲しいものです。

最後に、
処理手順を示す図としては、フローチャート以外にも、幾種類もあります。
図としてより軽く書けるものもあります。
また、UMLのアクティビティ図も処理手順を表すものです。世界標準であるUMLでかけるのですから、今の認知度だけでフローチャートを選択するのは、あまり良い選択肢ではないかもしれません。

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

オブジェクト指向と構造化 お勧めは？

「構造化設計にこだわるわけ」という記事で、誤解を招くような事を書いてしまいました。

問題・その１：オブジェクト指向＝クラスで設計　という書き方をしてしまった
この記述は誤りです。ゴメンナサイ
クラス設計はオブジェクト指向設計の一部でしかありません。
この詳細は、元記事のトラックバックにもある、後悔^H^H公開日記：別館 ： 組込みでのオブジェクト指向的思考で、ご指摘および、フォローの説明まであります。ぜひ、併せて読んでみてください。
（組込み屋さんにとっては、なるほど．．．　という内容だと思います。）

問題・その２：構造化設計にこだわるのは、オブジェクト指向設計の否定派だからではない
私の自身は、オブジェクト指向設計も推奨派です。
プログラムに馴染みが深い人にとっては、最初は構造化による手続き型の考え方の方が馴染みやすいと思っています。しかし、できればオブジェクト指向の方が、人が理解しやすいソフトウェア構造が作りやすく、「強いプログラム」にしやすいと思っています。

それならば何故、構造化設計を取り上げたか．．．
これを説明するために、オブジェクト指向と構造化についてもう少しお話しましょう。

オブジェクト指向では、振る舞いや、規則など、同じような特徴を持ったモノの集合を捉え、その共通点で抽象化したオブジェクトを考えます。ソフトウェアの設計では、システムの構成要素として、色々な特徴を持ったオブジェクトを抽出します。そして、それらオブジェクトが互いに何らかの関係で繋がることによって、システムが実現できるという考えです。
この考えは、人の日常に照らし合わせるとわりと自然な考え方です。

例えば、小さなお弁当屋さんについて、考えてみました。

■　オブジェクト指向で、お弁当屋さんをモデル化する
”調理員”と、”販売員”という、別々の役割を担った人がいます。販売員がお客さんの注文を聞き、注文に応じた”お弁当”を調理員が作る。出来上がったお弁当は販売員が売り、お客さんからお金をもらい、”売上”がたちます。また、売上から”食材”が購入することにより、次のお弁当が作れる。
これを一通りのお弁当屋さんシステムとします。

上記の説明の斜線にしたところが、オブジェクトだと考えます。それらは異なる特徴を持ち、オブジェクトどうしが、互いに何か関係をつくることで、「お弁当屋さん」という一つのシステムが成り立っているのです。

こうして考えると、あまり難しくは感じられないのではないでしょうか？
では、同じお弁当屋さんの例を、手続き型の思考でモデル化してみるとどうなるでしょう。

■　手続き型で、お弁当屋さんをモデル化する

お弁当屋さんの登場人物である、販売員と調理員。それぞれの仕事と、その実行順序を考ると、次のようになります。

・販売員さんの仕事
お客さんの注文を聞いて調理員に依頼　→　出来上がったら、お弁当をお客さんに渡す　→　代金をいただく。

・調理員さんの仕事
注文を聞いたら、お弁当を作る　→　出来上がったら、販売員に渡す。
（お弁当作りとは異なる時間帯に）翌日の営業用に、売上金から、食材を買い求める。

そして、二人の間をいつ、どのようなモノ（物理的な物、情報）が行き来するかを考えて、全体のシステムが表現できます。

二つのモデルを見比べてみてどうでしょう。
手続き型のモデルには、各担当の詳細な仕事が順序だてて明記されています。この仕事の内容は、オブジェクト指向型モデルには登場しません。
オブジェクト指向のモデルでは、仕事の内容は、オブジェクトの振る舞いとしてオブジェクト内部に定義されます。
モデル図だけを比べると、オブジェクト指向型のモデルの方が、シンプルで解りやすくないでしょうか。

何かシステムの概要を捉えるとき、詳細な処理や手順は隠して、モノどうしの関係性で考えた方が、人には理解しやすいのです。
しかし、ソフトウェアを作ることを考えると、そうはいきません。コンピュータに向け、何を、いつ、どうやって片付けるか... という細かな指示をしないといけません。プログラム作成に慣れた頭では、このコンピュータ向けの思考が設計時に現れてくるのです。
言い換えれば、コンピュータのために、かえって難しい考え方をしているのです。

このように、オブジェクト指向はシステムを設計する上で、本来の人の思考に近い技法です。
けれども、それをソフトウェアの実現手段として考えるには、慣れが必要でしょう。

とは言え．．．
現場にいるソフトウェア開発者にとって、この考え方に慣れるまでトレーニング時間を割いて、その後に設計をするなんて、悠長なことは言っていられません。常に、製品開発は動いているのです。
そこで、まず設計技法に取り組む第一ステップとして、お勧めするのが構造化設計です。

構造化設計は、処理を階層構造化して、概略的な処理の塊から、詳細な処理へとブレークダウンしていく考え方です。

先ほどのお弁当屋さんの例でいえば、手続き型モデルで考えた、販売員さんの仕事、調理員さんの仕事を、プログラムで実現できる細かな粒度にまで、徐々に噛み砕くような設計を行います。
はじめは、システム全体はいくつかの概略処理で捉える。それを、より具体的な処理への分解していく。分解したものを、動作できるように適切に組み立てて、プログラムとして連結する。　ということを、この技法では考えていきます。
構造化設計で唱える考え方は、多くのプログラマが考えてきた、手続き型思考の整理の仕方といっても、よいかもしれません。

まとめると．．．
　　強いプログラムを作るためには、オブジェクト指向設計はお勧め。
　　しかし、オブジェクト指向に取っつき難いと感じた方は、構造化設計からはじめることがお勧め。
と思います。

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

構造化設計にこだわるわけ

Interface誌の連載「強いプログラムを作るテクニックを学ぶ」では、設計技法として構造化設計を取り上げています。
第一回の本編でも書きましたが、構造化設計は30年以上前に提唱された、設計技法です。そのころに比べるとソフトウェアの稼働環境が大きく変わっており、プログラムは大規模化し、プログラミング言語も多様化しています。その環境を考えると、構造化設計は確かに古い設計技法です。

クラスというデータとメソッド（処理）をパッケージ化して実装できるオブジェクト指向設計に比べ、構造化設計はモジュール(処理）の関係だけでプログラムを構築します。
実は、ソフトウェアの部品（一部機能）を独立性高く作ろうとすると、オブジェクト指向を用いた方が、作りやすいのです。

ではなぜ、オブジェクト指向を取り上げずに、今なお構造化設計にこだわっているのか...
その理由は、クラス設計には、思考の転換が必要で、ハードルが高いと感じているからです。

設計技法を勉強せずに、とりあえずC言語でプログラムを書いていると、どういう順番で処理をしていくかという手続き型の思考になっています。その従来の考え方から、オブジェクトという塊の連携でプログラムを構成するという考え方へのシフトは、なかなか難しいものです。
しかし、この考えが難しいからと言って、手をこまねいていては、プログラムは改善しません。

世の情勢としては、ソフトウェアの開発効率をよりよくするために、既にいろいろな改善が試みられています。
プロダクトラインや、派生開発のXDDPもその一手段です。
しかし、それらのアプローチをとるためには、設計・テスト・プロセス管理について、しっかりした基礎力がなければ成功はないのです。

そこで... 手続き型の思考でも取りつきやすい構造化設計技法にて、まずは開発の基礎力をまずは向上させる。それが急務ではないかというのが、私の考えです。

下に、構造化設計の三大成果物の絵を添付します。
この絵に、皆さんの手元のプログラムを当てはめてみてください。

構造化設計技法は、手続き型の考えで、いかにプログラム構造を構築するかを提唱しています。
オブジェクト指向に比べると、そのハードルはだいぶ低くなると思います。

ソフトウェア開発の改善を少しでも早く進めるために、まずは構造化設計技法を身に着け、ソフトウェアの構造の改善に取り組んでほしい。そう考え、構造化設計を取り上げています。

※ 図中、成果物１の四角はモジュール（関数など）を表し、矢印はモジュール間の呼び出し関係を表しています。

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

プロダクトラインと派生開発（その２）

ソフトウェアプロダクトライン（以下、SPL）と、派生開発のプロセスXDDP（eXtreme Derivative Development Process）についての話の続きになります。

すこし前のことになります。
「SPLとXDDPによる多品種開発の品質と生産性の向上　～一見矛盾する2つのアプローチの関係をどう捉えるか～」
と題したセミナーが行われ、参加してきました。

はて、疑問です。この二つは対立軸にはないと思われるからです。
その疑問は、最後のパネルディスカッションでも取り上げられ、4名のパネラーの皆さんともに、やはり対立するものではないというコメントでした。

その中で、九州大学の中西先生が、次のように二つを対比してまとめられています。

　

【SPL　と　XDDP　の比較】

SPL	XDDP
パラダイム	メソトロジ
全体理解を志向	部分理解を容認
組合せを志向 (変化点の抽出が重要)	摺合せの容認 (変化点の概念が希薄)
計画駆動	変化駆動
アーキテクチャ駆動	アーキテクチャ希薄

なるほど、二つの考え方の違いがよく分かります。

SPLは、トップダウン・ボトムアップ2種類のアプローチがありますが、ポイントは全体志向であることでしょう。かならずシリーズ製品全体の仕様を考え、計画的な開発を行う。全体を通して変わらぬアーキテクチャを構築する事で、部分部分の変化点で個別の製品に対応する。そこは、SPLの譲れない考え方です。

対して、XDDPは完全にボトムアップのアプローチです。そして、派生開発の差分となる部分に関連したところだけの部分理解を容認しています。
実は、ここがSPLよりもXDDPの方が取り組みやすいところであり、危険なところであると思います。

既存製品のソフトウェアを隅々まで理解するということは、とても困難で、時間のかかる作業です。その点、部分理解容認というこの手法は、取り組み易い手法といえます。
しかし、製品としてリリースするからには、変更に抜け漏れや勘違いが混入してはいけません。つまりは、部分理解をする際、どこまでを理解すればよいかが、肝になります。その点について、強力な対策が示されていないため、レビューなどによってその点に十分なチェックが必要となるでしょう。

システムクリエイツの清水氏は、二つの関係について次のように言っていました。

SPLは2階建て構造であり、SPLに取り組むには次のような前提が満たされていることが条件である。

【SPLの前提】
　　・SPLに耐えるアーキテクチャ技術はあるか
　　・再利用性の高いモジュール技術はあるか
　　・劣化しにくい最初からの設計技術はあるか
　　・劣化しにくい変更技術はあるか
　　・計画通りに作業を進めることが出来るか

これら前提が満たされていなければ、SPLは遠い存在であり、実施できない。
また、XDDPによる派生開発を乗り越えられないようでは、SPLは成功しない。XDDPは、これらの前提を身に着け、2階（SPL開発）に登るための梯子の役割ともなる。

なるほどと思いました。
アプローチは異なるものの、いずれの方法論にも、ソフトウェア工学の基礎となる設計力、プロセス構築等は必須である。これらを習得せずして、SPLでもXDDPでも、開発の成功はありえないといことです。

ソフトウェア工学の基礎を学習し、XDDPという方法論を用いて日々学習を実践に活かしていくことで、将来SPLへの道筋が見えるのではないかと思いました。

プロダクトラインと派生開発（その１）

唐突ですが．．．
ソフトウェアプロダクトライン（以下、SPL）という、近頃流行の言葉をご存知でしょうか？
Software Product Line Engineeringの和訳本(通称：黒本)では、次のように書かれています。

～定義1-3：ソフトウェア製品系列開発（Software Product Line Engineering)～　（p14 より引用）
ソフトウェア製品系列開発とは、プラットホームと大量個別生産を用いて
ソフトウェアアプリケーション（ソフトウェア集約システムおよびソフトウェア製品）を
開発するパラダイムである。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

難しい表現です。

ここで引っかかるのが、製品系列開発と、パラダイムという言葉です。

旧来の製品開発では、個々の製品について、リリースする順番に開発していました。類似製品や、シリーズ製品の場合は、元となるシステムを参考にして、新/旧製品の差分を考えて作ります。
これに対し、SPLでは製品系列として、ひとまとめにして開発を考えるのです。製品系列を通して要求分析が行われ、シリーズで共通となるところ、差異になるところを見極めて開発するため、非常に戦略的かつ、効率の良い開発が見込まれます。

しかし、上記の引用にもあるように、SPLはパラダイムなのです。
SPL本に詳しく手順が示され、それを遵守して実行すればよいという方法論ではありません。
従来の製品開発プロセスが、上手く回っておらず、開発後半のテスト工程で止め処も無く出てくるバグを対策しているようでは、とてもじゃありませんが、すぐに取り組めるものではありません。
全体を見通してプロセスを考える力があり、システムのアーキテクチャがしっかり設計できる力がなければ、とてもじゃありませんが、このパラダイムシフトには乗れないのです。

SPLについて、だいぶ乱暴な説明になっております．．．
この説明はここまでとし、詳しく知りたい方は、上記の本をご覧ください。

さて、ではSPLにすぐ乗れないからといって、傍観しているだけでよいのでしょうか？？？
それでは、世の開発スピードから取り残されてしまいます。
なんとかシリーズ開発を、今より効率よく開発が行えないものかと考えるでしょう。

そこで、もう一つご紹介するのが XDDP（eXtreme Derivative Development Process）という、派生開発の方法論です。

派生開発という言葉は、ベースとなるシステムがあり、それに対して追加・変更・削除を行うことで、新しいシステムを開発するということです。まさに、前半で言っていた旧来のシリーズ製品開発そのものです。
XDDPでは、この派生開発を上手くまわすためのアプローチ方法を具体的に提案しています。
システムクリエイツ社の清水吉男さんが生みの親で、その詳しいことは、「「派生開発」を成功させるプロセス改善の技術と極意」という本にも紹介されています。

この方法論は、
　(1) 既存部分を正しく理解し
　(2) 派生開発で行う差分の仕様を見極める
　(3) 差分について設計する
という、きわめて当たり前のことをいくつかのツール(ドキュメント)を使って、手順まで定義しています。
かなり地道なやり方ですが、これを実施することで開発効率の改善が図れるのではないかと思います。

プロダクトラインと派生開発、一気にさわりだけ紹介しました。

組込みの現場は、よりスピードアップが今度も必要になると思っています。
そのためには、今までどおりの開発をしていては追いつきません。何らかの変化が、現場にも求められるでしょう。
開発現場が変化するためには、SPLとXDDP、どちらも有効な考え方です。

この話は、一度で書ききれないので、また続きを書きます。

※ 現在は私自身も、XDDPの方法論が広められるよう、派生開発推進協議会（AFFORDD)の運営委員として活動しています。

「強いプログラム」にこめられた意味

Interface誌で連載記事を書き始める前、決めていたテーマは、組込みソフトウェア開発ビギナ～初級者向けに、設計することの大切さを伝える記事にしたい。ということのみでした。

連載の内容を煮詰めるなかで．．．
さて、この記事で目標とするソフトウェアはどんなものだろう。と考えてみました。その結果として連載タイトルとしてつけたものが「強いプログラム」です。

では、ココでいう「強いプログラム」とは何を意味しているか、そのヒントは連載１回目のコラムにあります。

～Interface 2011年1月号　記事より転載～
コラム１：動くことと、使えること
　ソフトウェアに限らず，昔から技術の世界では，「動く」ことと「使える」ことは別だと伝承されてきました．動くソフトウェアを作るのは，時間とパワーさえかければできます．一方で，使えるソフトウェアを作るのは困難です．ソフトウェアの使えるという言葉には二つの意味があります．それは「安心して使える」こと，もう一つは「次もまた使える」ことです．
　ここで，安心するのもまた使うのも，主語は他人であるということも重要です．未来の自分も他人です．ですから，他人に対して，使える根拠を示せる必要があります．要求仕様から頭の中だけで思い描いたものをコードに落としても，誰にもそれが正しいと説明することはできません．
　コンピュータは素直な装置ですから，プログラム・コードの通りに動作します．ですから，基本的に「コードはすべてを物語り」ます．しかし，残念なことに，「ヒトはコードからすべてを読みとれない」のです．他人が安心して使えるためには，ヒトが理解できるものを設計情報として残すことも必要です．
~～～～～～～～～～～～～～～～～～～

このコラムにあるように、後々安心して使え、次もまた使えるプログラムなどを、”強いプログラム” という表現にしてみました。

それならば 「使えるプログラム」 の方が、適切なタイトルではないかと、思われることでしょう。
では何故、「使えるプログラム」 ではなく、「強いプログラム」という言葉にしたか．．．

実は、このタイトルを最初に付けたのは、編集担当のT嬢です。
私の方では、連載タイトルが決められず、”よい設計”とか、”理解しやすいソフトウェア” などの言葉が浮かんでいました。適切なタイトルが浮かばないまま、原稿を読んだT嬢が、バシッと付けてくれたのが「強いプログラムを作るテクニックを学ぶ」というモノでした。
それを見て、 「これは、いいかも！」 と乗っかったわけです。

設計して、品質の高いソフトウェアを目指す。
仕様や環境の変化に対応しても崩れにくい、強い基本設計を持ったプログラム。
たとえ不具合が混入しても、すぐに患部を見つけ出せる強い体質のプログラム。
そんなことをイメージして、「強い」という言葉を最終的に選びました。

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

ブログ始めました！

ブログ開始に当たって...

2011年1月号より CQ出版社のInterface誌において、「強いプログラムを作るテクニックを学ぶ」という連載を書かせていただいています。

この記事は、これまで私が組込みソフトウェアの開発現場や、各所での技術者教育に係わらせていただく中で、若い方々にも知っていて欲しいと思うことを、書き綴っています。
”若い方々にも．．．”という言葉の通り、この記事には目新しいことはあまり出てきません。2, 30年前から、ソフトウェア設計に真面目に取り組んでいた方々からみれば、”何を今更．．．”ということが多いでしょう。しかし、ソフトウェア設計の基礎的な話は、今更な事かもしれませんが、今でもな事が多いのです。

記事の方は、毎回4～6ページに収められるように書いています。
が、実は筆者暴走気味で、毎度オーバランしています。
連載中に書き残したことや、説明が不十分でフォローしたいこと、記事に関連する裏話 など、スピンアウト的な話を書いていきたいと思います。