「相手の立場に立つ」の本当の意味。新卒エンジニア4人が得た気づき

私は専門学校の在学中に、複数社のインターンに参加していました。当時は正直、それぞれの会社の違いがよく分からなかったのですが、「カオナビだけは明らかに他の会社とは違う」と思いました。

いかにして無駄のないコードを早く書いていくか、というような経験を各企業で積ませてもらっていたのですが、カオナビで実際に取り組んだのはそうではなく、インターンながら「ロジカルシンキングを使って課題を解く」ような作業だったんです。これがとても面白く感じました。

加えて、カオナビのメンバーが、仕事に追われるというより主体的にのびのびと働いているように感じられ、私もこんな風に働きたいと率直に思いました。

働き方には、私もとても魅力を感じました。「エンジニアは長時間働く」というイメージを持っていたのですが、逆求人のイベントでカオナビを知り、「フレックス±20時間制度」という制度があることを知ったんです。

所定の労働時間から月間でプラスマイナス20時間を調整できる制度で、実際に活用している先輩たちはとてもスマートに働いているように見えました。

また、個人の頑張りを正当に評価してくれる成果主義の社風にも惹かれましたね。私も先輩たちのように、メリハリのある働き方をして成果を出せるようになりたいと感じたのを覚えています。

確かに、「ぎゅっと働いてぱっと帰る*1」働き方はかなり魅力的でした。大谷さんと同じで、「エンジニアは夜遅くまで働くもの」というイメージが覆りましたね。

*1：カオナビの4つの行動指針の一つ

カオナビを知ったきっかけは、在籍していた専門学校主催のプログラミングコンテストでした。上位入賞者の特典としてカオナビの面接を受ける機会を得ることができたんです。

もともと自社開発のサービスに興味がありましたし、面接でお会いした社員の皆さんはとても魅力的だったので、ここで一人前のエンジニアを目指したいと思いました。

私もカオナビとの出会いは逆求人のイベントでした。そこで、平松（現プロダクト本部長）と話すと、「別府さんは、カオナビ以外の会社でも活躍できると思う」と言われたんです。

どういうことかと驚いていると、「でもカオナビでキャリアを積むことで、一人のエンジニアとして成長してほしい」と続けて伝えられました。こういうイベントでは、どの企業も自社の魅力のアピールに熱心になるものなのに、なんだかスタンスが違うなと。

一人のエンジニアのキャリアプランに重きを置く企業姿勢に惹かれました。

また、「プロダクトアウト」な会社の方針も、私の価値観と合っていました。

私は学生時代、自身が感じていた課題意識から「WEB会議中に参加者の感情を表すパラメーター」のツールを開発していたので、その経験を生かしつつ、技術に磨きをかけて、世の中を動かしていけるようになりたいというのが、当時思ったことですね。

それはみんな同じだよね？（笑） 5月から半年間にわたって取り組んだ実践開発研修です。

「プロダクト本部の開発状況を可視化するツールを開発してほしい」というお題をもらいました。具体的には、開発案件の進捗状況や作業時間対比の成果を見える化するツールだったのですが、何か雛形があるわけでもなく、開発の進め方も決まっているわけでもなく、全て話し合って決めるように言われたので、本当にゼロの状態からのスタートでした。

それまでの座学研修では、プログラムやセキュリティの基礎知識を学んでいただけだったので、急にレベルが上がって驚きましたね。心の中では「マジですか」と思っていました（笑）。

とても高かったです。どんな機能が必要で、それを実現するにはどんなデータが必要で、そのデータをどうやって取ってくるのか。更地の状態から4人で考えていくのはものすごく難しかったです。6月末には終了する予定だったのですが、最初のバージョンが完成したのは10月でした。

全く終わらなかったからです（笑）。もちろん6月の予定でスケジュールを組んではいたのですが、思い通りに進まず、力不足を思い知りました。

できあがったものを福田（現VPoE 福田健）に見せにいくと、「まだ考慮が足りていない部分があるんじゃないかな？」と。時には「全然違う。そうじゃないんだよな」とも。

もらったフィードバックを4人で咀嚼して、つくり直して、翌週もう一度提出してもまたダメで。返されたのは4、5回じゃないよね？

