LIFULLのエンジニアとしての目指す姿、「LIFULLエンジニア像」について

面接などでよく聞かれる質問で「LIFULLではどのようなエンジニア組織を目指していますか？」というものがあります。LIFULLではほとんどすべてのエンジニアが答えられると思います(きっと)。

それは、LIFULLで理想とするエンジニアの在り方として LIFULLエンジニア像 というものを定めているためです。それが見出しにもなっている「エンジニアとして経営をリードする」という言葉です。

今回は、その内容や作ったときのどんな課題を解決したかったか、という話をしたいと思います。

なぜ「エンジニア像」というものを作ったのか？

LIFULLには社是である「利他主義」をはじめとして、経営理念や社員の行動規範であるガイドライン、そして我々がステークホルダーに対し提供していく価値に対する品質基準である LIFULL Quality Standards 等、「何処を目指してどう登っていくのか、そしてそれはどんな提供価値を生み出すのか」といったことが明示されています。しかしながら、それらの中で「ではエンジニアとしてはどうあるべきか？」というのが明示されていませんでした。

LIFULLには現在プロパーで160人程度のエンジニアが在籍しています。10年ほど前、エンジニアの人数が5,60人程度のときであれば「エンジニアとしてどういう姿勢であるべきか、どう振る舞うことが求められているのか？」ということは肌で感じられていたと思います。しかしながら100人を超えてくると段々とそれがわからなくなってきます。(まさに会社のビジョンや行動規範を作っていく課題感と同じですね)
そうなると、エンジニアではあるものの「事業に貢献したい気持ちが強くプロジェクトにおいてのこぼれ球を何でも拾っていくことで成果を出すことに重きを置きすぎて、技術の研鑽をおざなりになっていく」というケースが見え始め、そしてそれは増えていく傾向がありました。

誤解がないように述べておくと、この「こぼれ球を何でも拾って価値を出すこと」自体を全く否定するものではなく、むしろ素晴らしいことです。こういうプレイヤーがいるPJは非常に成功確率が高まります。ただ、エンジニアの全員がその状態になりすぎることで技術に全くフォーカスしなくなると新しい技術が取り入れられなくなっていく、ということが起こりかけていました。
もし、その状態が続くと、プロダクトとしての持続的な成長はできなくなり、結果として会社も中長期的な発展がしにくくなる、つまりはビジョン実現に遠のいてしまいます。(ここのバランスは会社の規模やフェーズによっても違うでしょうし、同じ規模・フェーズでもその時の組織や技術の状態によって違うので一概にどれくらい、と言えないと思っています)

当時、そのような未来の状況を危惧し、エンジニアマネージャーたちとLIFULLエンジニアが目指すありたい姿として「LIFULLエンジニア像」を定義しました。

それが「エンジニアとして経営をリードする」です。

LIFULLエンジニア像の解説

「エンジニアとして経営をリードする」という言葉は、「エンジニア自身が新規事業を立ち上げましょう！」や「PLやBS、CFが読めるようになりましょう！」というようなことではありません。（もちろん、そういう事ができるようになるのは素敵だと思います）
エンジニアや技術の力を介在させることで、元のアイデアやプロダクトよりもっと発展した(そして価値のある)提案していくということや、全く気付いてなかった、もしくは思いつかなかった方法を提案し実現する。それによってLIFULLが目指すビジョンの実現をより早くより素晴らしいものにしていこう。そんな想いを込めています。

策定の議論の中では、「シンプルに『経営をリードする』だけでいいのでは？」という話や、「『リード』ではなく『牽引』がいいのでは？」などの話もありました。しかし、前述の通りに「エンジニアだからこそ出来得ること」に対して真摯に向き合って考え続けていきたかったこと、また「牽引」だと「引っ張る」ニュアンスがありますが、それよりも「道を切り拓いていく」そして「切り拓いた上で先導する」という意味を強めたかったのでリードという言葉を選びました。

「エンジニアとして経営をリードしている状態」のイメージは下記の図です。エンジニアのもつ技術によってビジネスに好影響を与えている状態を目指しました。

さらに、「エンジニアとして経営をリードする」ために、大切だと考えている要素も合わせて提示しています。内容は以下の図の4つです。

それぞれについて簡単に解説します。

1. 問題・課題に対して本質を考え続ける

(LIFULLではほぼそのようなことは起こりませんが)プロダクト開発においてエンジニアは下流工程のみに存在し、課題と解決策が固定された状態で仕様として落ちてくる場合があります。そもそものやりたいことは、その仕様を満たすことではなく、顧客の困りごと(潜在的なもの含む)を解決するということです。少なくとも自分がその困りごとに対して、その解決策が良いと思える(もし良いかどうかわからなくても、試してみたいと思える)ことが大切です。

これは、システムに関しても同じで、社内で行われてる既存の方法(実装の仕方やルール)などが必ずしも良いとは限りません。解決したかった問題もその時々で違うはずですし、以前問題だったものも取り巻く環境の変化や技術の進歩(こう書いたら大仰に感じるかもしれませんが、FWやミドルウェア、クラウドインフラの改善なども含まれます)によって問題ではなくなっていることはあります。

