なぜスタートトゥデイはエンジニア用の評価基準を持たないのか？

▼スタートトゥデイ・大蔵峰樹氏へのインタビュー第1弾
イノベーティブであるには、業務に合ったシステムを自ら内製化せよ。｜スタートトゥデイ 大蔵峰樹に訊く！

エンジニアである前に、スタートトゥデイのメンバーである意味

エンジニアはいかなる基準で評価されるべきなのだろうか？

今回、話を伺ったのは、日本最大級のファッションECサイト『ZOZOTOWN』、ファッションコーディネート検索サービス『WEAR』を生み出したスタートトゥデイ。

スタートトゥデイといえば、数々のWEBサービスや物流・社内システムを内製していることで知られ、数十名ものエンジニアが在籍している。

しかし、「エンジニアのための評価基準は設けていない」と語るのは、技術部門を統括する同社取締役の大蔵峰樹氏。スキルやノウハウ以上に、理念への共感や人柄を重視するという同社の考えを紐解きながら、エンジニアへの評価に対する新たなアプローチを探った。

スタートトゥデイ社　取締役 大蔵　峰樹氏

刑事のように「疑いの目」を持つエンジニアであれ。

― まず、スタートトゥデイが考える、理想のエンジニア像を教えてください。

明文化されているワケではありませんが、刑事のように「疑いの目」を持つエンジニアであってほしいですね。依頼に対して、「本当にそれでいいのか？」という疑問を持ってほしい。

依頼された機能を言われるがままに作るのは良くないですね。もし何も考えず言われた通りに作ったら、システム自体を崖の向こう側に落とすことになるかもしれないので。

― 「崖の向こう側に落とす」と言いますと？

たとえば、システムの改善を行なうときに、「ココをこんな風に変えて」と依頼がきますよね。でも、依頼を出す人ってシステムのほんの一部分しか見ていない可能性があるんですよ。その部分を変えることで、他のシステムに影響が出るなんて考えていない場合が多いんです。

だから、何の疑いもなく言われた通りに設計すると、一時的に改善されたように見えるけど、別部分の効率が悪くなった、なんてことも起こりえる。結果として、全体効率を悪くすることに繋がるかもしれないんです。

なので、言われたことに疑問をもって、「その人が何をしたいのか」「本来、実現したいことは何か」をキチンと理解することが大切。依頼を受ける時もそうだけど、設計する時も、開発する時も、それを頭に置いておくことが重要だと思います。

― 前編の「長期的な視点を持つ」という考えにも紐づいていますね。エンジニアはつねに一時的な部分最適でなく、全体最適を意識することが重要だと。

実際、スピード感を求められる中で、そこまで深く考えて作るって難しいんですが、機能の実現だけでなく、アクセス集中による負荷などの様々なリスクも考慮して、開発・改修の判断をできるエンジニアであってほしいですね。

エンジニアも、営業も、共通の軸で評価する。

― そんな理想の像がある中で、エンジニアの評価軸はどのように定めてらっしゃるんですか。

特別、エンジニアだけの評価軸って明文化されてないんですよ。エンジニアも、デザイナーも、皆「いい人をつくる」という経営理念で評価されます。エンジニアである前に、スタートトゥデイのメンバーだから、いい人をつくれると判断された人がステップアップしていくんです。

― それは面白いですね。では、大蔵さんがエンジニアの成長をはかるとき、何を見ていらっしゃいますか。

スキルとノウハウですね。

スキルの高さとは、職人さんに例えて言うと、良い道具を持っていて、良いものを生み出せること。そしてノウハウは、「こう作るとココが壊れるかもしれない」「ココをいじるとこんなコトが起こるかもしれない」という経験則からくる感覚的なもの。

個人的には、スキルよりもノウハウの方が大事だと思っています。ノウハウを身に付けるために必要なのは、経験ただ一つ。だから部下には色んな経験を積ませて、ノウハウを蓄積させるようにしています。

