こちらの記事はDIVXアドベントカレンダー2023の14日目の記事です。

はじめに

こんにちは、DIVXのCTOを務めている田島です。

初日の記事ではDIVXの新卒研修についてでしたが、今回はエンジニアが仕事に向き合う時のマインドについて書かせていただきます。

私は、エンジニアを育成する際はマインド面での成長を最も重視しています。つまりDIVXのエンジニアにおいては、技術よりもマインド面が重視されていると言っても過言ではありません。私は、人間が成長していく過程においてはマインド面は切っても切り離せないと考えています。実際、経験上マインド面に変化があった事で別人のような成長を遂げた人を何人も見てきました。

マインドを重視したい理由

結論から申し上げると、私がマインドを重視する理由は「サスティナビリティ（持続可能性）」を確保したいからです。たしかに現場で使える技術を教える事は即効性はあると思います。ただ、それでも現場ですぐに使える技術を教えないのは、私が育成対象とするエンジニアは「これからエンジニアとして生きていく覚悟を決めた人」だからです。

覚悟というと大げさに思うかもしれませんが、天性のセンスでやれてしまう一部のできる人以外にとって、エンジニアの業務は大変厳しく難しいものになるはずです。たとえば、今まで習得していた技術が使えない、あるいは新しい技術を習得しないと仕事にならない厳しさがあったり、誰も完成形がわからないものをオーダーメイドで作り続けなければならない難しさがあります。また、パソコンに向かってカタカタやっていればいいエンジニア像をイメージしていた人は、実際の現場で発生するコミュニケーションの難しさに驚く事でしょう。

人によってはその厳しさや難しさのプレッシャーに押しつぶされてしまいます。よって、私は流行の技術や表面的なチップスではなく、将来にわたってエンジニアとして生きていく為のサバイバル術を教えたいと思っています。その中心にあるのがマインドです。

IT人材不足の一端を担う者としての使命

さきほど、「マインド面に変化があった事で別人のような成長を遂げた人を何人も見てきました」と申し上げました。それとは逆に、技術力は十分足りているはずなのにマインド面に問題があって良くない事態に陥ってしまった人も見てきました。まるで他人事のように言っていますが、正直な話、私自身もその悪い方向にいってしまいそうになった事があります。だからこそマインドをどのベクトルに向けるか？の重要性を理解しているつもりです。

そこまで極端な良くない事態に陥らなくても、常に何かに迷いながら仕事をしているエンジニアは世の中にたくさんいると思っています。目の前の仕事だけでも大変なのに、「このままでいいのかな？」というマインドに起因して迷っている状態では、エンジニアとして生きていくのはとても苦しくなってしまいます。明確なゴールもなく漠然と「自己研鑽が必要！」と時間に追われて、手段と目的がよくわからなくなっている場合はその典型です。そして、もしそんな人で溢れてしまったら、その組織、ひいては社会で働くみんなが不幸せになってしまいます。

だからこそ、私はIT人材不足の課題を解決したい組織の一員として、マインドの重要性を伝えなければならないと思っています。技術力とか環境はその時々で千差万別ですが、マインドは変わらず自分の根幹を支える基盤となりえます。

よって、マインド面をエンジニアの初期に教えこむ事は、私の中では技術を教える事よりもプライオリティが高いのです。それに今の世の中、技術を学べる手段はたくさんあるので、私が教えなくても本人の努力次第で十分ハイスキルなエンジニアになれます。そして、その努力ができるかどうかも、結局マインドで決まってしまうのです。そう考えると、やはり私は技術習得の基盤においてもマインドが一番重要という考えが正しいように思ってしまいます。

もっと〇〇だったらいいのに

マインドが重要という抽象的な話が続いたので、具体的にどのようなマインドでいたら良いのか？の話にうつっていきます。それにあたって、よくない事態に陥ってしまうマインドの人が口にしがちな言葉を紹介します。

それは、「もっと〇〇だったらいいのに」です。

何故この言葉を口にするマインドがよくないか？といいますと、「未来の可能性を全て否定する言葉」だからです。極端な事をいうと、この言葉の裏側には「今の自分ができないのは〇〇が足りてないせいなので、自分ではどうしようもないし、できないとしても自分は悪くない」という開き直りを見出すことができます。

エンジニアにかぎらず人生レベルでそのような気がしていますが、この世の中は誰かのせいにしようと思えば無限にする事が可能だと思ってます。「たとえば社会のせい、親のせい、国のせい」という大きなレベルから、「仕事が忙しいせい、恋人がかまってくれないせい、上司がわかってくれないせい、部下がわかってくれないせい」という日常的な例までさまざまです。中には本当に、〇〇のせいな事もあると思います。ただ、〇〇のせいだから仕方ない…で本当に終わらせてしまっていいのか？を判断する事はとても難しいです。判断する人にどんな経験や知識があるかで、本当に〇〇のせいなのかは判断がブレるところであり、唯一の正解はないからです。

ならばいっそ、戦略的に「〇〇のせい」という考え自体を排除してしまおうというのが今回の私のマインド改革提案です。〇〇のせいかどうかの思い込みや追求に時間を使ったり精神をすり減らすのではなく、もっと建設的で前向きな行動に人生の時間を使おうという提案です。

