最近考えていること

ここ数ヶ月間、ブログへの投稿が減っている。9月は一件も投稿できなかった。理由は忙しさよりも環境の変化によるところが大きい。

2003年にSESSAMEで活動をするようになってから、本職の仕事とプライベートな立場でのコミュニティの活動を切り替えながらこなしてきた。

本職の仕事でモチベーションが下がったときは、コミュニティの活動に打ち込み、コミュニティで得た知識や人脈を本職の仕事に活かしたりして、両輪がうまく回っていた。

ブログは本職のノウハウに関係することはストレートに書けないので、一般化して書いたり、自分の業務ドメインとは違う自動車ドメインのことを書いたりしている。

そうこうしているうちに、最近になって工業会の仕事をするようになり、組織内での活動と組織外での活動の区別が付きにくくなってきた。

工業会の仕事というのは、自組織のためだけの活動ではなく、業界全体の利益、社会貢献のための活動であり、これまでやってきたコミュニティの活動とよく似ている。

したがって、スイッチのオンとオフの切れ目がはっきりしなくなってきたのだ。工業会の仕事をしていると、なんだか以前やっていたコミュニティの活動をしているような感覚になる。

だから、気持ちを切り替えるタイミングがはっきりしなくなり、工業会の活動を通じて社会貢献できているからいいかと思ってしまう。

ブログの目的は自分の中の頭の整理と、日本の組込みソフトウェアエンジニアのためにできることが有ればと思って書いているのだが「日本の・・・」って言っていていいのだろうかという気にもなってきた。

ここ数年で国際規格が出来上がってくる過程もわかり、自分もそれらの規格の検討に関わるようになると、問題は日本の中だけに留まっていないことも分かってきた。

もしかして、自分ができることは日本の中だけに閉じていないかもしれないという想いもある。

そんなこんなで、今は自分自身を充電している時期なので、どうか気長に新しい記事の投稿をお待ちいただきたい。

2013年8月の読者の関心事

下記の表はこのブログサイトの8月のアクセスページを滞在時間で1位から50位まで並べ替えたものだ。

不思議なことに8月は忙しくて一回もブログを書かなかったにも関わらず、お盆休みを除き、ウィークデーは毎日200件くらいのアクセスがある。そして新規読者が半数を超えている。

そして、下記の通り、時間をかけて読まれているは特集記事「ISO 26262との向き合い方」だ。

自分が興味をなくしたテーマにも関わらず世の中では記事を読みたい人がいるらしい。また、Google アラームで ISO 26262 のキーワードがヒットしなくなってきた。

約3ヶ月前くらいから ISO 26262 に関するニュースが流れなくなってきた。ついにキーワードによるブームが去ったのか。

これは勝手な想像だが、やっと当事者達はキーワードに踊らされていたことに気がついてきて、本当は何をするべきか考えるフェーズに入ってきたのではないだろうか。

それはいい傾向だ。そもそも機能安全で安全を追求できるのかについて、自分達の環境で自分達が作っている製品で考えてみるステージに移ってきたのだろう。

今、自分のドメインのことで頭がいっぱいなので自動車のことを考えている余裕がないが、困っていることがあって取り上げて欲しい話題があればこのサイトの右上の Message Leaf からメッセージを送って欲しい。

といっても、半分以上の読者が 検索エンジンで目的のページを直接開けているようなので、このメッセージは伝わっていないか。

1	ページ タイトル	平均ページ 滞在時間（分）
2	ISO 26262との向き合い方 (8) リスク分析しないでいいの？	29.72
3	ISO 26262との向き合い方 (10) ISO 26262 をテンプレートで乗り切る功罪	29.43
4	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	28.88
5	ISO 26262との向き合い方 (3) 規格認証とスコープについて	28.57
6	ソフトウェア資産の価値を可視化すべし	28.08
7	ユーザー要求の多様化とペルソナ法	27.90
8	ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する	27.00
9	ISO 26262との向き合い方 (21) 安全について理解を深める	26.62
10	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	25.33
11	ISO 26262との向き合い方 (6) 機能安全のマネジメント2	25.27
12	ISO 26262との向き合い方 (8) リスク分析しないでいいの？	25.22
13	MATLABのビジネスから見る知的生産性とは	25.00
14	ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2	24.78
15	ISO 26262との向き合い方 (14) FTAとFMEAの歴史	24.10
16	ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2	23.93
17	ISO 26262との向き合い方 (18) ツール認証って何だ？	23.55
18	ISO 26262との向き合い方 (21) 安全について理解を深める	23.35
19	100%の安全が確保できないからルンバを作らない？	23.23
20	ISO 26262との向き合い方 (22) テンプレートで乗り切る功罪2	22.58
21	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	22.37
22	ISO 26262との向き合い方 (11) ASILの分解は本当に可能か	22.16
23	ISO 26262との向き合い方 (21) 安全について理解を深める	22.12
24	ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する	22.05
25	ISO 26262との向き合い方 (3) 規格認証とスコープについて	21.68
26	プリウスブレーキ制御ソフト改変についての考察（再考）	21.55
27	ISO 26262との向き合い方 (13) 機能安全の歴史的背景1	21.50
28	トヨタのソフト戦略	21.20
29	ISO 26262との向き合い方 (4) 用語の定義からのトピックス	21.02
30	ISO 26262との向き合い方 (12) 対訳版を読み始めて思うことあれこれ	20.88
31	ISO 26262との向き合い方 (15) FTAを描いてみる1	19.95
32	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	19.63
33	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	19.28
34	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	19.00
35	ISO 26262との向き合い方 (18) ツール認証って何だ？	18.95
36	NHKのドラマ「メイドインジャパン」を見て2	18.82
37	ISO 26262との向き合い方 (15) FTAを描いてみる1	18.80
38	ISO 26262との向き合い方 (11) ASILの分解は本当に可能か	18.41
39	ISO 26262との向き合い方 (21) 安全について理解を深める	18.35
40	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	18.12
41	ISO 26262との向き合い方 (18) ツール認証って何だ？	17.63
42	Embedded Software Manufactory	17.23
43	ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）	16.92
44	ISO 26262との向き合い方 (20) 品質と安全の違い	16.83
45	西洋の真似をするだけというのはそろそろやめよう	16.70
46	ISO 26262との向き合い方 (13) 機能安全の歴史的背景1	16.50
47	ISO 26262との向き合い方 (1) 最初に読んで欲しいこと	16.27
48	ISO 26262との向き合い方 (6) 機能安全のマネジメント2	16.18
49	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	15.83
50	ISO 26262との向き合い方 (5) 機能安全のマネジメント1	15.53

