C言語によるデザインパターン

ひさしぶりに、『デザインパターンの骸骨たち』の内容を更新しました。
最後の更新から実に4年ぶりになりますね。興味のある方は、下記サイトをご覧ください。

http://www002.upp.so-net.ne.jp/ys_oota/mdp/

最近、少し気持ちに余裕が出てきたので、ずっとアイディアとしてあたためていたデザインパターンのＣ言語版を追加してみました。正味、４，５日で書き上げたコードですので、いろいろとコードに不備があると思います。そこは現役を退いたおやじが書いたコードと思って見てやってください。

さて、Ｃ言語でデザインパターンを作ってみようと思った動機ですが、最近、海外エンジニアと付き合っていく中で、Ｃ言語が、まだまだ現役どころか主流を占めていることに気がつき、Ｃ言語でデザインパターンを作ってみたら、意外と使えるものになるのではと思ったからです。

日米では、２０００年頃からすでに組込みの世界でもオブジェクト指向言語が導入されているところが多いですが、欧州やアジアでは、Ｃ＋＋で書かれたコードは今でも稀です。エンジニアもオブジェクト指向設計にこだわる姿勢があまりないように思います。多くの組込みＯＳは、Ｃ言語インターフェースですので、その流れでドライバも、ミドルウエアも、アプリケーションもＣ言語というのは自然の流れなのでしょう。

私も彼らと付き合ううちに、何もオブジェクト指向言語でなくても、オブジェクト指向設計は実現できるのだと思うようになってきました。実際、彼らは構造体と関数ポインタを駆使し、オブジェクト指向的な使い方で、Ｃ言語のコードの再利用、拡張をしているのです。（デバックはやりにくいですけど）　Ｃ＋＋やＪＡＶＡといろいろな言語が出てきましたが、結局、手段を変えて同じことを実現しているに過ぎないということを強く実感しました。

とは言うものの、一方で、今回、Ｃ言語版のデザインパターンのコードを作ってみて、Ｃ＋＋やＪＡＶＡの利便性をあらためて再確認することにもなりました。

Ｃ言語版のコードを見ていただければ分かると思いますが、まず、"thisポインタ"がおかしなことになっていることに気がつくと思います。あと、継承とメモリ管理ですね。オブジェクト指向言語は、このシステムがあるからこそ、実装効率が向上すると言っても過言ではないでしょう。オブジェクト指向言語特有の豊富で便利なライブラリも魅力です。Ｃ言語は、細かいところに気を使わなくてはならないので、コード書いていて少し疲れます。

このように、設計そのものには言語に依存するものではありませんが、使用言語は実装効率を著しく左右します。ゼロ・スクラッチで作るソフトウエアでは実装効率の観点から、オブジェクト指向言語を採用するほうがよいでしょう。しかし、過去のＣ言語で作られたソフトウエアを流用、拡張するような場合は、まちがいなくＣ言語を採用したほうがよいです。

いずれにしても根底にある設計が大事なのであって、開発言語は経済的な観点から選択するのが賢明な判断と言えるでしょうね。

日本のソフトウエア産業の行方

今年に入ってから、大手企業各社赤字決算が相次ぎ、日に日に経済の厳しさが増してきています。
日本のソフトウエア産業の多くは大手企業からの受託開発がメインのところが多いため、現在の不況の煽りをダイレクトに受けているところも多いと思います。また、BRICSなどの新興国が発展するにつれて、コストの安い海外へソフトウエア開発をシフトする企業も増え、二重の打撃となっていることでしょう。

ソフトウエアは最小限のインフラで、高等教育を受けたものなら誰でも実践できる工学領域です。半導体や鉄鋼などの産業基本資材、精密機械、化学や薬品などは、その国のインフラ、文化、そして産業をささえる高度な職人技術をもった中小企業群などが揃っていなければやっていけませんが、ソフトウエアは、ＰＣとコンパイラ、ターゲットとなる基板と電源があればできてしまいます。そのため、新興国であっても十分、先進国に取って代われるのです。

それは、自然の流れであってどうあっても止めることができません。このまま日本のソフトウエア産業は空洞化してしまうのでしょうか？私見ではありますが、答えはＮＯだと思います。ソフトウエアを実装することは確かに高等教育と、経験、ある程度のネットワークインフラがあればどの国でもできるでしょう。しかし、ソフトウエアを設計することは、誰でもできるものではありません。