前提条件や既存の枠組みにとらわれずアプローチを考え、より理想に近づける選択をするために考えつづけよう、ということを言っています。

2. 建設的にエンジニアとして伝え・表現し続ける 

エンジニアだからこそやりやすい手段の1つに、プロダクトをどんどん作って発信・ものを見せて語るということがあると考えています。プロダクトや機能の企画について話しているときに、モックでもなんでも、実際に動くものを作って見せながら提案してみると、わかりやすさや説得力は全然違ってきますよね。より良くすすめるために、建設的に伝えて表現していきましょう、ということを言っています。

他にも「伝える」という点では、例えば「上の理解が得られられなくて技術的負債を返済しにくい」という話があったとします。

この場合パターンは大きく分けて、
1. わかってるけどあえて返済しないという選択をしている
2. そもそも知らないので返済するという選択ができない
の2つあるかなと思っています。

会社のビジョン・ミッション達成のために事業を伸ばしていく、という観点で、同じ会社の仲間として目指すものは一致しているという前提で、1も2も両方コミュニケーションの問題だと思っています。(1→選択の背景がメンバーに伝わっていない、2→判断する人まで情報が伝わってない)

技術的負債を直接感じられるのはエンジニアだと思うので、技術的負債のもたらす影響を事業へのインパクト含めしっかりと説明し、返済計画をたて進言していく。というのも、この「伝える」という例だなと思います。

3. 世の中は変化していくものだと理解し、自分自身も変化し続け、周囲の人・環境も変えていく

1番目に書いていたことと被る部分はあります。技術の世界の1ヶ月前まで良いとされていた方法が今はもっと良い方法があるなどはよくあります。(技術だけではないと思いますが変化が早いという観点)

変化というのは、新たに適用するのに労力を使いますし、なんとなく怖いものでもあります。また気を抜いていると「何も変化しない」という選択をとってしまいがちです。そうならずに、最善の方法に向かって考え方や、やり方をアップデートし続け変化を恐れず受け入れる。そして必要とあれば、前向きな提案で周囲の人や環境にも働きかけ、変化を促していきましょう。ということを言っています。

本質を見失ってまで無理に変化を求める、ということや、流行りに乗りましょう、と言っているものではございません。(「変化が目的」になってしまうとおかしいことになりますよね)

4. それらを成し得る技術力を身につける

上記の1-3をエンジニアとして体現していくためには、広範な知識やスペシャリティにより、表現のレベルや考えられる幅を広げていくことが大切だと考えています。エンジニアとしての日々の研鑽は1-3を構築する上で大切な要です。 

浸透させていく

作った後には、浸透させていくということが大切です。難易度は「作る」よりも「浸透」のほうが難しいなと感じます。(よくあるスローガンやビジョンなど言葉系のものは掲げたものの飾りのようになっていることも少なくないと思います)

もともとLIFULLでは四半期に一度「エンジニア総会」というエンジニアの All Hands Meeting をやっていました。開始当時の目的は「エンジニア間の情報共有と結束力を高める」でしたが、近年は総会という形でなくてもナレッジ共有ツールや公式非公式問わず社内勉強会などにより、エンジニア間の情報共有できてきていました。

以下の写真は一昨年に開催されていた総会です(現在はオンライン開催)

そこでエンジニア総会の場を、LIFULLエンジニア像を理解してもらい浸透させていくために、活躍しているメンバーが実際に直近で行った業務と照らし合わせながら、どういうエンジニア像のどういうポイントを意識したのか(もしくは今考えると当てはまっていたのか)、などを語ってもらうような場に変化させました。プロダクト開発は結果だけ見るより、その過程でどのような課題があり、どう考え、どう判断をしていったのか、を考え方の指針とともに知ると非常に勉強になります。本当に毎回素晴らしい事例が出てくるので涙を堪えることも少なくありません(本当)
社歴の浅い社員からはエンジニア像の理解や、どういう考え方・行動をすれば体現していることになるのかは参考になる、という声も頂いております。

今までは実際に会議室で一同に介しておこなっていたのですが、昨年から完全オンラインに移行して実施しております。会場準備大変だったのでそれがなくなって非常に効率化したのと、カジュアルに録画しておけるので非常に良いです。

最後に

当初の「LIFULLエンジニア像」をつくったとき課題感や内容の説明、浸透施策などを書かせていただきました。現在、LIFULLにおいては「エンジニアとして経営をリードする」という言葉はエンジニアの一人ひとりに浸透しています。それを意識するようになったことで技術面でもかなり良くなっていると感じています(手前味噌ですが...)。

仕事の種類やポジションによっていろいろなエンジニアやエンジニアマネージャーがおりますが、それぞれ異なった「エンジニアとして経営をリードする」方法があると思いますし、その考え方を大切に進んでいれば、みんな違ってみんないいと思います。LIFULLエンジニア像に向かって私自身も引き続き邁進していきたいと思います。

お読みいただきありがとうございました。