先日記事の中でピーター・F・ドラッカーの本は斜め読みしにくいと書いた。実際、『マネジメント - 基本と原則 [エッセンシャル版]』
は斜め読みしにくいと思ったが、買っておいてまだ開いてもいなかった『プロフェッショナルの条件―いかに成果をあげ、成長するか』を斜め読みしたら、こっちはすごく読みやすかった。
しかも、書いてあることが逐一納得できる。この本はネタ本としては最適であることが分かったので、これから少しずつ記事の中で小出しにしていきたい。
【ピーター・F・ドラッカー】
Peter Ferdinand Drucker、1909年11月19日-2005年11月11日)はオーストリア生まれの経営学者・社会学者。なお、著書『すでに起こった未来』(原題"The Ecological Vision")では、みずからを、生物環境を研究する自然生態学者とは異なり、人間によってつくられた人間環境に関心を持つ「社会生態学者」と規定している。ベニントン大学、ニューヨーク大学教授を経て、2003年まで、カリフォルニア州クレアモント大学院教授を歴任。「現代経営学」、あるいは「マネジメント」 (management) の発明者と呼ばれる。ドラッカーの著書の日本での売り上げはダイヤモンド社刊行分だけで累計400万部余り。
【『プロフェッショナルの条件』 はじめに より引用】
今日あらゆる先進国において、最大の労働人口は、肉体労働者ではなく知識労働者である。20世紀の初め、最先端の先進国でさえ知的労働者はわずかだった。全労働人口の3%を超える国はなかった。だが今日アメリカでは、その割合が40%を占める。2020年には、ヨーロッパ諸国や日本もそうなる。このように大量の知識労働者は、歴史上初めての経験である。彼らは生産手段を所有する。知識を所有しているからである。しかも、その知識は携行品である。頭の中にある。
:
もう一度繰り返すならば、知的労働者とは、他のいかなる者とも二つの点で大きく異なる存在である。第一に、彼らは生産手段を所有する。しかも、その生産手段は携行品である。第二に、彼ら(そしてますます多くの彼女ら)は、雇用主たる組織よりも長生きする。加えて、彼らの生産手段たる知識は、他のいかなる資源とも異質である。高度に専門分化して、初めて意味を持つ。脳外科医が真価を発揮するのは、脳外科に専門分化しているからである。おそらく、膝の故障は直せない。熱帯の寄生虫にいたっては、手もでない。
:
1950年代、60年代のアメリカでは、パーティで会った人に何をしているかを聞けば、「GEで働いている」「シティバンクにいる」など、雇用主たる組織の名前で返ってきた。当時のアメリカは、今日の日本と同じだった。イギリス、フランス、ドイツその他あらゆる先進国が同じだった。ところが今日、アメリカでは「冶金学者です」「税務をやっています」「ソフトウェアの設計です」と答えが返ってくる。少なくともアメリカでは、知識労働者は、もはや自らのアイデンティティを雇用主たる組織に求めなくなっており、専門領域への帰属意識をますます強めている。今日では日本においてさて、若い人たちが同じ傾向になる。
:
今や唯一の意味のある競争力要因は、知識労働の生産性である。その知識労働の生産性を左右するものが知識労働者である。雇用主たる組織の盛衰を決めるものも、一人ひとりの知識労働者である。
これらのことが何を意味するのかが、本書の主題である。・・・・
【引用終わり】
本を斜め読みするときでも、「はじめに」はじっくり読むことにしている。なぜなら、「はじめに」は著者が示したその本のコンセプトであることが多いからだ。『プロフェッショナルの条件』の「はじめに」はハッと思ったのは、21世紀においては知識労働者の割合が40%を超しているというところだ。
コミュニティ活動で組込みソフトエンジニアの教育コンテンツを作る活動をするにあたって、ソフトウェアの世界で技術者教育が大事であることは直感的に分かっている。当然、いい教育を提供するためには費用もかかるし管理工数もかかるのだが、組織内でその費用を確保する際に「それだけの費用をかけるのなら効果についても示せ」などと言われることがある。有効な教育コンテンツを作成することに心を砕いている人は、教育に対する費用対効果を示すことほど難しいことを知っており、「それだけの費用をかけるのなら効果についても示せ」などと言われると「ああ・・・分かってないなあ」と感じる。
しかし、ピーター・ドラッカーが書いているように先進国では労働者の40%が知識労働者であることが認知されていれば、白いキャンバスの状態で入ってきた新入社員に必要な教育を提供することがいかに重要であるのかがわかる。
新入社員・初級技術者への教育の重要性が理解できない理由は体系的な教育、体系的なOJTを実施しなくても、職場で働いていれば必要な技術が身に付くと考えているからに他ならない。
しかし、現在の組込みソフト開発は、20年前の数人のプロジェクト、1年から2年あった開発期間のときとは規模、複雑性からしてまったく状況が異なる。試行錯誤的なアプローチで30人、30万行の組込みソフトウェアを品質よくスケジュール通りにリリースすることはほとんど不可能である。(30人以上のプロジェクトはプロがマネージメントしないと倒れるの記事を参照のこと)
ただ、そうはいうもののビジネス系のソフトウェア開発と違って、組込みソフトの開発では、新しいデバイスを使うときや要素技術的な検討をするときは試行錯誤的なアプローチも必要だ。なぜなら、すでにできあがっているソフトウェアモジュールを組み合わせて商品が作れるような状況では、その組織にしかできないコアな資産があるとは言えず、結局は競争力の弱い製品しか作れないからだ。
だから、新しいデバイス、新しい技術、自分たちにしかない技術を使ったソフトウェアを試行錯誤的なアプローチで作り、再利用可能な資産となるように洗練させるという工程が必要になる。組込みソフトの世界では試行錯誤的アプローチも必要だし、要求を分析してシステムの構造を考えるといったトップダウン的アプローチも必要なのだ。
ところが、その両方のバランスを考えるまでもなく10万行を超えるような組込みソフトを試行錯誤的なアプローチでだけで作りきってしまうプロジェクトも世の中には存在する。このような組込みソフトで起こるバグは非常に見つけにくいし、再利用もしにくい。
そんなプロジェクトのメンバーが、『プロフェッショナルの条件』の「はじめに」に書いてあるように、パーティの席で見ず知らずの人に自己紹介する様子を見ていれば、おそらくほとんどの技術者は「○○株式会社に勤めています」とか「○○株式会社のソフトウェアエンジニアです」と答えるだろう。
自分自身はこんなときには「組込みアーキテクトです」と答えたいと常々考えている。ピーター・ドラッカーが書いているように所属ではなく専門領域を言いたい。その深層には自分は組織に所属していることでステータスを示したいのではなく、専門領域のプロフェッショナルとしてのステータスを主張したい気持ちがある。
そう考えると、技術者個人が勉強するのはパーソナルスキルを高めるためではなく、プロフェッショナルスキルを高めるためということになる。パーソナルスキルを高めることで終わってしまうと「USBコントローラを使いこなしたい」とか「オブジェクト指向設計を身につけたい」とか「UMLを覚えたい」という目標になるが、プロフェッショナルスキルを高めるためと考えると、「顧客満足を高めるために必要な技術はなんだろう」とか「上司を納得させてこの提案を通すためにプレゼンテーション能力を上げたい」といった一段高い視点で考えるようになる。
ピーター・ドラッカーの本を読むということ自体も同じだ。ソフトウェアエンジニアがマネジメントの神様の本を読む必要はないと考えるか、それもと組込みソフトエンジニアとしてプロの仕事をするためには知識労働者がすべきことを学ぶ必要があると考えるのかは、組込み製品開発のプロフェッショナルを目指しているかどうかで変わる。
知識労働者が生産手段を所有し、それが頭の中に入っているとなると組織はその頭の中の知識を表に出して資産化する必要がある。そうしないと、知識労働者が組織を去ると同時にその知識労働者の頭の中にある大事な資産までも持って行かれてしまうからだ。ソフトウェア技術者を代替えが可能な部品のように考えているマネージャはこのことを理解していない。
協力会社の社員が入れ替え可能なように見えるのは、新たにアサインされた代わりの優秀なエンジニアがソースコードに埋め込まれた設計情報を読み取っているか、もしくは再設計しているのかのどちかだ。どちらにしても、無駄な人件費がかかっている。そんな無駄な工数がかかっていても開発費が抑えられているのは、仕事を出しているクライアントの会社の社員よりも何倍も優秀であっても、会社間の上下関係だけで不当に安い賃金でこき使われているからだ。優秀なエンジニアがその能力を正当に評価されていない状況を見るのは辛いものだ。
さて、昨年のソフトウェア品質シンポジウムの講演で ものづくり経営研究センター長 藤本隆宏先生は、「ものづくりとは設計情報の転写である」と言った。(「人工物に託して、設計情報=付加価値を創造し、転写し、発信し、お客に至る流れを作り、顧客満足を得ること」であるという意味。(ものづくり戦略とソフトウェア品質参照のこと)
組込みソフトにおいて、設計情報とは設計プロセスであったり、UMLで示したアーキテクチャであったりする。(ソースコードは粒度の細かい設計情報であり、再利用という観点からすると資産価値は低い)
ソフトウェア技術者がプロフェッショナルスキルを意識していれば、価値の高い設計資産をアウトプットすることに重要性を感じるはずである。
『プロフェッショナルの条件』には、30年以上繁栄し続ける組織は滅多にないと書いてある。知識労働者の寿命はもっと長いので、組込みソフトエンジニアは組織への帰属を意識するよりも、専門領域のプロフェッショナルとしてどう成長すべきかを考えることが大事なのである。
2007-07-29
2007-07-24
こころの処方箋
元文化庁長官で臨床心理学者の河合隼雄氏が19日午後2時27分、脳梗塞のため死去した。
河合隼雄氏は 1928年、兵庫県生まれ。京都大理学部数学科卒業後、米国留学を経て、1962~1965年にスイスのユング研究所に留学し、日本人で初めてユング派分析家の資 格を取得した。帰国後、ユング心理学を基礎にした心理療法の「箱庭療法」を完成・普及させ、日本にユング派心理療法を紹介した。
私的諮問機関「21世紀日本の構想」懇談会の座長や、教育改革国民会議委員など政府関係委員を歴任し、2002年1月、史上3人目の民間人として文化庁長官に就任しており、テレビでもよく姿を見ることがあった。
河合隼雄さんは人を包み込むような雰囲気を持っており、その著書の多くを読んだ。今回は、なぜ、河合隼雄氏の本を読んでいたのかを書きたいと思う。
プログラムは正確でないと動かない、曖昧なままでは期待したような動きにはならない。C言語などの高級言語ではやや曖昧さを受容するようにもなったが、アセンブラの時代などでは一命令でも間違っていればまったくプログラムが動かなかった。
そのような状況下ではソフトウェアエンジニアはロジカルな思考を求められる。ロジカルであればあるほど間違いの少ないプログラムを書くことができる。逆に言えば、いい加減な性格の人はソフトウェアエンジニアには向かない。
地道にこつこつこつこつとプログラムを書き論理的な問題点や、仕様が曖昧な部分があるとすぐに質問しすべてクリアにしてから前に進むような性格のエンジニアがプログラマに向いている。ことプログラマという職種に限って言えば、完全主義者であればあるほど早くて正確な仕事をし優秀であると評価される。
ところが、人間の脳は本質的にはロジカルな思考システムではない。脳神経学的に言えばコンピュータが0か1かの判断をするのに対し、人間の脳は多数決で判定を下す。また、その多数決に使われる入力はいつも同じではないため、必ず一定の結果になるとは限らない。
ようするにソフトウェアエンジニアは仕事上ロジカルであることが求められているにもかかわらず、本質的にはロジカルではないのだ。
そのギャップはときに社会生活を送る上で障害を起こすことがある。コンピュータがロジカルであるが故に生身の人間もロジカルな思考であるかのように勘違いしてしまうのである。その勘違いが進むと、人間もロジカルにコントロールできるという錯覚に陥ってしまう。そして、現実の人間はまったく論理的ではないため、コンピュータのように正確に予測したようには動かず、予測と現実が異なるためそのギャップに苦しむことになる。
例えば、野球で1点差で負けている試合、9回2アウト、ランナー2、3塁で最後のバッターを送り出す監督は選手に何というと成功に結びつくか?
「何が何でもここでヒットを打って逆転しろ」というのが監督の本音だ。でも、ベテランの監督なら「三振してもいいから思い切って振ってこい」などと言うだろう。三振しては困るのだがプレッシャーを与えないために、まったく逆のことを言った方が結果がよかったりする。人間とはそんなものだ。
また、ソフトウェアが大規模複雑化すると、ソフトウェアプロジェクトには多くのソフトウェアエンジニアが関わり合う。ロジカルでない人間が集まってロジカルにプログラムを作らなければいけない。そんな状況で問題が起こらないはずがない。このブログで顧客満足を高めることが大事と言っているのは、ロジカルと非ロジカルの矛盾を抱えながら組織やプロジェクトや個人がともに成功するためには、共通の価値観である顧客満足を高めることを目標にすれば、非ロジカルな部分のずれを修正して方向性を一つにできると考えるからである。
さて、ソフトウェアエンジニア個人が河合隼雄氏の本を読むとどんなよいことがあるのか。
それは、若いとがった気持ちで日々の仕事の黙々と取り組んでいるソフトウェアエンジニアがいるとする。自分だけの範疇ではこのような技術者はいい仕事をしている場合が多い。ところが、このような論理的でとがった気持ちをずっと解除しないでいると、複数人で共同作業をする場面やプライベートな時間で人と接するときに空回りしたり、他人を精神的に傷つけたりする。
河合隼雄氏の本をこんなエンジニアが読むとこのようなとがった気持ちを鈍らせて、所詮人間なんてそんなもんなんだということを気づかせてくれる。
河合隼雄氏の著書の中で読みやすく、もっともコンパクトな文庫本が『こころの処方箋』(420円)だ。こころの処方箋の中の一節を紹介したいと思う。
【こころの処方箋-こころの中の勝負は51対49のことが多い- より】
中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。
あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。
こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。
51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。
:
:
【引用終わり】
河合隼雄氏のような包み込むような語り口で人間の心理は1か0では判断できないと言ってくれる人は他にはいないと思う。河合氏が亡くなって生の声を聞くことができなくなったのがとても残念だが、氏が残した言葉は本の中で生き続けており、ふとたまに読み返すとコンピュータの思考になっている自分を現実の世界に引き戻してくれるのである。
河合隼雄氏は 1928年、兵庫県生まれ。京都大理学部数学科卒業後、米国留学を経て、1962~1965年にスイスのユング研究所に留学し、日本人で初めてユング派分析家の資 格を取得した。帰国後、ユング心理学を基礎にした心理療法の「箱庭療法」を完成・普及させ、日本にユング派心理療法を紹介した。
私的諮問機関「21世紀日本の構想」懇談会の座長や、教育改革国民会議委員など政府関係委員を歴任し、2002年1月、史上3人目の民間人として文化庁長官に就任しており、テレビでもよく姿を見ることがあった。
河合隼雄さんは人を包み込むような雰囲気を持っており、その著書の多くを読んだ。今回は、なぜ、河合隼雄氏の本を読んでいたのかを書きたいと思う。
プログラムは正確でないと動かない、曖昧なままでは期待したような動きにはならない。C言語などの高級言語ではやや曖昧さを受容するようにもなったが、アセンブラの時代などでは一命令でも間違っていればまったくプログラムが動かなかった。
そのような状況下ではソフトウェアエンジニアはロジカルな思考を求められる。ロジカルであればあるほど間違いの少ないプログラムを書くことができる。逆に言えば、いい加減な性格の人はソフトウェアエンジニアには向かない。
地道にこつこつこつこつとプログラムを書き論理的な問題点や、仕様が曖昧な部分があるとすぐに質問しすべてクリアにしてから前に進むような性格のエンジニアがプログラマに向いている。ことプログラマという職種に限って言えば、完全主義者であればあるほど早くて正確な仕事をし優秀であると評価される。
ところが、人間の脳は本質的にはロジカルな思考システムではない。脳神経学的に言えばコンピュータが0か1かの判断をするのに対し、人間の脳は多数決で判定を下す。また、その多数決に使われる入力はいつも同じではないため、必ず一定の結果になるとは限らない。
ようするにソフトウェアエンジニアは仕事上ロジカルであることが求められているにもかかわらず、本質的にはロジカルではないのだ。
そのギャップはときに社会生活を送る上で障害を起こすことがある。コンピュータがロジカルであるが故に生身の人間もロジカルな思考であるかのように勘違いしてしまうのである。その勘違いが進むと、人間もロジカルにコントロールできるという錯覚に陥ってしまう。そして、現実の人間はまったく論理的ではないため、コンピュータのように正確に予測したようには動かず、予測と現実が異なるためそのギャップに苦しむことになる。
例えば、野球で1点差で負けている試合、9回2アウト、ランナー2、3塁で最後のバッターを送り出す監督は選手に何というと成功に結びつくか?
「何が何でもここでヒットを打って逆転しろ」というのが監督の本音だ。でも、ベテランの監督なら「三振してもいいから思い切って振ってこい」などと言うだろう。三振しては困るのだがプレッシャーを与えないために、まったく逆のことを言った方が結果がよかったりする。人間とはそんなものだ。
また、ソフトウェアが大規模複雑化すると、ソフトウェアプロジェクトには多くのソフトウェアエンジニアが関わり合う。ロジカルでない人間が集まってロジカルにプログラムを作らなければいけない。そんな状況で問題が起こらないはずがない。このブログで顧客満足を高めることが大事と言っているのは、ロジカルと非ロジカルの矛盾を抱えながら組織やプロジェクトや個人がともに成功するためには、共通の価値観である顧客満足を高めることを目標にすれば、非ロジカルな部分のずれを修正して方向性を一つにできると考えるからである。
さて、ソフトウェアエンジニア個人が河合隼雄氏の本を読むとどんなよいことがあるのか。
それは、若いとがった気持ちで日々の仕事の黙々と取り組んでいるソフトウェアエンジニアがいるとする。自分だけの範疇ではこのような技術者はいい仕事をしている場合が多い。ところが、このような論理的でとがった気持ちをずっと解除しないでいると、複数人で共同作業をする場面やプライベートな時間で人と接するときに空回りしたり、他人を精神的に傷つけたりする。
河合隼雄氏の本をこんなエンジニアが読むとこのようなとがった気持ちを鈍らせて、所詮人間なんてそんなもんなんだということを気づかせてくれる。
河合隼雄氏の著書の中で読みやすく、もっともコンパクトな文庫本が『こころの処方箋』(420円)だ。こころの処方箋の中の一節を紹介したいと思う。
【こころの処方箋-こころの中の勝負は51対49のことが多い- より】
中学生や高校生のなかには、私のところに無理矢理に連れられてくる生徒がいる。たとえば、登校拒否の子など、心理療法家のところなど行っても仕方ないとか、行くのは絶対嫌だと言っているのに、親や先生などが時にはひっつかまえてくるような様子で連れて来られる。嫌と思っているのをそんなに無理に連れてきても仕方がないようだが、あんがいそうでもないところが不思議なのである。
あるとき、無理に連れてこられた高校生で、椅子を後ろに向け、私に背を向けて座った子が居た。このようなときには、われわれはむしろ、やりやすい子がきたと思う。こんな子は会うやいなや、「お前なんかに話しをするものか」と対話を開始してくれている。そこで、それに応じて、こちらも「これはこれは、僕とは話す気が全然ないらしいね」などと言うと、振り向いて、「当たり前やないか。こんなことしやがって、うちの親父はけしからん・・・」という具合に、ちゃんと対話がはずんでゆくのである。
こんなときに私が落ち着いていられるのは、心のなかのことは、だいたい51対49くらいのところで勝負がついていることが多いと思っているからである。この高校生にしても、カウンセラーのところなど行くものか、という気持ちの反面、ひょっとしてカウンセラーという人が自分の苦しみをわかってくれるかも知れないと思っているのだ。人の助けなど借りるものか、という気持ちと、藁にすがってでも助かりたい、という気持ちが共存している。しかし、ものごとをどちらかに決める場合は、その相反する気持ちの間で勝負が決まり、「助けを借りない」という方が勝つと、それだけが前面に出てきて主張される。しかし、その実はその反対の傾向が潜在していて、それは、51対49と言いたいほどのきわどい差であることが多い。
51対49というと僅かな差である。しかし、多くの場合、底の方の対立は無意識のなかに沈んでしまい、意識されるところでは、2対0の勝負のように感じられている。サッカーの勝負だと、2対0なら完勝である。従って、意識的には片方が非常に強く主張されるのだが、その実はそれほど一方的ではないのである。
このあたりの感じがつかめてくると、「お前なんかに話しをするものか」などと言われたりしても、あんがい落ち着いていられるのである。じっくり構えていると、どんなことが生じてくるか、まだまだ分からないのである。
:
:
【引用終わり】
河合隼雄氏のような包み込むような語り口で人間の心理は1か0では判断できないと言ってくれる人は他にはいないと思う。河合氏が亡くなって生の声を聞くことができなくなったのがとても残念だが、氏が残した言葉は本の中で生き続けており、ふとたまに読み返すとコンピュータの思考になっている自分を現実の世界に引き戻してくれるのである。
2007-07-14
トム・デマルコの「プロジェクト管理」がわかる本
昨日、久しぶりに池袋のジュンク堂に行った。コンピュータ関連のフロアを一通り眺めてみた感じたのは、組込みソフトの本とテスト系の本がここ2~3年でかなり増えたなあということだ。
組込みソフトの本で痛切に感じたのは、組込みソフトだからといって作る対象製品を特定せずに、CPUや周辺デバイスをインタフェースするドライバや、ソフトウェアの作り方を一冊の本で説明してしまうのはどうかなということだ。
なぜかというと、組込みソフトは制約条件や業務ドメイン、商品群、商品を投入する市場によって、アーキテクチャが変わるし、目的を達成する方法も一つではないので、どんな組込みソフトの分野にも効くゴールドスタンダードはないからだ。
ゴールドスタンダードがあるように読者に期待させると嘘になると思う。だから、『組込みソフトエンジニアを極める』では電子レジスタ商品群という具体的なモデルを対象にして、要素技術から商品群全体のアーキテクチャ、品質向上技術、再利用施策について書いた。、『組込みソフトエンジニアを極める』の読者が、自分たちの業務ドメインでそこに書かれている内容を現場で活かすためには、電子レジスタのモデルで展開された具体的な例を、自分たちのプロダクトだったらどういう風に適用すればよいのか、どのように投影すればよいのか考えないといけない。
どんな組込みソフト開発でも「こんな風にやれば成功しますよ」とは書いていないので、もどかしいと思う方もいるかもしれない。仮想の電子レジスタの開発という具体例で、組込みソフト開発の全体の流れや、技術者としての考え方、モチベーションの持ち方をつかんでもらい、自分達の開発現場にその考え方を投影し、展開する必要がある。
そして、この本の中に出てくる個々のソフトウェア工学の技術、たとえば、リアルタイムOS、オブジェクト指向設計、要求分析技術、テスティング技術などはそれぞれ専門書で勉強して欲しいと思う。「こういときに、こういう専門技術が必要なのだ」というあたりをつけて欲しい。
『組込みソフトエンジニアを極める』は組込みソフト開発に対してエンジニアがどのようなスタンスで取り組めばよいのかを考えるガイドラインとしてとらえてもらえるとありがたい。そういう視点で見てもらうと、組込み系では他に類似する本はまだないと思う。
組込みソフトで難しいのは、ここの技術を深く掘り下げて解説する本は書きやすいのだけれど、それらの技術を使って個別の開発を成功させるにはどうすればよいのかについては、その商品をどんなもので、どんな市場に対してどんな制約下で作ろうとしているのかが分からないと最適な方法論をサジェスチョンできないという点だ。
だから、組込みソフトの商品開発に深く入り込んで、開発を成功に導いたコンサルタントはその方法論を知っている筈だが、守秘義務があるのでその核心部分を公にはできない。
さて、前置きが長くなったが、ジュンク堂で良い本を見つけた。『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』(吉平 健治著)¥735- だ。
この本は、トム・デマルコの著書『ピープルウェア』『デッドライン』『熊とワルツを』のエッセンスを図解で分かりやすく示してくれている。同じシリーズに『ピーター・ドラッカーの「マネジメント論」がわかる本-ポケット図解』もあるので、これも後で買おうと思う。(ピーター・ドラッカーの原本の方は斜め読みがしにくくめげている)
『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』もまだ、読み始めたばかりだが、最初の1-1がプロジェクト管理の本質を示していると思うので、最初の部分から全体を推し量ってもらうべくここで紹介したい。
【『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』 1-1 プロジェクト失敗の本当の原因は? より】
1. 本当の原因は人間の中に存在する社会学的問題
確かに生産性や品質は向上したでしょうが、実際、プロジェクトに対する要求の複雑化、規模の増大は、このような技術の対応だけでは追いつかないところもあります。デマルコは、プロジェクトの失敗の原因は技術的な問題ではなく、実は、プロジェクトとそのチームの「社会学的」な問題によって引き起こされていると宣言しています。チームメンバーの意思疎通が疎かになったり、働く意欲が欠如したり、あるいは退職してしまったり、プロジェクト管理者への不信感が募ったりなどなど、人そのものと人に関する問題がトラブルの原因になっているのです。そらに事態を悪くしているのは、この事実を管理者たちが理解していないことだと彼は言います。
2. 開発者は交換可能な部品ではない
ソフトウェアは結束したチームによって開発され、他の多くのチームや部署とコミュニケーションしながらでき上がるものです。本当にハイテク技術を使っているのは一部の「研究者」と呼ばれる人たちで、ソフトウェア開発者は実際には「人間関係ビジネス」に携わっているのです。したがって、開発者を機械のように交換可能な部品として考えるのは大変危険です。この危険な傾向が管理者たちの間でまかり通っていると、デマルコは警鐘を鳴らしています。
【引用終わり】
他にもさまざまなベストプラクティスについて書かれているので、まず、この本を眺めてからデマルコの原書を読むとよいと思う。
組込みソフトの本で痛切に感じたのは、組込みソフトだからといって作る対象製品を特定せずに、CPUや周辺デバイスをインタフェースするドライバや、ソフトウェアの作り方を一冊の本で説明してしまうのはどうかなということだ。
なぜかというと、組込みソフトは制約条件や業務ドメイン、商品群、商品を投入する市場によって、アーキテクチャが変わるし、目的を達成する方法も一つではないので、どんな組込みソフトの分野にも効くゴールドスタンダードはないからだ。
ゴールドスタンダードがあるように読者に期待させると嘘になると思う。だから、『組込みソフトエンジニアを極める』では電子レジスタ商品群という具体的なモデルを対象にして、要素技術から商品群全体のアーキテクチャ、品質向上技術、再利用施策について書いた。、『組込みソフトエンジニアを極める』の読者が、自分たちの業務ドメインでそこに書かれている内容を現場で活かすためには、電子レジスタのモデルで展開された具体的な例を、自分たちのプロダクトだったらどういう風に適用すればよいのか、どのように投影すればよいのか考えないといけない。
どんな組込みソフト開発でも「こんな風にやれば成功しますよ」とは書いていないので、もどかしいと思う方もいるかもしれない。仮想の電子レジスタの開発という具体例で、組込みソフト開発の全体の流れや、技術者としての考え方、モチベーションの持ち方をつかんでもらい、自分達の開発現場にその考え方を投影し、展開する必要がある。
そして、この本の中に出てくる個々のソフトウェア工学の技術、たとえば、リアルタイムOS、オブジェクト指向設計、要求分析技術、テスティング技術などはそれぞれ専門書で勉強して欲しいと思う。「こういときに、こういう専門技術が必要なのだ」というあたりをつけて欲しい。
『組込みソフトエンジニアを極める』は組込みソフト開発に対してエンジニアがどのようなスタンスで取り組めばよいのかを考えるガイドラインとしてとらえてもらえるとありがたい。そういう視点で見てもらうと、組込み系では他に類似する本はまだないと思う。
組込みソフトで難しいのは、ここの技術を深く掘り下げて解説する本は書きやすいのだけれど、それらの技術を使って個別の開発を成功させるにはどうすればよいのかについては、その商品をどんなもので、どんな市場に対してどんな制約下で作ろうとしているのかが分からないと最適な方法論をサジェスチョンできないという点だ。
だから、組込みソフトの商品開発に深く入り込んで、開発を成功に導いたコンサルタントはその方法論を知っている筈だが、守秘義務があるのでその核心部分を公にはできない。
さて、前置きが長くなったが、ジュンク堂で良い本を見つけた。『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』(吉平 健治著)¥735- だ。
この本は、トム・デマルコの著書『ピープルウェア』『デッドライン』『熊とワルツを』のエッセンスを図解で分かりやすく示してくれている。同じシリーズに『ピーター・ドラッカーの「マネジメント論」がわかる本-ポケット図解』もあるので、これも後で買おうと思う。(ピーター・ドラッカーの原本の方は斜め読みがしにくくめげている)
『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』もまだ、読み始めたばかりだが、最初の1-1がプロジェクト管理の本質を示していると思うので、最初の部分から全体を推し量ってもらうべくここで紹介したい。
【『トム・デマルコの「プロジェクト管理」がわかる本―ポケット図解』 1-1 プロジェクト失敗の本当の原因は? より】
1. 本当の原因は人間の中に存在する社会学的問題
確かに生産性や品質は向上したでしょうが、実際、プロジェクトに対する要求の複雑化、規模の増大は、このような技術の対応だけでは追いつかないところもあります。デマルコは、プロジェクトの失敗の原因は技術的な問題ではなく、実は、プロジェクトとそのチームの「社会学的」な問題によって引き起こされていると宣言しています。チームメンバーの意思疎通が疎かになったり、働く意欲が欠如したり、あるいは退職してしまったり、プロジェクト管理者への不信感が募ったりなどなど、人そのものと人に関する問題がトラブルの原因になっているのです。そらに事態を悪くしているのは、この事実を管理者たちが理解していないことだと彼は言います。
2. 開発者は交換可能な部品ではない
ソフトウェアは結束したチームによって開発され、他の多くのチームや部署とコミュニケーションしながらでき上がるものです。本当にハイテク技術を使っているのは一部の「研究者」と呼ばれる人たちで、ソフトウェア開発者は実際には「人間関係ビジネス」に携わっているのです。したがって、開発者を機械のように交換可能な部品として考えるのは大変危険です。この危険な傾向が管理者たちの間でまかり通っていると、デマルコは警鐘を鳴らしています。
【引用終わり】
他にもさまざまなベストプラクティスについて書かれているので、まず、この本を眺めてからデマルコの原書を読むとよいと思う。
2007-07-07
30人以上のプロジェクトはプロがマネージメントしないと倒れる
PMI東京支部月例テクニカルセミナー 組込み系プロジェクトの現状と課題-プロジェクトマネジメントの専門家への要請-(講師 株式会社 プロセスネットワーク 金子龍三 氏)に参加し、今後、組込みソフトエンジニアがどのように対応していけばよいのかイメージがわいてきた。
冒頭の絵は、30人30万行以上のプロジェクトでは、プロのプロジェクトマネージャがぐいぐいと引っ張らないと凧(プロジェクト)空に上がらず、地に落ちるというイメージだ。30人30万行という数字は目安でありソフトウェアの複雑度によっても変わると思うが、30人30万行の規模でプロジェクトマネージメントの技術を使わずに、品質の高いソフトウェアをスケジュール通りにアウトプットすることはほとんど不可能だろう。
もしも、この規模のソフトウェアプロジェクトで、なんとかスケジュールが間に合っているのであれば、それは、プロジェクトメンバーの誰か(全員か一部か、それともサプライヤか)が死ぬほど働かされているはずだ。要するに人海戦術的なアプローチで乗り切ろうとしているのだ。そして、苦労してリリースしたソフトウェアの品質はかなり危うい状態にある。
大きな組込みソフトウェアプロジェクトで必要なプロジェクトマネジメント技術とは次のようなものだ。
さて、プロジェクトマネージメントの技術はプロジェクトマネージャがその道の専門家から学び実戦経験で培ってもらうとして、組込みソフトエンジニアを目指す若者は30人30万行のソフトウェアプロジェクトの中でどういう心構えで毎日の仕事に臨めばよいのだろうか?
組込みシステムでプロの組込みソフトエンジニアとして成功するにはどうすればいいのかという観点で考えてみた。
【-大規模組込みシステムで-プロの組込みソフトエンジニアとして成功するには?】
<自分が選んだ業務ドメイン(業界)の知識、技術を徹底的に身につけ、その道のプロと呼ばれるようになる>
<自分が作ったソフトウェア資産が、顧客満足を高めていることを実感できること>
じゃあ、そこまでして組込みソフトエンジニアを目指すのはなぜだろうか?
【なぜ組込みソフトエンジニアになろうとするのか】
<好きなこと(市場・ドメイン)にずっと携わっていられる>
そうなると大事なのは、顧客満足の向上と技術者のスキルのスパイラルアップ(左図)を実現させることだ。
そして、顧客満足を高めることを示すには、ソフトウェアシステムのアーキテクチャを可視化しニーズを実現しているソフトウェア資産を指し示すことができないといけない。
日本の組込みソフトエンジニアは同じ市場に同じような商品を投入し続け、他社製品のよいところや市場クレームを吸い上げて、性能を落とすことなくソフトウェアを最適化する能力を持っている。しかも、作り上げたソフトウェアの品質が高い(規模が小さい場合)。
でも、今のままのすり合わせ的組込みソフト開発アプローチにはデメリットもある。デメリットを克服しながら日本の強みを生かす方法はこちらの記事を参照していただきたい。
これまで築き上げた職人技をアーキテクチャとして可視化し、再使用資産を抽出した上で他社がまねできないコアアセットを軸に商品コンセプトや強みを前面に押し出す。もともと品質は高いので、開発効率も上がり他社に負けない商品となる。
今後、大規模・複雑化した組込みソフトウェアのアーキテクチャは組込みソフト開発にとって重要な要素となり、場合によってはソフトウェアエンジニアの組織構造の方を、商品群のソフトウェアアーキテクチャに合わせていく必要も出てくる。(コアアセットを開発するチームをアプリケーション開発部隊から切り離すなど)顧客満足を十分に実現しているアーキテクチャは組織の重要な資産であり、優れたアーキテクチャは美しくもある。
ただ、組込みアーキテクトは商品開発の中で、泥臭い部分も飲み込んでいかなければいけない。組込みソフトがどんなに大規模化しても、昔も今も関係なく組込みアーキテクト・組込みプロジェクトのリーダーには、大工の棟梁としての素養が求められる。
冒頭の絵は、30人30万行以上のプロジェクトでは、プロのプロジェクトマネージャがぐいぐいと引っ張らないと凧(プロジェクト)空に上がらず、地に落ちるというイメージだ。30人30万行という数字は目安でありソフトウェアの複雑度によっても変わると思うが、30人30万行の規模でプロジェクトマネージメントの技術を使わずに、品質の高いソフトウェアをスケジュール通りにアウトプットすることはほとんど不可能だろう。
もしも、この規模のソフトウェアプロジェクトで、なんとかスケジュールが間に合っているのであれば、それは、プロジェクトメンバーの誰か(全員か一部か、それともサプライヤか)が死ぬほど働かされているはずだ。要するに人海戦術的なアプローチで乗り切ろうとしているのだ。そして、苦労してリリースしたソフトウェアの品質はかなり危うい状態にある。
大きな組込みソフトウェアプロジェクトで必要なプロジェクトマネジメント技術とは次のようなものだ。
- 技術戦略、技術マネジメント
- プロダクトリスクマネジメント
- 予算統制
- 再利用資産開発
- 専門家集団との連携
さて、プロジェクトマネージメントの技術はプロジェクトマネージャがその道の専門家から学び実戦経験で培ってもらうとして、組込みソフトエンジニアを目指す若者は30人30万行のソフトウェアプロジェクトの中でどういう心構えで毎日の仕事に臨めばよいのだろうか?
組込みシステムでプロの組込みソフトエンジニアとして成功するにはどうすればいいのかという観点で考えてみた。
【-大規模組込みシステムで-プロの組込みソフトエンジニアとして成功するには?】
<自分が選んだ業務ドメイン(業界)の知識、技術を徹底的に身につけ、その道のプロと呼ばれるようになる>
- 自分がこれからずっと関わる領域がストレートに好きであり、自分の技術を磨いてよりスキルが高まることに喜びを感じられることが一番大事
- 業務ドメインのプロと、ソフトウェアエンジニアとしての両方のプロになることが必要
- その道のプロとして終わりなき技術鍛錬に挑み続ける覚悟もないとダメ
<自分が作ったソフトウェア資産が、顧客満足を高めていることを実感できること>
- 一回切りではない、長く使われる品質の高いソフトウェア資産をアウトプットし、その資産が顧客満足を高めることに貢献することが、エンジニアとしてのモチベーションの源泉となる
- そのためには、ソフトウェアシステムのアーキテクチャ(構造)を可視化する技術が必要
- 自分が構築したソフトウェア資産はコレで、この資産が、商品のこんな機能や性能を実現しており、その機能・性能が商品のウリにつながっていると説明できるようにならねばならない
- それができないと、大きな組織の歯車の一つとして扱われ、一生日の目を見ない技術者になってしまう危険性がある
- 組込みソフトの世界には、ハードウェア出身、工場出身の上長、組織上位層がたくさん存在する
- ソフトウェアの特徴(複雑性や不具合の見つけにくさ)などを知らない者を相手に主張を通せるようにならなければいけない
- ソフトウェアは見えにくいため、自分や自分たちが構築したソフトウェア資産が、商品を通じてどのように顧客満足を満たしているのかを説明し、これを維持発展させるために必要なリソース、時間、資金を勝ち取らなければいけない
- 交渉し、主張し、提案や意見を通すことができなければ、よく働く都合のよい作業者となってしまう
じゃあ、そこまでして組込みソフトエンジニアを目指すのはなぜだろうか?
【なぜ組込みソフトエンジニアになろうとするのか】
<好きなこと(市場・ドメイン)にずっと携わっていられる>
- 車好きでエンジン制御のソフトを作っている
- カメラが好きでカメラのソフトを作っている
- 音楽が好きで電子ピアノのソフトを作っている
- 何もないところから少しずつ組み上がって完成する様を体感できる
- 自分のくふうが商品の機能や性能に反映される
- いろいろな商品から自分が作ったものをお客さんが選んで、満足してくれている喜び
- ヒット商品を世に出すことができたときの満足感
- 民生品ならば見ず知らずの人が自分が作った商品を手にしているところに遭遇することもあるかも
- 社会インフラを支えている裏方としての誇り
- 自分の仕事の成果が多くの人々の役に立っているという喜び
そうなると大事なのは、顧客満足の向上と技術者のスキルのスパイラルアップ(左図)を実現させることだ。
- ニーズを分析
- 技術的困難を克服
- ユーザーニーズを実現し満足を得る
- 新たな技術獲得への欲求が生まれる
そして、顧客満足を高めることを示すには、ソフトウェアシステムのアーキテクチャを可視化しニーズを実現しているソフトウェア資産を指し示すことができないといけない。
日本の組込みソフトエンジニアは同じ市場に同じような商品を投入し続け、他社製品のよいところや市場クレームを吸い上げて、性能を落とすことなくソフトウェアを最適化する能力を持っている。しかも、作り上げたソフトウェアの品質が高い(規模が小さい場合)。
でも、今のままのすり合わせ的組込みソフト開発アプローチにはデメリットもある。デメリットを克服しながら日本の強みを生かす方法はこちらの記事を参照していただきたい。
これまで築き上げた職人技をアーキテクチャとして可視化し、再使用資産を抽出した上で他社がまねできないコアアセットを軸に商品コンセプトや強みを前面に押し出す。もともと品質は高いので、開発効率も上がり他社に負けない商品となる。
今後、大規模・複雑化した組込みソフトウェアのアーキテクチャは組込みソフト開発にとって重要な要素となり、場合によってはソフトウェアエンジニアの組織構造の方を、商品群のソフトウェアアーキテクチャに合わせていく必要も出てくる。(コアアセットを開発するチームをアプリケーション開発部隊から切り離すなど)顧客満足を十分に実現しているアーキテクチャは組織の重要な資産であり、優れたアーキテクチャは美しくもある。
ただ、組込みアーキテクトは商品開発の中で、泥臭い部分も飲み込んでいかなければいけない。組込みソフトがどんなに大規模化しても、昔も今も関係なく組込みアーキテクト・組込みプロジェクトのリーダーには、大工の棟梁としての素養が求められる。
- しがらみや制約条件の中で舵取りができる決断力
- ハードウェア出身、工場出身の上司・関係者との交渉力
- アーキテクチャ(ソフトウェアの構造)の善し悪しを判断し悪い所を指摘し、良い例を提示できる実績と経験
登録:
投稿 (Atom)