ソフトウエアが、一番活躍する現場といえば、会計処理、科学計算、システム制御です。この３つは、先ほど言った国の文化や科学技術の歴史、そしてノウハウが一番必要とされる部分です。新興国が、その分野において先進国のレベルに追いつくには、まだまだ時間がかかるでしょう。つまり、日本のソフトウエア産業が生き残るには、設計によりシフトしていくことが重要だということです。（巷ではそれをコンサルタントという人もいますが・・・）　

これから先、闇雲にどんなソフトウエアでも作りますとクライアントに売り込むソフトウエアハウスはもう生き残っていけません。自分たちのソフトウエアチームのスペシャリティを明確にし、各分野での深い知識・経験をもつ人材が揃っているところは、たとえコストが高くても魅力的に写ります。たとえば、会計処理ならば会計士や税理士資格をもったソフトウエアエンジニア、科学計算なら大学との共同研究や博士号をもつソフトウエアエンジニア、システム制御ならハードウエア設計もできるソフトウエアエンジニアなど。聞いただけでも凄みがありますよね。

ソフトウエアは所詮ヤドカリのようなものです。異なる産業の工学領域でMPUやCPUで処理できるものを横軸でまとめてソフトウエアと言っているに過ぎません。つい最近まで、Javaや.NETやWeb2.0やらと最新技術タームで酔いしれていた時代が続いていたこともあり、それが一つの技術領域であるかと、皆錯覚してしまっていました。しかし、これらは同じことを異なる形で実現しているにすぎません。

今では多くの人が、これらの技術タームにどれほどの価値があったのか？と疑問に思いはじめており、このような最新技術タームを売りにできる時代はもう終わりに近づいています。（たとえば、Javaのエキスパートエンジニアですとか、デザインパターンは熟知していますとか、SQLはばっちりですとか・・・。そんなものは新興国の若い優秀なエンジニアにごろごろいますから）　それだけ、ソフトウエア産業が成熟してきたことの証でしょう。

これから先、日本のソフトウエア産業で食べていこうという人は、自分の社会におけるスペシャリティは何なのか？それを常に意識するようにしてください。逆に言えば、ソフトウエアはあくまで自分の専門性を発揮する道具と思っていれば食いはぐれることはありません。ソフトウエアは精密機械産業における旋盤のようなものと思えばいいのです。

日本のソフトウエアエンジニア皆がそのことに気がつけば、今後、日本のソフトウエア産業は、まったく異なる発展を遂げると思います。でも、それは、もうソフトウエア産業と言えるものではないかも知れませんけどね。

そうは言っても、全く正反対のことを言いますが、私の経験から言わせてもらえば日本のプログラマは本当に優秀です。コミュニケーションの問題もあると思いますが、日本のプログラマは海外エンジニアに比べ、２～３倍の生産性をもっていると思います。それに専門知識が加われば鬼に金棒でしょう。潜在的には、日本は文化的にもインフラも、国民性も世界最高のソフトウエア設計ができる人材が十二分に揃っている国だと思います。まだまだ捨てたもんじゃありません。

皆さん、自信をもってこの不況を乗り切りましょうね！

組込みソフトのソフトウエアアーキテクチャ

久しぶりの更新です。すっかり月一ブログとなってしまっていますね。相変わらずの筆不精・・。

最近、ようやく私が統括していたプロジェクト達が収束を迎えようとしています。正直、年初には達成不可能なミッションかと思いましたが人間やればできるものですね。自分自信驚いています。担当していただいた皆さんには本当にご苦労をおかけしました。でも、開発した革新的な商品たちはどの国でも大きな反響を呼び大好評です。やった甲斐がありました。また、それ以上にプロジェクトに関わった多くの人たちから、大変だったけど充実したプロジェクトだったと言って貰えたことは、私にとって商品の人気以上に嬉しいことでした。

と、ようやく胸をなでおろしたのもつかの間、お隣のプロジェクトが火を噴き始めました。対岸の火事とも言っていられない状況ですので、様子を見てみたのですが、どうも開発者全員にソフトウエアの全体構造の共通したイメージがないのが大きな問題であることが分かってきました。各々のモジュールの構造は、それぞれのチームで詳細設計されていますが、全体を規定する構造がないのです。

その結果、何が起こっているかというと、モジュール担当同士の話合いでインターフェースの追加が乱発されモジュールの依存関係がくもの巣のようになってしまっていました。そのため、複数のタスクからインボークされたスレッドが入り乱れ動作が安定せず、また原因を追うのが困難なデッドロックが発生してしまっています。

