ひとりでは学食に入れないという若者が増えている

今週はもうひとつ映像コンテンツの感想を書こうと思う。NHK で4月23日（金）19:30に放送された特報首都圏「“ひとり”が恐い」というテレビ番組を電車の中でラジオで聞いた。


ゲスト ： 土井隆義
キャスター ： 中野純一

ひとりでは学食に入れないという若者が増えている。なかにはトイレで食事をすませる学生もいる。背景には、周囲から友だちがいないさびしい人間だと思われたくない心理が働いている。専門家は、携帯メールで２４時間常に維持される友人関係が、自己肯定感の大部分を占めるようになったと分析。大学では、友だち以外の分野で自分の居場所を持てるように、さまざまな取り組みを始めている。“ひとり”が怖いという若者の姿を伝える。

簡単に解説すると、学食でひとりで食べていることを見られることで、「あいつは友達がいないんだ」と思われることがイヤなので、そう思われるくらいなら歩きながらパンを食べたりトイレでささっと空腹を満たす方がいいとということなのだ。

「それほどまでに他人の目を気にするなんて」と思った人は、現代の若者達のコミュニケーションの方法について理解が足りていない。そうなる原因は携帯電話によるコミュニケーションの変化にある。

ようするに、現代の社会人になる前の若者達はメールで連絡を取り合うことで友達との連帯感を確保している。24時間「レス」できるようにしておくことが友達としての証であり、それができないと友達との距離が生まれる。

番組ではアドレス帳が500件までしか登録できないので700件まで登録できる携帯に買い換えた女子大生が出ていた。携帯電話のアドレス帳が友達の範囲であるような印象を感じる。

嘉悦大学では大学の入学式の前に新入生を集め大学構内を二人ひと組で回り、教授やサークルの先輩を訪ねるオリエンテーションゲームを行い、新入生の心のハードルを下げることに成功しているとのことだった。

冒頭に紹介したひとりで学食で食べられない学生に対して一緒に食事をしてくれるカウンセラーがいる大学もあるとのこと。（そうしないと辞めてしまう学生が後を絶たないのだとか）

もしも、自分が学生時代に携帯電話があったら確実に今の若者と同じ事をしていると思った。その環境があればもっとコミュニケーションが多くなって活動の範囲が広がったのではないかとも感じる。

ただ、その環境がなかったことでよかったのは一人で考えを巡らす時間が十分すぎるほどあったということだと思う。大学から離れた時にはたっぷりと一人の時間があった。

番組では携帯メールによる広くうすい四六時中つながっている状態の友達関係は若者の自立を疎外する傾向があるという。「自分は自分、他人は他人」という自己の確立が遅れるというのだ。

昔は、中学→高校→大学→社会人という流れの中で自己の確立が強まっていくのだが、携帯電話によるコミュニケーションにより、中学生レベルの自立にしかなっていないらしい。

twitter も24時間見ていてつぶやかないと疎外されるような感覚を持つようになると同様の問題が起きる可能性がある。

ちなみに、こういう時代になってしまった以上、パソコンや携帯電話が悪でありそれを排除すれば問題は解決すると考えるのはムリがあると思っている。なぜなら、これらのアイテムによるメリットもあるし、現実的に排除などできないからだ。

インフラの変化やコミュケーション手段の変化をキチンととらえて、それらのメリット、デメリットを把握しながら、どう向き合えばいいのかを考えていく必要があると思った。

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』という映画をTSUTAYAでレンタルして見た。あまりに内容がドラマティックだったので、これはどこまで脚色されているのだろうかと思って、もとのスレッドがまとめられているwikiサイトで記述をざっと読んでみた。驚いた。ほとんどスレッドに書かれていることが忠実に再現されているように見える。

考えさせられたのが、ここに描かれているのは組込みとITの違いがあるにせよ、同じソフトウェアを作るエンジニアの日々の風景だということだ。

この話しは本やコミック、映画になっているが、知らない人もタイトルを見れば、だいたい中身の予想は付くだろう。映画の中では R25 にブラック会社の条件が6つ書いてあり、主人公のマ男君が入社初日で全部当てはまることに絶句する。

【ブラック会社の条件】

