この記事は 食べログアドベントカレンダー2023 の10日目の記事です
はじめに
はじめまして。2023年4月に入社して、現在食べログシステム本部ウェブ開発部に所属している相馬です。 エンジニアとして入社して、あっという間に数ヶ月が経過いたしました。研修を終えて、業務にも携わるようになりました。小さな改修でしたが私が担当したものがあり、それがサービスの一部として公開されているのを見ると感慨深いです。 これは同部署・チームだけでなく、いろんな人の助けがあったからできたことです。
私は最初のころよりもできることが増えたおかげで最近は多くの案件に携わるようになってきました。 その分人と関わる機会が増え、就職前に想定していたよりも人と関わる機会が多くなり驚いています。改めて食べログというサービスに関わっている人の数が多いことや自分がそうしたサービスの中で働いているということが実感できました。 弊社ですでに働いている方の中には社会人・エンジニアとしてベテランの方が多くいて、サービスの企画・開発・運営に携わっています。 そうした方々とやりとりをする中で、自分が仕事に活かしていける考え方ややり方を知ることができました。
この記事では、数ヶ月の仕事を通して、私が発見したことの中ですぐに仕事に活かせることを私の考えと一緒にご紹介します。特に、現在就職活動中の学生の方は是非この記事を参考にしていただき、今から実践できそうなことを試してみてはいかがでしょうか。
コミュニケーション
卒業前の大学では、感染症の影響とオンラインの利便性によって基本的に教授とやり取りをする場合は、チャットか通話が主な手段となっていました。
就職してからの業務中にコミュニケーションを取る主な手段も、チャット か 通話 です。
対面でのコミュニケーションとやり方がまったく違うというわけではありませんが、それでもやはりチャットや通話で起こる問題というのもあります。
仕事を円滑に進めるために、私が特に意識しているのは以下の2つです。
1.簡潔にわかりやすく
これは対面・オンラインに関わらずに身につけたいことです。
私は考えたことをすぐに口に出してしゃべってしまうタイプで、とりえあえずしゃべって伝えたいことを伝えようとしてしまいます。
プラベートで友人・知人と話をしているときには、それで盛り上がることもあるため特に気にすることはありません。
ただし、いざ仕事となってみるとそうはいきません。
私が部署に配属されてから業務について教えてくださるトレーナーさん、面談をしてくれる部長やマネージャーさん、作業の相談に乗ってくれるチームのメンバーみんな予定がぎっしり詰まっています。何も考えずしゃべってしまうと他のメンバーの仕事の時間を無駄にしていることになります。これはチャットでやり取りをするときも同じで、長い文章をバーっと書いて、送ってみて「で結論は？」となると長い文章を書いた時間や、その文章を読んだ時間というのは無駄になってしまいます。
こうした時間を減らすことが自分だけでなく他の人のためにもなります。
最近は、「結論→理由」の順番で話したり、箇条書きで報告したりするようにしています。
チャットで基本的に報告をしていますが、文章で説明するのが難しかったり、文章が長くなったりしまうと見当が付いたら、通話で報告するようにしています。
「相手の理解への負担を減らす」という意識が大切です。
2.誤解のない文章を作る
チャットでの報告や資料を作成しているときに、文字に起こしたからこそ誤解が生まれてしまうことがあります。
誤解が生じる原因として「前提条件の違い」「曖昧な単語」「主語抜け」がありました。
前述した「1.簡潔にわかりやすく」にも関係しますが、文章を書く際には相手との前提条件の違いを意識する必要があります。
例えば何かしらのソースコードの調査依頼を受けて、それを報告・共有するときに、自分は調査をしたので調査した周辺のソースコードや仕様については多少詳しくなっています。しかし、それを報告する相手は不明点があったため調査を依頼しています。この時点で調査した範囲のソースコードや仕様の知識で自分と相手で差ができている可能性があります。この差を認識せずに話してしまうと相手の理解が追いつかないまま報告が続いたり、理解に時間がかかる報告になってしまったりします。こうした状態を避けるために、自分と相手の前提を確認しておく必要があります。
ただし、前提といっても職種であったり、部署であったり、扱っているシステムの違いであったりと様々です。私は全部把握できているわけではないので、まずは書く文章をとりあえず具体的に誰にでもわかる書き方で記述します。目指すはその辺で歩いている人に説明しても理解ができるくらいの文章です。そこから自分の知っている相手の前提に合わせて文章を修正しています。
また私は話すときや資料を作るときになんとなく広い意味を持った言葉を使ってしまいます。広い範囲をカバーしてくれる言葉は便利ですが、その分相手と自分でその単語での解釈に差がでてしまいます。
例えばタスクという単語です。タスクという単語を調べると作業や課題といった意味になります。これを作業と捉えるか課題と捉えるかで少し意味合いが違うのではないでしょうか？
また単純に作業といっても、どういった粒度の作業を指しているのかで受け取り手の認識が変わります。
文章中にこうした単語が多いとその数だけ文章への解釈に差がでてしまいます。お互いの認識をすり合わせるためにも誤解を招きやすい表現はすべきではありません。
使っている単語がその場その場で表現が変わっていないことや不安だからお茶を濁すような単語を使っていないかをチェックしています。
特に横文字を使っているときは、その言葉を他のわかりやすい単語に直すようにしています。横文字は便利ですが、解釈に幅があるものが多いので要注意です。
さらに基本的なことになりますが、主語が抜けている文章というのは誤解が生じる原因として大きいです。
例えば、誰がどう行動するのかといった説明をするときに主語が抜けてしまうと、読んでいる人の解釈は「主語が抜けていているが、直前の主語とは別の人が行動するのか」「直前に使われていた主語がそのまま使われているのか」という2つのケースが考えられます。前者であれば読んでいる方が疑問に思い確認する可能性がありますが、後者であった場合には確認されずにそのまま行動に移されてしまう可能性があります。
私は昔から話しているときに主語が抜けてしまうので主語の漏れについて特に注意しています。
誤解のない文章を考えるようになると、相手に誤解を与えないようにするだけでなく、自分が誤解をしないようにやり取りできるようになります。
ユーザー視点で考える
これは、就職活動をしているときよく見かけるフレーズでした。私も同意見ですし、これを大切にしている企業に入社したいと心に決めて就職活動をしていました。
ただ実際に業務に入り既存の機能改修や新しい機能を作っていると、こうした観点から離れて実装やテストを進めてしまうことがあります。
最近も新しく作った機能を依頼者の方に確認していただいたら、自分が考えて実施したテストとは違った観点でエラーが発見されました。
例えば、「ボタンを1回クリックすると特定の処理が実行され、画面が遷移する」と言った機能のテストで「ボタンを画面遷移前に2回クリックしてみる」といったことや「ブラウザバックしてまたボタンを押してみる」といった操作をしたときです。
実装した私が確認しているときはボタンを1回クリックすれば動作することを知っているので、ボタンを2回クリックすることやブラウザバックして再度実行してみるといった操作をしていませんでした。指摘していただいた点について依頼者の方と話してみると、似たような作業をしているときに実際にやってしまうことや、やりそうな操作ミスを試したとおっしゃっていました。私がテストで試していた一連の操作は、実際にユーザーができる行動のうちの1つでしかありませんでした。
他にも表示を少し変えて欲しいという依頼があったのですが、自分では何度も見ていた画面だったのに指摘されて確かに表示を変えた方がいいなと感じることがありました。
これは私が「実際にその画面を使って違和感や使いにくさはないか」という観点ではなく、「自分が実装した想定通りに動作しているか」という観点でしか確認できていなかったのが大きな原因だと考えています。
自分が作っているのは何をするための機能で、どういう人たちが使うのかということを考えればこうしたミスは減っていきます。 プログラムを書いているときはつい夢中で書いていってしまい、ユーザーの視点で考えるというのは難しいことかもしれません。 ですが、設計・テストは一度視点を切り替えて考えるタイミングにして、確認することならできます。
そもそもプログラムで作るものは、前提として「楽をして目的を達成することができるようにする」ものを作っているということを忘れずにプログラミングをしていきたいです。
勝手な遠慮をやめる
私は、人と接する上で気を配ることは大切なことだと考えています。
上述したコミュニケーションで「簡潔にわかりやすく」「誤解のない文章を作る」といったことも他の人への配慮です。
こうした配慮はプラスな面もありますが、いきすぎればマイナス効果になる場合もあります。
例えば、「質問したいけど相手が忙しそうだから様子見しよう」「ミーティングの予定入れたいけど、この時間帯相手が大変そうだし予定を入れない方がいいかな」といったように相手に迷惑がかかるかもしれないと考えて、自分の中に一旦仕舞い込んでしまうような場合です。私も最初こう考えることが多く、一旦抱え込んでしまっていました。
しかし、これでは自分の仕事が進みませんし、相手に迷惑がかかるかもしれないという勝手な憶測で機会を逃しています。 また自分が早くに聞いていれば起こらなかったミスが発生すれば、それこそ相手に迷惑がかかります。
「忙しいから無理」というのは相手が判断することであって、自分が判断することではありません。 みんな無理なら無理とはっきり言ってくれるので、下手な遠慮はせずに確認するようにしましょう。
そうすれば、自分も相手の負担も減り、仕事を円滑に進めることができます。
「ありがとうございます」で終わらせない
最初にわからないことがあるのは当然で、教えていただいたり、手伝ってもらったりすることは仕方がないことです。 ただし、そこで手伝ってもらったときに「ありがとうございます！」と返信して終わってしまうと、同じことがあったときに自力で解決できずまた手助けしてもらってしまうことになります。
私は配属してすぐのときにPCや環境設定のトラブルで先輩社員の方に助けてもらったことがありました。 その場は解決したのですが、最近になって似たようなトラブルがあり、そのときと同じような対処方で解決しようとしたら上手くいかず結局また助けを借りることになりました。そのあとこうしたトラブルがあった場合の資料があり、手助けしてくれた方はそこを見て対処してくださっていることを知りました。
ここでの反省は、「自分で調べてその資料に辿り着けたかもしれないこと」と「最初に手伝ってもらったときにどうしてそう対処したのかと確認をしなかったこと」だと考えました。
前者は、自分で調べて見つからないこともあり確認した方が早いことがあります。 しかし、後者は最初に確認しておけば2回目に助けを借りることは起きませんでした。 振り返ってみると、これまでの生活で誰かに助けていただいたときに「ありがとう！」と言って終わらせてしまっていることが多かったと気が付きました。
ここで言いたいのは誰かに頼るなということではなく、頼りっぱなしのままにしないということです。 仮に今までそうして頼っていた人がいなくなったときに、自力ではどうしようもなくなってしまうかもしれません。 そうした事態をさけるためにも、手伝ってもらったあとに感謝の言葉だけで終わらせずに、どうしてそうアプローチできたのかを聞くようにしています。
これを繰り返していけば、自分で解決できることが増えて、相手に確認してもらう時間や調べてもらう時間を減らすことができます。
おわりに
今回ご紹介した内容ですが、直接指摘していただいたり、ミーティングでお話を聞いたりしているときに気がついたものをご紹介しました。
私が、学んだことをまとめると「相手の余計な負担を減らして」「自分の負担も減らす」の2つになります。 相手の立場になって考えたり、相手にわかりやすく伝えたりすることで相手の負担を減らすことができます。 しかし、それだけでなく相手の負担を減らしたことで自分の負担も減ることが大切だと考えています。 例えば、チャットでのやりとりでわかりにくい文章を送って、相手に何度も聞き返されてしまうと自分もその返答をする必要があります。 最初にわかりやすく伝えていれば、そうした余計なやりとりがなくなり、お互いの負担を減らすことができます。 「相手の余計な負担を減らす」という意識が薄かったことが私の反省で、「自分の負担も減らす」というところまで気がつけたことが成長したところだと自負しています。 お互いに楽になれるようなやり方をどんどん考えられるようにしていきたいです。
まわりには社会人・エンジニアとしてベテランの方々がいます。そうした方々はどう対処しているのか真似してみると自分との違いがわかりやすくなり、自分のやり方を改善するきっかけになります。 こうしたベテランの方々から学べる機会が多いことが弊社の魅力の一つだと思います。 ただ、ベテランの方々から学んで満足するだけじゃなく、自分もそうしたレベルで業務ができる社会人・エンジニアとして一人前になっていきたいです。
エンジニアとしても、社会人としても学ぶことが多く、四苦八苦している日々ですが精進していきます!
明日は @weakbosonさん の「食べログネット予約における非同期メッセージ発行の設計パターン - Transactional Outbox のメリット」です。お楽しみに!
