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

今週はもうひとつ映像コンテンツの感想を書こうと思う。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. モンテッソーリメソッド（大人向け）：自立したエンジニアを育てよう！

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