1. 就業規則があるにも関わらず残業が当たり前
2. 何日も徹夜が続くことがある
3. 社内に情緒不安定な社員がいる
4. 必要経費が一切認められない
5. 同僚のスキルが異常に低い
6. 従業員の出入りが激しい

そして、確かにそういう会社がスクリーンに登場する。ちなみに、それはそれとして自分は主人公のマ男君や他のプロジェクトメンバーがやっている仕事の内容、流れについて見ていた。

【仕事の流れ】

1. 営業がクライアントから仕事を取ってくる。
2. 同行した技術担当は要求された仕事に対して開発期間が足らないと感じる。
3. 技術担当がクライアントにその日程ではムリと言おうとするとクライアントからダメなら他に回すよといわれ営業が受けてしまう。
4. 開発委託を受けた時点からすでにデスマーチが始まる
5. 納期に対してプロジェクト全体が責務を負い、遅れは分散するか特定のエンジニアへ集中させることでカバーする
6. 要求定義→設計→実装→テスト という工程はキチンと踏んでおり、プロジェクトの終了はシステムテストの成績書がすべてパスしたときになっている。
7. 死ぬほど残業してなんとか納期に間に合わせる。

そこでふと思ったのは、仕事の厳しさの違いはあるにせよ、この流れはどんなソフトウェアエンジニアも多かれ少なかれ経験しているようなことにように見えるということだ。

ブラック企業になるかならないか、もしくは、エンジニアが潰されてしまうかいなかの違いは、3のムリな日程を受けてしまうという部分と、5 の遅れの分散と特定のエンジニアへの仕事の集中のところだと思う。

【ムリな日程を受けてしまう営業】

クライアントとサプライヤという関係の場合、一般的にお金を払うクライアントの方が立場が強い。「イヤなら他に回すよ」と言われたら条件を飲まざる終えない。その条件を跳ね返すためには、ムリな日程を飲む以外の付加価値が必要になる。その付加価値が他の会社にはない価値でなければ競争に負けてしまう。

メーカーの場合、お金を払ってくれるのはエンドユーザーであり、リリースして商品が売れるか売れないかが分かるにはそれなりのディレイがあるから、請負開発の場合はよりプレッシャーが大きいと思う。

この問題は会社の経営者の考え方と経営方針で決まるのだろう。エンジニアを薄給でこき使って使い捨て目の前の売り上げを確保するという考えを持っているか、顧客満足を実現するのはエンジニアであり、顧客満足とエンジニアの満足・成長の両立を考えるのかで 180度環境は変わる。

後者よりも前者の会社に仕事を出すクライアントが多いとエンジニアにとって状況は改善しない。二次、三次といった下請け構造があると、下の階層になるほど環境は悪くなる。

『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』の主人公は、実力はあり、唯一近くにいたよき先輩に鍛えられてブラック会社の中で成長するのだが、ブラック会社にしか入れなかったのは学歴で能力を判断されてしまったからだった。

もしこの話しが本当であったのならば、マ男君は死ぬほど苦労したが、3年間でプロジェクトリーダーを一回経験しプロジェクトも成功させたのだから、その実績を使ってもう少し環境のよい会社や、クライアント企業への転職などもできるのではないかと思った。ようするに、学歴以外の実績は実際の仕事を成功させることで積み重ねることができると思うのだ。

【遅れの分散と特定のエンジニアへの仕事の集中】

これは「あたたかい人間関係の中のやさしい一員」という日本人の特性のよい面と悪い面が両方でていると思う。プロジェクトの中で職制がはっきりしておらず、遅れを全体でバックアップするというやり方は連帯感を生むメリット、達成感を共有できるメリットがある一方で、個の確立を疎外する側面もあると思う。

技術者個人の成果や負荷が見えにくくなると思うのだ。責任と権限が明確な世界では他人の領域には指示がなければ踏み込まないから最終的な責務と成果が個人別にはっきりする。

それが曖昧だとブラック会社では優秀なエンジニアに負荷が集中し、その成果はプロジェクト全体に分散されてしまう。ブラック会社でなくても日本の企業ではそういう傾向があるように思う。

