ユーザーを想って開発しよう【内定者バイトでの気付き】

この記事は CARTA TECH BLOGアドベントカレンダーの12/13の記事になります。

こんにちは！fluctで24卒内定者アルバイト中のしゅんしゅんです！

前回ブログを書かせていただいたときはCCIに所属していたのですが、長期でバイトしているため部署異動があり現在はfluctで広告の管理画面を作っています。入社前にいろんな部署を経験できてとても充実してます！

さてさて、fluctで働いて約２ヶ月、最近はただ開発をするだけでなくデザイナーさんと仕様について検討する機会が割と多くあり、そこでの気づきを書こうと思います。

ある日のできごと

その日、私はデザイナーさんと次に作る新機能について話していました。ただその機能は実装が見た目ほど簡単ではなく、作らなくても運用のできるものでした。

そのとき私はこの機能を作ると実装は複雑化するし、作らなくて良いのではないか？となんの気なく言いました。私にとっての関心は、そのコードのメンテナンスコストに向いていたのです。

それに対してデザイナーさんは「実装が複雑化するから作りたくない、というのはこっちの都合でユーザーには関係ないよね？もっとユーザーのことを考えて意見してみよう」と言われて思わずハッとしてしまいました。

機能追加とメンテナンスコスト

全く恥ずかしいことに、余分な機能を作らずにコードが少なく、メンテしやすいのは良いことだというエンジニアの考えをそのままソフトウェアに適用しようとしていました。もしその機能がユーザー全員が欲しいと思っている機能であったら、実装が複雑になるから...というのは作らない言い訳にならないでしょう。

ただ、ユーザーが欲しいからという理由でなんでも実装が複雑化してでも作るべきか？と言われるとそうではないと思います。複雑化したコードは、その後の開発の生産性を下げるというのはよく知られた話です。それは機能が欲しい！と思ってから実装されるまでのデリバリーが遅くなるという形でユーザーに不利益をもたらします。

つまり、その後の開発生産性を著しく下げるのでその形での機能追加はユーザーのためにならないですよということが言えれば、メンテナンスコストは作らない理由になる可能性があります。

ユーザーを想って開発する

結局のところ、ユーザーにとって何が最善か？を常に考えて仕事をする必要があるように思われます。

今まではコードを読みやすく書いたり、リファクタリングをしたりするのはエンジニアのためであると考えていました。ただそこからさらに突き詰めると、ユーザーに安定してデリバリーをし続けるためという目的があるのだということに辿り着きます。これこそがきっと本質であり、そのために自分は動いているのだということをより自覚しようと思いました。そう思うと、この仕様はどうあるべきかやタスクの優先順位が見えてくるような気がします。

ユーザーを主語にして議論する

またこうしたユーザーを主語にした議論をができるようになると、デザイナーさんとするプロダクトについての議論はグッと楽になりました。というのもユーザーというのはお互いの共通の関心事になるからです。今までの自分の中のイメージではプロダクトそのものを主語にして議論をしていました。ただ、そのときデザイナーさんがイメージしているプロダクトとエンジニアとしての自分がイメージするプロダクトはズレやすかったように思います。

というのも、デザイナーさんはユーザーが見ている画面と仕事をする時間が長いのに対し、エンジニアはそのプロダクトのコードと向き合う時間が長くなります。そうなるとプロダクトについて頭の中にイメージするものが違ってくるのは仕方のないことのように思います。そしてこのズレがプロダクトに対する課題感のズレを引き起こすように感じます。だから冒頭の話で自分はコードのメンテナンスについて懸念を持ったのかなと思います。

ただユーザーを軸にして考えれば、デザイナーもエンジニアも自分を分離して客観的に考えることができます。それがお互いの目線を合わせることに繋がってエンジニア以外の人との議論が楽になったのかなと思いました。