事業知識の深掘りでリファクタリング　人の役に立つWebサービスを作るために必要なこと

事業知識を深掘りする

Kubota Nao氏（以下、Kubota）：まずは自己紹介から。Kubota Naoと申します。私は大阪在住で、ふだんはWebエンジニアとして働いています。バンド活動もしていて、趣味でドラムを叩いています。今は30歳独身の一人暮らしで、最近は引きこもりゲーマーを極めています。今はポケモンにハマっていて、やっている方がいたらぜひ仲よくしてください（笑）。

今回は「事業知識を深掘りし、より人の役に立つサービスに改善する」というテーマで話しますので、よろしくお願いします。

もともとは事務系の職種で働いていましたが、3〜4年ほど前に人に役に立つWebサービスをつくりたいと思い立ち、職業訓練校や独学で勉強を始めて、現在はWebエンジニアとして働くようになりました。

エンジニアとして人の役に立つWebサービスを作るために

2018年9月から株式会社エイチームフィナジーという企業で、「世の中からお金の不安を解消しより人生が豊かになる社会を実現する」「クライアントの期待を超え続け業界の発展に貢献する」というミッションのもと、住宅ローン比較・情報サイト「ナビナビ住宅ローン」というサービスの運営に携わっています。「ナビナビ住宅ローン」の公式ナビゲーター、住井マイちゃんという女の子が発信しているTwitterアカウントもあるので、よかったらフォローしてください。

この「ナビナビ住宅ローン」はRuby on Railsで開発していてます。住宅ローンに関わる情報や商品を紹介しているようなサイトになっています。

私個人のミッションである「人の役に立つWebサービスをつくる」ことと、エイチームフィナジーのミッションである「世の中からお金の不安をなくす」を実現するために、毎日コードを書いています。

今回はその取り組みの中で、私が事業の知識を深堀りして、サービスの品質を改善していった話をします。技術的な話は少ないかもしれませんが、エンジニアとしてよりよいサービスをつくりたい方や、これから事業やサービスの運営に関わる仕事をしてみたい人の参考になれば幸いです。

今回話す「事業知識を深堀りする」という言葉の意味ですが、事業やサービスで扱う商品だったり、業界やマーケティングの知識、いわゆるドメイン知識を開発に取り入れていくことを指します。

なぜ事業知識を深掘りするようになったのか

エンジニアになる前までは、事務系の仕事をしていました。事業やサービスの開発により深く関わりたい思いで事務職からエンジニアに職種を変え、転職しました。最初に客先常駐のエンジニアとして勤務していましたが、そこでは仕様がある程度決まっている状態で開発していたので、ドメイン知識についてそこまで深く考えたことはありませんでした。

エイチームフィナジーに転職して、事業会社のエンジニアとしてインハウスで開発するようになったことで、自分の役割や仕事で関わる人たちなど、環境が大きく変わりました。これまでは開発者だけでチームを組んでいましたが、さまざまな職種の方々と直接関わりを持つようになって、実際サービスを提案したりするようにもなったんです。

今のチームにジョインして、最初はこれまで通り、イチ開発者としてコードを書いて事業にコミットしていました。しかし、マーケターやデザイナー、営業などの他の職種の方と一緒にチームで開発していくうちに、少しずつ自分の視野も広がっていきました。これまでは考える必要がなかったようなサービスの根本的な仕様のことなどを、よりよい機能で実現するためにはどうすればいいか、考えるようになったんです。

そこから事業知識をどんどん掘り下げて開発に取り入れていくようになりました。自分が事業に対してコミットできる範囲も増えていき、サービス品質を向上させる開発にもつながっています。

事業の知識がなく、ソースコードがどんどん複雑化

ここまでのお話だけだと「そんなの当たり前じゃん」と思われるかもしれないですけど、私はけっこうこの変化に苦労したと思ったので、実際にどのようにつまずいて、どのように変化していったのかを話します。

私が住宅ローンというサービスを扱っているチームにアサインされたころの頭の中は、常にこんがらがっていました。

業界特有の専門知識が多く、それぞれの言葉の意味もあまりわからなくて難しい。それぞれの言葉の関連性もわかっていない状態でした。言葉以外にもデータとかも扱っているのでとても複雑です。

住宅ローンの知識以外にもWebマーケティングやSEOの知識も必要でしたが、当時はその知識もあまりない状態。覚えるべきことがたくさんあって、すぐにこの事業やサービスについて理解するのが難しい状況でした。

散らばった情報をうまく整理できていない状態でデータを扱うと、さまざまな問題が起こります。カラムの単位が抽象的だったり、1つのカラムで複数の情報が入っているとか。あとは類似するようなデータがマスターデータに大量にできていて必要なデータが足りないとか、そういうことが起きていたんじゃないかと思います。

このような状態になると、データを扱うことも難しくなります。現実のサービスの状態とも乖離しているので、検索がうまくできなかったり、クライアント企業から来た要望や仕様に沿ったデータを提供できないという事態が発生します。また表示するデータの加工が必要になって、ソースコードがどんどん複雑化することもあると思います。

このような問題を気づかずに放置しておくと、日々の開発の中で少しずつ負債を増やしていく結果となります。

理解が浅いために発生したトラブル