そうすると優秀な技術者が潰される可能性が高くなり、かつ、その様子を見ている他の技術者は積極的に仕事の効率化を目指さなくなる。

【『ブラック会社に勤めてるんだが、もう俺は限界もしれない』スレッドより引用】

スレタイの意味・・・
それは、木村くんの下克上でも、父ちゃんの病気でもない。
藤田さんが、会社を去る・・・。まさにこれこそが限界だったのだ。

何のためにスレッドを立てたのか。
確かに俺は限界だった。
このスレッドを立て、全てを書き終えた時、俺は退職しようと心に決めていた。
伸びても、伸びなくても、それは変わらない。
結果的にスレは物凄い勢いで伸び、パー速に移住するほどになってしまった。

そして、その中で俺への励まし、心配、叱咤。
色々なレスが俺に向けられて書き込まれた。
ブログのコメントは、続きを書いてくれ、という内容ばかりだった。
俺は今まで、誰からも必要とされない、居なくなっても誰も悲しまない
くだらない人間だと思ってたんだ。

だけど、このスレを立てた事で
俺はみんなから励まされて、心配されて、叱咤されて・・・
たった一人の力は確かに小さいかもしれない。
だけど、それが何十、何百となったら？
その小さな力が集まって、大きな一つの力となったら？

俺は奇跡を信じる気になったよ。
だって、スレッドタイトルが変わるんだもの。
『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』が
『ブラック会社に勤めてるんだが、まだ俺は頑張れるかもしれない』に。

【引用終わり】

スレッドの最終章を見ると、マ男君を支えたのは先輩の藤田さんと、ブログで応援してくれた人たちというだということが分かる。

ソフトウェアエンジニアは知識労働者だ。人間が人間の頭で勝負している世界だ。そう考えるとやっぱり人間を人間として扱ってもらえる環境と人間の頭を成長させてくれる環境と、自分自身の知識労働者としての意欲が大事であるということが『ブラック会社に勤めてるんだが、もう俺は限界かもしれない』を見て再認識した。

ポイントは実績がないときには、今の仕事を成功させてその中で達成した他から認められうる点を積み重ねてそれを武器にすることだと思う。そのためには今の仕事をやっつけでいい加減にこなしてはいけない。この一つ一つの仕事をまわりに自慢できるくらいきっちりこなして積み重ねることができれば、よりよい環境に進むことができるとはずだ。

組込み開発現場のプロジェクトマネジメント＆プロセス改善

『組込み開発現場のプロジェクトマネジメント＆プロセス改善』を読んだ。この本は以下の6つのパート＆著者から構成されている。

■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の体系 にまとめることができた。

自分で自分のやることを選択して実行し、他人に認めてもらうというサイクルを回す際に一番苦しいのは、最初のステップ「自分で自分のやることを選択する」という点だ。なぜって、そこが最初だから選択した責任は自分にある。誰かから言われたことをやって失敗してら失敗した責任の一端は最初にヤレといった人にあるが、やるべきことを自分で選択したらすべての責任は自分にある。その覚悟をするのが大人になるとそれなりに重いのだ。

日本の技術者は自分でやりたいことを選択してやりきるという経験が非常に少ないように感じる。別にソフトウェア開発じゃなくてもいいから、料理でも作曲でも、目的を持ったブログでもちょっとした簡単なことでいいのでやってみるといい。やっていくうちにもう少し極めたいと思ったらしめたものだ。

そして「なんで、自分はこんなことをやっているのだろう」と必ず思うはずなので、そのときに根拠となるロジックを自分の中に構築する。これを習慣化すると自立したエンジニアになれる。

【参照】

1. モンテッソーリメソッド（子供向け）
2. モンテッソーリメソッド（大人向け）：自立したエンジニアを育てよう！

今回の記事を書きながら、そんなことを思ったのだった。

ものづくりに関する共感した話し

何を隠そう自分はものすごいラジオ好きである。通勤の間、風呂に入っているとき、寝る前、朝早く起きてしまったときラジオのスイッチを付ける。一日のうちテレビを見ている時間よりも圧倒的にラジオを聞いている時間の方が長い。

