はじめに
運が良いことに自分は今、今まで出会ってきたエンジニアの中で一番凄いと思う人と一緒に働けています。
今の会社で働けていてよかったな〜と日々感謝しつつ、一緒に働いている中でたくさんのことを勉強させていただいています。
そしてそろそろアウトプットせねば！（使命感）と思いこの記事を書いています。
今回は技術以外のことで学んだこと、大切だと思ったことを書いていきます。
（この記事の中で凄腕エンジニアさんのことはTさんと呼ぶことにします。）
（どれくらい凄いのかも本当は書きたいですが、この記事の目的とは離れてしまうので省略します。。。）
（本当は【凄腕エンジニア】という言葉でくくりたくないくらいすごいエンジニアさんです。。。）
ドメイン知識、業務知識の大切さ
今自分が参加しているプロジェクトではTさんが業務要件の整理やヒアリング、システムの設計、DBの設計を手掛けているのですが、
ドメイン知識というか業務知識の深さがすごく、その深さが業務要件のヒアリング、システムの設計、UIの設計、DBの設計等々ににじみ出てるんです。
現場の人と同じくらい知識があるので、現場の人が何が辛いのか、どうしてほしいのかなどが手に取るようにTさんにはわかるんです。
システムの改善案やこういう機能あったら嬉しいですよね？という提案なども的確で、業務知識やドメイン知識を深めることが使いやすいシステムの開発につながっていくんだなというのが身にしみてわかりました。
今まで自分はコードの書き方であったり、フレームワークの使い方であったり、設計であったりと技術力的な方面を重要視していたのですが、今回のプロジェクトを通して、ドメイン知識や業務知識を深める大切さを学びました。
（なので、今話題のニトリの1年半の現場研修もちょっと長い気もするな〜くらいで結構理解はできてしまう派でした。。。）
使いやすさを突き詰める姿勢
Tさんから
「脳死で操作できるUIじゃなきゃだめだよ。例え寝不足でもどんなときでも操作ミスしないような、そんなUIじゃなきゃだめだよ」
「他のプロダクトを押しのけてでも使いたいと思ってもらえるかどうか」
と言われたのを鮮明に覚えています。
自分自身開発をしていく上で、普通に使えて普通に動いていればよかったと思っていた面が多分にあったのですが、この言葉を聞いてはっとさせられました。
今では自分自身の中でいいUIかどうかの基準になっています。
それとTさんは、普段から
「どっちがユーザーさんが嬉しいかな？」
「どうすればユーザーさんが一番うれしいかな？」
「こういうふうにするとユーザーさん嬉しいと思うので！」
「これがあるとユーザーさん嬉しいんですよね〜」
というような言葉が自然と口から出ていて、徹底してシステムを使ってもらう人目線で考えることが当たり前になっており、本当に尊敬です。
自分もユーザーさんが一番うれしい形を追求、提供していきたいです。
それとTさんの言葉でもう一つ印象に残ってるものがあって、
【利用者に成り切り、演じて、痛みを一緒に被る】
という言葉です。
利用者に成り切ってシステムを触ってみて、利用者と同じ痛みを被ることで、改善点が見え、早く直さねば、改善せねばいけない！という気持ちになります。
本当の意味で自分事化してシステムを作るために必要なマインドだと思っています。
【何度も同じことを聞いていい、何度でも答えるから】というポリシー
これは本当にありがたかったです。
Tさんにはプロジェクト当初から
「いくらでも、例え同じ質問でも何回でもしてくれて大丈夫なので！」
と声をかけていただいていて、そのおかげで質問のハードルがとても下がり、気兼ねなく質問をすることができました。
今のチームではGatherというアプリをよく使っていて、テキストではなく直接対面で質問ができる環境だったので、スムーズに質問できました。
そして＋αで周辺の知識の話やもっとこうしたほうが良いよという話まで聞けて勉強になって、ありがたかったです。
（Tさんはテキストで質問するより直接質問してもらった方が早いし伝えやすいので。。。という人で、なおありがたかったです。）
そうなってくるとチーム内ではTさんに対してだけではなくて、自分に対しても質問いいですか？というコミュニケーションをとってもらえたり、自分からTさん以外のメンバーに質問をしにいったりと、質問しやすい環境が出来上がり、本当にTさんのポリシーのおかげだったなと思っています。
（こういう環境作りはスクラムマスター（@YUM_3）が良いチームづくりに力を入れてくれていた部分もとても大きいです）
もしもTさんが「質問はテキストだけで、同じ質問はしないでください」というような人だったら今のチームの質問しやすい環境はなかったと思いますし、それにより開発の効率も下がってしまっていたと思います。
自分にも後輩ができたら、Tさんと同じポリシーで接していきたいと思っています。
（質問されやすい雰囲気つくること重要）
設計は思いやりが大切
これはちょっとだけ技術的な話が入ってきたり使いやすさを突き詰める姿勢の話にも近いのですが、Tさんのコードや行動などを見ていると思いやりがとても重要だなと感じています。
例えばコードを書くときも
「他の人が読んだらどう思うかな？読みやすいかな？」
「この機能が改修するってなったら改修しやすいかな？」
こういうふうに相手を思いやれるかどうかでコードの綺麗さや質が変わってくると思っています。
Tさんの書いたコードはめちゃくちゃ改修しやすいんです。
issueのタイトルだけみたらとても大変そうなのに、いざ改修してみるとあれ？ここだけの修正でいいの？ってなります。
こういう体験は、開発中に他の人が自分のコードを改修する姿まで見えているからこそ生み出せるものなのだろうなと思っています。
思いやりについてはUIを考える上でも重要です。
そのシステムや機能が使われるコンテキストをしっかりと考慮し、システムを使って貰う人のことを想像して、
こういう機能あったらいいよね？
こういう文言あったらわかりやすいよね？
こういうステータスで検索できたらいいよね？
などなどこういうところまで考えられるかどうかで使いやすいシステムになるかどうかが決まるといっても過言ではないのかなと思っています。
最後に
記事を書きながら思ったのですが、Tさんは場面場面で徹底的に相手に成り切る力が凄いんだと思いました。
（根本的にドメイン知識や業務知識、技術力が凄いのはもちろん。。。）
システムの設計をするときはシステムを使ってもらう人に成り切り、コードを書くときは自分ではない他の開発者に成り切って、こうだったら嬉しいよね、こうだったら辛いよねというふうに徹底的に考えることができるのが、Tさんが圧倒的な価値提供をできている要因の一つなのだろうと思っています。
そしてシステムを使ってもらう相手に成り切るためには、ドメイン知識や業務知識が必要なので、技術力だけでは良いシステムは作れないということをこのプロジェクトで身にしみてわかったのはとても良かったです。
自分もTさんみたくなれるように、この記事に書いたことを日々意識していき、本当に使いやすいシステムを作れるエンジニアになれるように研鑽していきます。
ここまで、記事を読んでいただきありがとうございました！