実はこのプロジェクト、我々の作ったソフトを流用し機能拡張する兄弟プロジェクトです。我々のプロジェクトでは、開発者間に明確なソフトウエアアーキテクチャのイメージが共有されており、このような構造に起因する問題はほとんどありませんでした。あらためて、その重要性と維持の難しさを痛感しました。

特に組み込みソフトの場合は、ソースコードが丸見えになってしまいますので、ライブラリ化が進んでいるビジネスシステムと違い、ソフトウエアアーキテクチャを維持することが非常に困難です。アーキテクチャの意図を十分に理解していない開発者がソースコードを流用すると、設計そのものを自分流に大きく変更したくなる要求が強くなる傾向があります。そして実際にしてしまいます。これは実装に自信がある開発者であればあるほど、その傾向は強いようです。

しかし優れた実装が出来るからといって、優れたアーキテクトであるわけではありません。アーキテクトは市場からの要求、過去からの経緯、そして何よりも設計効率（コスト）が意識できる人間でなければ勤まりません。アーキテクトにとって、設計の美しさは二の次で、過去から蓄積したソフト資産に変更を加えず、どう流用していくかくらいの割り切りが必要です。今回のプロジェクトは、信念を持ってそれが実践できるキーマンがいなかったのは大きな失敗でした。

これから、複雑に絡み合った糸を一つ一つ解きほぐす気の遠くなるような作業を進めていかないと、とても今の状況を好転させることはできないでしょう。投入したうちのエースの働きに期待大です。苦労のかけ通しで、本当に申し訳ありませんが頑張ってくださいね！私もできる限りの応援します！！

しかし、経済がこんな危機的な状況にも関わらず、なかなか楽にはなりませんね。そのうち仕事が山のように詰まれていた日々を懐かしく思う日がくるのでしょうか・・・。

ソフトウエアの品質保証

久しぶりの更新になります。最近、ずっと休みなしの余裕のない生活を送っていたのですが、最近になり大きな峠を一つ越し、少しだけですが休みをとれるようになってきました。本日などは、今までの疲れを一掃するかのごとく、一日中寝ていました。久しぶりに気分爽快です。

さて、どのプロジェクトでもそうだと思いますが、ここ数ヶ月、私もソフトウエアの品質保証に苦しめられました。大規模ソフトウエアの評価は非常に難しく、ソフトの仕様が膨大になればなるほど、その組み合わせ条件が爆発的に増え、評価をやってもやってもキリがありません。また、どこまでが修正すべき問題で、どこまでが許容されるべき問題かという線引きも難しく、多くの場合、評価者の主観によって決められてしまいます。

その結果、設計側意見と品質保証側意見との食い違いが発生し、問題の扱いについて何度も協議が繰り返されることになります。このような意見の食い違いは、限られたシチュエーションでしか発生しない問題の場合が多く、設計側としては「特殊操作下でしか発生せず、問題とならない」、一方で品証側は「万が一発生した場合を考え直すべき」の平行線となってしまいます。

限られた状況でしか発生しない問題に多くの工数をかけて直すべきか、限られた条件下における問題は仕様として割り切るべきか非常に難しい問題です。前者を優先すると製品開発の工程は長くなり、スピーディに製品投入できません。一方で後者を優先すると、品質に対するモラルが低下していく懸念が残ります。いずれもバランスの問題であることは言うまでもありません。バランスのかけ方が設計側と評価側とで異なるのが問題なのです。

しかし、私は問題の根本はこのような議論の中にはなく、設計側と品質保証側の潜在的な対立構造にあるように思います。日本のソフトウエア開発が、まだまだ遅れているなと思うのは、ソフトウエア設計と品質保証の工程がまだウォータフォールモデルを脱却していないことにあります。一時期、IBMなどが提唱していたブラックボックステストの神話をまだ抜け切れていないのです。

大規模ソフトの場合は、一人のプログラマが書かなければならないコード以上に、検証しなければならないケースが非常に膨大になります。実際、コーディングよりも検証に多くの時間を割いている現場も多いでしょう。その結果、現場はデスマーチになります。