さて、3月28日(日)の夜、何気なくラジオを聞いていたら、村田製作所がスポンサーになっているTBSラジオ『サイエンス・サイトーク』という番組に植松 努さんという飛行機好き、ロケット好きのいかにもものつくり職人といった方がゲスト出演していてその話しがとてもよかった。よかったと思ったのは植村さんと自分は同類だと感じたからかもしれない。

この番組はポッドキャストでも配信されており、今日紹介する話しはiPODに録音して、少しずつ再生しながらポメラでテキストに起こしたものだ。

前置きはそれくらいにして、植村さんが何を言ったのか紹介していこう。

【植松 努さんのプロフィール】

植松努(うえまつつとむ)植松電機専務取締役 1966年北海道芦別生まれ。子供のころから紙飛行機が好きで宇宙にあこがれ 大学で流体力学を学び、名古屋で航空機設計を手がける会社に入社。 5年後の1994年に実家のある北海道へ戻る。父(植松清)が経営する植松電機へ。 産業廃棄物からの除鉄、選鉄に使う電磁石の開発製作に成功。 分別用電磁石は全国のシェアの八割を誇るまでに導く。

■2010年03月28日放送 … ロケットを作った町工場(1)　番組の紹介文

北海道赤平市にある「植松電機」。親子二人だけの小さな町工場でしたが、現在は約20人の社員で、ロケットや小型人工衛星の製造を手がけています。

その背景には「将来はロケットの設計をしたい」という植松さんの子供の頃からの夢がありました。「どうせ無理」だと考えず、あきらめないで頑張れば夢はかなう、という植松さんは仕事のかたわら、講演や子供向けのロケット教室などで全国を飛び回っています。2回に渡ってたっぷり話を聞きます。

■植松さんの子どもの頃

• 飛行機・ロケット好きの植松少年は飛行機が作りたくて、独学で飛行機やロケットのことを学んだ。飛行機、ロケットを飛ばした人たちの伝記を読みあさった。
• 伝記を読んでいたのでいろいろな人が工夫をしていく様、トラブルの解決の仕方を学んだ結果あきらめ方（あきらめて投げ出すということ）を知らずに育った。

→成功と失敗を疑似体験し、最終は成功するというイメージトレーニングが出来たのだろう。伝記とはそういうものだ。

■飛行機を設計する会社に入ったとき

自分が小さいときからあこがれていた堀越二郎（ゼロ戦の設計者）がいた会社に入ることができた。（神様はいるものだと思った）そして念願の飛行機の設計をできることになった。

ところが、そのうち植村氏は周りが高学歴な人たちばかりであることに気がつき不安が募るようにる。そして、組織の中で自分が少しでも役に立ちたいと思い、飛行機の知識を周りにひけらかしまくるようになる。自分は子供の頃からのめり込んでいた世界なので他の人より遙かに多くのことを知っていた。しゃべり続ければ続けるほど徐々に自分が嫌われていくようになっていた。自分自身もそんなことをしているのが嫌になって引きこもるようになり、人と関わらなくなるようになった。仕事だけはやってそれ以外の対人関係はできるだけ避けるという状態。

■引きこもり状態からの回帰

自分が引きこもりになったときに救ってくれたのが寮の仲間たちだった。スポーツマンの同僚が自分を何かある度に誘ってくれていた。しかし、彼は自分の反対側にいる人だと思っていたので、誘われてもいかなかった。それでも何回も誘ってくれて、いつの日か誘われるままにスキーにいった。

自分はオールレンタルで滑った。誘ってくれた同僚に「おまえすごいな、転ばないな」と言われた。考えてみたら自分は北海道出身だし、子供の頃学校でもスキーをやっていたので当たり前のこと。それでスキーの技術をスポーツマンの同僚に教えていったらみるみる上達していった。そうしたら他の人にも「こいつに聞け」と紹介してくれた。それで自信を取り戻し、帰ってからスキーを一式買ってワックスかけてエッジを整備してとやっていたらどんどん人が集まる部屋になっていった。

そのときに「不安とは恐ろしいものだ」「自信はとても重要なものなんだ」と痛感した。

誘ってくる同僚に対して当時「なんで見ず知らずの自分に関わってくるのだろう」「嫌だ嫌だ」とずっと思っていたのだけれども、困っている自分を見てなんとかしなくてはいけないなと思ってくれたのだと思う。もしかしたら彼自身も苦しい時期があったのかもしれない。

