はじめに
某企業で組み込み系ソフトエンジニアとして働いていますが「このままだと、将来ないかも？」と思えてくる場面に日々遭遇します。
今回は日本の組み込み業界の将来が不安になる、耳を疑った”上司の発言”をまとめてみました。
※実際にあった発言かどうかはご想像にお任せします。
上司の発言集
「最近の若いやつらは残業が足りない」
働き方改革が騒がれるこの時代に、そんなこと言う人いるの！？
と驚く方もいるかもしれないですが、いるんです、まだ一定数は。
そして、それがまかり通るような現場の一番の問題は
「開発業務の効率化、スピードUPを図る文化が根付かない」ことだと私は思っています。
「時間が足りなければ残業でカバーすればOK！残業代も出るしいいでしょ！」
というマインドでは、どうすれば開発スピードが上がるか？無駄な作業は何か？これ自動化した方がいいかも？といったアイデアは、日常なかなか出てきません。
考えていたとしても、残業を推進し次から次へと業務が積まれていくような現場では、改善アクションの実行はどんどん遅れていきます。
定期的に振り返りを行い小さな改善を繰り返す、という良いサイクルが生むためには、まずは日々の開発を健全なサイクルで回すことが重要です。
「オブジェクト指向は私には分からない」
オブジェクト指向というのは一例ですが、日本のレガシーな組み込みの業界では、上司が世の中当たり前に使われているソフトウェアの技術を知らない、ということが度々起きます。
分からないことを分からないと正直に言うことはいいことですが、
その部下たちがその技術を使って開発している（開発しようとしている）と以下のような問題が発生します。
・上司に技術的な説明が必要になると、余計な労力が発生する
・上司は技術的な理解が足りないので、適切な判断ができない／判断を間違える
例. 上司から技術的な課題を説明してほしいと言われたが、上司がクラス図を読めないため、PPTでポンチ絵みたいなものを書いて抽象的な説明をするハメになる
「アジャイル開発？それで本当にうまくいくのか？」
これも上の例と似ています。世の中一般的な開発手法やツール（Git, Redmine, Slack, …）については、知らないだけでなく、懐疑的であったりもします。
・ウォーターフォールは欠陥のある開発手法である
・未だウォーターフォールでソフトウェア開発してるのは日本くらいだ
というのはもう一般的な話だと思いますが、それすら上司は知らない可能性があります。
アジャイル開発が日本で浸透しない背景については色々ありますが、
まずは上司や組織全体が新たなやり方を導入することに協力的でないと、なかなか古いやり方から抜け出せず、開発効率UPを阻害する要因となってしまうことがあります。
「なぜそんなに開発に時間がかかっているのか理解できない」
現場を自分の目で見ようとしない上司は、こんな発言をすることがあります。
こんなシステムがあったとします。(ほとんど存在しないことを祈りたいですが)
・長年にわたる保守開発で機能数は増え、コードの複雑さも増加してしまっている
・自動テストも不十分でリファクタも進まない
・結果的に、開発スピードがどんどん低下してしまっている
・さらに、求められる品質や性能は日に日に増していっている
しかし、そういったライフサイクルの長いシステム開発の上司というのは、往々にしてそのシステムの初期の開発を行った人物だったりします。
どんなシステムも開発初期は機能もユーザーも少なく、設計上のしがらみもないため、ある程度自由にシンプルに作れるものです。求められる品質や性能も今ほど高くなかったかもしれません。
上司がそういった開発初期のシステムの良いイメージが強く、現在のシステムの置かれている状況を正確に認識できていないと、こんな発言で開発者を困らせてしまうことになります。
「私はそれは問題だとは思わない」
エンジニアが開発の課題やリスクを提示したとしたときに、こういった発言をする上司もいます。
はっきりとそう発言しなくても、あまり問題を聞いてくれず聞き流される場合も、同じと言えるでしょう。
ポジティブ思考は素晴らしいですが、現場の課題やリスクを無視すると失敗の確率は上がります。
影響度の高い課題やリスクを認識せず、効果的な解決策を講じることができなければ、プロジェクトは必然的に失敗します。（要は当たり前のリスクマネジメントの話）
課題やリスクを上司に提示する状況としては、以下が考えられます。
・課題やリスクが現場の裁量で解決できるレベルではない、なんらかの組織的な策が必要
・権限と責任が適切に現場に委譲されておらず、あらゆる決定が上の承認なしには実現できない
つまり、上司の協力が必要な場面ということですが、このような発言をされてしまっては、現場のエンジニアは嘆くことしかできません。
「社員は設計だけしろ、請負をもっと使え」
日本のプログラマ軽視の問題を表す、典型的な発言です。
上司は、以下のような一昔前のウォーターフォールの誤った認識を今も持っていると考えられます。
・上流工程が最も重要で、プログラミングは誰でもできるものだ
・設計とプログラミングは別工程だから、作業も分けられるものだ
また、社員がやっていた業務を請負に出すことで、"短期的に"見かけ上のコストを下げることができてしまうため、これは経営層からトップダウンで推進されている可能性もあります。
ソフトウェアを作って提供する企業であれば、顧客の課題解決を実現する最もコアな部分、価値として提供するものは、間違いなく”コード”です。
それを生産するプログラミング活動を、外部に依頼する。それは何を意味するでしょうか？
分かりやすいところで言うと、これによって、現場レベルの問題が多々発生します。そのため、結果的にコストダウンにならないことが多いです。
・請負先との新たなコミュニケーションコストが発生する
・請負先の能力が不十分で、レビューや不具合修正、リファクタなどで社員の工数が奪われる
しかし1番の問題は、会社の技術力低下を推進することになる、ということです。
社員はどんどんものを作れなくなり、会社にとって無益な自称エンジニアを量産することにつながります。ソフトウェアを作って提供する企業にとってこれは、長期的には会社の衰退を意味するでしょう。
何故そんな発言をするのか？
当たり前ですが、上司も会社を悪い方向に持っていこうと思ってはいません。
結局のところ「思考や常識が、Updateされていない」の一言に尽きると思っています。
別な言い方をすると「過去の成功体験にすがり、そこから抜け出せていない」ということ。
それで上手くいっていた時代があったのでしょう。
上記のような発言をする上司は、当時は優秀なエンジニアだった場合に多いと思っています。
また、１つ怖い仮説は、多くのエンジニアが歳を取ったら（エンジニアリングの現場から離れたら）そうなってしまう恐れがあるのでは？ということです。他人事と思ってはいけません。
どうすればいいのか？
そうは言っても、ある程度の規模の会社に所属する限り、多くの場合上司と部下の関係はなくなりません。
上司のいるエンジニアにも、部下と言えるエンジニアを持つマネージャーやリーダーにも共通して言えることは、
「まずは対話をしてください。対話する場がなければまずは作る努力をして下さい。」
ということです。相手の考えを尊重し、理解しましょう。
当たり前のことですが、結局のところそれしかないと思っています。
「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。」byピープルウェア
また、やるべき行動としては、以下が考えられます。
＜エンジニア＞
1. 現場で起きている問題を上司が正確につかめるようにする
2. 新しいソフトの技術や常識を上司にも説明し、理解してもらう
3. 自分たちの裁量でできることは、どんどん自分たちで考えてやる
＜部下を持つマネージャー/リーダー＞
1. 現場で起きている問題をちゃんと自分の目で見る
2. 新しいソフトの技術や常識を勉強する
3. できる限り現場を信用して、権限と責任を委譲する
さらに、自分が上司と呼ばれる立場になったときに部下となるエンジニアに同じ思いをさせないためには、世の中の技術の勉強を怠らず「思考や常識を、常にUpdateすること」が大事になるでしょう。
まとめ
みなさんの現場の上司は今回あげたような発言はしていませんか？
これは私の勝手な推測ですが、背景には、日本の組み込み開発の現場が、世の中の技術をキャッチし取り込むスピードが圧倒的に遅い傾向にある（それでも長らくやってこれてしまった）、ということがあるかもしれません。ライフサイクルの長いシステムであればあるほど、その傾向は強いと思います。
そのため、おそらく日本の同業種の企業も、もしかしたら同じような状況なのかも？と思っていますが、実際のところどうなんでしょう？うちはそこまでじゃないから大丈夫、という声が多く聞こえてくることを祈っています。
エンジニア不足が深刻な今、エンジニアの技術力向上とともに、組織の社会学的な問題をどううまく解消し、魅力的な開発現場にしていくのか？というのも重要な問題だと考えています。
そのために何ができるのか？ということを、これから先長期的に考えていきたいなと思っています。
