Nokiaの技術戦略

日経BPの情報サイト Tech-On! に「着実に成果を出すNokiaのプラットフォーム戦略、CTOにその秘訣を聞く」（読むためには無償のユーザー登録が必要）という記事が載っていた。

記事の話題に移る前に、まず、記事のタイトルについて一言。フィンランドの会社 Nokiaは日本の中では知名度は低いが、グローバルな市場では携帯電話のシェアのトップを走っている。また、CTO(Chief Technology Officer）は自社の技術戦略や研究開発方針を立案、実施する責任者のこと。要するにその会社の中で技術に関係した経営戦略を考える人のことだ。CTOは組織の中で技術者が目指すポジションと言えるかもしれない。

Nokia は体系的再利用戦略であるプロダクトラインを成功させたと言われている会社であり、Nokiaの技術系の最高責任者 Tero Ojanpera 氏が Nokia の研究開発体制についてインタビューに答えている。

【記事からの引用】

我々は，明確な戦略を持って内製と外部調達を使い分けている。例えば，S60（Symbian OSベースのミドルウエア群）などのソフトウエア・プラットフォームは競争力の源泉であり，内部で開発する。そのほか，W-CDMA関連の回路も我々が開発している。その方がコストや電力効率で有利だからだ。

確かにディスプレイやカメラ・モジュールは外部調達しているが，多くの場合は部品メーカーとの共同開発という形をとっている。我々は，外部調達した部品を組み合わせるための「アーキテクチャ」を設計できる力を持つ。これは我々の大きな強みだ。

【引用終わり】

この発言から、Nokia は携帯電話の中の各モジュールの特徴と商品価値との関係を十分に分析しており、その上でどこを外に出すか、どこの技術は中に保持しなければいけないのかを把握していることがわかる。

また、製品の構成をどのようにするかといったアーキテクチャを設計する技術に自信を持っていると語っている。自社製品の技術について、このような発言ができる上位層がいる会社は間違いなく技術力が強く成功する確率の高い会社だ。日本の場合、現場寄りのアーキテクトがそういう感覚を持っていても、組織の上位層でアーキテクチャ設計の技術に自信があると言える人物はそう多くはないだろう。

Ojanpera氏は、このような技術力をどのように獲得したのかと聞かれ以下のように答えている。

1. Nokia の研究所に、各分野を深く理解している技術者を大学や他の企業から積極的に招き入れる。
2. 招いた技術者には、まず基礎的な研究分野を従事させる。
3. その後、技術者を事業部門に送り、商品に近い開発をさせる。
4. そうして、技術者や研究者にビジネス感覚を身につけさせる。
   

これによって、Nokia社の技術者は，常に革新を生み出しながら，「ビジネスになるか否か」という感覚を磨いていくのだそうだ。

自分も優秀なアーキテクトを育てるには、研究分野だけでなく、事業部門やサービス部門、マーケティングなども経験させる必要があるという話は『組込みソフトエンジニアを極める』の第3章－再利用の壁を越える－に書いた。CTOを目指すような技術者はビジネス感覚を身につけることも必要だということだ。

ただ、ここで「Kokia の成功、そうは言うものの・・・」という話をしておこう。

数年間シンガポールで仕事をして、つい最近日本に帰ってきた友人に会った。彼が言うには、シンガポールでは Nokia の携帯電話を使っていたが、日本に帰ってきて携帯電話を日本製に変えて困っているというのだ。

Nokia の携帯電話は電話帳もメールもシンプルで使い方を覚えるのも簡単だったのに、日本の携帯電話は機能が多すぎて使いこなせないらしい。シンガポールでは高校生がものすごい勢いで携帯電話のキーを押しているような光景は見かけないとのこと。

要するに日本では、海外では使われないようなものすごく多くの機能を携帯電話の中に突っ込むことに成功しており、そこそこ品質も保っている。

Nokia はもっともうるさい消費者のいる日本ではまだ成功を収めているとは言い難く、ちょろいお客しかいないところで自分たちの技術が高いと言っているのかもしれない。

日本でこれだけ複雑な機能を持った携帯電話を短期間にリリースできるのは、日本人のねばり強さとすり合わせの能力の高さのおかげだと思う。スマートではないけれども、何とか形にする能力と残業という切り札を使って達成している成果ということだ。

だから、Nokia の Ojanpera氏 が自分たちは自信があると言った商品の強みを考慮したパーツの切り分け技術（ドメイン分析技術）を日本の技術者が身につけ、体系的な再利用を行うことに成功できれば、日本はまだまだ組込み産業で世界のトップを走ることができる筈である。

もしも、携帯電話のドメインにいるソフトウェア技術者の方で、現状体育会系のノリで巨大なソフトウェア開発に取り組んでいるような人がいれば、その開発をスマートに乗り切って悪循環から好循環のステージにシフトするための第一歩として『組込みソフトエンジニアを極める』を読んでいただきたい。

と、最後は本の宣伝で終わる。

英語は苦手

今日の話題は英語。タイトルにあるように自分は英語が苦手だ。ただ、たいていの人は（自分から見れば）かなり得意でも「英語は苦手です。」というので、客観的な評価指標として TOEIC のスコアで言うと 550点クラスということになる。この550点もこれまでの最高点で、その後受けるたびにじりじりと下がっている。

TOEICテストは集中力がいるのでもしかすると慣れがいい加減さにつながってしまっているのかもしれない。

自分が英語が苦手な原因を分析してみようと思う。中学生になって英語の授業が始まったときに「日本人なのになぜ英語を読み書きできないといけないのか」と思った。そのころの自分は自分が仕事で英語を使うような場面をまったく想像できなかったし、将来使う可能性がないものを必至に勉強するのはバカバカしいと考えていたわけだ。昔から必要性が感じられないことについてモチベーションが上がらない性格だったのだ。地理や歴史もそういう理由で子供の頃嫌いだったが、国内旅行、海外旅行するようになって、学習意欲がわいてきた。実際にその土地を訪ねて、自分の住んでいる環境との違いを感じたりすると、その土地の歴史を知りたくなる。

英語に関して言えば、きっと、クラスの中に英語をしゃべる外国人の友達がいたり、近所に外人の家族でも住んでいればがぜんやる気がでたと思う。生活の中で使う必然性、特に「コミュニケーション取りたい！」という動機があれば英語の学習意欲はあがっただろう。テストの点数を取りたいから勉強するという動機付けは自分にとっては効果がまったくない。

だから、もしタイムマシンがあるのなら、15歳の自分に「社会人になって英語で外国人としゃべったり、手紙書いたりすることがあるから、しっかり勉強しておけよ」とささやきたい。

英語が苦手のもう一つの原因は、今とは違って30年前40年前は生の英語を聞く機会が少なかったということもある。最初に接したのが中学校の英語の先生のネイティブとは言い難い英語だから、ネイティブな英語を聞いたのは大人になってからと言える。

一説には、英語のリスニングはかなり小さいときから聞いていないと、大人になってからでは獲得しにくいのだそうだ。

リスニングがどうこうというよりも、外国人とコミュニケーション取ること事態に恐怖心があった。「あった」と過去形になっているのは、ECCに2年間通って外国人に対する恐怖心だけはなくなったからだ。

ただ、いまでも相手が自分にしゃべったことが理解できなかったらどうしようとか、自分の意志が伝わらなかったらどうしようといった心配がある。英会話ができるようになった人の話を聞くと、自分のスキルの低さをさらけ出したくないというプライドを捨てることができると英語の上達が進むそうだ。

そう考えると、まずは相手の言ったことを理解できるところから始めたい。英語の学習法は今はいっぱいあるし、個人個人の特性によってぴったりフィットする勉強法は違うのでこれが絶対いいとは言わないが、何年も試行錯誤して「これはいいかな」と思った教材がある。

それが、冒頭に掲げた NHKラジオ英会話リスニング・テキスト What’s New? だ。この本は清泉女子大学教授の 大杉正明氏が監修した NHKラジオ英会話のリスニングテキストで、一回一分程度のトピックスを Key Hetherly と Christoper J. Phelan が交互に担当していて、50トピックス載っている。このテキストに対応する CD（NHKラジオ英会話リスニングCD What's New?）は別売りになっているので両方買わないと意味がない。

このテキストがいいのは、約1分という短いトピックス、たとえばテキサスに特有の食べ物の話とか、社交ダンスがイギリスでもブームになっているといった話題がたくさん載っていて、まず内容がおもしろい。

もともと、NHKラジオの英語リスニング入門という番組で、一つの小さいテーマを一週間少しずつ進めていくというやり方をしていたときがあって、これが自分にはよかったので自分のペースで進められる同じような教材を探していたところ NHKラジオ英会話リスニング・テキスト What’s New? を見つけたというわけだ。

このCDに入っている約50のトピックスを iPOD nanoに入れて、まずどれかのトピックスを一回聞く。当然、ほとんど理解できないが何の話かくらいはわかる。その後、繰り返し聞きながら、どうしてもわからないところはテキストを見たりして、内容を完全に理解した上で1分間のトピックスを聞いたときにディテールに渡って頭に入ってくるようになるまで繰り返す。

これを通勤電車の中で実行するのだ。ちなみに、この取り組みは一時期がんばっていたが一年近くさぼっているのでブログに書いたことをきっかけに再開したいと思う。 NHKラジオ英会話リスニング・テキスト What’s New? はNo.3 まであるのでまだまだストックはたくさんある。

ちなみに、英語の学習はみな苦労しているので、うまくいくと「これは絶対いいよ」と周りに勧める。ただ、どうも英語の学習方法にはゴールドスタンダードはなさそうであり、その人の性格によっても効く効かないがあるようなので、うっかり飛びつくとお金を無駄にすることになりかねないので注意が必要だ。

最後にここまで読んでくれた読者のみなさんにプレゼントをしよう。

娘が幼稚園児のころイギリス人の先生に英語を習っていたことがある。この先生、休み時間に英語のゲームサイト（Disneyのサイト）で子供達を遊ばせていた。そのサイトを久しぶりに探してみたら、子供に INTERNET SAFETY を教えるゲームを見つけてしまった。SURF SWELL ISLAND というゲームだ。

これ、英語の勉強にもなるし、子供がインターネットをする際に気をつけることが学習できる。 メールにBTW と書いてあったら "by the way"　のことだよといったことも教えてくれる。

思いっきり音楽が流れるから会社ではやらないように！

ゲームが好きな人にはこのサイトがある。あ～あ、教えちゃった。

『組込みソフトエンジニアを極める』に送られたメッセージ2

南野光太郎からメッセージが届いた。（南野光太郎とは、『組込みソフトエンジニアを極める』の中に登場するビジネス系のソフトウェアエンジニアのこと）

正確に言うと、SNS（ソーシャルネットワーキングサービス）のミクシィで知り合った、ビジネス系から組込み系にコンバートしたソフトウェアエンジニアの方から、『組込みソフトエンジニアを極める』の感想が届いたのだ。

本の中ではビジネス系のドメインでオブジェクト指向設計について学んだ南野光太郎が友人の組込みソフトエンジニアである組田鉄夫に自分のスキルを伝授する場面がある。この方は現実のソフトウェア開発にもこのような場面があることを教えてくれた。


【本の感想メールから引用】

『組込みソフトエンジニアを極める』を読ませて頂きました。

全体を通して、非常に中身の濃い本ですね。全くの組込み初心者には少し難しい内容かなと思いましたが、多少のベーススキルがあるエンジニアには知識の整理や、再利用を見据えた設計手法などの良い参考書として使えると思います。

組込み経験の浅い私には、１章のRTOSの基礎の説明で、はっきりと理解できていなかったRTOSの働きがきちんと整理できたように思います。

２章の機能分割についてはまさに今の仕事に関係するところで興味深く読むことができました。というのも、ある組込み機器に搭載してている一機能を設計フェーズから作り直しをするという作業を始めたばかりだったからです。

もともと、前機種で新規に実装した機能だったのですが前任のチームが仕様の取りまとめや実装面でトラブルを起こし、当初の思想からほど遠い実装状態でなんとかリリースしました。しかし、今後の機種展開の改修に耐えられないという判断から、再び設計からやり直しとなったのです。

この作業でちょうどレイヤ構成やモジュール分割、公開関数の粒度などで頭を悩ませていたのですが、オブジェクト指向の考え方が適用できる、という ことを第２章を読んで気づきました。私の中で「組込み系」は「業務系」と世界が違うのだと考えすぎていて、業務系で経験したスキルが応用できるのだという ところを見落としていました。

また今の作業では３章、４章の再利用と品質についても検討する場面が当然出てきますので、この作業をちょうどこの本の内容に沿ったケーススタディとして、色々と私なりの考えを巡らせ、実戦に適用できる部分が無いか試してみようかと思います。

【引用終わり】

自分も現実の仕事において、ビジネス系の世界でオブジェクト設計を学んだスペシャリストにいろいろと教えてもらった。近くにそのような人がいなければ独学では技術を習得するのは難しかったと思う。

長年組込みソフトをやってきた技術者とオブジェクト指向設計を使ってきた技術者では同じソフトウェア開発でも対象を見る視点が違う。大局から全体構造を考えるにはやはりオブジェクト指向設計的な視点で見た方がよいように思う。ただ、限られた制約条件の中で性能を満たすことができるかどうかは、組込みソフトの経験がものを言う。

さて、いみじくも2人のレビューワーからこの本は「全くの組込み初心者には少し難しいかもしれない」と言われてしまった。

実は本の見本ができあがって全体を通して読んだ際の自分の印象も「初心者にはちょっと難しい部分もあるかな」だった。文章が難しいという意味ではなく、中堅やベテランのエンジニアでなければ経験しないようなスキル、場面が後半の方に出てくるということだ。

しかし、だからといって初級の技術者に役に立たない訳ではない。まだ完全には自分のものにならなくても、ゴールのイメージを持つことは大事だと思う。

工房に入門した弟子が師匠の技を盗み取ることはまだできなくとも、師匠の行動や師匠が作った作品を見たり触れりすることは重要である。

道を究めるには、常に一流の作品に触れている必要がある。

そういう意味でも、『組込みソフトエンジニアを極める』は初級の組込みソフトエンジニアにも、ビジネス系のソフトウェアエンジニアにも読んでもらう価値があると思う。

組込みプレス Vol.3

組込みプレス Vol.3 が発売になった。今号から季刊になるとのこと。組込みプレス はこれまでは「是非、読んでね」くらいのレベルだったが、Vol.3 は「絶対読んでおけよ！」くらいのインパクトがある。バラエティに富んだ構成でありながら内容が濃い。

自分自身は、一般記事の中の SESSAME Workshop 2006 でモデレータを務めたパネルディスカッションの様子を「組込みソフト技術者のあるべき姿を探る」というタイトルで14ページの記事にまとめた。この記事も是非読んでいただきたいが、他にもおもしろい記事が盛りだくさんなので、一つずつ紹介していきたいと思う。

【特集1 ハード/ソフト技術、業界がわかる！　組込みシステム基礎の基礎】

この特集記事は、SESSAMEのメンバーでもある みわよしこ さんの記事で、「ハードウェア技術」「ソフトウェア技術」「組込み産業/組込み技術者」という3つの視点で組込みソフトにまつわるいろいろなことがらを解説している。ページをぱらぱらとめくってすぐに気がつくのは、部品が実装されたプリント基板や、LED、三端子レギュレータ、トグルスイッチ、ディップスイッチ、サーミスタ、モータなどの写真がふんだんに使われている点だ。組込みソフト系の雑誌というとデバイスのインターフェース周りの雑誌と、プロジェクトマネージメントやオブジェクト指向設計技術などどちらかに偏りそうなものだが、今回の組込みプレス Vol.3 は、その両方を網羅している。「大規模開発時代の組込みエンジニアのための技術＆マネジメント情報誌」というコンセプトに嘘はないように思う。

みわさんの記事は、具体的なハードウェアデバイスの特性や原理、使用方法を解説するとともに、プログラミングやテストリアルタイムOS、ミドルウェア、組込み産業の現状など、非常に広範囲に組込みソフトの領域を解説している。組込みソフトの世界に踏み込んだ新人や、ビジネス系から組込みソフトの世界に移り困惑している技術者にはうってつけの記事だ。

【本音で語る ソフトエンジニア vs ハードエンジニア】

組込み機器開発の中では日々起こっているソフト屋さんとハード屋さんのバトル。現場ではしょっちゅう起こっていることで、それぞれの立場の違いから起こる勘違いやいざこざはあることはわかっているものの、他の業種、他のプロジェクトでも同じなのかどうかはわからなかった。雑誌の記事の中でソフトエンジニアとハードエンジニアが意見を戦わせる座談会の様子が載るのはめずらしい。

【組込みソフトのプロになるための C言語入門】

C言語によるプログラムの書き方の解説に加え、この特集では組込みソフトエンジニアとしての心構えや考え方、コーディング規約や、コストとの闘い、品質の確保など、現場寄りの生々しい話題についても取り上げている。

【新人管理者のためのマネジメントの基礎知識】

この記事は、豆蔵のコンサルタントで、EEBOFのメンバーでもある井上樹さんの記事で、「QCD」「PDS」「段取り」「地図」の四種の神器で組込み開発の荒波を乗り越えるという内容だ。

大規模化したソフトウェアにはプロセスアプローチ、プロジェクトマネージメント、ソフトウェア工学の適用が不可欠だが、これらの理論をどのように、ソフトウェア開発の現場に適用すればよいかについて解説している。

【組込みソフト技術者のあるべき姿を探る】

この記事は、冒頭で紹介したように、 ２００６年1月23日に行われた Open SESSAME Workshop 2006 のパネルディスカッションの様子を記事にしたものだ。パネルメンバーは、前日経エレクトロニクスの編集長 浅見さん、東京大学CEOものづくり経営研究センターの立本さん、東陽テクニカの二上さん、電気通信大学の西さんの4人で、モデレータ役が自分だった。このパネルディスカッションは4人それぞれにロール（役割）をあらかじめ決めて、それぞれのロールで発言をしてもらった。浅見さんは組込み産業のマーケットリサーチャー、立本さんは産業競争力の分析者、二上さんは技術者教育のスペシャリスト、西さんはソフトウェア品質・テストの専門家といった感じだ。このパネルディスカッションの特徴は、パネルメンバーがそれぞれの分野のスペシャリストであるため発言の内容が深いところだと思う。このパネルディスカッションで語り尽くせなかった内容は、後日座談会を開いたので、こちら記事は組込みプレス vol.4 をお読みいただきたい。

【組込みリアルタイムソフトウェア開発のアプローチ】

最近独立系のコンサルタントとして活動は始められた橋本隆成さんの記事。「組込みソフトウェアとリアルタイムシステム」「組込みシステムの開発手法と戦略」「組込みリアルタイムシステム方法論の紹介」という3部構成となっている。組込みに特有のリソースの制約やリアルタイム性について、言及されており、DARTS(Designe Approch for Real Time Systems)やリアルタイムシステムの開発方法論「Harmony」が紹介されている。ビジネス系のモデルでは表現しきれないリアルタイム系のモデルの表現方法、設計方法についてさまざまな視点、開発方法で解決策を提示している。

【組込みユーザービリティエンジニアリング原論】

組込みの世界でユーザービリティはとても大事だ。ユーザーにとって使いやすい機器にできるかどうかは、ユーザーインターフェースの善し悪しにかかってくるが、今の組込み機器のユーザーインターフェースはソフトウェアの影響が強く表れる。ユーザーの使用環境をよく理解したエンジニアが製品開発全体を見渡せる時代はユーザビリティエンジニアリングは必要なかったのかもしれないが、ソフトウェアが大規模化した現在ではユーザビリティを分析した上でものづくりをしないと、ユーザーが使いこなせい機能が生まれてしまう。この記事ではユーザーの満足度を向上させるための組込みユーザービリティエンジニアリングについて解説されている。

【携帯電話開発の舞台裏】

この記事は組込みプレス Vol.3 の中でも一押しの記事だ。滅多にお目にかかれない、とってもおもしろいから絶対に読んだ方がいい。

何がおもしろいかといったら、著者の数々の苦い体験が具体例をともなって載っているからだ。アンチパターンをこれほど具体的に書いてある記事は貴重だ。たとえば

・数10Kバイトのメモリ削減のおふれが出る
・ポインタ幅の取り決めが守られずシステムリセット
・性能の高いシミュレーション環境では深刻な不具合が隠蔽されてしまう
・他社のコードをバージョン管理システムに登録する際の契約
・CPU内蔵の高速RAMが救ったプロジェクト
・海外の開発拠点で開くPM会議では必ず２名程度の欠席がある
・欧米人は年に計5週間ほどの休暇を取り、その間にメールを送ると休暇中のメッセージを発信する vacation プログラムが活躍している
・兵役で戦線離脱するエンジニア
・入社6年というと目を丸くする外国人
・大規模開発では優秀なエンジニアに仕事が殺到しボトルネックになってしまう
・英会話能力の低さが招く悲劇
・長い海外出張で減る日本国内の友人

などなど、おもしろい話題が満載だ。

【海外エンジニア事情】

日本と海外のエンジニアの環境や考え方の違いを知るのはおもしろい。いかに日本が特殊な環境にいるのかがわかる。今回はインド・バンガロールの様子が紹介されている。

【超入門！ダイナミックリコンフィギュラブルプロセッサ】

最近、コンフィギュラブルプロセッサという舌をかみそうなキーワードをよく見かける。まだ、完全に理解していないのでこの記事を読んで理解を深めようと思う。

【世界に広がるARM32ビットRISCプロセッサその理由とは】

ARMよく使われてる。なんでARMの使用が広がっているのか、ARMの特徴は何か、4回構成で紹介してくれるとのこと。

最後に、巻末の小林道場で 川柳を募集している。開発現場で起こった災難・苦労などを5・7・5の川柳で送ると特賞は図書券三千円が当たるそうだ。

『組込みソフトエンジニアを極める』に送られたメッセージ

『組込みソフトエンジニアを極める』がリリースされてちょうど一ヶ月がたった。編集者の話では実売は「まあまあ」とのこと。

ひとつ誤算だったのは、本のリリースにあわせて読者の声を吸い上げるためにWEBサイトやブログサイトを立ち上げたにも関わらず、現場の組込みソフトエンジニアの生の感想を十分に聞くことができていないという点だ。

組込みソフトエンジニアの口は結構重い。マイクを向けて興味のありそうな質問をすると答えてくれるし、日々苦労していることなどについて水を向けると堰を切ったように話してくれる。

でも、なかなか自ら情報を発信はしてくれない。要するに「強い個人」と「やさしい一員」の典型的なやさしい一員なのだろう。

ただ、情報を発信しないからといって何も考えていないわけではない。SESSAMEのセミナーでは毎回セミナー終了後に何ページにもわたるアンケートを書いてもらっているが、後で集計すると叱咤激励、自組織の問題点、愚痴、新たなセミナーやコンテンツのリクエスト、感動のメッセージ等々コメントがいっぱい書いてある。

ちなみに、昨夜ある組込み開発の現場で技術リーダーをしている方から、『組込みソフトエンジニアを極める』の感想メールをいただいた。

昨年秋のあるフォーラムでこの方がご自分の取り組みを発表していたときに、たまたま自分がその話しを聞いていて「これは本に書いた取り組みに似ている」と感じた。

まだ、原稿を脱稿したばかりだったのでとりあえずSESSAMEの名刺を交換をして自己紹介だけしてあった。

その後、本の見本ができたときに強引とは思いつつ、事情を書いたメールをお送りし「是非、本を読んでいただき感想を教えてもらえないか」と打診したところ快くお受けいただいた。その後、一ヶ月がたちそろそろかなと思っていたら、以下のようなメッセージをいただくことができた。全部を引用することはできないが一部だけでも紹介したい。

【組込み系の技術リーダーの方からメールより一部引用】

　　：
私と私が管轄するプロジェクトのリーダーの2人で読ませていただきました。総じての感想ですが、中堅のエンジニアに是非読ませたいということで意見が一致しました。
　　：
何も知らない初心者にはちょっとつらいかもしれませんが、ある程度実践経験のあるメンバーには、何をするべきかの良いインデックスの役割を持つと思います。特に１章では、技術的な課題とその背景が明確にされているため、解決策として何が有効なのかが理解でき現在の技術の必要性の理解に役立ちます。
　　：
本に書かれてある再利用の壁、品質の壁をに直面している段階で、第3章にあるように体系的な再利用を推進するためになにが必要かを見直している所です。
　　：
いくら製品のロードマップをベースにプラットフォームとなる構造を作り出し、再利用できる部品を作り出しても実際の商品化に有効利用していく体制を作らないと、構造も部品も定着しません。（コア資産になりません）これから、水平展開（裾野の拡大：定着）、ブラッシュアップ（再利用、品質と効率の向上）をすすめる段階に移ります。この本は、これからの我々にとって、良い指標・なにを考えるべきかの指標として、良い情報を与えてくれます。今後の展開に有効に利用させていただこうと考えております。

蛇足ではありますが、技術導入と水平展開には組織・体制などの整備が不可欠と思います。本書の立花さんの役割が重要になってくるのではないでしょうか。デマルコ風の外伝から予想して、立花さんの活躍（組織を動かす苦労）も載ってくるのかな？と思っていたのですが・・・。

技術導入は組織を説得する苦労とペアであるように思います。組織は数字による裏づけなしには動きません。効果の見せ方などにも言及していただくと、これまで動かなかった（動けなかった）エンジニアにも刺激になると思います。

【引用終わり】

このメッセージに対して以下のような返信を書いた。

【返信メールより引用】

本の感想ありがとうございました。

組込みソフトのソリューションはドメインによって処方箋が全部違うはずです。だから組込みソフトにはゴールドスタンダードがなくそのものズバリという本がないのだと思います。

そのような環境の中で実際に組込みソフトを開発している方に評価されたことが率直にうれしいです。この本書いてよかったと思いました。この本の中で繰り返し書いた真のユーザーに満足を与えることができたという実感をつかむことができました。

ところで、以下、さすがは現場で体系的な再利用に取り組んでおられる技術リーダーのコメントだと思いました。

> 蛇足ではありますが、技術導入と水平展開には組織・体制などの整備が不可欠
> と思います。本書の立花さんの役割が重要になってくるのではないでしょうか。
> デマルコ風の外伝から予想して、立花さんの活躍（組織を動かす苦労）も載って
> くるのかな？と思っていたのですが・・・。
> 技術導入は組織を説得する苦労とペアであるように思います。組織は数字による
> 裏づけなしには動きません。
> 効果の見せ方などにも言及していただくと、これまで動かなかった（動けなかった）
> エジニアにも刺激になるのではないでしょうか。次回作に期待していいでしょうか？

実は、組織を動かす・説得する苦労が載っていないという点については明確な理由が2つあります。

一つ目は、この本で想定したユーザー（顧客）と問題解決の目的はエンジニア個人とスキルアップであり、組織や組織の成功ではないという点です。もちろん、プロジェクトや組織に成功のための取り組みがテーマであることには間違いないのですが、本というプロダクトを買ってくれる最大の顧客はエンジニア個人です。したがって、組織を説得するというテーマは非常に大事ではありますが、何千人または何万人の組込みソフトエンジニアが求めているかと考えると追求すべきはエンジニア個人の利益（いかに苦境を乗り切るために学習意欲を高めることができるかどうか）の方が強いということになります。

二つ目は、私自身のこれまでの取り組みが自分のプロダクトのラインナップで実施してきた再利用、品質向上施策であり、組織全体にはまだ展開されていなかったからです。要するに自分の責任と権限の範疇で実施できたことを書いたというのが事実であり、組織を説得するようなところまでは至っていなかったというのが本当のところです。

ある意味、私は自分自身がリアルな世界で達成できなかったことを本というバーチャルな世界の中で立花という自分の分身に実現させて夢を見ていたわけです。

ところが、リアルな世界で異変があり、この4月から開発の現場を離れて現場のプロジェクトを支援・指導する立場になりました。

このことは本の原稿を脱稿してからわかったことで、本に書いた話が現実化してしまい苦笑いしているところです。

ということで、組織を動かす苦労はこれからたっぷりと味わうことになります。すでにその苦労は始まっていますので、何年かすれば組織を説得するためのソリューションをなんらかの形で示せるかもしれません。

【引用終わり】

最後にこの技術リーダの方が書かれた「技術導入は組織を説得する苦労とペアであるように思います。組織は数字による裏づけなしには動きません。効果の見せ方などにも言及していただくと、これまで動かなかった（動けなかった）エジニアにも刺激になるのではないでしょうか。」のコメントはEEBOFが取り組んでいる課題のひとつだと思う。

この課題の解決にはEEBOFとEEBOFでコンサルタント修行中のよしのさんのがんばりに期待したい。

自分の方も苦労話や成功体験がたまってきたら、このブログサイトでも公開できる範囲でお知らせしていこうと思う。

また、『組込みソフトエンジニアを極める』への感想、ご意見は巻末のメールアドレスまで是非お送りいただきたい。そられのフィードバックがあってこそ次回の改善につながるのである。

TOYOTAの組込みソフトウェアに関するリスク

トヨタ自動車は2005年度決算説明会で、2006年度はECU（電子制御ユニット）統合によるコスト低減活動を重視するとの方針を示した。（日経BP Tech-onの記事はこちら。無料の会員登録をしないと見られないので注意）

キター！という感じた。なにが「キター！」なのかというと『組込みソフトエンジニアを極める』の中で、これまでハードウェアとソフトウェアをセットにして機能分散してきた組込みソフトの作り方を、コスト削減のために機能集中的にしていくと、ソフトウェア品質を低下させるいろいろな危険が増えるよ、という主張をしているからだ。

左の図は『組込みソフトエンジニアを極める』の第二章－機能分割のハードルを越える－の中に出てくる図2.1 機能分散型と機能集中型の違いの図だ。

実はこの図の上は、自動車のEUC（Electronic Control Unit：電子制御ユニット）を想定していた。今自動車には100個以上のCPUが使われており、左右のドアミラーの制御にも一個ずつCPUが使われていると聞いたことがある。tech-onの記事にかかれているのは、ECUシステム（機能単位でCPUの数ではない）約60個を、複数のECUを一体統合化して標準4群に統廃合するというものだ。

もちろん、CPUの数が4個になる訳ではないが、ソフトウェア側から見れば機能分散的な作り方が機能集中型になるのは間違いないと思う。

このような機能分散から機能集中に移行する傾向は、自動車だけでなく、他の業務ドメインでも起こっている。

その原因はCPUの高性能化とコストダウンの目的からだ。CPUがムーアの法則（CPUの性能は18ヶ月～24ヶ月で2倍になるという経験則）によりどんどん高性能になるのだから、一個のCPUに機能を集中させてコストダウンしようと考えるのは当然だ。

しかし、ここには大きな落とし穴がある。CPU（ソフトウェア）とハードウェアが一体となって機能を担っていたときは、ソフトウェアエンジニアとハードウェアエンジニアが同じ土俵で仕事をしており、不具合が発生してもハード、ソフトに問わずエンジニアが顔をつきあわせて問題の解明に当たることができる。

ところが、機能集中型の作り方になると、ひとつの巨大なソフトウェアに対して、複数のハードウェアがぶら下がることになり、ハードウェアエンジニアはソフトウェアとのインターフェースだけをチェックして「後はよろしくね」というパターンになりやすい。どこで何をやっているのかわからないくらいソフトウェアが巨大化してているからしょうがない。

そのような状況になると、ソフトウェアの中身がどんどん見えなくなってくる。結局機能集中型の構造にしたとしても、いかにソフトウェアの中身が機能分割されてその分割が見えるようになっているかどうかがソフトウェアの信頼性や安全性に直結することになる。

ただ、『組込みソフトエンジニアを極める』で何回も繰り返したのは、ソフトウェアによる機能分割を優先させたことにより、時間分割（リアルタイム性、応答性）を犠牲にしてしまっては日本の組込みソフトのよさや強みを殺してしまうことになるということだ。

自動車のECUの場合は、これまで機能分散型でいかにネットワーク上で問題が起こらないようにするかに関心が集まっていたが、トヨタがコストダウンのため機能集中・機能統合をめざしたことによって、ソフトウェアの中の機能分散、独立性の確立に注目が集まるようになるだろ。

冒頭の記事の表面的な部分だけ見て、「コストダウンのためにCPUを一個にしろ！」などという経営者が出てくると後でひどいことになりかねない。

30代が主役

何の気なしにテレビのチャンネルを回していたら、作家の村上龍が二人の若者を相手に対談をしていた。

テレビ東京の「カンブリア宮殿」という番組だ。5月9日のゲストは、ミクシィ社長の 笠原　健治氏と、はてな社長の 近藤　淳也氏だった。なんとふたりはちょうど30歳。

ミクシィの笠原氏、はてなの近藤氏は、孫、三木谷に続く次世代のネット起業家と言われており、どちらのサービスも日頃お世話になっている。

ミクシィは日本のＳＮＳ（ソーシャルネットワーキングサービス。知人の紹介による会員制ネットコミュニティ）の最大手、はてなは知りたいことを文章で質問すると、ネット上のユーザーが回答を寄せてくれるシステム、どちらも基本的には無料もしくは低料金で利用できる。

笠原氏は東大出身、近藤氏は京大出身で学歴だけ見るとエリートのように見えるが、官僚を目指すようなテストの点数だけが高いエリートとは決定的に違う点がある。

それは二人とも自分たちのサービスを利用するユーザーのために有用なシステムを提供したいと考えており、顧客からの要望を徹底的に吸い上げ、圧倒的なスピードでシステムやサービスを改善することが大事だと言い切るところだ。

経営者が顧客満足を最大に考えるというのは当然だが、３０代の若い企業家兼技術者が「ユーザーの要望を吸い上げ、改善し続けることが重要」と言うのはいろんな意味で強い。スパークスシステムズ ジャパンのこうのさんもこの2人と考え方が一致していると思う。

この考え方は、『組込みソフトエンジニアを極める』でも引用したコトラーのマーケティング・マネジメント 基本編に出てくる、顧客が組織を駆動し、マーケティングが各機能を統合する顧客中心の考え方だ。これまでの企業は財務、人事、製造、マーケティングが同じ重要性を持っており、顧客の存在は薄かった。

３０代の若い優秀なエンジニアが顧客駆動の考え方でがんがん攻めてくるとこれは強い。もう何でもありだ。はてなの近藤社長は、スタッフ会議の様子をネットに動画配信しその会議の内容についてネット上のユーザーに意見を求めていた。

でも、これと同じようなことをおじさん達がたくさんいる組込みメーカーでやろうとする目を丸くされた上で、さまざまな障壁が立ちはだかる。大抵の場合は障壁を目の前にして新しい試みに嫌気がさしあきらめることになるのだが、Lifehacks って知ってた？のコラムで紹介したように若いエンジニア達のITスキルを解放して業務を変革することが組込みメーカーにも今求められている。

SEの実力を磨く究極仕事術―問題解決・図解術・会議の技術・メール術・プレゼン・時間管理術・やる気創造法という日経SYSTEM編のムック本に書いてある「やる気を阻害する要因となっている人や組織」の上位を紹介すると

1.上司(55.9%)
2.勤務先の会社(53.6%)
3.同僚/チームメンバー(32.4%)
4.顧客/ユーザー(23.5%)
5.部下(19.1%)

※複数回答可。有効回答数＝1613人

となっている。これはITエンジニアの例だが、いかに上司や勤務先の会社がモチベーションを低下させる要因となっていることか。

組織は30代の優秀な技術者の発言に耳を傾け、彼らのやる気をそがず、技術者のモチベーションが顧客満足の高い商品やサービスにつながるような手だてを考えなければならない。

ソフトウェア品質とは何か

こうのさんからエールをもらったので、精神的に余裕のある休みの間に読む人にいろいろ考えを発展させてもらえるような記事を書いておこうと思う。ちなみに、タイトル下雑誌の写真は クオリティワン―ソフトウェア品質のための総合情報誌 という日本科学技術連盟が発行しているソフトウェア品質に関する読み物で、今回の記事と直接の関係ない。しかし、ライオンと魔女の記事でも書いたように、エッセイの内容を象徴するような絵をワンポイントで入れるのは「どんなことが書いているのだろう」という疑問を一瞬で振り払う効果があるので、ソフトウェア品質の話題の象徴ということでこの絵を入れてみた。

さて、連休の間にこの記事も含めて4本書いたので結構いいペースだけれど、それは時間に余裕があるからだ。でも、よくよく考えたら、これまでメールやメーリングリストで結構ブログのネタになりそうな話題を何回も書いていることに気がついた。

これらのネタを小出しにしていけばブログもコンスタントに更新できるかもしれない。思いついたらすぐ事実行。

一ヶ月くらい前に、EEBOFのメンバーでソフトウェア品質に関わっておられる方から「新入社員に“システム開発における品質とはなんですか？”“標準とは何ですか？”と問われたとしたら、どのように回答しますか？」　という質問メールをもらった。ソフトウェア品質に関しては、『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－でも、結構真剣に書いたし、本業でも今後本格的に取り組んでいくことになったので考えていることはたくさんある。

この質問メールの答えが自分でもいい答えだったかもしれないと思ったのでここで紹介しようと思う。

【一回目の返信より引用】

まずは google で”品質とは”と検索するとミツエーリンクスという会社のこのアドレスがトップででてきます。

http://www.mitsue.co.jp/column/backnum/20030131a.html

このページに書かれている「品質とは、顧客要求を満たし満足させる程度」に賛同します。品質と顧客満足を結びつけた説明は中堅社員向きかと思います。

新人向けには ISO9126-1998 による　ソフトウェア品質特性および属性 を説明するとよいかも知れません。 ソフトウェアエンジニアリング基礎知識体系―SWEBOKに書いてあります。

機能性（Functionality）
使用性（Usability）
効率性（Efficiency）
保守容易性（Maintainablity）
移植性（Portability）

なぜなら・・・　新人技術者は答えのない、もしくは答えがひとつではない問題に解答するのが苦手な傾向があります。そういう訓練を受けていないのですね。だから、品質とはと聞かれたら、「国際標準で定義があるよ」と言うとそれ以上つっこんでくる可能性がほとんどありません。

しかし、中堅になってきたら、機能性がよいとなぜ品質が高いの？　とか、どんなメリットがあるの？とか、効率性を高めると保守容易性が低下することはないの？　とかについて考えて欲しいものです。したがって、冒頭の品質と顧客満足を結びつけた考え方を紹介した方がよいと考えます。

【引用終わり】

このあと、最初のメールだけでは何か説明が足らないような気がして以下のような追加のメールを送った。

【二回目の返信より引用】

一つだけ追加させてください。　品質を語るときは”誰に対しての品質であるか”を考える必要があると思います。　標準も同じで、いくら国際標準であっても特定の地域だけでしか売らないプロダクトなら従うメリットがないかもしれません。

"123.45" という（ピリオドで）小数点表示するソフトウェアがあって、そのソフトをスペインでも使う可能性があるのなら、"123,45" とカンマで表示できるようにした方がスペインやドイツのユーザーに対しての品質が上がります。

しかし、日本国内だけでしか使わないのなら過剰品質となり、その開発費を商品価格に上乗せしただけ、国内ユーザーに対して商品価値が下がると言えるかもしれません。

国際標準の場合、国と国との力関係もあるので一概にはいえませんが、グローバルに商売するのなら、CEマーキングとか取っておいた方が品質が高いと評価されることが多くなります。
PSEマークなんか付けていても、海外じゃなんの評価にもつながりません。

誰に対するとか誰のための品質かということを考えることも大事だと思います。

【引用終わり】

今もこの意見は変わらない。品質を考えるときに“誰のための品質か”について考えることは重要だ。そこがはっきりしないと、商品を提供する側が考える品質という価値を過剰にまた間違った形でユーザーに押しつけることになりかねない。冒頭で紹介したように品質を顧客が満足する度合いであると考えると分かりやすい。

ちなみに、ソフトウェアの品質を高めるためには金も時間もかかる。技術者への教育も必要だ。事故が起こってはいけないクリティカルデバイスにとって過剰品質などないという主張もあるかもしれないが、人も物も金も無限に使っていいわけではない。ソフトウェアの品質を高めた上で、競合他社との競争に勝って対価を得ていかなければ意味がない。

そのためには、、『組込みソフトエンジニアを極める』で書いたように顕在的価値（Real Value）と潜在的価値（Potential Value）のバランスをとることが重要だと思う。カタログスペックに書かれるような顕在的価値が高くても、商品が壊れやすかったり、保守の対応が悪いといった潜在的価値が低いとリピートオーダーはこない。しかし、潜在的な価値だけ高くても魅力的な商品にはならない。

やはり商品を市場に投入してユーザーに満足してもらいながら利益を得ていくのであれば、商品の顕在的価値と潜在的価値はどちらも高くなければならない。

誰のための価値か、誰のための品質かについて考えないと、そのバランスをとることは難しい。単純に機能性（Functionality）、使用性（Usability）、効率性（Efficiency）、保守容易性（Maintainablity）、移植性（Portability）の6つを高めるだけではソフトウェア品質は語れないはずだ。

ソフトウェア品質とは商品の潜在的価値に起因するもので、商品や組織、ブランドに対するユーザーの満足度と相関を持つ。また、ソフトウェア品質をどこまで追求すべきかは、商品の潜在的価値と顕在的価値のバランスを考えて決めるべき、というのが最終的な質問の答えとなる。

ライオンと魔女

つい最近、ライオンと魔女の映画を見た。映画が始まるやいなや目頭が熱くなってきた。なぜかというと、ライオンと魔女は少年時代に夢中になって読んだ本であり、自分の中で30年間もやもやっとした想像の世界の物語だったのに、そのもやもやが目の前のスクリーンで鮮明な映像となって再現されたからだ。

さらに、隣で10歳になる自分の娘が同じ映像を見ている。娘には何年も前にナルニア国物語の全7冊セットを買ってあったのだが、彼女はハリーポッターがお気に入りで勧めてもなかなか読んでくれなかった。それがライオンと魔女の映画化が決まり、コマーシャルが流れ始めてから本を読む気になって読破したところで、自分から映画を見に行きたいと言ってきた。（しめしめ）

娘のリクエストがきっかけということで見に行った映画の冒頭で父親の方がウルウルしてしまった訳だ。具体的には末娘のルーシーが箪笥の中のコートの束を通り抜けてナルニアの雪の世界に足を踏み入れたところ。やっぱり映像の力はすごいと思う。本は想像力をかき立てるが、映像はストレートに感情を揺さぶる。

しかし、映像による印象は非常に強いだけに、監督は原作のイメージと乖離しないような配役の人選に苦労したはずだ。全世界の子供たちが読み継いできたライオンと魔女は子供だけでなく親の方にも登場人物のイメージができあがっている。本を読んで登場人物のイメージをすでに持っている者に「あー、違う」と思わせてはいけない。そういう意味ではライオンと魔女の配役は本のイメージぴったりだった。

ライオンと魔女で一番印象に残っているのは、4人兄弟の末っ子ルーシーが半人半獣のフォーンで裸に赤いマフラー姿のタムナスさんの家に呼ばれてお茶をいただくシーンだ。タムナスさんは最初と最後しか出てこない登場人物なのだが、以前このブログでも紹介した『アメリカ人と日本人』で言うところの日本人の特徴である「やさしい一員」の性格が前面にでているキャラクターである。

タムナスさん役のジェームズ・マカヴォイは、みごとにやさしく愛嬌がありそれでいて悲しげな側面も持ち合わせた紳士のフォーンを演じている。

自分が日本人だからかどうかはわからないが、ライオンと魔女で一番気になるキャラクターがフォーンのタムナスさんなのだ。

ちょっと強引で申し訳ないのだが、『組込みソフトエンジニアを極める』の主人公、組田鉄夫のキャラクター作りのときもイラストレーターの武田亜樹さんにいろいろと注文をつけた。組田鉄夫のイメージは頑固で追求心が強くまじめな感じ。ここで人物のイメージと性格の設定がずれてしまうとすべてが台無しになってしまう。

キャラクター設定を間違うと、どんなに本の中身に納得しても違和感が残ってしまう。本に人物イラストを入れるのは諸刃の剣でもあるのだ。技術書における挿絵はそうでもないが、文学書における挿絵はその本に与える影響が非常に大きいと思う。

ライオンと魔女では、原作の挿絵にあるタムナスさんよりもジェームズ・マカヴォイが映画で演じたタムナスさんの方がより原作のタムナスさんの性格をより忠実に表していたかもしれない。

プロダクトラインが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 のマシンガン体制のベースには、コア資産を構築するのに時間と工数がかなりかかっているという情報を明らかにしてくれたこの記事の功績は大きい。

なぜなら、日本では悪循環を断ち切るために付け足し付け足しのソフトウェア開発はやめにして、どこかの時点で体系的な再利用戦略に切り替え、悪循環から好循環に移行したいと技術リーダーたちが考えていても、組織が一時的なコストアップや工数アップに理解を示してくれないからである。

日本でプロダクトライン戦略を成功させるには、現場のエンジニアの負担がさらに増えることを覚悟の上でコア資産を再構築しつつ納期も遅れされないという犠牲を払わないとダメかもしれない。

どちらにしても、プロダクトラインというキーワードが一人歩きせずに、成功例とともに体系的再利用戦略が広まることで、エンジニアの負担を減らしソフトウェアの品質を高め、商品の開発効率を高めることにつながって欲しいと思う。

Ｍｉｎｄｍａｐで幹を太くする方法

遅ればせながらマインドマップを書き始めている。

自分は古くから、インスピレーションというソフトを使っている。インスピレーションもマインドマップも考えをまとめるツールとして優れていることに違いはない。でもインスピレーションはブレイクせず、マインドマップはブレイクした。マインドマップの図は、よく見ると QC7つ道具の特性要因図（フィッシュボーン）にも似ている。

マインドマップをドローイングするツールとしては、ネオテニーベンチャー開発株式会社が扱っているMindManagerを選んだ。今はトライアル版を使っている。

マインドマップの図でよく見かけるのがたこ足のように中心となるトピックからのびた幹が中央が太くて徐々に細くなる描き方だ。これが簡単に描けると思ったらどうしてもやり方がわからない。

インターネットで調べてもわからないし、近くの本屋にはマインドマップの本は置いていないし、結局困ったあげく、ネオテニーベンチャー開発株式会社に問い合わせしてみたら、まだ買ってもいないのに丁寧に答えていただいた。おそらく、自分以外にも描き方がわからないで困っている人がいるやもしれないので、ここで教えてもらった操作方法を紹介しておく。

【ネオテニーベンチャー開発株式会社さんからの回答から引用】

[質問]
よくサンプルでみる湾曲した幹が中央は太く中央から離れるにつれて細くなり色づけする方法がどうしてもわかりません。

[回答]
はい。操作方法を以下に示しますのでお試し下さい。

1. 「中心となるトピック」を右クリック[Format Topic...]をクリックします。
2. 表示されたダイアログで 上部タブ[Subtopics Layout]を選択し、右部の[Line style]で「Arc」を選択してから下部の「適用」ボタンをクリックします。
3. 次に枝の太さを変えるために、ダイアログの上部タブ[General Layout]を選択して [Main_Topic Line Width] でスライドバーを右に大きく動かして下部の「OK」ボタンをクリックします。
4. すると枝をあらたに追加すると"タコ足"風の枝で追加できます。
5. 枝の色については それぞれの枝を選択してから、下部ツールバー[Line Color]から色を変更できます。(筆のアイコンをしたものがそれです。)

【引用終わり】

ネオテニーベンチャーさん、ありがとうございました。ちなみに、MindManagerって英語版なんですね。分かりやすい解説本を探そおっと。

→2006年6月に待望の日本語版が発売された。こちらから体験版がダウンロードできる。（酒井追記）

考える脳考えるコンピューター

いま、『考える脳 考えるコンピューター』という本を読んでいる。今からさかのぼること20年前、大学の卒業論文のテーマは「脳神経系のシミュレーションモデルの製作と検証」だった。当時はワープロは一般的でなく手書きで書いた原稿を製本して卒業研究論文としていた。

この論文の内容のサマリは『Software People Vol.4』のコラム「人間の考え方，コンピュータの考え方」に書いた。不思議と『考える脳 考えるコンピューター』とタイトルが似ている。

『考える脳 考えるコンピューター』はパームコンピューティング社を設立し事業としての成功を収めたジェフ・ホーキンスが長年興味を持っていた脳についての研究を続け研究所を設立してしまった。もうこななると趣味の世界ではない。ほとんど自分の脳への探求心を追い続けるための資金を調達するために事業をしているようなものだ。

まだ、完読できていないのだが、半分まで読み進んでジェフ・ホーキンスも自分もコンピュータと人間の脳の情報処理の仕方がまったく異なるということを十分に認識できているという点が一致していると思う。

ただ、新しい発見というか、新しい理解としてジェフ・ホーキンスは、コンピュータは脳の500万倍ものスピードで情報を処理できるのに、人間の脳の情報処理能力が高いのは脳が情報を並列処理しているからではないと『考える脳 考えるコンピューター』の中で書いている。並列処理するのではなく、すでに記憶した豊富な経験の中から答えとなる答えを連想により引き出すだけだから早いのだ。

問題に対して似たような成功体験をしていなければ、その問題に似た体験や知見の記憶を探すわけだが、そのような記憶がまったくない場合は混乱したり、不安や恐怖を覚えることもあるかもしれない。

EEBOFの研究員のよしのさんがブログの中で以下のように書いている。

【ブログより引用】

計画を立てずに見切り発車し、がむしゃらに取り組むと失敗するかな。たいていこういう時には、無駄な作業がたくさん発生するわりに、本当に必要な情報を見落としちゃったりします。

　　：
　　：

自分の気持ちの中では多くの時間をかけ「努力」したのにアウトプットがまったく出せないのは私に能力が無いんだろうと思うようになり、そこからは仕事が手に付かず、パニックになってしまったのです。皆さんはそういう経験ありませんか？

【引用終わり】

自分は、何かの企画・計画を立てるとき、過去の成功体験の中から似たようなものをつなぎ合わせて、うまくいくような感覚を持たないとスタートをかけない。その企画が自分だけのタスクですむことなら、成功のイメージが現実となる確率は高い。

しかし、自分だけでなく他人も巻き込んだプロジェクトの場合は、プロジェクトメンバーのスキルや性格から想定されるイメージとプロジェクトの目標を総合して、成功のイメージが描けるかどうかがポイントとなる。

自分だけのタスクではないので、最初のイメージがよくても必ずしもその通りにいかないときはままある。しかし、最初に成功のイメージがない場合、見切り発車して現実に成功する確率は低いように思う。

上記のよしのさんへのアドバイスは、若いうちは小さな成功体験を積み重ねる、成功しそうなプロジェクトに参加して成功体験を積み重ねることをやったらどうかと思う。