冒険の旅をやりきるにはEP(Experience Point）の積み上げが必要

仕事で問題を解決すると自分の経験値が上がったと実感することがある。

ロールプレイングゲームの E とか EP (Experience Point) というヤツだ。経験値が設定値まで達すると主人公のレベルが一つ上がる。

ロールプレイングゲーム（左は初代ドラゴンクエストの画面）と現実の世界が違うのは、現実の世界では経験値が見えないということだ。

自分はセミナを開催したときは、「メールで送っていただいた質問には必ず返信します。」とアナウンスすることにしている。会場での質問に答えるのも自分自身の訓練になるが、メールで相手が満足するまで、納得するまでやりとりすると達成感があるとともに、自分自身の経験値が上がった実感を持てる。

自分のエンジニア人生を振り返ると、いろいろなことを勉強するのに必至だった20代、成果が上がってきた30代、そして、40代になって問題解決能力が高まってきた感じがする。

問題解決能力が高まってくると、いろいろな問題を解決することがだんだんおもしろくなってくる。難しい問題であればあるほどモチベーションが上がるのが自分でも分かる。

あるラジオ番組のパーソナリティが、日本人のボランティアは指示を待つ人が多いが、ボランティアの先進国であるアメリカのボランティアは助けが必要なところに乗り込んでいき、そこで求められていることを探して自ら仕事を作ると言っていた。

この話は『採用基準』に書かれていた、リーダーだけがリーダシップを発揮するという狭いリーダーシップの概念ではなく、プロジェクトの誰もがリーダーシップを発揮してよいという本来のリーダーシップのあり方にも通じると思った。

問題解決能力が高まると、どうすれば解決の道が拓けるかの道筋が見えてくるので、提案すべきことが浮かんでくる。メンバーの多くにそのようなひらめきが浮かべば、それを議論して何を採用すべきかを決めればよい。

日本の会議ではみんな黙っていることがあまりにも多い。解決策が思い浮かんでそれやりたいと思ったら、どんどんリーダーシップを発揮して、問題を解決してしまえばよい。自分が名目上のリーダーや責任者じゃなくてもいいのだ。

それを実践すると自分の経験値がどんどん上がっていくことが実感できる。外から見ると自らやらなくてもよい仕事を背負ったように見えるのだろうが、本人はものすごくモチベーション高く、取り組めている。自ら選択した問題に集中することができ、解決できれば実績になる。

それを繰り返してくると不思議と、他の人でもできる仕事が寄ってこなくなる。すると、結果的に難しいが自分がやりたい仕事だけに集中することができる環境ができてくる。

ただ、一つだけ問題があって、ロールプレイングゲームでは常に画面に表示されている HP(Health Point）やEP(Experience Point）は現実の世界では表示されてはいないということだ。

そうなると、溜まった経験値を何らかの形でアピールする必要が出てくる。いろいろ方法はあるだろうが、直属の上司にだけアピールするのはあまり得策ではないと思う。もちろん、組織内の機密情報は明かせないが、どんな経験値が積み上がったのかを一般的なことばで自分のプロフィールに追加して何からの形で表示するのは表現の自由が保障されている国でやってもよいだろう。

エンジニアのEP(Experience Point）って、とても重要だと思う。他人の批評だけしていても EP はまったく上がらない。現実の世界では、問題を解決してこそEP が上がるのだ。

そう考えると、人生観すら変わる可能性がある。嫌々日々の仕事を片付けるのではなく、どんな仕事も自分の経験値を高めることにつながると感じられるようになり、経験値が積み上がってきてレベルアップすると、よりやりたい仕事が選べるようになり、モチベーション高く、さらに難しい問題に挑戦できる道が拓ける。結果的にサラリーが上がるか、もしくはその実績を評価できる別の組織から声がかかるかもしれない。

傍目で見ていると EP がなかなか上がらない人がいる。そういう人はEP の上がり方をもう少し意識してみたらどうだろうかと思う。EP を効果的に上げるにはどうしたらよいか必至に考えると、何を学習すればよいのかが見えてくる。RPG の世界では EP を上げるには敵を倒すのだが、現実の世界では、リアルな問題を解決できるとぐっと EP を上げることができる。そのためには、どんな知識が必要で、どんな経験がいるかをよく考えるようになる。

そういう感覚を持っていると、世の中にある洪水のような情報の中で、自分の EP を上げるのに役立つ情報と、役に立たない情報の切り分けができるようになってくる。

情報を右から左に流したり、評論しているだけでは EP は上がらない。冒険の旅をやりきるには必ずレベルアップが必要で、レベルアップするには EP を積み重ねることが必要だということを意識しないといけない。