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