エンジニアが事業やユーザーを理解することの意義

どーも関西でエンジニアをしている人です。
最近DDD(業務の構造をコードに反映して保守しやすくする手法)を同僚と輪読会して、学び、特にシステムが存在する意義や付き合い方について発見があったので話したいと思います。


システムは何のために作られるか?

エンジニアは技術を使ってシステムやサービスを構築することが仕事ですが、その過程で避けられないのが、目的の明確化です。つまり何のデータを保存、変更、抽出しどういった画面に出力するかです。

そして、この目的の明確化の質はプログラムの質も左右します。
目的が曖昧な場合は、コードレベルでもその曖昧さを表現しないといけません。その結果、検証項目や考慮漏れが増え未定義の領域が拡散していき、思わぬエラーを引き起こしてしまいます。

なので、事業やユーザーのワークフローの解像度をできるだけ高めることで、それらの曖昧さを排除することは、コードを書きやすくし、後々の保守もやりやすくしてくれます。


ユーザーと開発者の認識は揃えておく

サービスやユーザーのワークフローを理解するために、人にヒアリングしていく必要がありま。そして、必ずぶち当たるのが固有の専門用語です。例えば、

* 客からの問い合わせ = インクエリ
* 離脱率 = スキップ率
* 課金処理 = クレジットカードを入力 + 外部サービスで決済する

といったものです。これらの専門用語はできるだけ収集し、且つ専門用語で会話するべきです。

なぜなら、専門用語にはユーザーが無意識にひとまとめにしている処理などが含まれているので、コードで処理を書くときの単位や順番などを考える参考になります。

また、サービスや事業は常に市場の競争にさらされているので、変化を求められます。そしてそのたびにヒアリングの必要に迫られるので、用語の認識を揃えて会話することは誤解を防ぐことにつながります。

ログの対象が明確になる

ヒアリングを通して、情報がそろってくると処理の単位やタイミングも明確になり、曖昧さをコードで表現しなくてもよくなります。サービスを成長させるために何のデータを保存しておくべきかも明確になってきます。

特に、昨今だとたくさんのデータを持って分析できる状態にしておくことは、施策の検証や企画に大いに役に立つので非常に重要です。

そのために、前もってテーブルの設計や速度などを念頭において設計することができます。

最後に

理想論だと言われそうですが、現在仕事している会社は社内システムの開発の関係でよくユーザーと話すことがあり、上記の重要性は痛感しています。

読んだ本自体も非常に読みやすいものだったので、興味があるエンジニアは読んでみることをお勧めします。

システム設計の原則



この記事が気に入ったらサポートをしてみませんか?