2008-07-26

なぜ、この仕事を続けている? の投票結果

1. 好きで選んだ仕事だから 10 45%
2. この道で一流になりたいから 6 27%
3. お客さんに喜んでもらえるとうれしいから 5 22%
4. 生計を立てるため 4 18%
5. いまさら変えるのは面倒 3 13%
6. サラリーがそこそこいいから 3 13%
7. キャリアアップしたいから 3 13%
8. なんとなく 2 9%
9. この会社(組織)が好きだから 1 4%



投票総数 22名(複数回答可)


ちなみに、1と2と3と7と9はポジティブな回答、5と6と8はどちらかと言えばネガティブな回答となる。ポジティブな回答が上位にいったので、まずは安心。

なお、「好きで選んだ仕事だから」は組込みの場合、どちらかと言えば業務ドメイン(例えば車なら車関係、カメラ好きならカメラ関係)やものづくりに関係している組込み業界に愛着があるという人が多いのではないだろうか。

「この道で一流になりたいから」は業務ドメインだけではなく、ソフトウェアエンジニアとして一流になりたいという意味も含まれる。「キャリアアップしたいから」はスキル向上、出世に対する意欲を示している。

「お客さんに喜んでもらえるとうれしいから」は顧客満足が仕事へのモチベーションにつながっているので、多少辛いことがあっても前向きに仕事に取り組んでいける可能性が高い。

一方で、「生計を立てるため 」「いまさら変えるのは面倒」「なんとなく」はやや投げやりであり、一時的な感情であればいいが、長期的にそのような感覚を持ち続けているであれば、「好きで選んだ仕事だから」「この道で一流になりたいから」「お客さんに喜んでもらえるとうれしいから」といったポジティブな気持ちになるには何がどう変わればいいのかを考えることが必要だと思う。

長い人生の中で仕事を続けていくのだから「好きで選んだ仕事だから」「この道で一流になりたいから」「お客さんに喜んでもらえるとうれしいから」と思えるようになりたいものだ。
 

2008-07-21

ブログを訪れたきっかけとなった「キーワード」

学校も夏休みに入ったので本ブログも夏休みモード(楽して役に立つ情報の提供)に入ります。

今回は、本「組込みソフトウェア工房」に検索エンジンを使って訪れた人が使ったキーワードのランキング(過去一ヶ月間)をアップします。

傾向としては車系のキーワードが多いように感じます。固有名詞が出てくると「なぜ、この人が?」という興味が沸きますね。

キーワードの ISO 26262 とは 自動車分野の機能安全 のこと。機能安全ということばは何回説明を聞いても意味がよくわからないので個人的には嫌い。勝手に想像するに、ISO 26262 とは、車の安全を確保するために製造業者は何をすべきかを示した国際標準だと思う。

近年の自動車はECUを多数搭載し、ソフトウェアの量も尋常ではないため、ソフトウェアを安全にする、ソフトウェアで確実に安全をコントロールすることが求められています。国際的な基準を作って守っていかないと安全に動くのが当たり前と思っている自動車が凶器になる危険性があるから、このような基準が作られることになるのでしょう。

ただ、勘違いしないようにした方がいいのは、ISOはそれだけでは法的拘束力はありません。各国(ヨーロッパの場合はEU)が国内法に取り込む、または、規制の対象にしなければ法的な拘束力はないのです。ただ、ライバル会社が みな、その国際標準の適合を宣言したのならば、競合上他社に劣る、もしくは安全とはいえないと見なされ、売り上げが落ちるかもしれないので、みんな情報を収集しようとするのですね。

グローバルマーケティングにおいてトップグループを走っている日本のメーカーとしては、安全に関する国際標準をクリアできていないとは言えないでしょう。



