DIVXのエンジニアが目指す「横着しないエンジニア」とは？
はじめに
こちらの記事はDIVXアドベントカレンダー2022の1日目の記事です。
初日となる今日は、DIVXのCTOを務めております私、田島からお届けいたします。
「横着をしていない」というワークルール
DIVXでは、DIVXで働く人達が生産性高く働く事を目的とした「ワークルール」を定めています。その中でもエンジニア特有のワークルールの1つとして「横着をしていない」があります。
「横着」という意味を辞書で調べると「すべきことを怠けてしないこと」のような意味が出てきます。ワークルールで意味している「横着」もこの意味なのですが、人によって解釈が変わる抽象的な言葉ではあると思います。だからこそ、DIVXへ入社したエンジニアの方に対しては、横着の意味を理解してもらう為の研修を行っています。
というわけで、今回の記事では「何故横着してはいけないと考えているのか？」と「横着が何を意味しているのか？」のWhyとWhatについて、そして横着しないエンジニアのあるべき姿について、この記事をご覧になっている皆さんにお伝えしようと思っています。
DIVXのエンジニア組織の雰囲気を、この記事から少しでも感じ取っていただけたら幸いです。
DIVXが目指すもの
「IT人材不足という社会課題を解決したい」
私達が具体的にやっている全ての事は、ここに結びついています。たとえば現在注力しているDX支援ひとつとっても、IT人材不足が解消すれば自動的に解消されていくと思っています。ここでいうIT人材というのは、エンジニアはもちろん、それ以外のITリテラシーのある人材も含まれています。
フルスタックエンジニアを目指す方針
そのような壮大なビジョンがありつつも、「誰もがエンジニアとして活躍できるようになる組織づくり」が当面の課題です。その為にはエンジニアを成長させる為の仕組みが必要ですが、それを考えた末に私達は1つの仮説にたどり着きました。
「人が成長するかどうかは、持って生まれた能力よりも経験によって大きく変わる」
よって私達は、DIVXのエンジニアに経験をたくさん提供しようという方針に至りました。そして、エンジニアリングにおいては特定の技術領域だけに絞るよりも、幅広さを重視した方が経験のバリエーションを豊かにできる為、フルスタックエンジニアをエンジニアとして目指すべき姿としました。
ちなみに、フルスタックエンジニアを目指すべき姿としたのは成長面だけではありません。
今の世の中が既にそうですが、多様性が重視される今後の世の中で発生する課題はより複雑になっていくと考えています。そのような世の中で活躍する人材を育てる為には、専門教育よりもリベラルアーツ（一般教養）を養う教育が必要という考え方があります。
私はエンジニアにおいてもその考えが重要だと思っており、リベラルアーツが養われたエンジニア像として、フルスタックエンジニアが結びつきました。そのようなエンジニアが、答えのない問題に対して、ITの力で最適な答えを出せるのではないか？そして、フルスタックエンジニアを輩出し続ける事がIT人材不足を解消する事に繋がるのではないか？と思っています。
もしも特定の領域におけるスペシャリストになるとしても、土台としての幅広い教養（フルスタックさ）があるからこそスペシャリストとして活躍できる。私個人はそう考えています。
何故横着してはいけないと考えているのか？
最初に「DIVXが目指すもの」についてご説明させていただいたのは、「何故横着してはいけないのか？」という問いに答える為の大前提だからです。
横着してはいけない理由は、下記のシンプルな一言でまとめる事ができます。
「横着すると経験を積むことができないから」
上で述べた通り、私達が考えるエンジニアの成長には「経験を積むこと」が何よりも重要なのですが、横着はそれを阻害します。
私なりに噛み砕くと、「横着するとフルスタックエンジニアになれない」という表現をする事もできますが、発散するのでその理由は最後にまとめとして述べます。
ここまで横着という言葉を何度も使ってきましたが、「横着が何なのか？」について私の言葉として何も語っていません。つきましては、次にその意味について説明いたします。
横着が何を意味しているのか？
結論として、私がエンジニアに対して思う「横着」は下記を意味しています。
「意思決定が原理原則にもとづいていない」
人によってはこれも抽象的に捉えられる言葉ですので、説明します。もしもこの言葉で「わかるわ〜」って思った方は、横着をしない行動原理を既に持っている方かもしれません。
物事を分解して考えない事
原理原則という言葉はどちらも「原」という言葉が入っている通り、それ以上分解できないアトミックな「理論」や「法則」を意味しています。
よって、原理原則にもとづいた意思決定を行う前提として、今自分が向き合っている課題をシンプルな要素に分解していくアクションが必要です。それをしない事は横着につながります。
Dockerが動かなくなりました
たとえば具体的な例として、あるエンジニアが「Dockerがエラーで動かなくなりました。どうしたらいいですか？」という質問をするという意思決定を下したと仮定しましょう。もしもこの意思決定が原理原則に基づいていない場合、横着している事になります。
エラーという言葉を使っているので、恐らくエラーメッセージのようなものがコンソール画面に出力され、Dockerのアプリケーションが動作していない状態だと推察されます。
ここで横着しない為には、質問に先んじて下記の分解したアクションをとる必要があると思います。
- エラーメッセージを読む
- エラーメッセージの意味を理解する
- 問題となっているDockerコンテナだけを起動してデバッグする
- Dockerfileの記述や起動オプションを一旦Hello World的にシンプルなものにし、インクリメンタルにオリジナルへ近づけながらデバッグする
エンジニアとして、当たり前過ぎるアクションのように思うかもしれません。ただ、そう思う人でもいざ同じ状態になると1すらやらず、エラーメッセージでググって解決策が出てこなかった時点で、立ち往生してしまう事があります。
もしも3や4のアクションで解決できない場合、より本質的な分解を行うためのアクションが必要です。一部ですが具体的には下記のようなものが考えられます。
- Dockerコンテナ間で連携しているプロセスがnginxとMySQLとPHP-FPMだとしたら、それら自身の動作原理、あるいは、それらが連携する仕組みについて理解する事
- Docker自体のエラーであれば、Dockerそのものの仕組みについて理解する事
- アプリケーションのエラーであれば、アプリの挙動をソースコードから読み解き、時にはデバッグしながら理解する事
- アプリケーションレイヤーから離れて、TCP/IP等のネットワークレベルで問題を切り分けていく事
- TCP/IPの仕組みがわからないなら、仕組みを理解する事
どれも一朝一夕でできる事ではありません。時間が限られている中、自分一人ではなんとかできない事もあるでしょう。
しかし、たとえ今は誰かに助けを求めたとしても、次に同様の問題が発生した時は自力で対応できるよう、原理原則にもとづいた準備をしておくのが横着しないエンジニアです。そういった経験を繰り返す中で、横着しないエンジニアは成長していくのだと思います。
自らの可能性を諦めてしまっている
不具合に遭遇した場合の具体例をあげましたが、どんな課題も分解して突き詰めていくと、自然と原理原則に近づいていきます。したがって、分解さえすれば誰もが原理原則にもとづいた意思決定を行う事ができると私は思っています。しかし、その「分解する」という行動は様々な理由で行われず、横着として姿をあらわします。
様々な理由として、単純にめんどくさかったからやらなかった、分解するという発想がなかった。あるいはどうしたら分解できるのかわからなかった等です。
ただ、私個人の所感としては、総じて自らの可能性を諦めてしまったゆえの横着に思えてしまい、もったいないと感じてしまいます。
横着しないエンジニアのあるべき姿
技術の世界において一見別々に思えるような領域も、分解していけばある程度同じカテゴリーで分類できる事があります。一般的にそれは抽象化と言われますが、抽象化された認識の中で世界をとらえる事ができれば、全く経験がないような技術領域でも一定のアドバンテージのもとに扱う事ができます。
それをできるのがフルスタックエンジニアであり、彼らが何でもできてしまう理由は、意思決定とその行動が原理原則にもとづいているからだと考えています。
そして、それが「横着しないエンジニア」である事はこれまで述べてきた理由から自明でしょう。DIVXはそんなエンジニアを目指すべき姿としています。
横着しないエンジニアの働き方に興味がある方は、ぜひ採用ページを御覧ください。
最後までご覧いただき、ありがとうございました。