■なぜ、飛行機を設計する会社を辞めてしまったのか？

自分たちよりも後に入ってくる人たちが飛行機から遠ざかっていることに気がついた。飛行機を作る仕事をしているのに飛行機にまったく興味がない。学研の図鑑を読んだことがない人たちが続々と入ってくるようになってくる。そうすると彼らは好きじゃないから頑張れない。そしていわれたこと以外ことをすると損をするという発想を持っている。だから要求されたことしかやらないようになる。当時、自分のいた会社には「奇跡は仕様書には書かれていない」「奇跡は要求されたことの中には書いていないからお人好しが起こすんだよ」という言葉があった。彼らはそれをやらない人たちになっていった。それはミニマムマキシマムだと思った。最低限これだけはやっておいてねといわれたことを、「それだけやっておけば十分なんだろ」「それ以上のことをしたら損する」という考え方。

好きなことはどれだけやっても損はしないはず。ところが好きなことが奪い取られるしくみがある。それは中学校くらいから始まる。「受験以外のことをしたら損をするよ」ということを誰かが教える。「必要最低限のやまを暗記してそれ以外のことを入れたら頭が損をするよ」と教えられるようになる。そうると受験勉強のこと以外のことをいっさいできなくなる。

この世の中に損なことはひとつしかなくて、それは何もしないこと、面倒くさいけど自分がやりたいこと避ければ避けるほど本当は損するのに「最短コースこそが美徳です」のようなことを教えてしまうと負のスパイラルは激しさを増す。

「効率が嫌いなんですか」というラジオパーソナリティの問いに対して、

手加減をしている一秒も自分の一秒ですから自分の人生短いんだから手加減したり楽したりしないほうがいいんじゃないのと思う。それを誰かが「楽をして暮らすんだよ」「楽した方がいいよ」と教える。楽ということを目標みたいに伝える人がいる。でも楽したら辛いと思う。

暇はつぶしちゃいけないんですよ。暇は自分にとって特になることに使えば人生の時間はすごく輝きを増すはずなんです。人生の幸せは生涯賃金の総額ではないことはみんな分かっていると思う。人生の時間を費やして得た知恵と経験と周りの信頼と愛情こそが人生の価値だろうと思う。

自分のくふうが報われたときに泣けるんです。泣くほどしんどいときに泣けるんだろうと思います。

自分は自分のことを職人だと思っているから、植村さんの言っていることがよく分かる。しかし、一方で自分がものづくりに寄せる想いの強さと、それほどまでに想いが強くない人たちと一緒に仕事をしなけれいけないという現実も分かっている。それがイヤなら植村さんの会社のように少数精鋭の組織で仕事をするしかない。しかし、もっと大きな組織でなければできない商品もある。

車の世界では新車種の開発はチーフエンジニアと呼ばれる技術者が全責任を担う。トヨタではチーフエンジニアのアシスタントを4～５年務めてからチーフエンジニアに昇格するのが普通だったが、車種の増加と開発期間の短縮で近年は「経験を十分に積まないまま、チーフエンジニアに抜擢されるケースも目立つらしい。昔はチーフエンジニアを中心に開発チームが寝食を忘れて徹底的に議論して一台の車を作り上げる泥臭さがあったがいまではパーツごとの縦割り開発にならざるを得ない。

プリウスのブレーキシステムの複雑さを見れば分かるように、今では車全部の機能やメカニズム、制御方法をチーフエンジニアが全部把握するのは無理だ。ひとりのエンジニアがシステム全体を見渡せるシステム規模ではなくなっている。

だから、植村さんが言うようなエンジニアが必要なことは間違いないが、プロジェクト全員にそういう意識を持たせるのは難しい。それでも、顧客満足は満たさなければいけないし、安全は絶対に確保しなければいけない。「品質を心配する意識の強さ」「エンジニアの商品にかける熱意」だけでは安全は確保できない時代に突入している。「品質を心配する意識の強さ」「エンジニアの商品にかける熱意」を保ちながら、システマティックに安全分析を行い、安全アーキテクチャを設計することが求められている。