キーワード セッション
1 iso 26262 37
2 組込みソフトウェア 16
3 協力会社 組み込み 13
4 シンドラー エレベーター 事故 12
5 組み込みソフト 設計 ドキュメント 12
6 embedded manufactory 11
7 問題解決能力 9
8 見せる化 9
9 matlab マイコン コード 8
10 國方 7
11 理系白書から考えるソフトウェア工学 7
12 組込みソフトウェア工房 7
13 はじめての課長の教科書 6
14 トヨタ 重松 6
15 jaxa 片平 5
16 シンドラー 事故 5
17 ソフトウェア 開発工程 5
18 トヨタ 戦略 5
19 トヨタの戦略 5
20 モデルベース開発 自動車 5
21 モデル駆動開発 5
22 misra-sa 4
23 nokia 戦略 4
24 ソフト プロセス改善 4
25 ソフト 技術伝承 とは 4
26 ソフトウェア 安全性 4
27 ソフトウェア分割 テクニック 4
28 ソフトウェア開発 工程 4
29 ソフト開発 工程 4
30 回路図 ソフトウェアエンジニア 4
31 月で遭難 4
32 理想 現実 仕様 管理 4
33 組込み 品質 改善 4
34 詳細設計 組み込み フローチャート 4
35 iec61508 ソフトウェア 3
36 matlab 開発効率 3
37 misra sa 3
38 uml 組込み 3
39 あしたをつかめ 平成若者図鑑 3
40 アメリカ人と日本人 3
41 シンドラー エレベータ 事故 3
42 ジョエルテスト 3
43 ソフトウェア開発工程 3
44 ハイバネーション技術 3
45 ベストエフォート ギャランティ 3
46 モデル駆動 3
47 仕様変更 組み込みソフト 3
48 品質とは 3
49 大西 建児 プロダクト ライン 3
50 安全設計 3
51 組み合わせ型製品 3
52 組み込みソフト 開発 図書 3
53 組み込みソフト開発 3
54 組込み emc 必要 3
55 組込みシステムではないもの 3
56 組込みソフトエンジニアを極める 3
57 進藤智則 3
58 酒井 embedded 3
59 alc工 2
60 critical system 組込み 2
61 eebof メーリングリスト 2
62 embedded ブログ 2
63 etss 2
64 labview matlab 比較 2
65 matlab スペクトル 表示 2
66 mbd 開発 2
67 qaスペシャリスト 2
68 rtosを使うメリット 2
69 uml 組み込み 2
70 xp マルチコア 最適化 2
71 あしたをつかめ平成若者図鑑 2
72 ここが変だよ日本の管理職 2
73 すり合わせ型 2
74 すり合わせ型 組み合わせ型 2
75 すり合わせ型とは 2
76 すり合わせ型開発 2
77 エレベーター事故処理 2
78 ギャランティ型ビジネスモデル 2
79 グローバル変数 割り込み 組込み 2
80 シンドラー 安全側 設計 2
81 ソフト バグ 再発防止 2
82 ソフトウェア 品質 過剰 2
83 ソフトウェア 品質とは 2
84 ソフトウェア 安全設計 2
85 ソフトウェア 組込み 再利用 2
86 ソフトウェア 開発計画書 2
87 ソフトウェア工学 品質特性 2
88 ソフトウェア開発 失敗 2
89 ソフトウェア開発手順 2
90 トヨタのマーケティング戦略 2
91 マイコン ソフトウェア 分割 2
92 モジュール 疎結合 2
93 ライオンと魔女 挿絵 2
94 人事 部下を選ぶ 2
95 共有結合 ソフトウェア 2
96 分析 設計 実装 評価 工程 ソフトウェア 2
97 品質とは ソフトウェア 2
98 商品コンセプト 2
99 問題解決キッズ 2
100 安全設計 組み込み 2

2008-07-05

ルールを決める権利を放棄する日本人

子供の頃、民主主義とは多数決で物事を決めることだと思っていた。ホームルームの時間に何か決めごとがあると、まず、議長がみんなから意見を聞き意見がが出尽くしたところで多数決を取る。

昔を振り返ると、学校のホームルームでは議論が発熱することはあまりなく、意見を言う生徒も大抵は決まっていた。いつも自分の意見を言わない者もいた。たまに自分が議長になったときなど、なかなか意見がでない状況で誰かを指名して無理矢理意見を言わせるのがイヤでしようがなかった。

「なぜ、最初から多数決を取らないのだろう」と思ったものだ。

ところが最近になって、そうは思わなくなった。何で物事を決める際に議論をしつくさなければいけないのか何となく分かってきたような気がする。

例えば、組込みソフト開発において、プロジェクト内でコーディングルール・コーティングスタイルを決めるというシチュエーションを例に取って考えてみよう。

自分の経験ではプロジェクトに「コーディングルールを決めてください」とお願いすると、サッとできてくるチームとコーディングルール・コーディングスタイルを提示してあげなければいつまでたっても出来てこないチームの二通りがある。

ちなみにサッとできているチームも、必ずしもプロジェクト内で十分にディスカッションしているとは限らない。率先してコーディングルール・コーディングスタイルはこうあるべきと主張する一人のエンジニアの考えを丸呑みしてしまっていることも多い。

これは、ホームルームの時間に議長が意見を求めても、一部の人しか発言しない状況とよく似ている。発言してその案が採用されたときに言い出しっぺとして「自分自身に責任が降りかかってくるのではないか」という恐怖心があるのではないだろうか。

民主主義で物事を決めるということは、参加者が自分の意見を発言するという権利を行使してディスカッションの場に提示し、自分の意見の正当性を主張し、意見が一つにまとまらなかったら多数決で決定するということだと思う。