実際、私は理解が浅い状態で開発をしていました。そのときに起きたトラブルとして、1つ目に、類似するような専門用語の変数名の命名がうまくできなくて、何を指しているかわからないものが多数発生しました。同じ変数名なのに、例えばrate_typeという変数名があって「こっちが扱っているrate_typeとあっちで扱っているrate_type、なんか中身が違うぞ？」みたいな何を指しているのかわからないものがたくさん発生していました。

2つ目に、データの持ち方がけっこう複雑なので表示の出し分けに柔軟に対応できず、商品ごとに特化したメソッドをつくらざるを得ない状況になってしまいました。「このメソッドは何のためにあるんだろう？」みたいなものが複数あって。

3つ目は、そんな内部的に複雑な設計になっているので、1行コードを書くたびに1行負債が生まれる状態でした。簡単な表示修正のために多くの無駄な工数が発生し、本来行うべき機能改修や追加の作業がどんどん遅れていきました。

こうなると、最終的に私以外誰も手を入れられなくなる状態になってしまいます。

知識を手に入れる

あるとき「このままではこのサービスを負の遺産の塊にしてしまうな」ということに気づき、意を決して本格的に住宅ローンについて学びました。そこで、住宅ローンアドバイザーという資格も取ってみました。

実際に掘り下げて理解を進めてみると、頭の中がすごく整理された状態になりました。理解が進んだ状態になると、今までの理解が間違っていたなとか、抽象的過ぎたなということに気づきました。

現実のサービスの状態と同じように適切にデータを扱えていれば、現実で発生するような要望とかやりたいことにもすぐ対応できます。あとは検索や表示も簡単にできるので、ソースコードも読みやすく書けます。

実際にこのように理解が進んでから、これまで自分で書いてきたソースコードを振り返ってみると、今まで書いていたコードが泥沼に見えるようになりました（笑）。

今は、泥をがんばって除去して、水を入れ直しているような状態です。まだまだ汚染されている場所も多いので、これからもがんばってリファクタリングをしたいと思います。

不幸中の幸いで、ある程度テストはいっぱい書いていたのでリファクタリングがそこまで苦な作業にはなりませんでした。テストを書くことを習慣化するのは大事だと心から思いました。

扱うサービスを深く知る

実際に自分で事業知識を深堀りしてみて、新たな強みも得られたと思います。

扱うサービスについて詳しくなることで、サービスの改善提案として「もっとこうしたらいいんじゃないか」という本質的なものも提案できるようになりました。また、活発に議論に参加できるので、チーム内のコミュニケーションも非常に円滑にとれるようになりました。

事業知識に詳しい状態だと、これまで話したとおりコードもきれいに書けるようになるので、サービスの品質向上に貢献できるようになったと思います。

事業知識を深堀りする上で意識していること

最後に、事業知識の深堀りをする上で私が意識していることを話します。まず、「散らばった情報の言葉とか要素とか関連性を整理していくこと」が大事だと思っています。

そのあとで、「それぞれの言葉の意味に疑問を持って調べる」ことを徹底しています。普段使っている言葉の意味とその業界の中で使っている言葉の意味は、少しニュアンスが違っていることもあるので、できるだけ調べるようにしています。

また、自分だけが理解するんじゃなくて「チーム内での理解を揃えて共通言語をつくる」ことも非常に重要で、チーム内のコミュニケーションから質のいいサービスが生まれると私は考えています。実際に私のチームでも新機能や新サービスはみんなで活発に議論をして決めていて。

今回の話ではサービスの品質改善に重きを置いて話をしましたけど、事業知識を深堀りすることが、サービスの機能改善にもつながっていくと思っています。

最後になりましたが、エンジニアが新しい技術トレンドを日々追っていくなかで事業知識なども深堀りすることは大変。でも深い事業知識に踏み込んでいけば、新しい視点からよりよいサービスに改善できると私は思っています。サービスに対する新しい価値観も身につくと思うので、どんどん深堀りして世の中によいサービスを生み出していきましょう。

以上になります。ありがとうございました。

（会場拍手）

ドメインの理解がない状態でのテストは助けになったか？

司会者：どうもありがとうございました。エンジニア、プログラマの仕事というのは場所が変われば大きく変わることがよくわかりました。では、質問のある方、どうぞ手を挙げてください。

質問者：最後のほうに「テストを書いていてリファクタリングできてよかった」みたいな話がありましたが、ドメインについての理解が進まない状態で書いたテストで、とくに助けになったとか、逆にドメインへの理解ある今だからこそ「あのときのテストはこう書いたほうがよかった」ものってありますか？

Kubota：難しいんですけど、複雑化していたときってムダなメソッドがいっぱいできていました。それぞれのメソッドが何の引数を受け取って何を返すかということが、テストをすることによって担保されていたので、それさえ守っていればきれいにできる状態だったというところです。

質問者：ありがとうございます。では、「こういうインターフェースで、この引数では、こういう返り値が返るよ」と思って、ドメインに照らし合わせてみると間違っていた。そこでメソッド自体を変える必要になった場合はどうしますか？

Kubota：そうですね。そういうところは全部いったん見直して書き直すようにしています。

質問者：ありがとうございました。

司会者：時間になりましたので、終わりたいと思います。Kubotaさん、どうもありがとうございました。

Kubota：ありがとうございました。

（会場拍手）