このような状況下では、設計側は、評価部隊は重箱の隅をつつくパラノイアに見えてくるし、仕事をどんどん積み上げてくる鬼のように見えます。一方、評価側は、いつまでたっても安定しないソフトウエアを繰り返し繰り返し毎日評価させられ、賽の河原を積み上げるような苛立ちを設計側に対してもつようになります。

しかし、設計者と評価者が開発段階から密接にかかわっていたら、このような対立は劇的に少なくなるでしょう。評価側は仕様に対して責任をもち、設計側は設計に対して責任をもつことを開発段階から明確にすれば、そもそも、このような対立はおきようもないのです。

評価チームは製品仕様からユースケースを作成し、設計側はユースケースに基づいたコードを提供し、機能毎に評価を実施してもらうサイクルを開発段階から細かく回していけば、評価も設計も成果物に対して等しく責任を負う形になります。ちょうど、発注・検収者と開発委託の関係を社内的に構築していくような感じでしょうか。

このようなやり方はソフトウエア品質保証の中でも最先端のやり方で、評価者はソフトウエアを知りませんでは済まされないどころか、設計に対しても口出しをするくらいでないと務まりません。開発初期においては、すべてのモジュールがそろっていないので、評価者は自分の作ったユースケースを満足するテスト用のコードも必要になるわけです。

このソフトウエアサイクルが実現できれば社内に膨大な開発者を抱える必要もなくなり、オフサイトさらにはオフショア（海外）での開発を組織的に行うことができ、開発者不足に頭を悩ませる必要もありません。ソフトウエア開発組織としては、非常に柔軟性に富み、競争力の高いものとなるでしょう。

もちろんブラックボックステストは最終段階では必要です。しかし、それは仕様を隅から隅まで理解した人がやるものでなく、製品／サービスに対して先入観のない人に取扱説明書を渡し、ユーザーと同じ条件下で評価を進めるべきものです。また、その評価は製品やサービス全体を評価するものになり、取扱説明書やメカ的な使い勝手などソフトに限定できるものではなくなります。

日本のソフトウエア品質保証の考え方は、まだまだ発展途上で、このブラックボックステストとホワイトボックステストがごちゃ混ぜに議論されているように思います。もちろん私の会社でも。。。

なるべく、この状況を変えたいと思っているのですが、官僚化した縦割りの大企業の中では、なかなか思うように事は運ばないものですね。

ソフトウエアのエラー処理

32bit オペレーションシステムで2Gバイトの壁に再びはまってしまいました。

といっても、今回は実装の話ではありません。エラー処理の話です。私はメーラーに Thunderbird を使っているのですが、先日、メールを受信しようとしたら、突然ハングしたり、落ちるようになりました。送信は問題ないのに受信をしようとすると問題が発生します。

受信ボックスはかなりの量があったので、2Gバイトを超えちまったかなと思い、振り分けをして受信ボックスを空にしたのですが、それでも症状はかわりません。いろいろと調べてみたはものの、やっぱりメールを振り分けなおせばだいたい直ると書いてあります。う～ん、困りました。

しょうがないので受信フォルダを直接覗き、INBOXを見てみたところ、メーラー上では受信ボックスは、空になっているのにも関わらず、受信ボックスのファイルは2Gバイト以上になったままでした。振り分け処理は、単にコピーをしただけで、実体は減らされていないようです。そこで、振り分けされたメールがきちんと保存されていることを確認した上で、INBOX を削除したところ、無事、復旧しました。
つまらないことで時間を使ってしまったものです。

どうも、Thunderbird は、2Gバイト以上になってしまったファイルの扱いが、ルーチン毎にバラバラのようですね。読み込み処理ではファイルのオープンエラーをリカバリーする処理があるようですが、INBOXの再作成では更新時にエラーが返ってきた時点で処理を抜けているようです。さらに、メールの受信処理では、エラーハンドリングもしていないようです。そのせいで、最初、問題がどこにあるのかよく分からず戸惑ってしまいました。

オープンソースだけあって、エラー処理の仕様の統一性がとれていないのが如実に表われていて、ちょっと面白い例だなと思いました。

メーカーの製品開発でも、機能仕様は関係者間で設計や詳細仕様を詰めますが、エラー処理は実装者の判断に任されていることが多いと思います。しかし、この例でも分かるように、エラー処理も仕様を統一しないと、問題の特定がしにくく、品質の維持が難しいソフトウエアとなってしまいます。

目立つところだけでなく、エラー処理のような細かい部分にもきちんと気を配ったソフトウエアを作っていきたいですね。