「人間関係」がテックドリブン経営の礎になる──会社の黎明期も他社も知るCROOZ SHOPLISTの“出戻りエンジニア”に学ぶ、エンジニア組織の土台づくり

加藤クルーズはこれまでも5年に一度ぐらいのペースで、大がかりな構造改革を繰り返してきました。僕自身はそのたびに成長してきた実感がありますし、楽しいとすら感じてきましたね。

そうした経験も活かしながら、今回の構造改革においては、会社の文化を作ってきた新卒採用組のメンバーと、他の会社の良い面を知っている中途採用組のメンバーが、どちらも100%力を発揮できる状況をつくりたいと考えています。自分はどちらの気持ちもわかりますし、経営陣の考え方もよく知っている。トップのスピード感に現場のメンバーがついていけるよう、自分ができる最大限の働きをしていきたいですね。

加藤優秀な人や意欲の高い人がのびのびと力を発揮しさえできれば、技術水準は自然と高まっていくもの。ですから、そうした環境を整えることが、改革のゴールだと思っています。少し無責任に聞こえるかもしれませんが、「こういった技術を身につけてください」と詳細に指示するのではなく、いま必要な技術をエンジニアが自発的に習得して活躍できる環境を整えることのほうが、重要な要件だと思います。

加藤組織の技術力を高めるうえで大切なのは、技術の“前”に存在しているもの、つまり人間関係やコミュニケーションです。これを円滑にしなくては、どんなに優秀な人が入ってきても活躍できません。

僕の経験上、「エンジニア同士が対等に話せていないな」と感じさせるチームは、技術力も高まらないと考えています。必要以上に相手に合わせて、自分を抑えてしまいがちですし、「あの人がいる間は自分は上に行けない」とすら考えてしまう。

また、問題を見つけて指摘してくれた人が「面倒臭い人」とみなされてしまうような組織はダメですよね。その人の声が改善のきっかけになり、成長していける組織をつくらなくてはならない。「重要プロジェクト」を通じて、そうした雰囲気の醸成に取り組んでいるところです。

加藤何年か職場で働いていると、「この人は心から信頼して話せる」という人と、「この人とは話しづらいな」という人に分かれてきますよね。全員が前者のような関係性になれると、かなり強い組織になる。技術は素早く浸透しますし、困っているときに困っていると声をあげやすくなりますから。

大切なのは、普段どれだけ相手を承認して過ごしているか。何気なく仕事をしていると気づきづらいですが、難易度の高い課題解決を一緒にクリアしていくと、相手の良さを知る機会は自然と多くなります。そうした日々の行動を通じて、人間関係の土台を構築しておく必要があります。

加藤人間って不思議な生き物で、見えないと気にならないことでも、見えた瞬間、「なんとかしなければ」と思うものなんです。

課題を見える化するためには、「タスクに対してどれくらいの時間がかかっているのか」などの事実を数値化する必要があります。それが見えないうちは、改善に向けた動きはなかなかスタートしません。ところが、課題が一目瞭然になった瞬間、多くの人が動き出します。課題を可視化することが、改善に向けた第一歩だと考えています。

加藤課題の見える化とは、コミュニケーションを対等にする上で必要な情報を整備する作業とも言えます。現状をクリアに理解できる状況を作り出せば、新卒／中途、若手／ベテランにかかわらず、メンバーが十分な情報を持ったうえでコミュニケーションを取れるようになります。

見える化する作業を「面倒だな」と思ってしまう気持ちもわかります。でも、一回やってみると、「こんなに改善できるものなんだ！」と面白さを実感できるはず。そうして楽しめるようになってくると、コミュニケーションは円滑になり、課題解決もどんどん加速していきますよ。

加藤SHOPLISTでは、経営陣も含めた全員が、時代についていくために必死に変わろうとしています。時代の変化にあわせて開発の方向性を示すのは、経営陣や部長陣の役割だからです。たとえば、今から約20年前のサービス開発は、「スピード勝負」の側面が強くありました。正直、IT初期の世界で生きてきた僕たちからすると、「期日までにつくれないのは負けだ」という感覚さえあった。

でも、今のIT業界ではスピードはもちろん大切ですが、品質が重視されるようになりました。昔のような勢いだけ重視する開発では、市場のニーズに合ったきめこまやかなサービスはつくれない。こうした変化に経営陣が対応しなければ、構造改革はなしえません。

加藤僕らは変化の過程にあって、できていないことはまだまだたくさんある。でも、こういうフェーズの企業で働くことは、できないものができるように変わっていく過程を知る貴重な機会だと思うんです。それは今後のキャリアを築いていくうえで、プラスに働くはずです。

変化にはパワーが必要ですし、面倒ですから、嫌がる人もいるでしょう。でも、結果として苦労の何倍もの効果が得られることを体感することで、変化の重要性が身にしみて理解できるようになるはずです。僕自身は前職でチーム内のメンバーの関係性や仕事の進め方をまるっと変える経験をしました。そうした経験は、IT業界で生きていく上で大きな糧になっています。

加藤エンジニアがサービス企画に参画できる度合いが大きいと思います。プロジェクトオーナーが社長と同等の意思決定権を持つので、階層は非常に少なく、エンジニアでも企画にコミットできる。この規模のサービスでそうした働き方を実現できる環境は、なかなかないと思いますね。

また、新しいプロジェクトが増えているので、高難易度の技術を必要とするケースも増えてきています。その場合は、開発に集中できるように切り分けることも重要だと感じています。過去の歴史では、特定の技術チームが会議室にこもってそれだけに集中するなんてやり方もありました。僕も当時それを見て参加したいと感じた事もありましたし、何をすると一番課題解決に繋がるかが重要と考えます。

開発には技術力、企画力、チームワークすべてが必要です。役割の大切さを互いに承認できて、一緒に楽しんでくれる人と働きたいですね。