正直、コンピューター系エンジニアのノウハウってなかなか身に付きづらいんですよね。たとえば職人さんだったら、先輩の手さばきを見て「なんで今、鉄板で補強したんだろう」「なんでマニュアルにない動きをしたんだろう」とか色々考えながら、ノウハウを見て盗めるじゃないですか。それがコンピューター上になると、わかりづらい。だからまずは、「転ばぬ先の杖」の存在にさえ気づいてくれれば御の字ですね。

― では、新たにエンジニアの採用を行なう場合もスキルとノウハウをご覧になっているのでしょうか。

採用で見ているのは人柄ですね。コミュニケーションが8割、スキルが1割、ノウハウが1割って感じかな。スタートトゥデイには独特の雰囲気があるんですよ。

誤解を恐れずに言うと、大学サークルのような色んな考えを持った人がいるなかで、皆がだいたい同じ方向を向いていて、なんか楽しそうにやってるというような。

もちろん、技術力のあるエンジニアはノドから手が出るくらい欲しいけど、会社の雰囲気に合うかどうかを一番大切にしています。だから採用時も、「エンジニアだからココを見てる」っていうのはないですね。

エンジニアが飛躍を遂げる法則

― 貴社には経験の浅いエンジニアも多いと伺いましたが、実際どのように育ててらっしゃるんですか？

まずは小さな成功体験をたくさん積ませるようにしています。成功体験というか、人から感謝される経験ですね。

誰かのPCトラブルを解決する、管理画面の不具合を調査する、なんでもいい。とにかく、人の役に立っている手ごたえを感じさせて、自信をつけてもらいます。第一段階は、自分の仕事が“会社に必要なパワー”になっているという実感を持たせること。

中堅クラスになると重要なのが、失敗体験。エンジニアの成長ってキレイな比例グラフを描かないと思うんですよね。最初は右肩上がりに伸びるんですけど、必ずと言っていいほど大きな壁にぶつかり、一旦落ちるんです。落ちるところまで落ちたら、もう後は上がるしかないですから。失敗体験こそ、エンジニアが大きくジャンプアップするために欠かせないことだと思います。

― 失敗体験をしたエンジニアは、具体的に何が変わりますか？

仕事への姿勢や、視野の広さかな。

僕が育成したエンジニアの中で、「めちゃくちゃ伸びたな～」と感じている社員がいます。失敗体験をするまで、頼まれたことはやるけど、自分から聞いたり、動いたりはしない、受け身の働き方だったんです。それまでのやり方では成長の天井が見えてしまっていた時期に、大きな壁となる失敗体験がありました。

その社員は自分が開発責任者だったサービスをリリース日までに完成させることができなかった。失敗するのはわかっていたけど、僕はあえて黙って見ていました。ヘルプを出されても、一切手を貸さなかったんです。

それを機に、劇的に変わりました。仕事を上手く進めるための全体把握能力を身に付けたからか、自分から質問したり、動いたりするようになったんです。自分の中で仮説を立てて、相手がイメージする完成形を探ったりね。

その後、部長に昇格。やっぱり失敗体験って、エンジニアとして大きくジャンプアップするために欠かせないんじゃないかな。

今は当社も上場していますし、あまり大きな失敗をされると困っちゃうんですけどね(笑)。

― では最後に、大蔵さんが考える「デキるエンジニア」とはどんな人か教えてください。

勉強の仕方を先に勉強する人ですかね。

たとえば、プログラミングについて勉強したいと思った時、普通の人は参考書を買って、勉強して、わからないところを質問しますよね。

でもデキる人って、「どの言語から勉強したら良いですか？」「どの参考書が良いですか？」って聞くんです。まずやり方やコツを学ぼうとする人は、「デキる人」だと思いますね。

これはエンジニアに限った話じゃないですね。こういう人ってエンジニアでも、営業でも、デザイナーでも、なんでも活躍できますから、どこでも評価されると思います。

― エンジニアならではの評価軸を持たず、全職種を同じ軸で評価する。そんな同社の方針から、エンジニアである前にイチ会社員として評価される存在であることの重要性に気付かされました。貴重なお話しをありがとうございました。

（おわり）

［取材] 松尾彰大　[文] 磯田優里亜

編集 ＝ 松尾彰大