そうなんです。だから最初のうちは、何が悪いのかも分からなかったんです。福田の言葉のニュアンスをどう咀嚼し、機能に落とし込んでいくかを考えるのに苦労して。課題を提出しては戻されを毎週のように繰り返していました。

スクラム開発の大枠については座学で教わっていたのですが、実際にチーム開発をやったことはなかったので、開発は本当に手探り状態でした。

最初は正直、「作業時間のグラフを出すだけなら簡単でしょ」と思っていたんです（笑）。でも、福田とのやり取りを何度も繰り返すうちに、開発の進め方が根本的に間違ってるんだなと気づかされました。

福田からは、「依頼者のニーズに応えるだけでなく、君たちがどういう考えでこのシステムをつくったのかを説明してほしい」と常に言われていました。

福田が発注するお客様の立場に、私たちが仕事を受ける企業の立場に置かれていたので、お客様の要望に対し企業としてどう応えていくかが試されていたのだと思います。

この研修で痛感したのは、相手がほしいものを提供することの難しさでした。

言い渡されたお題は「データを可視化してほしい」だけだったのですが、可視化したデータを使って相手が何をしたいのかまで考えることができて初めて、「この機能もあった方が良さそうだ」といったことに気づくことができました。

私たちに求められていたのは、相手の言う通りのシステムをつくることではなく、相手の視点に立った仮説思考でシステムを考えることだったんです。

がむしゃらにつくるのではなく、一旦立ち止まって、相手が求めるものを分析する重要性を実感しました。大学時代にサービスの開発経験はあったものの、自分が面白いと思うものと人が求めるものをつくるのとでは、わけが違いましたね。

私も大学院でシステム開発をしていたのですが、自分が「これがあったらいいな」と思うものをつくる段階で止まってしまっていたことに気づきました。

仲田も言っていましたが、それではお客様から「これが見たい」と言われたときに、「見えればいいんだな」と思ってつくるだけになってしまう。そうすると結局「確かに見えるようにはなったけど、これだけではどうにもならない」と言われて、最悪の場合つくり直しになってしまいます。

お客様の言葉を表面的に受け取るのではなく、「お客様が実現したいことは何か。それをできるようにするためにはこうしよう」と一歩進んで考えられるようになったのは成果だと思います。

私は、ただ技術を得ていけばよいというわけではなく、使う技術の選択肢を広く持つ必要性を感じました。

ある機能を実現する術を一個しか知らないのと、複数個知っている中から選ぶのとでは、開発過程それ自体が変わるのはもちろんのこと、完成したプロダクトの意味合いも全く異なるものになります。

複数の手段から一番良いものを選べる知識を身につけなければと思いました。

私は他のメンバーよりも開発経験が浅かったので、まずはコードの書き方からスタートしました。実践研修でフロントエンドを担当したのですが、この領域の技術はアップデートが早く、2年も経てば古いものになってしまいます。検索して出てきた古い情報をうっかり使ってしまうと、全然動かないんです。

最初はなぜ動かないのかすら、よく分からなかったのですが、検索の方法を変えて試してみたり、先輩やチームメンバーに聞いたりするうちに、情報の判別方法が分かるようになってきました。

はい。先輩方はみんな優しくて、実戦研修で開発したツールの使いにくいところを教えてくれたり、「こうした方が良くなりそうだよ」と具体的なフィードバックをくれたりして、非常にありがたかったです。

厳しい言葉だけでなく、「この機能はよく考えられていいね」といったお褒めの言葉ももらえたのは嬉しかったですね。ほとんど在宅勤務だったのですが、Slackといったツールでリアルタイムのコミュニケーションをとりやすく、困ることはほとんどなかったような気がします。

Slack上でのやりとりにもすぐにレスポンスをいただけて、スムーズにコミュニケーションが取れたので困ることはほとんどなかったような気がします。

実は……第一段階としてリリースはしたものの、まだ完成したと言える状態ではありません。足りない機能がまだまだあります。なので、今後も本配属後のメインの業務をこなしながら、時間を作って機能追加を含めたアップデートを行っていく予定です。