なぜ、少数意見も含めて議論をし尽くしてから多数決を取らなければいけないかと言えば、議長は会議の参加者が自分の意見を発言するという権利を出来る限り平等に行使できるように気を配らなければいけないからだ。

ようするに少数意見であっても発言させないのはアンフェア-だから、議論をし尽くさないで多数決を取ってはいけないのだ。

でも日本人は「さあ、発言してください」と会議で口火を切ると大抵の場合黙っている。黙っているということは発言できる権利を放棄しているということになる。

発言の権利を放棄してしまったということは、無条件に決めごとに従うと宣言したようなものだ。日本人はこの権利を放棄しているという感覚が分かっていない。

例えば、自分たちでコーディングルールやコーディングスタイルを決められないチームに、ベースとなるコーディングルールやコーディングスタイルを提示すると、いったんはそれに従おうとするが、しばらくしてルールに逸脱する者が現れても、それを注意したり、自分たちで是正しようとしない。ルールからの逸脱を外部の誰かから指摘されない限り、是正しようとしない。

これは日本人の気質だと言ってしまえばひと言で終わってしまうが、民主主義を自分たちで勝ち取った権利であると考える人たちからみればルールを自分たちで決める権利を放棄したのに、指定されたルールに従わない実にアンフェア-な人々に見えるに違いない。

自分たちでルールを決めることに消極的な組織はルールに振り回される傾向がある。ルールを決める際に議論に参加していないため、「そのルールがなぜ決まったのか」、「どうしてそうしなければいけないのか」についての思慮が足りない。だから、ルールを守る方も守らせる方も重箱の隅をつつき合ってはちょっとした逸脱について過敏に反応したりする。

ISO9001の外部監査、内部監査などで是正を食らわないことだけを争点に水掛け論をしている光景を目にすると、品質マネジメントシステムがキチンと機能しているかどうかを確認していることを忘れているのではないかと感じる。

原理原則を理解せずにルールに振り回されている日本の技術者は大勢いいる。このような技術者は他人にバグを見つけてもらっても「ありがとう」とは言わないし思わない。

アメリカ人と日本人』の記事で書いたように、日本人は「あたたかい人間関係の中のやさしい一員」としてものづくりに有利な面を持っていると思う。しかし、「創造性と個性にあふれた強い個人」の人たちとも一緒に仕事をしなければいけないし、「創造性と個性にあふれた強い個人」が作ったルールに従わなければいけない場面も多々ある。

【よくある日本のプロジェクト】
・ルールを自分で決められない(ルールを決める権利を放棄してしまう)
・ルールからの逸脱を是正することができない(自制できない)

なぜ、これがいけないのかといえば、ルールを自分で決められず、ルールからの逸脱を是正することができないプロジェクトや組織は品質の高いソフトウェアをアウトプットできない可能性が高いからだ。30万行を超えるような規模のソフトウェア開発では特にそう思う。

ルールがあっても形骸化する組織やプロジェクトはルールの作成時の議論に積極的参加していない(権利を行使していない)か、ルールの本質を理解していないからだ。

そう考えるとすでに存在するルールをプロジェクトに適用する際には、最初にその本質も含めてプロジェクトに対して最初にキチンと説明してから適用しないとフェアーではないということになる。開発の途中からルールへの遵守を求められたら、それはフェアーではないと主張しなければいけない。

組織はプロジェクトに対してルールを理解させるトレーニングを提供する義務がある。そして、いったんルールの意味を理解したのならば、対象者に資格を与えルールからの逸脱を監視して、場合によっては資格を剥奪しなければならない。

こういうまどろっこしいことを一切省略して、プログラマーの能力を最大限に引き出し、ソフトウェアシステムの完成度を高めるという開発手法もある。優秀なエンジニアの集団にルールを押しつけるよりも、このような方法でプロジェクトのパフォーマンスを上げる方を優先させた方が結果的に品質が上がる場合もある。

しかし、このような技術者個人に依存するやり方では組織は常に一定の水準のソフトウェア品質を担保できるとはいえないし、その組織が品質の高いソフトウェアをアウトプットできることを内外に示すことができない。ルールやプロセスやプロセス内で実施する活動を規定せずにソフトウェア品質を高めるしくみがないとダメだ。でも、人間がキーボードをたたきながらソフトウェアを作っている限り、そんな都合のいい方法はないだろう。

日本人もルールに正面から向き合うくせをつけて、ルールを自分たちで決める権利についてよく考え、頭の中で権利と義務と責任について常日頃整理しておかないと、グローバルマーケットでものづくりはできないと思う。