[ 入社のきっかけ ]
クリエイティブで、
大きな仕事がしたくて
就活生の頃に考えていたのは、「クリエイティブに携わりたい」「やるからには大きなことをしたい」の2点でした。学生時代は美術部と演劇部に所属していて、みんなでものづくりをすることに価値を感じていたので、どんな形でもクリエイティブに関われる職業に就きたいと考えていました。
リスペクトには当時からデザイナーやライターのようなクリエイティブ職のほか、営業系やエンジニア系の職種も同じくらいの人数が在籍していました。いろいろなタイプの人との関わりが自分の成長にもつながりそうだと思えたことは、リスペクトに入社を決めた大きな要素です。
実は「大企業を相手にビジネスを行う大企業」に就職する選択肢もありました。そんな中、中小企業を含む多くの企業をコンサルティングし、業界全体の底上げを図ろうとするリスペクトの事業内容を知って、「仕事の大きさは規模だけではない」と気づきました。大企業に比べれば一つひとつの仕事は小さいかもしれないけれど、社会に与えようとしている影響力の大きさにワクワクしたことを覚えています。
それと、人間関係がフラットで、若手社員の意見も聞いてくれる風土がある点も入社の決め手になりました。上下関係や長年の風習のようなものに邪魔されず、自分のやりたいことを追求できる環境はとても魅力的でした。
[ 現在の仕事内容 ]
エンジニアは、
成果に一番近い仕事
現在はDX事業部のサービスディベロップメント課のメンバーとして、長年お付き合いしている大型クライアントのバックエンドエンジニアを担当しています。単にコードを書くだけでなく、設計などの上流工程から携わるお仕事です。ほかにもいくつかのプロジェクトでバックエンドエンジニアの役割を担っており、自分自身で制作を行うほか、外部パートナーへの発注なども行っています。
個人的に、エンジニアは成果から一番近くにいる、責任もやりがいも大きい職種だと思っています。私たちがWebサイト制作で担うのは、リリース前の最終工程だからです。エンジニアの仕事をシンプルに言えば「企画・デザインされたものを動くサイトとして作ること」ですが、ユーザーは私たちが最終的に作ったものをそのまま使うことになるので、ユーザー目線を意識しながら求められるクオリティを定義し、制作することが大事だと思っています。
そして、意識すべき目線はユーザーだけではありません。プロジェクトには、共に推進するチームメンバーやクライアント側の担当者様など、多くの人が関わります。しかし、全員にエンジニアリングの知識があるわけではないし、自分と同じように案件内容を把握していない可能性もあります。例えるなら、ブランコが欲しい顧客が「ブランコが欲しい」と言ってくれるとは限らない、ということです。ブランコの存在やその有用性を知らないことも考慮し、なぜそれが最適解なのかを伝える力も求められます。特に、ブランコの危険性を説明して、必要な安全装置を取り付ける責任はエンジニアにあるので、慎重に検討・説明しなければなりません。このように各関係者の目線を意識しつつ、情報をわかりやすく伝えるためのコミュニケーション面の工夫も、業務を円滑に、より有意義に進行する上では欠かせないと思います。
また、なるべくログを残すことも意識的に行っています。アプリケーションを設計するときのように、案件進行でも、メモをたくさんとってログを残すのです。人間は忘れてしまう生き物なので、未来の自分や関係者のために作業ログをチャットに打ち込むようにしています。認識違いを防ぎ、ミスを抑止するためにも明文化することは重要ですし、文字にすることで自分の行動を客観視できているようにも思います。
さまざまな工夫を凝らしてはじめて、私たちは「世界をより良くするもの」を作れるのだと思います。その作り方をこの頭で考え、この手でつくること。そして、実際に動かし、誰かに利用してもらえること。それが私にとっての大きな達成感です。エンジニアリング領域を担うチームの一員として成果に貢献できている実感も強いですし、いろいろな業界のお仕事ができる楽しさもあります。
[ 私の挑戦 ]
新卒2年目で挑んだ、
大型プロジェクト
もともと「大きいサイトに関わりたい」とアピールしていたこともあり、入社2年目で新規の大型サイトを制作するプロジェクトにアサインしてもらえました。まだまだ未熟だったので正直に言えばビビっていましたが、要件定義や設計といった上流工程を経験すればスキルアップにつながると思い、先輩社員についてもらいながらチャレンジさせてもらうことになりました。
それまでは実際にコードを書く仕事がメインだったこともあり、やはり上流工程の対応には難しさを感じました。なので複雑な要件を整理するために、条件分岐やサイト状態の変化に応じてどんな動きをするかを資料にまとめました。要は知識不足と経験不足を補うことを目的とした、自分がプログラムを書くための資料です。しかしある日、その資料がクライアントに報連相を行うタイミングや、複数のエンジニアで手分けして作業するときの認識合わせにも役立っていることに気づき、「自分に貢献できるのはコードを書くことだけじゃない」と強く実感しました。
リリースまでは、クライアントとの密な連携を心がけました。Webサービスで最も避けたいのはサービスが使えない状況、いわゆる「鯖落ち」ですが、それが起きないよう慎重にテストとリハーサルを重ねました。テストで見つけた不具合やボトルネックを直しては、またテストをする。厳しい作業でしたが、クライアント共に改善案を持ち寄り、フランクに情報共有しつつ検討することで、大きな問題を起こすことなくリリースすることができました。この経験のおかげで、品質やオペ-レーションの正確性には人一倍気を使うようになったと思います。何事でも失敗した人を憎まず、要因を特定して仕組みを改善していく。この挑戦を通して身についた姿勢が、すべてのプロジェクトの振り返りと対策に活きています。
リリース後に寄せられたユーザーのポジティブな声を伺って、クライアントと一緒に「作ってよかった!」と喜んだことは今でも鮮明に覚えています。それまでの苦労が吹き飛ぶくらいのうれしさでした。こうした瞬間を共有できることも、クライアントに寄り添いながらチームでものづくりをすることの良さだと思います。そのプロジェクトでは密なコミュニケーションがクライアントとの新しい関係値を醸成することにもつながり、現在はより上流から一緒にサービスを運営させていただいています。