もちろん、過度に自分のせいにし過ぎてしまい心が病んでしまうケースもあるので、状況によってはオススメできない事もありますが、基本的なスタイルとして私はそうありたいと思っています。
前置きが長くなりましたが、その派生としてエンジニアがよく思いがちな「もっと〇〇だったらいいのに」をとりあげました。最後にいくつか〇〇の具体例をあげて、この記事を終わりたいと思います。

もっと自分にスキルがあればいいのに

残念ながら、スキルが完全に足りてる状況で仕事に取り組める事はないです。私もいまだに、必要なスキルが全部足りてるなっていう感覚で仕事に取り組める事はないです。足りないので、いつも準備に時間をとられています。

そして、これが重要なのですが、必要な準備の中で未知のスキルや知識のキャッチアップが占める割合は皆さんが思っているほど大きくないです。もしも毎回スキルのキャッチアップに時間が足りないと感じてしまっているなら、経験のあるエンジニアの方に対してキャッチアップや、自己研鑽の方法に助言をもらいましょう。実際のエンジニアリング業務においては、クリエイティビティを発揮する為のスキルやキャッチアップが重要だと気づけるはずです。

もっと納期まで余裕があればいいのに

残念ながら納期までは余裕がない事が多いでしょう。それは本当に足りないのではなく、人間という生き物の性質上仕方ありません。夏休みがいくらあっても、最終日に宿題をやっていた事に心当たりがある方もいるでしょう。このように、いくら時間があっても結局最終日まで頑張っている構造になってしまうのです。もちろん、エンジニアやチームの実力によってアウトプットは違うので、あるエンジニアは3日でできる事が別のエンジニアだと2週間かかるような場合は、前者に余裕が出る事はあります。

納期はビジネス側の都合で決まっていく事もありますが、エンジニアの意見との調整で決定できる事も意外と多いです。ただ、その場合も「ちょっと無理かも」くらいが適切だと思っています。エンジニアは、品質や生産性をあげなければならない中で成長しますが、負荷がかからない環境ではそれは実現できないからです。よって、テックリードの方や上長に工数の妥当性を判断してもらうような場面では、自分が「結構この人無茶いうよな…」と思う工数で設定されている時の方が、自分の常識を超えたクリエイティビティを発揮して成長できる可能性が高いです。

もっと強いメンバーがチームにいればいいのに

スキルは自分が鬼のように頑張ればある程度足りない感覚が解消されるかもしれませんが、自分が「チームにこんな人がいたらいいな」って思う願望が満たされるかどうかは運に左右されます。なので、これこそが開発現場における「そんな事思ってもしょうがない」の最たる例だと考えています。これに執着してしまうと「メンバーが足りてないのでできません。なお、私は悪くありません。以上」で、一切の行動をストップしてしまう大義名分ができてしまいます。それを主張してしまうと、結果はもちろん出せませんし成長もできません。だからこそ、今ある状況の中でどんな手段で問題が解決できるだろうか？というクリエイティビティを発揮する中で、あなただけの経験が積まれていくのだと思います。そうしていくうちに、自分が思い描いた強いメンバーにあなた自身がなっているはずです。

もっと綺麗なコードだったらいいのに

「綺麗なコードと汚いコードどっち触りたい？」とエンジニアに質問したら、100人中100人が綺麗なコードを触りたいに決まっています。ただ「コードが汚いので何もできないです」では結果を出すことはできませんし、誰も評価してくれません。もちろんコードの汚さを良しとするわけではありません。それを嘆いて終わらせず、自ら改善できる人になりましょう。改善できなくとも、今の状況を受け入れた上で結果を出せる人になりましょう。

余談ですが「一から全部作り直したい！」という主張を定期的に言う人がいますが、個人的には「どこに問題があるのか分析するのがめんどくさいので、全部一から作り直したい」という思考停止的なニュアンスが透けて見えてしまいます。本当にコードを改善したい人は、一から全部作り直すなどという現実味の薄い主張ではなく、原因となる箇所から段階的に計画を立てて提案し、問題のラインを見極めて実行できる人だと思っています。

もっと経験があればいいのに

スキルは仕事外の独学や趣味で体験できるようなものに対して、ここでいう経験は「〇〇のプロジェクトを回して成功させた経験」のように、仕事じゃないと体験できないもののイメージです。
現実の仕事はゲームのように、ステージ1、ステージ2、ステージ3というように適切な難易度の順番で経験できるとはかぎりません。ステージ2、ステージ5、ステージ1のようなでこぼこな難易度で経験する可能性が十分あります。

たとえこの社会でIT人材が適切に育成され、適切な人数が確保されていったとしても、私達がやるべき価値のあるものは難易度とは無関係に存在するので、ゲームのように難易度順でお膳立てしてもらうのは難しいでしょう。そうであるならば、経験の足りなさを嘆いて終わらず、「今ここにアサインされている自分がやるべき事を全力でやる！」と、覚悟を決めた方が建設的です。もしも成功体験に繋げる事ができれば、経験がない事を成功させられるエンジニアという事ですし、失敗してもこの経験を活かして次の成功体験に繋げられるエンジニアになれるはずです。

まとめ

一部を抜粋して共有しましたが、エンジニア業務においては以上のような「もっと〇〇だったらいいのに」というネガティブマインドを排除する事が重要だと考えています。そして、結果を見据えた建設的なプロセスに自分やチームの時間を投下する事で、「サスティナビリティ（持続可能性）」のある仕事ができると信じています。

divxでは一緒に働ける仲間を募集しています。
興味があるかたはぜひ採用ページを御覧ください。