3月8日の金曜スーパープライム「池上彰くんに教えたい10のニュース」のラストで3月一杯でTVの仕事から離れる池上彰氏が、「自分が生きている間にベルリンの壁が崩れるなどとは思っていなかった。チュニジアのデモからエジプトのムバラク大統領の退陣までこんなに早いとは思わなかった。時代の変化は早くなっている。今流れているニュースはいずれ歴史になる。そういう目でニュースを見なさい。」と言って去って行った。
3月8日は東日本大震災が起こる前だったから、想像もできなかっただろうが、まさに日本で流れているニュースは今後、歴史に刻まれることになる。
そう考えると、今、乗り越えなければならない問題の解決のプロセスは現在だけのことだけではなく、未来から見た歴史になるという意識で対峙しなければいけない。
品質マネージメントの観点から考えたときに、問題が起こったときに重要なのは、同じような問題が起こらないように予防と是正を行うことだ。
品質をマネージメントする技術者はCAPA （Corrective Action and Preventive Action：是正・予防措置）に注力を注がないといけない。問題が起きたときに犯人を見つけて責任を追及することは容易だが、再発防止の取り組みを築き上げるためには技術もいるし、組織的なマネージメントもいる。
再発防止を実現するためには、何よりもまして、同じ問題を起こしたくないという強い意志がエンジニアやマネージャになければいけない。
日々のビジネスシーンでは、QCD（Quality, Cost, Delivery）のうち、コストや納期が品質よりも優先される、優先しろという指示、圧力がかかることが少なくない。真の技術者は製品やサービスにおいて当たり前にできていることの技術、その品質を維持することの難しさをよく知っている。一方、製品やサービスを表面からしか見ていない者は当たり前にできていること＝潜在的な価値の重要性を常に意識することができない。
潜在的価値が意識されるのは、当たり前品質が当たり前でなくなったときだけだ。すなわち当たり前できているはずのことが、できなくなり故障、障害、事故が起きたときに当たり前品質の重要性と、その潜在的価値を支えている技術が十分出なかったことが分かる。
このときに、組織や社会が認識しなければいけないのは、当たり前にできていることの裏にある技術や、どんなリスクを想定し、どんなリスクコントロールをしているのか、していなかったのかというリスク分析である。そして、品質マネージメントのプロセスに従い、CAPA （Corrective Action and Preventive Action：是正・予防措置）を実施する。そのとき、技術者やマネージャは同じ故障、障害、事故を起こさないという強い意志を持たなければいけない。
エンジニアは事態の収拾でホッとするのではなく、再発防止の取り組みに力を注ぎ、組織はQCD（Quality, Cost, Delivery）の Quality を軽視しない、コストや納期を優先させて品質への意識を忘れてはいけないことを心に誓う必要がある。
実際には、Quality, Cost, Delivery の間にはトレードオフの関係があることが多い。納期やコストを優先させると品質が低下する可能性は高い。しかし、技術力によって QCDのバランスを確保することは可能だ。
例えば、商品群のコアとなるソフトウェア資産を抽出し再利用可能な管理ができれば、品質とコストと納期の要求を満たすことはできる。ソフトウェアプロダクトラインの技術だ。このとき、医療機器などのクリティカルデバイスにおいては、機器を取り巻くリスクに対して、そのリスクを受容可能なレベルまで引き下げるリスコントロール手段（設計上の対策）がコア資産に含まれいるとなお、その資産価値は高まる。（コア資産の顕在的価値と潜在的価値の両方を含めることができるとなお良い）
そのソフトウェア資産の安全性や信頼性を高めることに注力を注ぎ、その後何世代にも渡ってコア資産を再利用することができれば、QCD の要求を同時に満たすことができる。
クリティカルデバイスの開発は、失敗や事故との闘いであるとも言える。失敗や事故を再発されないためのノウハウを製品につぎ込み続けることが当たり前品質を高めることにつながる。だから、新規参入が難しいとも言える。ただし、大規模複雑化したソフトウェアの場合、単純に安全装置としてのソフトウェアを追加し続けると、これまで正常に動いていたシステムをデグレードさせてしまうこともあるから注意が必要だ。
ハザードやリスクがどう変化したのか、見落としていたのかを再評価し、リスクコントロール手段を要求としてとらえ、実現するアーキテクチャを設計する。日本人はこの設計上流の分析や設計がとても苦手に見える。試行錯誤で付け足しや修正をするのは得意だが、上流に立ち戻って再設計するのは下手だ。
障害や事故を再発されないという強い気持ちとリスク分析、リスクコントロールのアーキテクチャ設計ができないとないと、障害や事故はまた起こる。気持ちだけでもダメだし、技術力がなくてもダメだ。
そして、是正・予防措置は、気持ちだけでは進まない、組織に品質マネージメントを仕組みを根付かせ、日々前向きな気持ちで回していなければできるものではない。
そして、ジャーナリズムにお願いしたいのは、障害や事故が起きたとき、その後組織が再発防止の取り組みを続けているかどうかを監視することと、今は起こっていないが何かあったら大変なことになる社会インフラ、重要デバイスに問題が起こったらどうなるのかという視点を持ってもらうことだ。
何か起こってから追求するのは誰でもできるが、これから起こるかもしれない障害、事故を防ぐためには経験や知識、幅広い視点が必要になる。ジャーナリズムには事故を未然に防ぐ技術やマネージメントについての報道を期待したい。
2011-03-27
2010-04-17
組込み開発現場のプロジェクトマネジメント＆プロセス改善
■Part 1 新人管理者のためのマネジメントの基礎知識
著者：井上 樹(いのうえ たつき)
(株)豆蔵にて組込ソフトウエアを中心にオブジェクト指向/UMLの導入、プロセス改善等に関する教育、コンサルティングを担当。最近はモデルを活用したシステムエンジニアリングに注目中。
■Part 2 現場が共鳴する開発環境の姿
著者：杉浦 英樹(すぎうら ひでき)
1986年、富士ゼロックス(株)に入社。以来、複写機の組込みソフトウェア開発を担当。複数のドメインを複数のパラダイムで開発。開発現場の問題のほとんどが、コミュニケーションに起因し、真の管理の重要性を痛感。SESSAMEメンバー。
■Part 3 実践的プロジェクト計画の立て方
著者：竹山 寛(たけやま ひろし)
ビジネスモデル構築、ソフトウェア開発プロセス、プロジェクト推進支援、品質管理、プロジェクト管理、開発工程管理、セミナーなどITコンサルタントを手がける。著書に『管理者になって困らない[実践的]ソフトウェア開発工程管理』(技術評論社)がある。
■Part 4 プロセス改善のススメ
著者：玉木 裕二(たまき ゆうじ)
(株)東芝 ソフトウェア技術センター所属。入社以来十数年、社内のソフトウェア開発部門各所に、アーキテクチャ設計提案、プロセス整備やインフラ整備、コーディングやデバッグなど、いろいろな立場で関わってきた。それなりに知見も増えてきたけれど、まだまだ足らないと実感する毎日。
著者：荒見 美香子(あらみ みかこ)
(株)東芝 ソフトウェア技術センター所属。十年以上に渡り、CMM/CMMIなどのモデルを活用したプロセス改善活動に従事。社内のソフトウェア開発部門への改善コンサルに奔走しつつ、効果的な進め方を模索中。最近は、社内のプロセス資産化やインフラ整備に注力。
■Part 5 勘違いだらけのプロセス改善
著者：杉本 恭子(すぎもと きょうこ)
横河ディジタルコンピュータ(株)所属。最初の仕事はソフトウェアプログラマ。その後開発ツールベンダのテクニカルサポートやマーケティングを経て、現在はプロセス改善関連の企画営業を担当。日々、お客様の生の声やお困りごとに接し、支援部隊への橋渡しをしている。
■Part 6 プロダクトラインの歩き方
著者：今関 剛(いまぜき たけし)
(株)ビズモ コンサルティング部所属。日ごろから開発現場でオブジェクト指向やプロセス改善の指導をしているが、解決方法やツールを利用することが目的化して玉砕しているところが多いと感じる今日この頃。現在は、アーキテクチャリファクタリング、テスティング、モデリングを組み合わせ、人材や既存資産の能力をうまく引き出しながら、全体最適の視点に立った再利用型ソフトウェア開発を目指す。IEEE、SEA、SESSAME、EEBOFメンバー。
※プロフィールは掲載当時のものです。
見ていただければわかるように、それぞれのパートは技術評論社の『組込みプレス』に掲載されたプロジェクトマネジメント・プロセス改善に関係する記事（Part6 は再利用戦略の内容）であり、本書はこれらの個別の記事を集約している。
それぞれのパートのキーワードを拾ってみよう。
■Part 1 新人管理者のためのマネジメントの基礎知識
- QCD(Quality:品質、Cost:予算、Delivery:納期)
- PDS(Plan:計画→Do:実行→See:評価) PDCAよりもわかりやすいPDSで説明しているとのこと。
- SWEBOK(Software Engineering Body Of Knowledge)
- PMBOK(Project Management Body Of Knowledge)
- CMMI(Capability Maturity Model Integration)
- モチベーション管理
- コミュニケーション管理
■Part 2 現場が共鳴する開発環境の姿
- ブルーオーシャン戦略
- 変化に取り残される開発現場
- どうしても人に依存してしまう開発現場
- 開発技術の退行
- PDCA(Plane-Do-Check-Action)の不在
- 改善/改革できない理由（非技術的要素、人的要素）
- 実践的な開発管理のヒント
- CMMIやPMBOKが目的ではない
- 現場中心の管理スタイル
- 改善するための具体的なヒント
- 開発者の気づきをどう促進するか
■Part 3 実践的プロジェクト計画の立て方
- プロジェクトマネジメントの失敗要因
- ソフトウェア開発の階層構造
- プロジェクトマネジメント作業の進め方
- アローダイアグラムによるプロジェクト計画の立て方
- アローダイアグラムの作成
- アロー代打グラムでの進捗管理
■Part 4 プロセス改善のススメ
- 混乱する現場
- スケジュールの逼迫（ひっぱく）
- 変わりやすい要求仕様
- 改造の繰り返し
- 外部リソース依存
- 不透明な進捗
- 混乱を抑えるのに有効な技術
- UML(Unified Modeling Language), MDA(Model Driven Architecture)
- リファクタリング
- CMM
- ソフトウェアプロセスとその改善活動
- ソフトウェアアーキテクチャとプロセス改善
- 改善事例（基本仕様書の標準化、単体テストの改善、構成管理の改善）
- 改善活動を推進する方のためのヒント
- プロジェクトの中に改善リーダーを見つける
- ときにはプロジェクトの開発者として作業を請け負う
■Part 5 勘違いだらけのプロセス改善
- プロセス改善とは何か
- いつから始めたらよいか
- どこから始めたらよいか
- CMM/CMMIを参考にする
- CMM/CMMIの上手な使い方
- プロセス改善の勘違いと落とし穴
- たちまち仕事が楽になる？
- たちまち工数が削減される？
- 目に見えて生産性が向上する？
- 教育と実践、どちらが先か？
- 身の丈に合ったプロセス改善
- プロセス改善は活動し続けるもの
- 外部から見てもらう
- 改善は組織全体の取り組み
■Part 6 プロダクトラインの歩き方
- どうしてプロダクトラインなのか？
- なぜ再利用が進まないのか？
- コア資産開発
- アーキテクチャ定義
- コンポーネント開発
- COTS(Commercial Off-The-Shelf ：市販ソフトウェア製品）の利用
- 既存資産の発掘
- 要求エンジニアリング
- テスト
- 構成管理
- デザインパターン
- 統合運営パターン
- 商品開発パターン
- 資産確立パターン
- コールドスタートパターン
- プロセスパターン
- プロダクトラインとCMMI
- 何をもってプロダクトラインと言えるのか？
キーワードを見てもらえばわかるようにテーマは似たようなところにあっても、それぞれの著者の組織、経験によって抑えるべきポイント、視点が異なることがわかる。
この本を購入しようとする読者は、この本をプロジェクトマネジメントやプロセス改善の教科書＝そこに書かれている通りに実施すればよいという手順書 と考えてはいけない。そうではなくて、プロジェクトマネージメントやプロセス改善の6つのプララクティス（実戦経験）から何かを学ぼうと考えるのが正しい読み方だ。
6つプラクティスもしくは体系は、似ている部分もあれば、異なる部分もある。その違いに混乱することなく、自分達の状態に一番近いものを選び、一番「その通り！」と思える部分に付箋をつけていく。
個人的には Part 4 に一番多く付箋が付いた。この本をお勧めするに当たりもっとも重要なのは、相手が人間である以上、改善の対象となる組織や組織を構成する人間、目に見えない文化や習慣を考慮して活動を進めなければ改善活動は成功しないということだ。
また、必ずしも論理的でない人間は、ロジカルにアプローチをしても予想通りの結果をもたらさない。だから、改善のサイクル(PDCA）を回し続けなければ、目的に近づかない。ソフトウェアの品質改善よりも人間や組織の改善の方がよっぽど手間と時間がかかる。
多くの著者がCMM/CMMIを取り上げているのは、それだけCMM/CMMIが優れた体系であるからだが、CMMやCMMIは自分達の身の丈にあった活動を続けていって、やっとサイクルがまわり成果が出てきたかなあと感じるようになった時点、CMM/CMMIを勉強するくらいがちょうどよいと思う。改善のサイクルが回っていない組織がいきなり CMM/CMMI を勉強し始めると空回りする可能性が高い。
何はともあれ、プロジェクトマネジメントやプロセス改善のテーマで6つの視点を比較することができるという意味でこの本は貴重な存在である。
P.S.
ときどき、「なんで自分はこのブログを続けているんだろうか」「このブログを読んでくれている読者は自分のことをどんな人物と受けとめているのだろうか」と考えることがある。一回の記事を書くのにだいたい1～2時間くらいはかかるから、たまに面倒くさいなあと思う。原稿料をもらっているわけでもないので締め切りもないので、「書き続ける」モチベーションを保ち続けるのもたいへんだ。
最初は本の読者と双方向の意見交換をするつもりだったが、結果的にはこちらかの情報発信が圧倒的に多い。（議論のもとになるネタまってます。以前、高校生からの「組込みソフトってなんですか」の質問では大いに盛り上がりました。）
でも、このブログを4年も続けていて実感しているのは、ブログに記事を書くことは明かに自分のためになっているということである。
他の人が書いた記事や、聞いた話を、ブログを通して多くの人に伝えるためには、いったんインプットされた情報を整理して読者を想定してかみ砕いて分かりやすくアウトプットしなければいけない。これはものづくりやソフトウェア開発にも役立つ。要するに、外界からセンシングした情報をインプットとして加工し特定のユーザーに受け入れられるようにアウトプットする訓練をしているのと同じだ。
コピペではなく、本や雑誌に書いてあることを、キーボードで打ち直すのは面倒だと思うかもしれないが、自分はこの作業がまったく苦にならない。なぜなら、文章を打ち直す行為は学校で先生が黒板に書いたことをノートに写すのと同じで、その行為によって理解や記憶が深まるからである。
もうひとつ。学校で授業を受ける際のインプットは先生が選択した情報だが、自分がやっているのは誰かから強制的に与えられた情報ではない、自分が自分の意志で選択した情報だ。そこに一貫性がないとブログの内容はその人の興味のあること＝日記風になり、何らかの目的、一貫したテーマがあれば、最終的にはその目的、テーマを達成るための体系になりうる。
もちろん、このブログは後者を目指しており、結果的に『組込みソフトエンジニアを極める』→設計に関する体系と『リコールを起こさないソフトウェアのつくり方』→V&Vの体系 にまとめることができた。
自分で自分のやることを選択して実行し、他人に認めてもらうというサイクルを回す際に一番苦しいのは、最初のステップ「自分で自分のやることを選択する」という点だ。なぜって、そこが最初だから選択した責任は自分にある。誰かから言われたことをやって失敗してら失敗した責任の一端は最初にヤレといった人にあるが、やるべきことを自分で選択したらすべての責任は自分にある。その覚悟をするのが大人になるとそれなりに重いのだ。
日本の技術者は自分でやりたいことを選択してやりきるという経験が非常に少ないように感じる。別にソフトウェア開発じゃなくてもいいから、料理でも作曲でも、目的を持ったブログでもちょっとした簡単なことでいいのでやってみるといい。やっていくうちにもう少し極めたいと思ったらしめたものだ。
そして「なんで、自分はこんなことをやっているのだろう」と必ず思うはずなので、そのときに根拠となるロジックを自分の中に構築する。これを習慣化すると自立したエンジニアになれる。
【参照】
今回の記事を書きながら、そんなことを思ったのだった。
2010-01-16
Forecast と Backcast の視点
エコの世界にはフォアキャスト（Forecast）とバックキャスト（Backcast）という言葉があるらしい。
そもそも、フォアキャスト（forecast）やバックキャスト(backcast)は、釣りの世界の専門用語で、フライフィッシングにて、釣り糸と仕掛けの重さだけで自分の思うポイントに疑似餌を投入する竿と糸の振り方（キャスティング）で、前に振るのをフォアキャスト、後ろに振るのをバックキャストと言うのだそうだ。
で、エコの世界でどのようにフォアキャスト（Forecast）とバックキャスト（Backcast）が使われているかというと・・・
【「バックキャスト」と「フォアキャスト」とはどかが違うの？ より引用】
要するに、このまま放っておけば地球は滅亡する。それを防ぐためにはこれこれのことを積み上げていかなければいけない。今年の目標が達成できなければ、来年は今年実現できなかった分も実施する。生き延びることができた場合の未来から過去を振り返ったときに、やるべき事を考えるのがバックキャストということだ。
そこでふと思った。エコの世界だけでなく、フォアキャスト（Forecast）やバックキャスト（Backcast）という視点は大事だということである。
フォアキャスト（Forecast）とは、「前を見通す」という意味で、現状分析から出発して、将来どのようになっているかを考える。楽観的な人は楽観的な未来を悲観的な人は悲観的な未来を予想するだろう。どちらにしも、ある意味未来に対しての責任があるという色彩は薄い。
しかし、環境問題で使われているバックキャスト（Backcast）の例を見れば分かるように、バックキャストには目指すべき未来を実現するための責任という意味も含まれる。
これは、ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）の実践にぴったりじゃないか。
ソフトウェアプロダクトラインが日本での成功例がなかなか見あたらない一つの理由に、日本人の未来を見通す力の低さと、来るべき未来を実現するための今の責任という視点に欠けているという点があると思う。
これこそ、フォアキャスト（Forecast）とバックキャスト（Backcast）の視点だ。
ソフトウェアプロダクトラインは、コアとなるソフトウェア資産を構築して、それを使ってさまざまな派生製品を作っていく戦略だ。簡単に思えるかもしれないが、実現するのは極めて難しい。難しい理由は、次の三つだ。
そのためには、あるべき姿、未来の成功した自分から現在をバックキャストして何が足らないのかを考えることも必要だし、現状を分析して未来に向けて何をすべきかというフォアキャストの視点もいる。
辛い現実があるとつい近視眼的な視点になりがちだが、5年、10年というレンジで、フォアキャスト（Forecast）、バックキャスト（Backcast）の視点で、左うちわで価値の高い商品を生み出すことに成功している自分を想像しつつ、そのために今やるべきことは何かを考え、実行することが大切ではないかと思った。
バックキャスト（Backcast）したときに、今の自分の双肩にかかっている責務を感じることができない人は、結局はいろいろな誘惑に負けて想定した未来を掴むことはできないのだと思う。
そもそも、フォアキャスト（forecast）やバックキャスト(backcast)は、釣りの世界の専門用語で、フライフィッシングにて、釣り糸と仕掛けの重さだけで自分の思うポイントに疑似餌を投入する竿と糸の振り方（キャスティング）で、前に振るのをフォアキャスト、後ろに振るのをバックキャストと言うのだそうだ。
で、エコの世界でどのようにフォアキャスト（Forecast）とバックキャスト（Backcast）が使われているかというと・・・
【「バックキャスト」と「フォアキャスト」とはどかが違うの？ より引用】
フォアキャストでは、過去の実績を延長して（たとえば）25年後の目標を決めます。この場合、25年後の目標はたとえば努力の程度、実現の難易度などで複数個（～無限個）のものを設定することができます。これとは全く違って、バックキャストでは、たとえば「炭酸ガスの排出量を25年後に6億トン以下に抑える」といったことを「決めます」。目標は動かさない（動かせない）のです。そうしておいてから、「では今、そして来年から25年後まで、何を何時迄にやらなければならないか」を決めます。これにも幅（余裕、選択）は（ほとんど）ありません。そして実行してみてたとえば1年後に結果を見て、もし計画からずれていたら直ちに今年の計画に組み込まなければなりません。【引用終わり】
要するに、このまま放っておけば地球は滅亡する。それを防ぐためにはこれこれのことを積み上げていかなければいけない。今年の目標が達成できなければ、来年は今年実現できなかった分も実施する。生き延びることができた場合の未来から過去を振り返ったときに、やるべき事を考えるのがバックキャストということだ。
そこでふと思った。エコの世界だけでなく、フォアキャスト（Forecast）やバックキャスト（Backcast）という視点は大事だということである。
フォアキャスト（Forecast）とは、「前を見通す」という意味で、現状分析から出発して、将来どのようになっているかを考える。楽観的な人は楽観的な未来を悲観的な人は悲観的な未来を予想するだろう。どちらにしも、ある意味未来に対しての責任があるという色彩は薄い。
しかし、環境問題で使われているバックキャスト（Backcast）の例を見れば分かるように、バックキャストには目指すべき未来を実現するための責任という意味も含まれる。
これは、ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）の実践にぴったりじゃないか。
ソフトウェアプロダクトラインが日本での成功例がなかなか見あたらない一つの理由に、日本人の未来を見通す力の低さと、来るべき未来を実現するための今の責任という視点に欠けているという点があると思う。
これこそ、フォアキャスト（Forecast）とバックキャスト（Backcast）の視点だ。
ソフトウェアプロダクトラインは、コアとなるソフトウェア資産を構築して、それを使ってさまざまな派生製品を作っていく戦略だ。簡単に思えるかもしれないが、実現するのは極めて難しい。難しい理由は、次の三つだ。
- 再利用可能なコアアセットを作るスキルが足らない
- コアアセットを作るための一時的に時間とコストがかかる
- せっかく作ったコアアセットを我慢できずにすぐ修正して派生させてしまう技術者を組織が制御できない
- 開発効率が上がりこれまでの半分くらいの工数で楽々新製品のソフトウェアができてしまうソフトウェアプロダクトラインが成功したときのプロジェクトの姿を想像する。
- そのための必要なスキルや、組織構成、時間、コスト、必要な技術支援は何かを考え、実現のための計画を立てる。
- 最初（コア資産ができあがるまで）は辛くとも、未来の自分達の姿を夢見てスキルアップに精進する。
ここにはフォアキャスト（Forecast）とバックキャスト（Backcast）の両方の視点が入っている。大事なのは、未来のあるべき姿を実現するためには、辛くとも努力を続けあきらめずに途中で取り組みを放り投げないことだ。
そのためには、あるべき姿、未来の成功した自分から現在をバックキャストして何が足らないのかを考えることも必要だし、現状を分析して未来に向けて何をすべきかというフォアキャストの視点もいる。
辛い現実があるとつい近視眼的な視点になりがちだが、5年、10年というレンジで、フォアキャスト（Forecast）、バックキャスト（Backcast）の視点で、左うちわで価値の高い商品を生み出すことに成功している自分を想像しつつ、そのために今やるべきことは何かを考え、実行することが大切ではないかと思った。
バックキャスト（Backcast）したときに、今の自分の双肩にかかっている責務を感じることができない人は、結局はいろいろな誘惑に負けて想定した未来を掴むことはできないのだと思う。
2009-05-12
再利用資産を作る勇気
最近、「別製品の過去のソフトウェアを参考にして（とある）機能を実装した」という変更履歴を見た。その行為に対して「同じ機能を実装するのになぜ修正が必要なのか？」「再利用できる資産を使うという解決方法はないのか」という突っ込みを入れる者はプロジェクト内に誰もいない。これこそが、「あたたかい人間関係の中のやさしい一員」の特徴だ。プロジェクトリーダーの承認やプロジェクトメンバーのレビューなしに変更が進められ、誰からも「ちょっと待った」と言われることはない。直近の問題解決が優先され、長期的な改善活動のことは視野には入っていない。
それはそのソフトウェア資産の価値と寿命で判断する。価値が高く、寿命が長いソフトウェア再利用資産は技術を駆使し、勇気を持って再構築する。顧客に対する価値がそれほど高くなく寿命が短いソフトウェアは無理して再利用資産にする必要はない。資産化するコストに見合わないことが多い。
価値は高いが寿命が短い、価値はそれほどではないが寿命が長い場合はよく考える。価値は表に出やすい顕在的価値だけでなく、バグがあるとユーザーに多大な不利益が降りかかるような潜在的な価値（当たり前品質）もあるので注意が必要。
ソフトウェア再利用資産を構築しメインテナンスするには技術だけでなく勇気もいる。特にボトムアップで再利用資産を構築するときは自己犠牲を払う覚悟もいる。だから、コピペしてお茶を濁してしまう技術者があちらこちらに出てきてしまう。
日本でソフトウェアの体系的な再利用戦略を実践するには、「開発効率と品質向上の向上」についての現場からの必要性の叫びと、組織的トップダウンの取り組みの両方がかみ合わないと難しい。どちらかだけでもダメだ。一度構築したソフトウェア再利用資産を使い続けるには組織的マネージメントも必要だ。統制が取れていないプロジェクト、組織ではせっかく作成したソフトウェア再利用資産が使われなくなってしまう。実質的にはソフトウェア資産の可視化と、その資産がどれくらい価値があるのかの周知ができなければ、見えにくいソフトウェア資産はすぐに埋もれてしまう。
価値を見えるようにするということがいかに大事かということである。
2009-01-24
ソフトウェア資産の価値を可視化すべし
メカ（機械設計）、エレキ（アナログ、デジタルを含む電気設計）、ソフト（ソフトウェア設計）の3つを比べたとき、開発の効率化、高品質化がやりやすいのは、メカ＞エレキ＞ソフトの順番ではないかと思う。
たぶん、その理由は各設計ドメインにおける開発の成果が見えやすいか否かの違いだろう。メカはできあがったものを見て動かしてみればできの善し悪しを判断できる。評価はできあがったものをみんなで触ってみればいいし、うまくできたら上司に「動かしてみますので見てください」と言えばいい。ソフトウェアの場合、上司に「いい関数ができたので見てください」と言っても明確かつ一般的な評価指標がないから面倒くさいと言われるだけだ。（共通の価値を見いだすのが難しい）
エレキはそもそも完成された部品を組み合わて回路を構成するため部品単位の検証を行う必要はない。また、ブロック図や回路図といった抽象化されたモデルが必ず存在し、さらに、部品が実装されたプリント基板をまじまじと眺めることができる。
それに比べてソフトウェアはどうだろうか。「いやー、この間の開発で作った○○モジュール、あれはいい仕事だったね」とか「△△のソフトウェアはライバル会社の××のよりも数段性能が高かった」などという会話を聞いたことがあるだろうか。そんなのエレキでも同じだと言うかもしれないが、エレキの場合物理的な実装プリント基板がある。電気屋さんは発注したプリント基板が上がってきたとき、そのプリント基板に部品を実装して正常に動作したとき、喜びを感じることができるし、同僚とも喜びを分かち合えるし、上司に「できました」と物を持って報告にいける。
ソフトウェアの場合は同じことができるのは、ソフトウェアが製品に実装されたときだけだ。そこに大きな問題がある。ソフトウェア部品、ソフトウェアサブシステムが完成したとき、喜びをかみしめることができるのはごく少数の技術者であり、完成したと思ったサブシステムもさみだれ式に変更を繰り返していたのでは完成したという区切りが見えないので「終わった」という感覚がない。だから、組込みソフトウェアエンジニアはソフトウェアが製品に実装されたときにしか周りの人たちに評価されないという問題がある。ソフトウェアの部品単位で評価されることはないから、ソフトウェア部品の作りかたやソフトウェア部品の品質がいいとか悪いなどと評価される機会は残念ながらほとんどない。
ビジネス系のパッケージソフトウェアならばソフトウェア部品であったとしても、ソフトウェア部品としての売り上げで、そのソフトウェアの価値を推し量ることができる。ところが組込みソフトの場合はメカ、エレキ、ソフトが一体となって出荷されるために、もし商品がヒットしても、売り上げに貢献したのがメカなのか、エレキなのか、ソフトなのか分かりにくい。
メカやエレキは性能を計測するこができるから評価する指標を作りやすい。ソフトウェアの場合はどうか。「この製品は1000行あたりのバグが少ないんです」などとハードウェア出身の上司に言おうものなら「バグはゼロにして出荷しろ」と言われるだけだ。「いや、そうじゃなくて」としゃべり始めたときには上司はもう向こうに歩き始めているだろう。
要するに組込みソフトウェアの場合、プラスの価値を表現するのが難しいのだ。パッケージソフトウェアの場合と同様に、ソフトウェア部品を売る会社は、そのソフトウェア部品の売り上げで価値を評価することができるが、実はここにも問題がある。
エレキの場合、部品の検証は相当厳しく実施され、検証が十分に終わらないと出荷はしない。なぜなら、電気部品に不具合があって、その部品を使って商品を作成し、電気部品の不具合が原因でユーザーが被害を被った場合、部品メーカーはそれ相当の責任を負うことになる。エレキの場合、どの部品が不具合の原因かは正確に分かるし、不具合の状況を部品メーカーに突き付けることもできる。問題が起こったら部品メーカーは逃れようがないのだ。だからこそ、エレキの部品メーカーはリリースする部品が完全であることを確認して出荷する。電気部品の場合、検証に必要なテストケースは有限な場合が多い。その有限のテストケースをパスすれば、後は生産の問題に引き継げる。
ただ、エレキの世界でもワンチップマイコンのように、いろいろなデバイスをパッケージした製品を作ると、検証に必要なテストケースは爆発するようになり、すべてのケースをテストするのは不可能になる。だから、まれにワンチップマイコンにはバグが報告される。実際にはバグとは言わず、機能制限ということばで説明され、「これこれ、こういう使い方はしないでください」という注意書がデータブックなどの説明書に書かれる。これを見落とした場合の責任はデバイスを使う側にある。
さて、それでは市販されているソフトウェア部品を使う場合、そのソフトウェア部品はエレキの部品と同じように完全に検証され、不具合はないと言えるだろうか。その答えが NO であることは、組込みソフトウェア開発をやったことがある技術者ならすぐわかるだろう。実際、市販ソフトウェアに瑕疵（不具合）があったら賠償を請求できるだろうか。それは多くの場合できないし、そもそもバグがゼロだなんでだれも思っていないから賠償請求もしない。市販ソフトウェアは部品単体で完成度を表すことは難しいし、そこに問題がないことを証明するのは市販ソフトウェアを製品に組み込む側の責任であるという認識であることが多い。
そう考えると市販ソフトウェアのように明確に部品化されたソフトウェアであっても、そのソフトウェア部品が正しく動くということは部品メーカーサイドは保証することはできないので、そのソフトウェア部品が仕様どおりに動くという当たり前品質における価値は確定することがほとんどできない。ソフトウェア部品の場合、完成を確定することができないので、市販されるソフトウェア部品であってもその価値を確定することが難しいのだ。
ソフトウェアは簡単に変更できてしまうので、ソフトウェア部品のメーカーは出荷したソフトウェアに問題が発覚するとその情報を保守契約している使用者に流し、バージョンアップしたソフトウェア部品を配布する。でも、その市販ソフトウェアを使った製品を出荷してしまったメーカーはいったいどうすればいいのか。それは、その問題がユーザーにリスクを与え、そのリスクが許容できないと判断された場合は、製品のソフトウェアをバージョンアップし、場合によってはリコールするしかない。
ソフトウェア部品の価値の議論にもどると、このようにソフトウェアは当たり前にできているべきことが出来ていないときに負の評価が表面化する。負の評価の評価指標はソフトウェアの作り直しの費用や、ユーザーに対する弁済の費用だ。リコールにかかった費用がもっとも分かりやすい。ソフトウェアが原因でリコールしたら、そのリコールの費用がソフトウェアの負の価値として組織内外を駆け巡ることになる。
そこで、今回の記事のタイトル「ソフトウェア資産の価値を可視化すべし」となる。もちろん、可視化するのはソフトウェア資産のプラスの部分だ。
エレキの場合、性能を評価することがしやすいと書いたが、コストダウンも評価しやすい。同じ性能を安く実現できた場合、コストダウンぶんは直接利益になるからだ。
ソフトウェアの場合もエレキと同じような作戦でソフトウェア資産の価値を可視化する作戦を考えた。ソフトウェアの開発はほとんどが人件費だ。市販ソフトウェアだってもとは技術者が作るわけだからもとは人件費となる。したがって、ソフトウェアは再利用すればするほど、再利用するソフトウェアが問題を起こさなければ起こさないほど価値が高まる。ソフトウェアは複製しても劣化しないから部品を削減するのではなく、開発にかかる費用をセーブし、かつ、品質を高めることができればコストダウンにつながる。
【ソフトウェア資産の価値を可視化する作戦】
ソフトウェアシステムは大抵の場合サブシステムに分割される。ソフトウェアは見えないとよく言われるが、10万行を超えるようなソフトウェアシステムのソースファイルを一つのフォルダで管理しているプロジェクトはないだろう。多くの場合、ソフトウェアシステムのアーキテクチャに考慮して、フォルダを分けるはずだ。非常におおざっぱだが、そのサブフォルダの名前がサブシステムの責務を表しており、そのサブフォルダに入っているソースプログラムを作るのにかかった費用を計算する。これはそのサブシステムの価値の一つの評価指標になる。
サブシステムを協力会社に発注したのであれば、協力会社にいくら払ったかでサブシステムの価値を金額で表すことができる。もしも、設計と検証でかけた費用を分けることができれば、設計にかけた費用が顕在的な価値、検証にかけた費用を潜在的な価値と見なすことも可能だ。
もし、サブシステムを組織内で作成したのであれば工数を集計して、その工数に何かしらの金額（時給）をかければいいだろう。
それらの評価指標が使えない場合は、しょうがないからプログラムソースコードの実行コード行数にある一定の金額をかければよい。ソフトウェア開発がそもそも人件費で成り立っているのならそれもある程度の根拠となる。
これをすべてのサブシステムに実施すると、どのサブシステムがどれだけの価値を持っているか（いくらかけて作ったのか）が見えてくる。そして、次の開発でそれらのサブシステムのうちどれかをそのまま使うことができたら、使ったサブシステムの価値（開発にかかった費用）ぶん、新しい製品の開発費をセーブできたことになる。一つのサブシステムの開発費が数百万、数千万円になることはよくあるから、サブシステムをまるまる再利用すると数百万円、数千万円ぶん開発費をセーブできたことになる。
これができれば、リコールが発生したときにマイナス側でしか評価されていなかった組込みソフトエンジニアは初めてプラス側の評価を得ることができるようになる。これが定着していけば2010年代には日本でも「開発費をよりセーブできるアーキテクチャを設計したエンジニアが評価される」というソフトウェアエンジニアに対する評価のパラダイムシフトが起きるかもしれない。
日本のソフトウェア開発がぐだぐだになるのは、日本人の「あたたかい人間関係の中のやさしい一員」という特性のせいだとこのブログで書いているが、もうひとつの側面はソフトウェアの価値がハードウェア出身のマネージャのみならず、ソフトウェアエンジニア自身のも見分けがつかないからなのだと思う。
ソフトウェアの価値を高めるにはどうすればいいのかの議論は誰でもする。でも、価値が高まったかどうかの評価指標がないので、声の大きいものの発言に引っ張られ、やってみて成功しても失敗しても結果的にソフトウェアの価値が上がったのか下がったのかがわからない。開発期間の短縮という評価指標は、要求の変更などに振り回されるから正確な判断材料にならない。
だから、ソフトウェアサブシステムに開発費がいくらかかって、次の開発でいくら開発費をセーブできたのかでソフトウェア開発プロジェクトやエンジニア、アーキテクトを評価すると道は拓けるはずだ。再利用が進めば進むほど開発費は数百万、数千万円単位でセーブされていく。それが可視化されると、ソフトウェア資産の再利用が進み、ソフトウェアエンジニアは次の開発でできるだけ手を入れないで資産を再利用するにはどのようなアーキテクチャにすればよいのかを真剣に考えるようになる。アーキテクチャを工夫して再利用が成功すれば、数百万、数千万円単位で費用をセーブすることができ、セーブした費用ぶんがそのアーキテクトのソフトウェア開発効率化の実績になる。
ソフトウェアサブシステムは再利用しているといっても、実はかなり手を入れてしまって実際には派生してしまっていることも多い。しかし、これは構成管理ツールなどと連動してフォルダ内のプログラムソースがどれくらい変更されたのかをウォッチすれば変更量がわかるし、また、どれくらいソフトウェアサブシステムが他のアプリケーションから参照されているかもわかるだろう。ソフトウェアの資産価値のみならず、サブシステムが変更されたことによる注意信号（赤、黄、青）を灯すことも可能だ。
このような情報をソフトウェアサブシステムの価値に換算することで、ソフトウェアの開発を行うたびにソフトウェア資産の価値がダイナミックに変化することが見えるようになる。そのソフトウェアサブシステムを作るためにいくらかけたのか、そのサブシステムは何回再利用されたのかという指標がもっともベーシックな価値になるが、ソフトウェア検証やデバッグにどれくらい費用をかけたのかという指標もソフトウェアの信頼性の価値を判断する指標になるだろう。
「このソフトウェアの性能は最高です」とか「バグを減らしました」とか「バグが出にくいソフトウェアを作りました」なんて主張しても、ソフトウェア開発の経験のない組織の上位にいる人たちは表面的には「良くやったね」と言ってくれるかもしれないが、実際には何のことかさっぱり分からず、それらの情報でソフトウェアエンジニアを評価することはできないだろう。所詮、人間なんて自分の中にない価値基準で説明されても評価なんかしないものだ。
環境が違う場所で育った人たちが互いに理解しあうためには共通の価値基準で語りあう必要がある。メカ、エレキの出身の人たちとソフト屋さんの間で共通理解を得るためには共有できる価値基準を用いて話しをするしかない。
げすな話しと思うかもしれないが、ソフトウェアを作ったことがない、もしくは何十年も前に現役を離れてしまっている人達との共通の価値というのはここではお金のこと指す。ただ、よく考えて欲しいのはお金というのは人類が発明した全世界共通の価値基準であり、金に換算することでほとんどの人がその対象に対して共通の価値を認識できる。
だから、ソフトウェアエンジニアはソフトウェアが見えにくいということを嘆いているのではなく、また、リコールによる負の価値でマイナスに評価されることに甘んじるのではなく、ソフトウェア資産の再利用でいくら開発費用をセーブできたかを可視化すればよいのだ。
そして、開発費用をたくさんセーブできるアーキテクチャが評価され、そのようなアーキテクチャを設計できるアーキテクトが評価される。これこそが、日本版 Value-Driven Architecture である。
ソフトウェア資産の価値を簡単に評価して表現できるようなソフトウェア構成管理ツール、例えば、プログラムソースファイルをチェックイン、チェックアウトするたびにサブシステムのフォルダにソフトウェア資産の価値を表す金額が表示される、フォルダ内のファイルの変更が増えるとフォルダの色が青から黄、赤に変わる、変更が減ると青になるような構成管理ツールが現れたら是非教えて欲しい。すぐ導入するから・・・
2008-11-29
ツールの導入とは自分自身が変化するということ
Embedded Technology 2008 が終わった。5月のESECと11月のETは組込み系の首都圏で開催される2大イベントで、これらの展示会に行くことでツール類の情報や、開発方法論の情報などをチェックする。
日頃、ソフトウェア開発に関するツールについて、「ツール至上主義はいけない」とか「ツールベンダーの口車に乗ってはいけない」などと言っているが、ツールについて最新情報をチェックしていない訳ではない。何が本当に役に立つのか、立たないのかの判断基準を自分の中にしっかり持ってツールを見定めているし、ツールベンダーの話も聞くようにしている。
そういう目で展示会の会場を回っていると、ツールを通してエンジニアを助けてあげたいと思っているツールメーカー、ツールベンダーと、時流にのって売り上げを伸ばすことだけを考えているツールメーカー、ツールベンダーが見分けられるようになる。
ツールメーカーは純粋にソリューションを提供したいと考え、ツールベンダーは売り上げしか考えていないとか、ツールベンダーの営業員によっても目先の売り上げだけを考えている者と、ユーザーと長く付き合うために何とか要望を聞いてあげたいと考える者がいるので、一概にあの会社はいいとか悪いとか言えないが、好ましくないベンダーは好ましくないユーザーがいるからこそ生き残ってしまうのではないかと思うことがある。
ET2008の展示会場で 富士設備工業（株）電子機器事業部 の浅野さんと話しをしていたときのことだ。（富士設備工業なんて、およそソフトウェアと関係ありそうもないが、実は海外の開発ツールを積極的に導入しサポートまで提供している）
富士設備工業（株）電子機器事業部 では、ソフトウェアプロダクトラインの支援ツール pure::variants を取り扱っている。今でこそ、ソフトウェアプロダクトラインはメジャーなキーワードになりつつあるが、たぶん日本で初めて話題になったのは2003年くらいからだと思う。当時、自分はEEBOFでソフトウェアプロダクトラインのことを知り、CQ出版の Interface誌 2003年12月号で『具体例で学ぶ組み込みソフトの再利用技術』というタイトルで自分がモデレータとなってソフトウェアプロダクトラインにも関係する記事を書いた。浅野さんはこの記事をことを覚えていてくれて、当時ソフトウェアプロダクトラインの情報源のひとつとして役に立ったと言ってくれた。
浅野さんとソフトウェアプロダクトラインを日本で成功させるのは簡単ではないという話をしていたら、お客さんの中にはツールを導入しても結果的にうまくいかず、ツールやそのソリューション自体に対して役に立たないという烙印を押してしまい、その経験がトラウマになってしまう人たちもいるということを聞いた。
自分はツールを導入するきっかけは、技術者個人がある状態から別の状態に変化すること、あるいは変化したいと思うことにあると考えている。
現在の状態では問題がある、効率が悪い、品質が上がらないので、それらの問題を解決し、開発効率がよい状態、ソフトウェア品質が高い状態に移行したいと考え、ツールが状態変化に必要だから導入するという考え方だ。
みなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということだ。
ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身（正確に言えばエンジニアの頭の中）がある状態から別の状態に変わるということなのだ。だから、自分自身が変わる気はさらさらなく、ツールがソリューションを提供し成果物を変化させてくれるはずだと考えているとたいてい失敗する。
一番成功する確率が高いのは、技術者が自分自身で状態の変化を手作業で実現し、その手作業の工程を自動でやってもらうといケースだ。手作業で業務なりプロセスなり、活動なりを改善し、その一部をツールに任さるためにツールを導入するケースだ。すでにやったことがあって効率化を図るという方法ならほとんどの場合成功する。
それとは逆に自分自身が変わる気がなく、ツールを魔法の箱にように見たてて期待していても何も起こらない。高い金払ったのだから何か出せと言っても何もでてこない。
ただ、ツールを購入したことをきっかけにして、ツールを使いこなせるようになることで自分自身の変化のきっかけにする人はいると思う。でも、自分自身の変化の必要性の認識とそのたいへんさが十分に理解できていないと結局は途中でくじけてツールはお蔵入りとなる。
世の中には操作者が何も考えなくてもインプットを与えて期待するアウトプットを出力するタイプのツールもたくさんある。でもソフトウェア開発に使うツールはソフトウェア開発自体がひとつの方法論には集約できないのでそんな単機能のツールなど存在しないし、そのような単機能なツールはあったとしても一般化されているのでESECやETで物色することもないのだ。
ソフトウェア開発ツールには結局は何かしらのソリューションが隠蔽されているのだけれど、利用者側はそのソリューションがどんな問題を解決する方法論からきているのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をカスタマイズしてもらわないと問題解決に有効でないこともよくある。
ツールを使うユーザーが自分自身の変化について心の準備ができており、変化しなければならない目的が明確になっており、その目的のためには多少の犠牲も必要というそれなりの根性があればツールは活きてくる。そのようなユーザーに手厚く援助してくれるツールメーカーやツールベンダーを見つけないといけない。
その自信がないユーザーはまずは、ツールを買うのでなくソリューション自体を学習したり、手持ちの道具を使って問題を解決してみることを考えるとよい。解決できる見通しが立ってからツールを導入すれば失敗はしない。
実は、Excel や Word やフリーのツールなどをくふうすることで解決できてしまう問題はたくさんある。そういう努力を日々やっていると、「なんで、わざわざこんなツールを作るの？」とクビをかしげたくなるようなツールも見えるようになってくる。
日頃、ソフトウェア開発に関するツールについて、「ツール至上主義はいけない」とか「ツールベンダーの口車に乗ってはいけない」などと言っているが、ツールについて最新情報をチェックしていない訳ではない。何が本当に役に立つのか、立たないのかの判断基準を自分の中にしっかり持ってツールを見定めているし、ツールベンダーの話も聞くようにしている。
そういう目で展示会の会場を回っていると、ツールを通してエンジニアを助けてあげたいと思っているツールメーカー、ツールベンダーと、時流にのって売り上げを伸ばすことだけを考えているツールメーカー、ツールベンダーが見分けられるようになる。
ツールメーカーは純粋にソリューションを提供したいと考え、ツールベンダーは売り上げしか考えていないとか、ツールベンダーの営業員によっても目先の売り上げだけを考えている者と、ユーザーと長く付き合うために何とか要望を聞いてあげたいと考える者がいるので、一概にあの会社はいいとか悪いとか言えないが、好ましくないベンダーは好ましくないユーザーがいるからこそ生き残ってしまうのではないかと思うことがある。
ET2008の展示会場で 富士設備工業（株）電子機器事業部 の浅野さんと話しをしていたときのことだ。（富士設備工業なんて、およそソフトウェアと関係ありそうもないが、実は海外の開発ツールを積極的に導入しサポートまで提供している）
富士設備工業（株）電子機器事業部 では、ソフトウェアプロダクトラインの支援ツール pure::variants を取り扱っている。今でこそ、ソフトウェアプロダクトラインはメジャーなキーワードになりつつあるが、たぶん日本で初めて話題になったのは2003年くらいからだと思う。当時、自分はEEBOFでソフトウェアプロダクトラインのことを知り、CQ出版の Interface誌 2003年12月号で『具体例で学ぶ組み込みソフトの再利用技術』というタイトルで自分がモデレータとなってソフトウェアプロダクトラインにも関係する記事を書いた。浅野さんはこの記事をことを覚えていてくれて、当時ソフトウェアプロダクトラインの情報源のひとつとして役に立ったと言ってくれた。
浅野さんとソフトウェアプロダクトラインを日本で成功させるのは簡単ではないという話をしていたら、お客さんの中にはツールを導入しても結果的にうまくいかず、ツールやそのソリューション自体に対して役に立たないという烙印を押してしまい、その経験がトラウマになってしまう人たちもいるということを聞いた。
自分はツールを導入するきっかけは、技術者個人がある状態から別の状態に変化すること、あるいは変化したいと思うことにあると考えている。
現在の状態では問題がある、効率が悪い、品質が上がらないので、それらの問題を解決し、開発効率がよい状態、ソフトウェア品質が高い状態に移行したいと考え、ツールが状態変化に必要だから導入するという考え方だ。
みなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということだ。
ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身（正確に言えばエンジニアの頭の中）がある状態から別の状態に変わるということなのだ。だから、自分自身が変わる気はさらさらなく、ツールがソリューションを提供し成果物を変化させてくれるはずだと考えているとたいてい失敗する。
一番成功する確率が高いのは、技術者が自分自身で状態の変化を手作業で実現し、その手作業の工程を自動でやってもらうといケースだ。手作業で業務なりプロセスなり、活動なりを改善し、その一部をツールに任さるためにツールを導入するケースだ。すでにやったことがあって効率化を図るという方法ならほとんどの場合成功する。
それとは逆に自分自身が変わる気がなく、ツールを魔法の箱にように見たてて期待していても何も起こらない。高い金払ったのだから何か出せと言っても何もでてこない。
ただ、ツールを購入したことをきっかけにして、ツールを使いこなせるようになることで自分自身の変化のきっかけにする人はいると思う。でも、自分自身の変化の必要性の認識とそのたいへんさが十分に理解できていないと結局は途中でくじけてツールはお蔵入りとなる。
世の中には操作者が何も考えなくてもインプットを与えて期待するアウトプットを出力するタイプのツールもたくさんある。でもソフトウェア開発に使うツールはソフトウェア開発自体がひとつの方法論には集約できないのでそんな単機能のツールなど存在しないし、そのような単機能なツールはあったとしても一般化されているのでESECやETで物色することもないのだ。
ソフトウェア開発ツールには結局は何かしらのソリューションが隠蔽されているのだけれど、利用者側はそのソリューションがどんな問題を解決する方法論からきているのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をカスタマイズしてもらわないと問題解決に有効でないこともよくある。
ツールを使うユーザーが自分自身の変化について心の準備ができており、変化しなければならない目的が明確になっており、その目的のためには多少の犠牲も必要というそれなりの根性があればツールは活きてくる。そのようなユーザーに手厚く援助してくれるツールメーカーやツールベンダーを見つけないといけない。
その自信がないユーザーはまずは、ツールを買うのでなくソリューション自体を学習したり、手持ちの道具を使って問題を解決してみることを考えるとよい。解決できる見通しが立ってからツールを導入すれば失敗はしない。
実は、Excel や Word やフリーのツールなどをくふうすることで解決できてしまう問題はたくさんある。そういう努力を日々やっていると、「なんで、わざわざこんなツールを作るの？」とクビをかしげたくなるようなツールも見えるようになってくる。
2008-09-01
ソフトウェア工場 vs アジャイル どっちが組込みに向いている？
先日、「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」というタイトルの講演（講師 日本アイ・ビー・エム株式会社ソフトウェア事業 Rational テクニカルセールス＆サービス 藤井 智弘氏）を聴いた。簡単に言うと、IBMによって開発された統合開発環境のEclipseを開発したチームが使用したチームコラボレーション支援ツールを一般向けに使えるように整備するというプロジェクトの話しだ。
オブジェクト指向におけるデザインパターンの有名な本の著者 GoF (Gang of Four) の一人、Erich Gamma もこのプロジェクトにスイスから参加している。
ものすごく表面的でやじうま的な見方をすると、Microsoft が提唱した Software Factories の開発手法とまったく正反対のアプローチを IBM Rational が打ち出した・・・ように感じた。
【Microsoft の Software Factories】
Software Factories の考え方は、開発から運用までのソフトウェア・ライフサイクルの効率化を開発者の側に立って推進する「Dynamic Systems Initiative(DSI)」がベースにあって、Microsoft の戦略に乗っかるのならば、Visual Studio Team System を使っていくことになる。
どちらかと言えばトップダウンのアプローチであり、ソフトウェアプロダクトライン、ドメインエンジニアリングの考え方も踏襲されていて、非常にシステマティックだと感じるし、これまでのソフトウェアエンジニアリングの延長線上にあるように見える。
ただひとつだけ引っかかるのは、優れたアーキテクトがプロジェクト内にいない状態でSoftware Factories のアプローチを進めていくには無理があって、どうしてもやりたい場合はVisual Studio Team System を使うことで Microsoft が用意したアーキテクチャやソフトウェア資産を使うように誘導されてしまうような気がする点である。
また、Visual Studio Team System を使いこなすだけでもソフトウェアエンジニアに相当量の学習が必要がある。ある程度システムの全体構成を構築できてしまえば、その後の開発が飛躍的に効率化できるようになるものの、そこに達するまでのハードルが高いという印象がある。
【IBM Rational の Team Concert】
一方、IBM Rational Team Concert を利用した Jazz プロジェクトは、「分散」「アジャイル」「コラボレーション」といったキーワードからわかるように、どちらかと言えばボトムアップのアプローチで巨大ソフトウェアシステムの開発を成功に導こうとしている。
これまで Agaile は大規模システムへの適用は困難と見られていたが、IBM Rational Team Concert はAgaile のアプローチの人力で提唱されていた部分をすべてシステムに取り込んで、数百人の規模の開発でも、Agail の効果を最大限に引き出すことを目的にしているようだ。
実際、Eclipse の開発で成功した実績があるのだから説得力がある。
Rational Team Concert では、日々の作業はワークアイテムを中心に回っていく。ワークアイテムは「反復する計画と関連するワークアイテムの管理」「ソース管理」「ビルド」「レポート」を含む。
ある拠点に置かれた大量なトランザクションを処理できる強力なサーバー（おそらくはIBMのサーバー）を中心にして、世界中のプログラマーが WEB上のポータルサイトを共有するような感じで、プロジェクトの状況をリアルタイムに見ることができる。各人の写真も掲載され、チャットもできるし、プロジェクトリーダーやコンポーネントの責任者からの指示も共有できる。
共通環境で管理されるのはユーザー間の情報のやりとりとソースファイルであって、分散された環境でそれぞれが持っている個々の開発環境はあまり制限せずに、それらの環境への URL によるリンクのみがツール上で飛び回ることになる。
一方で、プロジェクトの状況は自動的にグラフ化され、それらのグラフを眺めることで開発の進捗を確認したり、品質を推し量ったりできる。
ソース管理に関する機能は重要視されていて、リーダーは各チームが勝手にソースをチェックイン、チェックアウトできなくすることも可能。（チームのコンテキストにより運営ルールをダイナミックに変更できるというところが Rational Team Concert が単なるコミュニケーションツールではなく、コラボレーションツールであるという理由）
【組込みで使えそうか？】
「Rational Team Concert にみるソフトウェア開発におけるチームコラボレーション支援について」の講演を聴いていておもしろかったのは、ソフトウェアシステム開発におけるアーキテクチャの話しはほどんど出てこない点だ。アーキテクチャはコンポーネントアーキテクチャだとのこと。要するにソフトウェアのモジュールをコンポーネントに分けるところまでが重要なポイントで、後は繰り返しリリースを重ねる過程で最適化していくというような考え方に聞こえた。
大人数での Agile 開発での注意点は「コミッターボード」「ガバナンス」「チェックインの制限」ということで、ソフトウェア技術者に勝手気ままにやらせない上手なコントロールをツール上で提供することだということだった。
Rational Team Concert は表面的には出てこないが、プロジェクト内に必ず優秀なアーキテクト兼プロジェクトリーダー（複数人かもしれない）が必要になる。彼または彼らが上手にプログラマー達をコントロールしてソフトウェアシステム開発を成功に導く。表面的は完璧なボトムアップアプローチだ。（表には出てこないが、プロジェクトリーダーのリアルタイムの舵取りがプロジェクトの成功の鍵を握っているため、その意味ではトップダウンとも言えるかもしれない）
Iteration（反復）を数多く繰り返すことに重きが置かれているため、もともとポテンシャルの高い技術者が参加しているのなら、プログラマとしての成長も早いだろう。
ソフトウェアエンジニアリングの歴史から考えると正反対のアプローチのように見えるが、人間工学・組織行動学的には理にかなっているように見える。
IBM Rational Team Concert 的なアプローチがいいのか、Microsoft Software Factories 的なアプローチがいいのか・・・
組込みソフトの世界なら次のようなシナリオで適用したらうまくいくような気がするのだけれどどうだろうか？
（そのドメインの制約条件を含む知識を十分に持ち合わせた優秀なアーキテクトがプロジェクト内にいると仮定して）まず、IBM Rational Team Concert で徹底的に Iteration（反復）を繰り返し、完成度の高いプロトタイプモデルを作る。次に、できあがったプロトタイプモデルのアーキテクチャとドメインの要求がどのようにすり合わされたのかを分析し、今後同様の製品群を作成するためのプロセスモデル、ドメインモデル、アーキテクチャを Visual Studio Team System を使って設計し、可視化されたモデルをレビューし洗練させる。システムの品質が担保できるようにテスト計画を立て、すでに実施されているテスト結果を利用しながらシステム全体の Verification（検証）と Validation（妥当性確認）を確立する。
個人的な感想を言うと、IBM Rational Team Concert では、開発チームのパフォーマンスは最大になるように思うが、開発チームはシステムの品質をも担保できているようには見えない。（システム品質の説明責任を果たすことが難しい） 開発のパフォーマンスを最大限に上げることでシステム品質までも凌駕してしまおうというアプローチであり、根拠ははっきりしないが実効性はあるようにも感じる。（優秀なアーキテクト兼プロジェクトリーダーの存在が必須）
一方、 Visual Studio Team System では、プロセスモデル、ドメインモデル、アーキテクチャを構築するハードルが高く、それを実現できるプロジェクトは非常に少ない。道筋がつけられるまでを外部の優秀なアーキテクトにコンサルテーションしてもらうことは可能だが、効果が現れるまで時間がかかるし、効果が現れるまでに必要な時間や費用を組織内で確保するのが難しい。
でも、どちらのアプローチにも必要なのはドメインの知識に精通したアーキテクトの存在だ。ドメインの知識に精通したアーキテクトを育てるためには、Iteration（反復）をできるだけ回した方がいいから、IBM Rational Team Concert の方を先に取り入れた方がよいかもしれない。
【参考資料】
Rational Team Concert に関して Jazzプロジェクト
Eclips （Wikipedia)
Erich Gamma（Wikipedia)
Visual Sstudio Team System に関して(Microsoft)
Software Factories に関して(@it)
2008-03-08
三菱電機の携帯電話事業撤退で見えること
三菱電機が携帯電話事業から撤退することを決めた。
このニュースで驚いたのは三菱電機が作っていた携帯電話の数がシェアトップでもないのに2007年度で210万台もあったということだ。売上金額は1000億円とのこと。単純計算でも1台あたり4万7千円で売ったことになる。
これまで日本では消費者が知らないうちに携帯電話の価格の一部を通話料金に上乗せして月賦で払っていた。携帯電話のショップは携帯電話を1台売ると携帯電話のキャリアから販売奨励金を3～4万円程度もらっていた。（金額は正確でない） だから、携帯電話の売値を仕入れ価格よりも下げても赤字にならなかった。携帯を1円で売っても損しないカラクリはここにある。そして、この販売奨励金の金額は携帯電話のキャリアがユーザーから徴収する毎月の基本料金に上乗せしてしていた。
ローンでものを買うのが嫌いな人もいると思うが、ローンを組まされているとも知らずに実際の価格よりも見かけ上2～4万円も安く買っていた人が何百万人もいるということだ。
この携帯電話の価格を見かけ上安く見せかける販売方法は総務省の要請でもうなくなっている。この結果何が起こるか。それは、現在の日本の携帯電話の本当の価格が日の目にさらされるということだ。（総務省の通達：携帯電話に係る端末価格と通信料金の区分の明確化に関する携帯電話事業者等への要請）
これまで3万円台で買っていたものが、販売価格が5万円くらいになり月々の通話料金が安くなる。1～2年使い続ければトータルで同じではないかと思うかもしれないが、本当にそうだろうか。
あなたは今携帯電話を持っていて特に不自由なく使えているのに、5万円も6万円もする新しい携帯電話を買い換えようと思うだろうか？
3万円なら少し考えて「よし買おう」という金額だと思うが、5万円の買い物をするのにはそれなりの決心がいるし、自分だけでなく家族を納得させるだけの根拠もいるだろう。
日本の携帯電話はNokiaなどの海外の携帯電話に比べて機能が（異常に）多いと言われている。確かに自分も携帯電話の機能を使い切れてはいない。
【よく使う機能】
・電話として使う
・メールを読み書きする
・今の時間を見る
・WEBブラウザでニュースを確認する
【たまに使う機能】
・写真を撮る
・パソコンにつないでパケット通信する
・アドレス帳の管理
・留守番電話を聞く
【滅多に使わない機能】
・音楽を聴く
・スケジュールを管理する
・アラームをかける
・動画を撮る、見る。
・QRコードを読み取る
・USBマスストレージとして使う
・電卓として使う
自分の場合、冷静に考えれば留守番電話を含む電話機能とメール、WEBブラウザだけでもいいかなと思う。
それなのになぜ、こんなにたくさんの機能を搭載した携帯電話を買うのか、ワンセグのテレビを見たいがために6万円も7万円も出費するのだろうか？
普通に考えれば、商品ラインナップの中でハイエンド機種は機能も多いが価格も高く出荷台数はスタンダードモデルよりも少ない。商品ラインナップの中間に位置するスタンダードモデルや下層のバリュアブルモデルが一番数がでるのが普通だろう。
日本では携帯電話では見せかけの販売価格のからくりがあったために、市場価格が故意にゆがめられ本当は価格が高いハイエンドモデルがばかばか売れていたのではないかと思う。
三菱電機が携帯電話事業から撤退した理由の一つに、今後ハイエンドモデルの売り上げは減り、ますます携帯電話で利益を上げるのが難しくなるという予測があったのだろう。傷口を広げる前の判断としてはタイミングがよかったのではないか。
今後、携帯電話の販売価格が軒並み2万～3万円高くなることで、組込みソフトの世界にも変化が現れそうだ。
日本人は組込み製品の商品コンセプトを考えるのが下手だ。その商品、その組織のアドバンテージとなる機能や性能を前面に出し、その他の部分をそぎ落として特長を際だたせることができない。どんどん機能を追加する。
特に、材料費のアップにつながらないソフトウェアの機能追加については「A社にあってウチにないのなら入れろ」とは言っても「その機能を入れると特長がぼやけるからやめておけ」とは決して言わない。
個人的にはプロダクトマネージャの商品に対する自信のなさがこう言わせているのではないかと思っている。商品をリリースしてライバル会社に売り上げで負けたときに「あっちには○○の機能があるが、ウチにはないからだ」と営業に言われたとき反論できないのでカタログスペック上だけでも他社に負けないようにしておきたいのだ。これではユーザーの本当のニーズを考えた商品開発ができていない。
一言でいえばユーザーオリエンテッドの仕様立案ができない、マーケティングができていない、商品戦略がないということなのだが、この傾向は日本全体に多く見られ組込みソフトエンジニアを苦しめる一つの要因になっている。
携帯電話の見せかけの販売価格の件は、何でもかんでも機能を突っ込めばいいという日本の企業によく見られる幼稚な商品戦略を助長させた。その結果、ユーザーはたいして使わない機能満載の商品を見かけ上本当の価格よりも2万円～3万円安いという理由で「まいっか」というノリで買っていた。
これまでの携帯電話の価格体系は「5万円とか6万円もするなら、もっとシンプルな機能の商品を買おう」という一番多い層の顧客の行動が表面にでないように消費者を暗に誘導してきた。
このことはグローバルマーケットでは Nokia などのシンプルな携帯電話が圧倒的に多く売れており、日本だけで本当は価格が高い端末が何百万台も売れていることで分かると思う。
さて、三菱電機の携帯電話事業からの撤退をきっかけに、携帯電話のソフト開発で食べてきた受託ソフトウェア会社は仕事を失うところが出てくるではないかと考えている。
携帯電話に限らず、日本の組込みソフトウェアはメーカーのエンジニア以上にソフトウェアの受託開発会社のソフトウェアエンジニアのマンパワーに頼っているところがある。
もちろん、日本では携帯電話以外にも組込みソフト技術者の需要はたくさんあるので供給が需要を上回ることはないと思うが、三菱電機の携帯電話事業の撤退で取引先のソフトハウスは新しい仕事を探すのにやっきになっているに違いない。
メーカーサイドは約600人の携帯電話関連の人員を別の部門に振り分けることができるが、ソフトハウスはクライアントとの付きあいをいったん切られると新たなつながりを探すのは意外に難しい。
三菱電機の携帯電話事業の売り上げが1000億円で、ソフトウェア開発費比率が仮に5%だとすれば開発費は50億円だ。この50億円の多くがソフトハウスへの発注だったとすれば、この仕事が突然なくなるわけだし、今後、業界全体で携帯電話の外部発注ソフトウェア開発自体が大幅に減る可能性がある。
極端な話、これまでユーザーは携帯電話の使いもしない付け足し機能のソフトウェア開発費に対して1台あたり5千円以上払っていたことになり、この5千円の積み重ねの50億円が今回消えることになったとも考えられる。
こんな局所的なバブルを生み出してしまった原因は日本の組込み機器メーカーの商品戦略のなさではないだろうか。日本の組込み機器メーカーもそろそろ新製品＝（ソフトウェアによる）機能の付け足しという考え方をやめたらどうだろう。
機能を付け足すだけの頭を使う必要のない誰でも考えつく幼稚な商品戦略が減少し、贅肉をそぎ落として特長を際だたせるような骨太の商品コンセプトが当たり前になっていけば、その市場に投入すべき商品群の特長が明確になり、自組織の得意な部分を活かした再利用すべきソフトウェア資産がなにかが見えてくるはずだ。
本当かどうかは知らないが Nokia はそれを成功させたと聞いている。（プロダクトラインがNEのカバーストーリーに登場を参照のこと）
このニュースで驚いたのは三菱電機が作っていた携帯電話の数がシェアトップでもないのに2007年度で210万台もあったということだ。売上金額は1000億円とのこと。単純計算でも1台あたり4万7千円で売ったことになる。
これまで日本では消費者が知らないうちに携帯電話の価格の一部を通話料金に上乗せして月賦で払っていた。携帯電話のショップは携帯電話を1台売ると携帯電話のキャリアから販売奨励金を3～4万円程度もらっていた。（金額は正確でない） だから、携帯電話の売値を仕入れ価格よりも下げても赤字にならなかった。携帯を1円で売っても損しないカラクリはここにある。そして、この販売奨励金の金額は携帯電話のキャリアがユーザーから徴収する毎月の基本料金に上乗せしてしていた。
ローンでものを買うのが嫌いな人もいると思うが、ローンを組まされているとも知らずに実際の価格よりも見かけ上2～4万円も安く買っていた人が何百万人もいるということだ。
この携帯電話の価格を見かけ上安く見せかける販売方法は総務省の要請でもうなくなっている。この結果何が起こるか。それは、現在の日本の携帯電話の本当の価格が日の目にさらされるということだ。（総務省の通達：携帯電話に係る端末価格と通信料金の区分の明確化に関する携帯電話事業者等への要請）
これまで3万円台で買っていたものが、販売価格が5万円くらいになり月々の通話料金が安くなる。1～2年使い続ければトータルで同じではないかと思うかもしれないが、本当にそうだろうか。
あなたは今携帯電話を持っていて特に不自由なく使えているのに、5万円も6万円もする新しい携帯電話を買い換えようと思うだろうか？
3万円なら少し考えて「よし買おう」という金額だと思うが、5万円の買い物をするのにはそれなりの決心がいるし、自分だけでなく家族を納得させるだけの根拠もいるだろう。
日本の携帯電話はNokiaなどの海外の携帯電話に比べて機能が（異常に）多いと言われている。確かに自分も携帯電話の機能を使い切れてはいない。
【よく使う機能】
・電話として使う
・メールを読み書きする
・今の時間を見る
・WEBブラウザでニュースを確認する
【たまに使う機能】
・写真を撮る
・パソコンにつないでパケット通信する
・アドレス帳の管理
・留守番電話を聞く
【滅多に使わない機能】
・音楽を聴く
・スケジュールを管理する
・アラームをかける
・動画を撮る、見る。
・QRコードを読み取る
・USBマスストレージとして使う
・電卓として使う
自分の場合、冷静に考えれば留守番電話を含む電話機能とメール、WEBブラウザだけでもいいかなと思う。
それなのになぜ、こんなにたくさんの機能を搭載した携帯電話を買うのか、ワンセグのテレビを見たいがために6万円も7万円も出費するのだろうか？
普通に考えれば、商品ラインナップの中でハイエンド機種は機能も多いが価格も高く出荷台数はスタンダードモデルよりも少ない。商品ラインナップの中間に位置するスタンダードモデルや下層のバリュアブルモデルが一番数がでるのが普通だろう。
日本では携帯電話では見せかけの販売価格のからくりがあったために、市場価格が故意にゆがめられ本当は価格が高いハイエンドモデルがばかばか売れていたのではないかと思う。
三菱電機が携帯電話事業から撤退した理由の一つに、今後ハイエンドモデルの売り上げは減り、ますます携帯電話で利益を上げるのが難しくなるという予測があったのだろう。傷口を広げる前の判断としてはタイミングがよかったのではないか。
今後、携帯電話の販売価格が軒並み2万～3万円高くなることで、組込みソフトの世界にも変化が現れそうだ。
日本人は組込み製品の商品コンセプトを考えるのが下手だ。その商品、その組織のアドバンテージとなる機能や性能を前面に出し、その他の部分をそぎ落として特長を際だたせることができない。どんどん機能を追加する。
特に、材料費のアップにつながらないソフトウェアの機能追加については「A社にあってウチにないのなら入れろ」とは言っても「その機能を入れると特長がぼやけるからやめておけ」とは決して言わない。
個人的にはプロダクトマネージャの商品に対する自信のなさがこう言わせているのではないかと思っている。商品をリリースしてライバル会社に売り上げで負けたときに「あっちには○○の機能があるが、ウチにはないからだ」と営業に言われたとき反論できないのでカタログスペック上だけでも他社に負けないようにしておきたいのだ。これではユーザーの本当のニーズを考えた商品開発ができていない。
一言でいえばユーザーオリエンテッドの仕様立案ができない、マーケティングができていない、商品戦略がないということなのだが、この傾向は日本全体に多く見られ組込みソフトエンジニアを苦しめる一つの要因になっている。
携帯電話の見せかけの販売価格の件は、何でもかんでも機能を突っ込めばいいという日本の企業によく見られる幼稚な商品戦略を助長させた。その結果、ユーザーはたいして使わない機能満載の商品を見かけ上本当の価格よりも2万円～3万円安いという理由で「まいっか」というノリで買っていた。
これまでの携帯電話の価格体系は「5万円とか6万円もするなら、もっとシンプルな機能の商品を買おう」という一番多い層の顧客の行動が表面にでないように消費者を暗に誘導してきた。
このことはグローバルマーケットでは Nokia などのシンプルな携帯電話が圧倒的に多く売れており、日本だけで本当は価格が高い端末が何百万台も売れていることで分かると思う。
さて、三菱電機の携帯電話事業からの撤退をきっかけに、携帯電話のソフト開発で食べてきた受託ソフトウェア会社は仕事を失うところが出てくるではないかと考えている。
携帯電話に限らず、日本の組込みソフトウェアはメーカーのエンジニア以上にソフトウェアの受託開発会社のソフトウェアエンジニアのマンパワーに頼っているところがある。
もちろん、日本では携帯電話以外にも組込みソフト技術者の需要はたくさんあるので供給が需要を上回ることはないと思うが、三菱電機の携帯電話事業の撤退で取引先のソフトハウスは新しい仕事を探すのにやっきになっているに違いない。
メーカーサイドは約600人の携帯電話関連の人員を別の部門に振り分けることができるが、ソフトハウスはクライアントとの付きあいをいったん切られると新たなつながりを探すのは意外に難しい。
三菱電機の携帯電話事業の売り上げが1000億円で、ソフトウェア開発費比率が仮に5%だとすれば開発費は50億円だ。この50億円の多くがソフトハウスへの発注だったとすれば、この仕事が突然なくなるわけだし、今後、業界全体で携帯電話の外部発注ソフトウェア開発自体が大幅に減る可能性がある。
極端な話、これまでユーザーは携帯電話の使いもしない付け足し機能のソフトウェア開発費に対して1台あたり5千円以上払っていたことになり、この5千円の積み重ねの50億円が今回消えることになったとも考えられる。
こんな局所的なバブルを生み出してしまった原因は日本の組込み機器メーカーの商品戦略のなさではないだろうか。日本の組込み機器メーカーもそろそろ新製品＝（ソフトウェアによる）機能の付け足しという考え方をやめたらどうだろう。
機能を付け足すだけの頭を使う必要のない誰でも考えつく幼稚な商品戦略が減少し、贅肉をそぎ落として特長を際だたせるような骨太の商品コンセプトが当たり前になっていけば、その市場に投入すべき商品群の特長が明確になり、自組織の得意な部分を活かした再利用すべきソフトウェア資産がなにかが見えてくるはずだ。
本当かどうかは知らないが Nokia はそれを成功させたと聞いている。（プロダクトラインがNEのカバーストーリーに登場を参照のこと）
2007-12-21
ソフトウェア開発工程の区切りが見えない
ソフトウェア開発の場合、開発工程の区切りがよく見えないことがある。例えば、次のような工程（プロセス）の区切りを明確に見分ける方法は存在するだろうか？
1．ソフトウェア開発計画
2. ソフトウェア要求分析
3. ソフトウェアアーキテクチャ設計
4. ソフトウェアユニットの実装と検証
5. ソフトウェア結合
6. ソフトウェアシステム試験
7. ソフトウェアリリース
別にウォーターフローのプロセスじゃなくてもいい、インクリメンタルでも、ユニファイドプロセスでもなんでもいいが、どこが区切りかどうやって内外に示すのか？
電気回路の設計なら、プリント基板の完成や部品の実装という形で明確に一次試作や二次試作の工程のくぎりが見える。部品が実装され一通りのテストが終わったら「じゃあ、飲みに行こうか」と言える。
しかし、ソフトウェア開発の場合、工程の区切りが曖昧なので、「ソフトウェア開発計画が完成したから一区切りついた」とか、「ソフトウェア要求仕様ができあがったので飲みに行こう」という感じにはなかなかならない。ソフトウェア開発の工程で区切りが明確に分かるのはソフトウェアをリリースするときだけなのだろうか。
ソフトウェア開発の上流工程は特に少数の技術者、場合によってはひとりの技術者の作業に集約されてしまうことが多いから達成感や区切りが見えにくい。
ソフトウェア開発の工程の区切りを見るのに一番分かりやすいのが、アウトプットとなるドキュメントの完成だ。ソフトウェア開発計画工程のアウトプットとしてソフトウェア開発計画書、ソフトウェア要求分析工程のアウトプットとしてソフトウェア要求仕様書を作成する。これらのドキュメントが完成したことで工程の区切りを判断することができる。
ところが、これらのドキュメントで明確に分かるのは書類があるかないかであって、その工程内で実施すべきアクティビティがキチンと実施されたのかどうかはドキュメントの中身を精査したり、プロジェクトにインタビューしたりしないとわからない。電気設計のように「回路図がを出図した！」とか「実装されたプリント基板が動いた！」というほど工程が完了したというインパクトがない。
ソフトウェア開発の場合、悲しいかなドキュメントの中身をキチンとレビューできるレビューワーがいないと、各工程でやるべきことが実施されたかどうかも分からない。工程の区切りが明確でなく、工程のアウトプットドキュメントをきちんレビューできないと、結果としてぐだぐだになってしまりのない開発になる。
しまりがないというのは、計画通りにプロジェクトを進めるとか、ここから先は要求仕様の変更はしないとか、アーキテクチャは大幅に変更しないとかいった判断ができず、プロジェクトリーダーやプロジェクトメンバの個人的な判断、個人的な折衝力で、変更要求をはね返したり、プロジェクトの舵取りをしなければいけない状態のことだ。
ソフトウェアプロジェクトの内外から「ソフトウェアはいつでも変更できる」と見られていると、変更がソフトウェアシステムに与える影響を考えずに開発工程の後半であっても、プロジェクトは変更要求を受け入れてしまう。
複雑な仕事を成し遂げるには、当然のごとく最初の段取りをしっかりしておかないといけないが、開発工程の最初の方がぐだぐだのプロジェクトは開発の後工程で相当苦労する。
日本の組込みソフトウェア開発では、20年も30年も前は、もともと明確な「プロセス」を設定して、ひとつずつ前に進む仕事の進め方ではなく、試行錯誤でソフトウェアを作成し、プロトタイプを動かしてみて問題があったらすぐ直すという作り方をしてきてその進め方が体に染みついているので、にわかルールで開発プロセスが定めてもすぐに形骸化してぐだぐだの開発になりがちだ。
メインフレームのソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えた時点で、試行錯誤的なやり方では開発が完了しないことがわかり、プロセスアプローチの重要性が認識された。
組込みソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えていない開発が多いので、まだ、試行錯誤的なやり方では開発が完了しないという事態にまでは至っていないのではないだろうか。
そして、日本ではそんなぐだぐだな開発プロジェクトがたくさんあるはずなのになんだかんだいって製品はちゃんとリリースされていく。
おそらく、ギリギリのところで破綻していない理由は開発の前工程がぐだぐだでも、後工程で残業してがんばってなんとかつじつま合わせているのだと思う。表面的には破綻していないように見えて、プロジェクトメンバーの中には倒れている者もいるかもしれない。
このぐだぐだの先の見えない開発スタイルの流れはこのブログでも何度となく言っているように実際に開発に関わっている技術者が幸せになる目がない。毎回、前工程ぐだぐだで後工程でがんばるというやり方を繰り返していると、ソフトウェアの規模が増大し複雑化していくので、後工程でがんばる部分の負担がどんどん増えていく。
開発を重ねるたびに楽になっていくとか、クリエイティブなことを考える時間が増えるとかいった感じがしない。自分が不思議なのはこの悪循環な状況を改善したいと考える、もしくは、改善しなければ自分たちに明日はないと考える組込みソフトエンジニアが驚くほど少ないということだ。
なぜ、少ないのかはいろいろ理由があると思うが一番大きな理由は、このままではダメだと思っても状況を改善するには各方面に働きかけをしないといけない、人間系の壁を動かさないといけない、自分たちはソフトウェアを作るのは好きだけれど、人を動かすのは得意じゃないし面倒だと考えいるからではないだろうか。または、改善をして開発が楽になるというイメージを想像することができないのか。
自分が考える「開発を重ねるたびに楽になっていく開発」「クリエイティブなことを考える時間が増える開発」とは、その製品や製品群の価値が凝縮されているソフトウェア資産を明確にし、その資産の完成度を高めて再利用し、再利用資産を徐々に積み重ねていく開発だ。
これは一回の開発ではうまくいかない。何回か開発を重ねていくたびに徐々に楽になっていく。そして、再利用資産を抽出して隔離するときが一番時間も工数もかかる。だから、約三回の開発を経て効果がでることをプロジェクトの内外に説明して納得してもらう必要がある。
ぐだぐだの開発から抜け出せない理由は、複数の開発という長期レンジの視点を組織上位層もプロジェクトも持てていないのと、「最初は時間がかかるが、次かその次には開発効率とソフトウェア品質は確実に改善する」と宣言する自信とか気迫がないからだと思う。
組込みソフト開発の現状を打開するには、複数回の製品開発のプランとソフトウェア開発の技術の修得と変革を宣言して実行するリーダーシップのすべてが必要となる。
1．ソフトウェア開発計画
2. ソフトウェア要求分析
3. ソフトウェアアーキテクチャ設計
4. ソフトウェアユニットの実装と検証
5. ソフトウェア結合
6. ソフトウェアシステム試験
7. ソフトウェアリリース
別にウォーターフローのプロセスじゃなくてもいい、インクリメンタルでも、ユニファイドプロセスでもなんでもいいが、どこが区切りかどうやって内外に示すのか？
電気回路の設計なら、プリント基板の完成や部品の実装という形で明確に一次試作や二次試作の工程のくぎりが見える。部品が実装され一通りのテストが終わったら「じゃあ、飲みに行こうか」と言える。
しかし、ソフトウェア開発の場合、工程の区切りが曖昧なので、「ソフトウェア開発計画が完成したから一区切りついた」とか、「ソフトウェア要求仕様ができあがったので飲みに行こう」という感じにはなかなかならない。ソフトウェア開発の工程で区切りが明確に分かるのはソフトウェアをリリースするときだけなのだろうか。
ソフトウェア開発の上流工程は特に少数の技術者、場合によってはひとりの技術者の作業に集約されてしまうことが多いから達成感や区切りが見えにくい。
ソフトウェア開発の工程の区切りを見るのに一番分かりやすいのが、アウトプットとなるドキュメントの完成だ。ソフトウェア開発計画工程のアウトプットとしてソフトウェア開発計画書、ソフトウェア要求分析工程のアウトプットとしてソフトウェア要求仕様書を作成する。これらのドキュメントが完成したことで工程の区切りを判断することができる。
ところが、これらのドキュメントで明確に分かるのは書類があるかないかであって、その工程内で実施すべきアクティビティがキチンと実施されたのかどうかはドキュメントの中身を精査したり、プロジェクトにインタビューしたりしないとわからない。電気設計のように「回路図がを出図した！」とか「実装されたプリント基板が動いた！」というほど工程が完了したというインパクトがない。
ソフトウェア開発の場合、悲しいかなドキュメントの中身をキチンとレビューできるレビューワーがいないと、各工程でやるべきことが実施されたかどうかも分からない。工程の区切りが明確でなく、工程のアウトプットドキュメントをきちんレビューできないと、結果としてぐだぐだになってしまりのない開発になる。
しまりがないというのは、計画通りにプロジェクトを進めるとか、ここから先は要求仕様の変更はしないとか、アーキテクチャは大幅に変更しないとかいった判断ができず、プロジェクトリーダーやプロジェクトメンバの個人的な判断、個人的な折衝力で、変更要求をはね返したり、プロジェクトの舵取りをしなければいけない状態のことだ。
ソフトウェアプロジェクトの内外から「ソフトウェアはいつでも変更できる」と見られていると、変更がソフトウェアシステムに与える影響を考えずに開発工程の後半であっても、プロジェクトは変更要求を受け入れてしまう。
複雑な仕事を成し遂げるには、当然のごとく最初の段取りをしっかりしておかないといけないが、開発工程の最初の方がぐだぐだのプロジェクトは開発の後工程で相当苦労する。
日本の組込みソフトウェア開発では、20年も30年も前は、もともと明確な「プロセス」を設定して、ひとつずつ前に進む仕事の進め方ではなく、試行錯誤でソフトウェアを作成し、プロトタイプを動かしてみて問題があったらすぐ直すという作り方をしてきてその進め方が体に染みついているので、にわかルールで開発プロセスが定めてもすぐに形骸化してぐだぐだの開発になりがちだ。
メインフレームのソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えた時点で、試行錯誤的なやり方では開発が完了しないことがわかり、プロセスアプローチの重要性が認識された。
組込みソフトウェア開発の世界では、ソフトウェアの規模と複雑性が限界を超えていない開発が多いので、まだ、試行錯誤的なやり方では開発が完了しないという事態にまでは至っていないのではないだろうか。
そして、日本ではそんなぐだぐだな開発プロジェクトがたくさんあるはずなのになんだかんだいって製品はちゃんとリリースされていく。
おそらく、ギリギリのところで破綻していない理由は開発の前工程がぐだぐだでも、後工程で残業してがんばってなんとかつじつま合わせているのだと思う。表面的には破綻していないように見えて、プロジェクトメンバーの中には倒れている者もいるかもしれない。
このぐだぐだの先の見えない開発スタイルの流れはこのブログでも何度となく言っているように実際に開発に関わっている技術者が幸せになる目がない。毎回、前工程ぐだぐだで後工程でがんばるというやり方を繰り返していると、ソフトウェアの規模が増大し複雑化していくので、後工程でがんばる部分の負担がどんどん増えていく。
開発を重ねるたびに楽になっていくとか、クリエイティブなことを考える時間が増えるとかいった感じがしない。自分が不思議なのはこの悪循環な状況を改善したいと考える、もしくは、改善しなければ自分たちに明日はないと考える組込みソフトエンジニアが驚くほど少ないということだ。
なぜ、少ないのかはいろいろ理由があると思うが一番大きな理由は、このままではダメだと思っても状況を改善するには各方面に働きかけをしないといけない、人間系の壁を動かさないといけない、自分たちはソフトウェアを作るのは好きだけれど、人を動かすのは得意じゃないし面倒だと考えいるからではないだろうか。または、改善をして開発が楽になるというイメージを想像することができないのか。
自分が考える「開発を重ねるたびに楽になっていく開発」「クリエイティブなことを考える時間が増える開発」とは、その製品や製品群の価値が凝縮されているソフトウェア資産を明確にし、その資産の完成度を高めて再利用し、再利用資産を徐々に積み重ねていく開発だ。
これは一回の開発ではうまくいかない。何回か開発を重ねていくたびに徐々に楽になっていく。そして、再利用資産を抽出して隔離するときが一番時間も工数もかかる。だから、約三回の開発を経て効果がでることをプロジェクトの内外に説明して納得してもらう必要がある。
ぐだぐだの開発から抜け出せない理由は、複数の開発という長期レンジの視点を組織上位層もプロジェクトも持てていないのと、「最初は時間がかかるが、次かその次には開発効率とソフトウェア品質は確実に改善する」と宣言する自信とか気迫がないからだと思う。
組込みソフト開発の現状を打開するには、複数回の製品開発のプランとソフトウェア開発の技術の修得と変革を宣言して実行するリーダーシップのすべてが必要となる。
2007-10-19
マーケティングと商品コンセプト
日経ビジネスオンラインに「ハンズは30年前からロングテールだった！」という和田けんじさんの記事が載っていた。
ロングテールとは簡単に言えば、それほど売れ筋ではない商品でもインターネットのようなバーチャルストアーで扱うことで、ながーい期間棚に陳列しておけば、トータルで十分に儲かるということだ。需要曲線が長い尾を引くことからロングテールと呼ばれる。
さて、和田けんじさんは16年間東急ハンズに勤めた経験から、マーケティングの考え方について記事を書いている。
【「市場調査が個性を殺す」より引用】
企業は、市場を調査し需要を確認してから店舗を展開します。需要が存在しないところに大切な資金を投入したくありませんから、「顧客はいるのか」「利益は見込めるのか」しっかり調査します。
しかし、大抵の企業のマーケティングの結果にそれほどの違いはありません。その結果を基本に店作りをするわけですから、名前が違うだけで、同じような品揃えの、同じようなコンセプトのお店ばかりになってしまいます。
これでは、消費者にとって魅力のあるおお店にはなりません。
【引用終わり】
東急ハンズは言わずと知れた、売れ筋のみに固執せず、豊富かつ専門的に商品を展開する店で、現在のネット通販に見られるロングテールビジネスを30年も前から店頭でやっている。
和田けんじさんは15年前に、バス・トイレタリー用品の担当だった時、バス用品の売り上げの90％以上を占める大定番のプラスチック製の製品とは別に高価な上に使わない時は日陰干しにするなどしないと、すぐカビが生えたりヒビが入ったりする檜の風呂椅子・風呂桶・ひしゃく・石鹸台・湯かき棒を仕入れたそうだ。
プラスチックの風呂椅子が高くても2000円くらいなのに対し、檜のそれは1万円を超えていた。今でこそ、バスタイムを楽しもうという提案も珍しくないが、「オーガニックブーム」でも「癒やしブーム」でもなかった頃に、そうやすやすとは檜のバス用品は買ってもらえなかった。
売れ筋を後ろに下げて、この檜シリーズを棚の一番目につくところに陳列までしてもすぐには売れなかった。それでも、上司は、そんな売れない檜シリーズの展開をやめろとは言わなかったそうだ。
むしろ、品物の良さをすぐ理解し、慈しむように眺めては、「買っていただけた？」と目を輝かせて毎日のように聞いてきたとのこと。
そうこうするうち、次第に商品の良さが理解されるようになり、結果的には大変多くの客様にご購入いただくことができた。
当時の和田さんの考えは、プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないかというものだった。
今日のブログのテーマはこの話から学ぶ「組込み機器開発のマーケティングと商品コンセプト」についてである。
和田けんじさんは「市場調査が個性を殺す」と書いているが、組込み機器開発ではものを作ることから始まるので、最初から市場で売れ筋の他社製品のマネだけすることは少ない。
多くのメーカーは（商社ではないので）商品の仕入れ方で独自性を出すのではなく、機能や性能で独自性を出すことを考えている。もっとも安易な開発手法として、市場で売れ筋の商品とまったく同じ機能でコストを安く、販売価格を下げるという戦略はあるが、その方法はアジア諸国と勝負できないし、人件費が高くなってしまった日本では利益がでないのでもう誰もやらない。
そうなると、次に考えるのが売れ筋の他社製品にプラスアルファの機能を付けて、カタログスペックで機能や性能を表にしたとき一つだけ抜きんでるようにするという作戦だ。これを繰り返し行くと同じ市場に同じような商品を投入するA社、B社、C社、D社が次々に同じことをするので、機能比較の表がどんどん長くなってくる。
この安易な商品戦略の考え方（戦略と呼べるようなものではないが・・・）は、日本の組込みソフトエンジニアに長い間習慣として染みついてしまった試行錯誤・付け足しのソフトウェア開発のスタイルにベストフィットする。
商品群を何世代にも渡って、機能を付け足し続け、ユーザークレームを払拭するように改善し続ける。この取り組みは一見顧客満足を高める方向にしか進まないように見えるが、実はそうではない。
デメリットは2つ。
ユーザーサイドのデメリットは、本当に欲しい機能以外の機能がたくさんついていて使いこなせなくなるというデメリットだ。使わない機能は放っておけばよいという考え方もあるが、使わない機能のユーザーインターフェースが本当に使いたい機能の操作を迷わせることも多々あるのでそう簡単ではない。
普通に考えれば商品に機能を追加していけばコストが高くなるはずだが、ソフトウェアで機能を追加していく場合、材料費アップにはつながらず開発費だけがアップするので、開発費のアップぶんをエンジニアのオーバーワークであらかたカバーしてしまえばメーカーサイドの痛手は少ない。
となると、メーカーサイドのデメリットは、ソフトウェア資産の再利用性の低下だろう。機能を付け足し付け足ししていくということは、すなわち明確な商品コンセプトがなく、長期的な再利用戦略がないままに最初に考えたアーキテクチャを引きずりながら、だましだまし進んでいくということになるため、結果的に再利用資産を中心に派生開発を行うことができない、もしくは難しい。
ようするに、売れ筋商品を思い浮かべてプラスアルファする、そのとき流行のデバイスを使ってみる、といったそれほど頭を使わないマーケティング、商品開発を続けていると、顧客満足も高まらない、開発効率も上がらないという悪循環の道に入り込んでいく可能性が高い。商品の外見を変えると一瞬、市場やユーザーも振り向くが、本当に使い勝手がよい商品でないと支持が長続きしない。長続きしないから、また短期間に付け足し商品を開発しようとする。
このような悪循環から脱出するには、「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」というユーザーサイドに立った商品コンセプトを打ち立て、そのコンセプトを開発の最初から最後まで貫くことが必要だ。
コンセプトを明確にして商品開発を行うのが得意なのは食品や生活用品の開発者だろう。商品コンセプトの善し悪しが売り上げに明確に反映するような商品の場合、自ずと商品コンセプトの重要性は開発チームに伝わる。
ところが、組込み機器、組込みソフトウェアの開発には商品開発に多くの知識・技術が必要なため、商品コンセプトよりもどうやって機能や性能を実現すべきかという方法論の方に技術者の興味が向かいがちだ。しかし、組込み機器の開発では制約条件と機能・性能とのトレードオフが必ず発生するので、商品コンセプトが明確でないと開発チームの方向性が右に左に揺れて、大きなソフトウェアの仕様変更が何回も発生してしまう。
自分のスキルを駆使して機能や性能を実現することに生き甲斐を感じている組込みソフトウェアエンジニアにとっては、右に左に揺れる仕様変更さえ「やったるぜ」と張り切って取り組む者もいるだろう。
でも、その付け足しアプローチを続けていると、開発効率は上がらず、ソフトウェア品質は下がり、ユーザーにも「使えない」商品になってしまう。
だからこそ、組込み機器開発者は「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」といった視点を持つべきなのだ。
残念ながら、このことはどんなソフトウェア工学の本を読んでも書いていない。（と思う）
でも、ものづくりに生き甲斐を感じたい＝組込み機器を使ってくれるユーザーの満足を高めたいという気持ちと、そのためには何をすればよいかということをよくよく考えていけば、自ずと商品コンセプトを明確に持って、ソフトウェアシステムのアーキテクチャを考え、再利用資産を何にすべきか明確にすることの重要性が分かると思う。
組込みソフトエンジニアの盲点は、技術やスキルを高めることに夢中になって、顧客満足の高い商品を作るために必要なことは何かを日々考えることを怠ってしまうことだと思う。
その危険を回避するためには、自分が作っている商品がエンドユーザーにどんな風に受け入れてもらえるだろうかということをいつも気にしていることが大事だ。そのことをいつも心に留めておくと、不思議と身につけるべき技術や迷ったときのトレードオフの選択の方向性が見えてくる。
そのドメインのエキスパートになるということは、要求を実現する技術を持つことも大事だが、自分の成果物がお客さんに喜んでもらえるはずという自信と、本当にそうだろうかかという不安と緊張の両方持ちながらものづくりに邁進することなのだと思う。
ロングテールとは簡単に言えば、それほど売れ筋ではない商品でもインターネットのようなバーチャルストアーで扱うことで、ながーい期間棚に陳列しておけば、トータルで十分に儲かるということだ。需要曲線が長い尾を引くことからロングテールと呼ばれる。
さて、和田けんじさんは16年間東急ハンズに勤めた経験から、マーケティングの考え方について記事を書いている。
【「市場調査が個性を殺す」より引用】
企業は、市場を調査し需要を確認してから店舗を展開します。需要が存在しないところに大切な資金を投入したくありませんから、「顧客はいるのか」「利益は見込めるのか」しっかり調査します。
しかし、大抵の企業のマーケティングの結果にそれほどの違いはありません。その結果を基本に店作りをするわけですから、名前が違うだけで、同じような品揃えの、同じようなコンセプトのお店ばかりになってしまいます。
これでは、消費者にとって魅力のあるおお店にはなりません。
【引用終わり】
東急ハンズは言わずと知れた、売れ筋のみに固執せず、豊富かつ専門的に商品を展開する店で、現在のネット通販に見られるロングテールビジネスを30年も前から店頭でやっている。
和田けんじさんは15年前に、バス・トイレタリー用品の担当だった時、バス用品の売り上げの90％以上を占める大定番のプラスチック製の製品とは別に高価な上に使わない時は日陰干しにするなどしないと、すぐカビが生えたりヒビが入ったりする檜の風呂椅子・風呂桶・ひしゃく・石鹸台・湯かき棒を仕入れたそうだ。
プラスチックの風呂椅子が高くても2000円くらいなのに対し、檜のそれは1万円を超えていた。今でこそ、バスタイムを楽しもうという提案も珍しくないが、「オーガニックブーム」でも「癒やしブーム」でもなかった頃に、そうやすやすとは檜のバス用品は買ってもらえなかった。
売れ筋を後ろに下げて、この檜シリーズを棚の一番目につくところに陳列までしてもすぐには売れなかった。それでも、上司は、そんな売れない檜シリーズの展開をやめろとは言わなかったそうだ。
むしろ、品物の良さをすぐ理解し、慈しむように眺めては、「買っていただけた？」と目を輝かせて毎日のように聞いてきたとのこと。
そうこうするうち、次第に商品の良さが理解されるようになり、結果的には大変多くの客様にご購入いただくことができた。
当時の和田さんの考えは、プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないかというものだった。
今日のブログのテーマはこの話から学ぶ「組込み機器開発のマーケティングと商品コンセプト」についてである。
和田けんじさんは「市場調査が個性を殺す」と書いているが、組込み機器開発ではものを作ることから始まるので、最初から市場で売れ筋の他社製品のマネだけすることは少ない。
多くのメーカーは（商社ではないので）商品の仕入れ方で独自性を出すのではなく、機能や性能で独自性を出すことを考えている。もっとも安易な開発手法として、市場で売れ筋の商品とまったく同じ機能でコストを安く、販売価格を下げるという戦略はあるが、その方法はアジア諸国と勝負できないし、人件費が高くなってしまった日本では利益がでないのでもう誰もやらない。
そうなると、次に考えるのが売れ筋の他社製品にプラスアルファの機能を付けて、カタログスペックで機能や性能を表にしたとき一つだけ抜きんでるようにするという作戦だ。これを繰り返し行くと同じ市場に同じような商品を投入するA社、B社、C社、D社が次々に同じことをするので、機能比較の表がどんどん長くなってくる。
この安易な商品戦略の考え方（戦略と呼べるようなものではないが・・・）は、日本の組込みソフトエンジニアに長い間習慣として染みついてしまった試行錯誤・付け足しのソフトウェア開発のスタイルにベストフィットする。
商品群を何世代にも渡って、機能を付け足し続け、ユーザークレームを払拭するように改善し続ける。この取り組みは一見顧客満足を高める方向にしか進まないように見えるが、実はそうではない。
デメリットは2つ。
ユーザーサイドのデメリットは、本当に欲しい機能以外の機能がたくさんついていて使いこなせなくなるというデメリットだ。使わない機能は放っておけばよいという考え方もあるが、使わない機能のユーザーインターフェースが本当に使いたい機能の操作を迷わせることも多々あるのでそう簡単ではない。
普通に考えれば商品に機能を追加していけばコストが高くなるはずだが、ソフトウェアで機能を追加していく場合、材料費アップにはつながらず開発費だけがアップするので、開発費のアップぶんをエンジニアのオーバーワークであらかたカバーしてしまえばメーカーサイドの痛手は少ない。
となると、メーカーサイドのデメリットは、ソフトウェア資産の再利用性の低下だろう。機能を付け足し付け足ししていくということは、すなわち明確な商品コンセプトがなく、長期的な再利用戦略がないままに最初に考えたアーキテクチャを引きずりながら、だましだまし進んでいくということになるため、結果的に再利用資産を中心に派生開発を行うことができない、もしくは難しい。
ようするに、売れ筋商品を思い浮かべてプラスアルファする、そのとき流行のデバイスを使ってみる、といったそれほど頭を使わないマーケティング、商品開発を続けていると、顧客満足も高まらない、開発効率も上がらないという悪循環の道に入り込んでいく可能性が高い。商品の外見を変えると一瞬、市場やユーザーも振り向くが、本当に使い勝手がよい商品でないと支持が長続きしない。長続きしないから、また短期間に付け足し商品を開発しようとする。
このような悪循環から脱出するには、「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」というユーザーサイドに立った商品コンセプトを打ち立て、そのコンセプトを開発の最初から最後まで貫くことが必要だ。
コンセプトを明確にして商品開発を行うのが得意なのは食品や生活用品の開発者だろう。商品コンセプトの善し悪しが売り上げに明確に反映するような商品の場合、自ずと商品コンセプトの重要性は開発チームに伝わる。
ところが、組込み機器、組込みソフトウェアの開発には商品開発に多くの知識・技術が必要なため、商品コンセプトよりもどうやって機能や性能を実現すべきかという方法論の方に技術者の興味が向かいがちだ。しかし、組込み機器の開発では制約条件と機能・性能とのトレードオフが必ず発生するので、商品コンセプトが明確でないと開発チームの方向性が右に左に揺れて、大きなソフトウェアの仕様変更が何回も発生してしまう。
自分のスキルを駆使して機能や性能を実現することに生き甲斐を感じている組込みソフトウェアエンジニアにとっては、右に左に揺れる仕様変更さえ「やったるぜ」と張り切って取り組む者もいるだろう。
でも、その付け足しアプローチを続けていると、開発効率は上がらず、ソフトウェア品質は下がり、ユーザーにも「使えない」商品になってしまう。
だからこそ、組込み機器開発者は「プラスチックという品揃えに物足りなさを感じ、せっかくの一日のリラックスタイムを、もっと楽しんでいただきたい。何か、もうひとつお風呂に入る時間を豊かな時間にできるものはないか」といった視点を持つべきなのだ。
残念ながら、このことはどんなソフトウェア工学の本を読んでも書いていない。（と思う）
でも、ものづくりに生き甲斐を感じたい＝組込み機器を使ってくれるユーザーの満足を高めたいという気持ちと、そのためには何をすればよいかということをよくよく考えていけば、自ずと商品コンセプトを明確に持って、ソフトウェアシステムのアーキテクチャを考え、再利用資産を何にすべきか明確にすることの重要性が分かると思う。
組込みソフトエンジニアの盲点は、技術やスキルを高めることに夢中になって、顧客満足の高い商品を作るために必要なことは何かを日々考えることを怠ってしまうことだと思う。
その危険を回避するためには、自分が作っている商品がエンドユーザーにどんな風に受け入れてもらえるだろうかということをいつも気にしていることが大事だ。そのことをいつも心に留めておくと、不思議と身につけるべき技術や迷ったときのトレードオフの選択の方向性が見えてくる。
そのドメインのエキスパートになるということは、要求を実現する技術を持つことも大事だが、自分の成果物がお客さんに喜んでもらえるはずという自信と、本当にそうだろうかかという不安と緊張の両方持ちながらものづくりに邁進することなのだと思う。
2007-10-08
エンジニアの品格
今回は時事ネタを2つ。
その前に、WEBブラウザでこのブログを見ている人はこのブログサイトの右上の「あなたのプロフィールは？」の投票に是非参加していただきたい。このブログサイトを最初に作ったとき、できれば読者との双方向コミュニケーションを実現したいと思っていた。でも、実際にはたまに少数の方がコメントを書いてくれるとき以外はほとんど一方向の情報発信となっている。そこで、せめてどんな人がこのブログを見てくれているのかをリサーチして、その結果を見ながら話題を変えていきたいと考えている。(Let's vote!)
【エンジニアの品格】
さて、一つめの話題。先週、時津風部屋の序ノ口力士、時太山＝当時（１７）、本名斉藤俊さん＝がけいこ後に死亡した問題で日本相撲協会が時津風親方を解雇した。
この事件でTVやラジオやインターネットでいろいろな方がコメントを寄せているが、どれにも「品格のある行動だったかどうか」という視点がないのが不思議だった。
朝青龍が出場停止になったとき、世間はあれだけ「横綱の品格」のことを話題にしておきながら、相撲部屋での親方や兄弟子達の振る舞いには品格を問わないのか？ 親方や相撲部屋での力士達の行動に品格があれば、今回のような制裁と思われる行動は起こらなかったのではないだろうか。
厳しい稽古、時には竹刀で叩くような行為は力士を鍛えるための叱咤激励か、制裁行為かどっちにも取れるように思うが、叩いている方に品格があるかどうかで、強くなるための試練か、制裁行為かある程度判断できると思う。開かれた相撲部屋では近所の人たちが稽古をのぞきに来ることがしょっちゅうあるそうだ。このような相撲部屋では、近所の人たちの目が暗黙に親方や力士達の行為に品格があるかないかをチェックしていたのではないだろうか。いじめや制裁は閉鎖された空間で起こりやすい。でも、品格のある人たちであればいじめは抑えられる。
品格のない相撲部屋から品格のある横綱が誕生するとは考えにくい。もしも、それが実現したのならその横綱の品格は表面的に繕っているもののように見える。日本相撲協会は今後相撲部屋にも品格を求め、品格のない部屋は相撲の世界から去ってもらうと宣言して欲しい。そこまで言って品格を持った行動が大事だというのなら、横綱に品格を求めるという話にも自然に同意できる。強くなるまではどんな行動をしてもよく、横綱になるときだけ品格を求めるというのでは説得力がない。
似たようなシチュエーションが組込みソフトの世界にもあるように思う。組込みソフトの世界もプロジェクトリーダーの進め方によっては閉鎖された環境になりがちだ。ハードウェア出身のプロダクトマネージャからはソフトウェアの開発はブラックボックスに見えるので、ソフト屋さん達が何をやっているのかよく見えない。成果物もソースコードだけだといいのか悪いのか分からないから見る気にもならない。
かくして、ソフトウェアプロジェクトは閉鎖された空間となり、品格のないエンジニアがいじめを始めたりする。ターゲットになりやすいのは、立場上反論しにくい協力会社だ。メーカーやクライアントサイドの仕様が曖昧であることが原因で詳細仕様の勘違いやバグが発生しても悪者はソースコードを納品した協力会社の人間にされたりする。
メーカーサイドの能力のない発注者が自分自身の問題点を棚に上げて開発の遅れや品質の低下を協力会社のせいにするのを見ると、無性に腹が立つ。こういうときに「こいつはエンジニアとしての品格がない」と思う。相撲における品格と同じで、品格のあるエンジニアが他人を責めるときには、厳しい言葉であっても責められた方も周りも納得がいく。しかし、品格のないエンジニアが他人を責めるときの言葉は、誰が見てもいいわけがましく、自分の失敗を他人に押しつけているように見える。
エンジニアの品格とは、技術的な裏付けに基づいた言動・行動、長期的展望、リーダーシップ、揺るがない信念のようなものから生まれるのだと思う。自分の成果が外に見えにくいだけに、エンジニアとしての品格のある言動・行動がソフトウェアエンジニアにも求められるのだと感じる。
日本人が『あたたかい人間関係の中のやさしい一員』という特徴を持っている中で、組込みソフトエンジニアやソフトウェアプロジェクトはエンジニアとしての品格を堅持しておないと、目的を失い、ともすれば弱い者いじめをする集団と化してしまう危険性があるように思う。
日本人が欧米人のように、明確な責任と権限を持たず、曖昧な上下関係の中で、品質の高いものづくりができるのは、「あたたかい人間関係の中のやさしい一員」という気質にエンジニアとしての品格がプラスされているからではないかと感じる。
【携帯電話のソフトウェアの規模が拡大したカラクリ】
2つめの話題。ａｕブランドの携帯電話を展開するＫＤＤＩが、携帯電話機の大幅な値下げ原資となっている「販売奨励金」制度を適用しない新料金プランを導入するとのこと。
ＫＤＤＩが新プランを導入するのは、総務省が携帯各社に対し、2008年度をめどに、販売奨励金と通話料を分離し、利用者が、コスト負担を判断できる料金体系を設けることを要請したためだ。
販売奨励金の存在は前々から知っていたが、このところの各方面からの報道でその金額が4万円にもなるという話を聞いた。ようするに、2万円で売っている携帯電話の本体価格は本当は6万円、3万円の携帯電話の価格は7万円だったということだ。
この話、携帯電話を製造するメーカーから見ると自分たちは希望小売価格6万円、7万円で売って欲しいと思っている商品を、すべての消費者が、頭金2万円、3万円で残りの4万円をローン契約で買ってくれていたということになる。
本当なら店頭に表示される価格は6万円とか7万円なのに、消費者は勝手に長期ローン契約にされてあたかもメーカーの希望小売価格が2万円とか3万円かのように見せかけていたということだ。今後携帯電話のキャリア各社とも KDDI と同様に、販売奨励金をなくしたプランを出してくると思う。それによって、携帯電話の本当の価格が消費者に見えてくる。
ちなみに、自分は携帯電話がもし6万円も7万円もするものだったら、購入するかどうか悩むと思う。2万円か3万円で基本機能だけの機種を探すだろう。実際、販売奨励金をなくしていく方向に動いた場合、携帯電話の市場では安い基本機能だけの機種が増えると予想されている。
このニュースを聞いたときに、日本が携帯電話の機能が異常に多く、ソフトウェアの規模が大きかった原因は「コレだ！」と思った。
ユーザーは携帯電話の価格を表面上低く見せられていたので、価格と製品の機能とのバランスが崩れていた。高機能なものがより安価に買えるので、たいして使わない機能があってもカタログスペックで他社より上回っているものを買っていた。メーカーサイドもハイエンドの機種がバンバン売れるのでお金をかけたコマーシャルを打つことができる。それによって消費者はハイエンド機種に誘導される。
ユーザーは携帯電話のラインナップの中で高機能なハイエンド機種群を見かけ上安く買っていた（買わされていた）。通常商品ラインナップの中でハイエンド機種は高価で一番出荷台数が少ないものだが、携帯電話の場合は、ハイエンド機種の出荷台数が一番多かったということになる。
そんな状態が何年も続けば、そりゃソースコードの規模も600万も700万もいくだろう。でも、その裏には販売奨励金によって見かけ上4万円も小売価格を低くするカラクリがあった。
もしも、最初から端末の価格表示が実勢にあったものであれば、携帯電話におけるソフトウェアの規模の爆発はこれほどではなかったのではないか。携帯電話下請けソフトウェアエンジニアが女工哀史のようになることはなかったのではないだろうか。
ただ、携帯電話キャリア各社のこの作戦で、高機能な携帯電話が日本中に短期に爆発的に普及し、携帯電話が技術革新を生んだのも事実だろう。携帯電話のおかげで、高密度、大容量のバッテリや、小型振動デバイス、高精細カラー液晶などが開発されたし、ソフトウェアの世界でもオブジェクト指向設計の普及を後押ししたのではないかと思う。
でも、この異常状態がこの後解消されていけば、市場やユーザーは価格と機能のバランスを考えて携帯電話を購入するようになる。使わない機能が満載のかっこいい機種ではなく、自分の収入に見合った価格の中から必要な機能が入っている機種を購入するようになる。
携帯電話メーカーの売れ筋商品はハイエンドからミドルレンジ、ローエンドの機種に移ってくるため当然利益も減ってくる。商品群の中で共通なソフトウェアコア資産を再利用するソフトウェアプロダクトライン戦略も組織的に取り組んでいかないと利益を維持できなくなっていくだろう。
これまでカタログやCMに踊らされていた消費者は、財布の中身を気にしながら本当に自分に必要な機能は何かをじっくり考えるようになる。そして、そのニーズをいち早くくみ取ってそこにターゲットを合わせ、その機能や性能の価値に消費者が納得できる価格を付けることができたメーカーが市場で生き残るだろう。もちろん、他社にはない自分たちの得意技術をウリにできなければ差別化することはできないが・・・
そう考えると、携帯電話業界における異常なほどの技術者の残業、ソフトウェア規模の急激な拡大、人材不足は、消費者がそうとは知らずに高い携帯電話を買わされていたためだと考えられないだろうか。いびつに形成された市場が生み出した負の側面ということだ。
前にも書いたけれど、海外でNOKIAの携帯電話をレンタルしたりすると、本当に基本的な機能しか入っていないことに気がつく。いくら日本人が新しもの好きだからといって、みんながみんなこんなにたくさんの機能が付いている携帯電話を持っているのは絶対異常だと思っていたが、今回の話でその裏事情が見えてきた。
メーカーは市場と製品、機能・性能とその価値を適正に把握できないと、商売に失敗するだろうし、そこにいるエンジニアもしあわせにはなれないと思う。市場やユーザーから本当に求められているものを適正な価格（開発費）で提供するためには、エンジニアは制約条件の中で何ができるか、よーく考えなければいけない。その前提が崩れると正しい判断ができなくなり、考える能力が鈍ってくる。
ユーザーニーズと商品の価値と価格、この関係をきちんと分析できた者が、その市場で成功を収めることができるのだと思う。
その前に、WEBブラウザでこのブログを見ている人はこのブログサイトの右上の「あなたのプロフィールは？」の投票に是非参加していただきたい。このブログサイトを最初に作ったとき、できれば読者との双方向コミュニケーションを実現したいと思っていた。でも、実際にはたまに少数の方がコメントを書いてくれるとき以外はほとんど一方向の情報発信となっている。そこで、せめてどんな人がこのブログを見てくれているのかをリサーチして、その結果を見ながら話題を変えていきたいと考えている。(Let's vote!)
【エンジニアの品格】
さて、一つめの話題。先週、時津風部屋の序ノ口力士、時太山＝当時（１７）、本名斉藤俊さん＝がけいこ後に死亡した問題で日本相撲協会が時津風親方を解雇した。
この事件でTVやラジオやインターネットでいろいろな方がコメントを寄せているが、どれにも「品格のある行動だったかどうか」という視点がないのが不思議だった。
朝青龍が出場停止になったとき、世間はあれだけ「横綱の品格」のことを話題にしておきながら、相撲部屋での親方や兄弟子達の振る舞いには品格を問わないのか？ 親方や相撲部屋での力士達の行動に品格があれば、今回のような制裁と思われる行動は起こらなかったのではないだろうか。
厳しい稽古、時には竹刀で叩くような行為は力士を鍛えるための叱咤激励か、制裁行為かどっちにも取れるように思うが、叩いている方に品格があるかどうかで、強くなるための試練か、制裁行為かある程度判断できると思う。開かれた相撲部屋では近所の人たちが稽古をのぞきに来ることがしょっちゅうあるそうだ。このような相撲部屋では、近所の人たちの目が暗黙に親方や力士達の行為に品格があるかないかをチェックしていたのではないだろうか。いじめや制裁は閉鎖された空間で起こりやすい。でも、品格のある人たちであればいじめは抑えられる。
品格のない相撲部屋から品格のある横綱が誕生するとは考えにくい。もしも、それが実現したのならその横綱の品格は表面的に繕っているもののように見える。日本相撲協会は今後相撲部屋にも品格を求め、品格のない部屋は相撲の世界から去ってもらうと宣言して欲しい。そこまで言って品格を持った行動が大事だというのなら、横綱に品格を求めるという話にも自然に同意できる。強くなるまではどんな行動をしてもよく、横綱になるときだけ品格を求めるというのでは説得力がない。
似たようなシチュエーションが組込みソフトの世界にもあるように思う。組込みソフトの世界もプロジェクトリーダーの進め方によっては閉鎖された環境になりがちだ。ハードウェア出身のプロダクトマネージャからはソフトウェアの開発はブラックボックスに見えるので、ソフト屋さん達が何をやっているのかよく見えない。成果物もソースコードだけだといいのか悪いのか分からないから見る気にもならない。
かくして、ソフトウェアプロジェクトは閉鎖された空間となり、品格のないエンジニアがいじめを始めたりする。ターゲットになりやすいのは、立場上反論しにくい協力会社だ。メーカーやクライアントサイドの仕様が曖昧であることが原因で詳細仕様の勘違いやバグが発生しても悪者はソースコードを納品した協力会社の人間にされたりする。
メーカーサイドの能力のない発注者が自分自身の問題点を棚に上げて開発の遅れや品質の低下を協力会社のせいにするのを見ると、無性に腹が立つ。こういうときに「こいつはエンジニアとしての品格がない」と思う。相撲における品格と同じで、品格のあるエンジニアが他人を責めるときには、厳しい言葉であっても責められた方も周りも納得がいく。しかし、品格のないエンジニアが他人を責めるときの言葉は、誰が見てもいいわけがましく、自分の失敗を他人に押しつけているように見える。
エンジニアの品格とは、技術的な裏付けに基づいた言動・行動、長期的展望、リーダーシップ、揺るがない信念のようなものから生まれるのだと思う。自分の成果が外に見えにくいだけに、エンジニアとしての品格のある言動・行動がソフトウェアエンジニアにも求められるのだと感じる。
日本人が『あたたかい人間関係の中のやさしい一員』という特徴を持っている中で、組込みソフトエンジニアやソフトウェアプロジェクトはエンジニアとしての品格を堅持しておないと、目的を失い、ともすれば弱い者いじめをする集団と化してしまう危険性があるように思う。
日本人が欧米人のように、明確な責任と権限を持たず、曖昧な上下関係の中で、品質の高いものづくりができるのは、「あたたかい人間関係の中のやさしい一員」という気質にエンジニアとしての品格がプラスされているからではないかと感じる。
【携帯電話のソフトウェアの規模が拡大したカラクリ】
2つめの話題。ａｕブランドの携帯電話を展開するＫＤＤＩが、携帯電話機の大幅な値下げ原資となっている「販売奨励金」制度を適用しない新料金プランを導入するとのこと。
ＫＤＤＩが新プランを導入するのは、総務省が携帯各社に対し、2008年度をめどに、販売奨励金と通話料を分離し、利用者が、コスト負担を判断できる料金体系を設けることを要請したためだ。
販売奨励金の存在は前々から知っていたが、このところの各方面からの報道でその金額が4万円にもなるという話を聞いた。ようするに、2万円で売っている携帯電話の本体価格は本当は6万円、3万円の携帯電話の価格は7万円だったということだ。
この話、携帯電話を製造するメーカーから見ると自分たちは希望小売価格6万円、7万円で売って欲しいと思っている商品を、すべての消費者が、頭金2万円、3万円で残りの4万円をローン契約で買ってくれていたということになる。
本当なら店頭に表示される価格は6万円とか7万円なのに、消費者は勝手に長期ローン契約にされてあたかもメーカーの希望小売価格が2万円とか3万円かのように見せかけていたということだ。今後携帯電話のキャリア各社とも KDDI と同様に、販売奨励金をなくしたプランを出してくると思う。それによって、携帯電話の本当の価格が消費者に見えてくる。
ちなみに、自分は携帯電話がもし6万円も7万円もするものだったら、購入するかどうか悩むと思う。2万円か3万円で基本機能だけの機種を探すだろう。実際、販売奨励金をなくしていく方向に動いた場合、携帯電話の市場では安い基本機能だけの機種が増えると予想されている。
このニュースを聞いたときに、日本が携帯電話の機能が異常に多く、ソフトウェアの規模が大きかった原因は「コレだ！」と思った。
ユーザーは携帯電話の価格を表面上低く見せられていたので、価格と製品の機能とのバランスが崩れていた。高機能なものがより安価に買えるので、たいして使わない機能があってもカタログスペックで他社より上回っているものを買っていた。メーカーサイドもハイエンドの機種がバンバン売れるのでお金をかけたコマーシャルを打つことができる。それによって消費者はハイエンド機種に誘導される。
ユーザーは携帯電話のラインナップの中で高機能なハイエンド機種群を見かけ上安く買っていた（買わされていた）。通常商品ラインナップの中でハイエンド機種は高価で一番出荷台数が少ないものだが、携帯電話の場合は、ハイエンド機種の出荷台数が一番多かったということになる。
そんな状態が何年も続けば、そりゃソースコードの規模も600万も700万もいくだろう。でも、その裏には販売奨励金によって見かけ上4万円も小売価格を低くするカラクリがあった。
もしも、最初から端末の価格表示が実勢にあったものであれば、携帯電話におけるソフトウェアの規模の爆発はこれほどではなかったのではないか。携帯電話下請けソフトウェアエンジニアが女工哀史のようになることはなかったのではないだろうか。
ただ、携帯電話キャリア各社のこの作戦で、高機能な携帯電話が日本中に短期に爆発的に普及し、携帯電話が技術革新を生んだのも事実だろう。携帯電話のおかげで、高密度、大容量のバッテリや、小型振動デバイス、高精細カラー液晶などが開発されたし、ソフトウェアの世界でもオブジェクト指向設計の普及を後押ししたのではないかと思う。
でも、この異常状態がこの後解消されていけば、市場やユーザーは価格と機能のバランスを考えて携帯電話を購入するようになる。使わない機能が満載のかっこいい機種ではなく、自分の収入に見合った価格の中から必要な機能が入っている機種を購入するようになる。
携帯電話メーカーの売れ筋商品はハイエンドからミドルレンジ、ローエンドの機種に移ってくるため当然利益も減ってくる。商品群の中で共通なソフトウェアコア資産を再利用するソフトウェアプロダクトライン戦略も組織的に取り組んでいかないと利益を維持できなくなっていくだろう。
これまでカタログやCMに踊らされていた消費者は、財布の中身を気にしながら本当に自分に必要な機能は何かをじっくり考えるようになる。そして、そのニーズをいち早くくみ取ってそこにターゲットを合わせ、その機能や性能の価値に消費者が納得できる価格を付けることができたメーカーが市場で生き残るだろう。もちろん、他社にはない自分たちの得意技術をウリにできなければ差別化することはできないが・・・
そう考えると、携帯電話業界における異常なほどの技術者の残業、ソフトウェア規模の急激な拡大、人材不足は、消費者がそうとは知らずに高い携帯電話を買わされていたためだと考えられないだろうか。いびつに形成された市場が生み出した負の側面ということだ。
前にも書いたけれど、海外でNOKIAの携帯電話をレンタルしたりすると、本当に基本的な機能しか入っていないことに気がつく。いくら日本人が新しもの好きだからといって、みんながみんなこんなにたくさんの機能が付いている携帯電話を持っているのは絶対異常だと思っていたが、今回の話でその裏事情が見えてきた。
メーカーは市場と製品、機能・性能とその価値を適正に把握できないと、商売に失敗するだろうし、そこにいるエンジニアもしあわせにはなれないと思う。市場やユーザーから本当に求められているものを適正な価格（開発費）で提供するためには、エンジニアは制約条件の中で何ができるか、よーく考えなければいけない。その前提が崩れると正しい判断ができなくなり、考える能力が鈍ってくる。
ユーザーニーズと商品の価値と価格、この関係をきちんと分析できた者が、その市場で成功を収めることができるのだと思う。
2007-08-04
インドのソフト会社
あるところでインドのソフト会社（組込み系だけも1500人以上いるかなり大きい会社）の話を聞いた。（どんな会社かはこのブログ記事を参照のこと）ソフトウェアの場合、オフショア開発で失敗した話はよく聞くし、CMMのレベル5を取っているからといって組込みソフトの世界でも通用するのかどうか懐疑的だったのであまり期待はしていなかったが、今後の大規模組込みソフト開発へのヒントをいくつか見つけた。
まず、前提条件としてこの会社の場合技術者は入社したときからソフトウェア工学の成績が高い者を採用している。まず、この点が日本と違う。日本では現状、入社した後に実践に必要なソフトウェア工学を教育することが多く、場合によっては大学でも会社組織でもソフトウェア工学を教わることなくなんとなく流されるまま中堅となってしまうことがある。
次に、組織内の技術者がみなソフトウェア技術者であり、日々勉強してスキルレベルを保っていないと給料が下がってしまうような仕組みを持っている。自社のスキル体系を構築しており定期的にテストを実施しているという。この点は、プロフェッショナルの条件の記事で書いたように21世紀では知識労働者が40%なのだから、常に鍛えておかないとプロフェッショナルとしての仕事はできないという課題に対してキチンと取り組んでいると言える。
また、この会社は言語のギャップを埋めるために、トランスレーターの組織を持っており、ソフトウェア技術・知識はそれほど持っていないが日本語はぺらぺらというグループがいて、テレビ会議やインドまで日本人が出向いていって打ち合わせをするときは彼らを仲介役に付けてくれるのだそうだ。
多種、多様な仕事を受けた実績があるため扱ったことのあるCPU、統合開発環境、OS、言語、ツール類の種類が非常に多い。一人の技術者が全部できるわけではないが組織としてかなり多くの開発経験を持っていることがうかがえる。ドラッカーが言うように知識労働者は自分の頭が生産手段なのだが、組織がうまくコントロールすれば生産手段を頭の中から引っ張り出して、その一部をプロセスやツールに埋め込むこともできる。イメージ的にはそれができているような印象を受けた。
そしていくつかの質問をしてみた。まずは、「クライアントから受けた仕事で作ったソフトウェア資産を他のクライアントで使うことはあるか？」という質問。もちろん答えは「No」。次に、「自分たちで作ったUSBのドライバとか、ファイルシステムなどをソフトウェア資産として再利用することはあるか？」と聞いた。答えは「クライアントと相談して、この部分の開発は開発費はいらないので自分達の資産にさせて欲しいといい、自組織の資産とする場合はある。」と言っていた。
ようするに、ソフトウェアの資産化、再利用についても考えているという答えだ。ただ、自分自身が商品を企画、販売する訳ではないので、商品群の長期販売戦略に基づいたソフトウェア再利用資産の構築を計画することはできていない。そこが惜しいなあと思う。（日本でもほとんどの組織でできていないと思うが・・・）
でも、明らかに日本の多くのソフトウェアプロジェクトと違うのは、冒頭に掲げた絵にあるように、日本ではハード部隊とソフト部隊が近い関係にあるが故に、ソフトウェアのプロセスとプロセスが曖昧になりがちで試行錯誤的にソフトウェアを作ってしまうのに対し、このインドの会社ではキッチリプロセスを分けて前に進んでおり、ソフトウェア技術者がソフトウェア工学を学んでいて、それぞれが Methodology に基づいて作業をしているというところだ。
ただ、組込みソフトの開発では、そのトップダウン的アプローチにはデメリットがある。要件定義はきちんとできていて、アーキテクチャも考えているが、実装してみたらCPUパフォーマンスやメモリリソースが足らないというような制約条件をクリアできていないという事態をまねく場合があるという点だ。
「開発を進めていくと、制約条件をクリアできずにアーキテクチャを見直すことはないのか。」と聞いてみた。そうすると「それは、いつも悩んでいることでありアーキテクチャを修正することはある」という答えが返ってきた。
ここですごいと思ったのは、このインドの会社が「制約条件をクリアできないときはアーキテクチャ設計まで戻ってアーキテクチャの見直しをする」というアプローチを取っているということだ。日本の場合は、自分のシステムのアーキテクチャ自体がどんなものか分かっていない場合が多い。なぜなら試行錯誤的アプローチでソフトウェアを作り込んでしまうからだ。だから、制約条件をクリア出来ない場合は、アーキテクチャに立ち戻るのではなく、その場しのぎの対策をしてしまう。これでは、ソフトウェアはスパゲッティ状態になってしまっても不思議ではない。
また、このインドの会社では、要件定義が固まるまでは正確に工数が見積もれないので作業にかかった時間だけ費用をもらい、要件定義が固まった後は仕事量に対して見積もり金額を請求すると言っていた。非常にリーズナブルな回答であり、日本のソフトウェア受託開発会社でそのような方針を取っているところはあるだろうかと考えてしまった。
このような対応をするためには開発の前工程で要求分析を十分にし、要求仕様の確度を高くする必要がある。そのため、クライアントに対し仕様面で分からないところ、曖昧なところは徹底的に質問してクリアにするように心がけているそうだ。
インドはハードウェアの生産手段を持たずにソフトウェアの効率的生産で勝負しようとしている。ハード、ソフトのすり合わせ的な部分でのメリットは出しにくいが、ソフトウェア開発の効率化のメリットがそのデメリットを上回りそうな勢いを感じる。実際、このインドの会社はハードソフトのすり合わせ的な部分の設計についての重要性も理解しており、ちゃんと対応もするがソフトウェアの開発効率は落ちるので、その部分を日本に常駐して作業する際のコストはインド国内での作業の約倍のコストがかかると説明していた。うーん、実にリーズナブルな回答だ。
このインドの会社から日本が学ぶべきことは次のようなことになる。
- ソフトウェアの規模が大きくなり複雑化してきたら（目安は30万行、30人）ソフトウェア部隊だけの組織体制を作るべき（日本のメーカーでもそのようにしている会社が増えてきている）
- ソフトウェア技術者への組織的なソフトウェア工学の教育を行い、スキルレベルを定期的にチェックすべし（日本では技術者のリソースの数が少ないので優秀な人間を選択できないところがネック）
- 要件定義は開発の前段階で確度を高めておく。後工程での仕様変更にはコストがかかるため安易に応じないという姿勢も必要。
でも、ソフトウェアのコア資産までもインドの会社に出してしまったら、ソフトウェア再利用資産を使った開発の効率化は難しいかもしれない。また、組込みソフトウェアエンジニアとしての最大の問題はソフトウェア開発をまるごと外に出してしまったら自分たちがやること、くふうのしがいがなくなってしまうという点だ。そんなことになったらモチベーションは著しく下がるだろう。
2006-05-02
プロダクトラインがNEのカバーストーリーに登場
日経エレクトロニクス2006年4月24日号のカバーストーリーにソフトウェアプロダクトラインの記事が載った。カバーストーリーの構成は以下のようになっている。
第１部：激変は前提。絶え間ない製品投入は必至。設計資産の構築で生き抜く
第２部：ソフトウェア編。プロダクトラインで10倍の格差。ソフトウェア工学にビジネスの視点を
第３部：ハードウェア編。長期展望の設計思想で世界同時立ち上げを実現
第４部：社外リソース編。開発・製造受託企業をマンツーマンで使いこなす
記事を読むと家電製品の価格の下落は激しいらしい。確かに消費者側からみると1年前に発売されたDVDレコーダなどは驚くほど安く買える。1980年代後半、AV機器の価格下落率は年率10％にも満たなかったのに、2000年代のDVDレコーダの価格下落率は年率20％近いそうだ。
日経エレクトロニクス2006年4月24日号のカバーストーリーではこの現象をデジタル民生機器が「生鮮品」と化したと書いている。早く売らないと腐ってしまうという意味だ。価格が下落しにくい「オンリー・ワン」の商品を作れているメーカーはいいが、組み合わせプラスちょっとしたユーザーインターフェースの違いで商品を作っている企業はなかなか厳しい。
日本ではほとんど持っている人を見かけないフィンランドの携帯電話メーカー Nokia Corp. は、世界市場ではかなりのシェアを持っていることは知っていたが、Nokia がプロダクトライン戦略に成功していたという話はこの記事で知った。2005年、日本の端末機メーカーの投入機種数はわずか10～15機種程度だったのにくらべて、Nokia は年間56機種も世界市場に投入したとこのこと。その Nokia もプロダクトラインにおけるコア資産を構築するために、2004年はリリースできた機種が36機種と、前年の40機種よりも落ち込んでいる。2000年ころから部品やプリント基板などハードウェアのモジュール化に、2001～2003年ころに体系的に再利用できるミドルウェアに構築に取り組んだそうだ。2005年になってから開発効率向上による恩恵を着実に享受できるようになったと、Nokia の Technolpgy Platforms Director, Software Platforms Marketing の担当者は語っている。
日経エレクトロニクスのすごいところは、ちゃんと Nokia に取材して情報をつかんでくるところだ。さらに具体例としてキャノンや松下電器産業、Philips、 Microsoftといったプロダクトラインに取り組んでいる企業を見つけて成功事例やこれからの取り組みを取材して記事にしている。
日本でソフトウェアプロダクトラインの取り組みを現場に指導できる数少ないコンサルタントであるイーソルの今関剛さんから提供された情報が掲載されていることもあって、キーワードが先行しやすいプロダクトラインの記事としては今回のカバーストーリーは現場に根ざしたエンジニアにも有益な記事になっていると思う。
自分も含めて、日本でボトムアップでプロダクトラインによる体系的な再利用戦略を実現し、開発の効率とソフトウェアの品質を高めようとする者にとって、Nokia のマシンガン体制のベースには、コア資産を構築するのに時間と工数がかなりかかっているという情報を明らかにしてくれたこの記事の功績は大きい。
なぜなら、日本では悪循環を断ち切るために付け足し付け足しのソフトウェア開発はやめにして、どこかの時点で体系的な再利用戦略に切り替え、悪循環から好循環に移行したいと技術リーダーたちが考えていても、組織が一時的なコストアップや工数アップに理解を示してくれないからである。
日本でプロダクトライン戦略を成功させるには、現場のエンジニアの負担がさらに増えることを覚悟の上でコア資産を再構築しつつ納期も遅れされないという犠牲を払わないとダメかもしれない。
どちらにしても、プロダクトラインというキーワードが一人歩きせずに、成功例とともに体系的再利用戦略が広まることで、エンジニアの負担を減らしソフトウェアの品質を高め、商品の開発効率を高めることにつながって欲しいと思う。
登録:
投稿 (Atom)