はじめに

社会人生活3年目に突入し現職にも慣れてきたことで、チームのフィーチャー開発でバックエンドエンジニアとしての意見を出し、開発方針に対して判断・責任を持つことが増えてきた。

その中でソフトウェア設計に関する議論で意見をうまく伝えられない機会が何度かあり、スランプのような状態に陥っているので自分の気持ちを整理すべく言語化してみた。

課題に思ったきっかけ

特定の領域の知識がある程度成熟してくると、いわゆる「チョットわかる」状態になってくる。自分の場合はDDD（ソフトウェア設計）に関する領域がこれにあたる。

DDDの目的は「ビジネスドメインをシステムに反映させ、ユーザーのメンタルモデルに寄り添った使いやすいシステムを構築すること」といったように自分は捉えている。（あくまで自分なりの理解を言語化したもの

ある日デザイナー・PdMの方とデザイン初稿を元にしてデザイン要件についての議論をする際に、DDDの境界づけられたコンテキスト（戦略的設計）の考え方が役に立つと思い説明をしたが、自分が話す時間が長くなり議論を長引かせてしまうことがあった。

その後も議論を続けていくと、自分がDDDの用語を説明せずとも似たような考え方に基づいた検討は既にされており、お互いの目的に対してギャップはなかった。

まずやるべきだったのは目的と現状のデザインになった理由を共有することで、DDDの用語を説明することではなかったと反省した。

目的と手段をセットに考えない

この話自体、最初に目的を共有するのは当たり前、に尽きるかもしれない。ただHowの知識に固執してしまうと思考がHowに寄ってしまいやすくなる気がする、ので思考が寄らないような心がけから始めたい。

DDDの境界づけられたコンテキストはあくまで手段でしかない。DDDの目的に対応する考えは職種関係なく持っているかもしれないが、目的と手段をセットにして考えてはいけない。

知識だけでなく手を動かす

関連して最近よく考えるのは知識はあくまで知識でしかないということ。「知識が役に立つ」と考えるのであれば手を動かして何かしらのアウトプットを出すことでわかりやすく伝えたい。

手を動かすことで考えが明確になり、より説得力のある意見を出せることもあるし、要望にフィットせず意見を改めることもある。

まとめ

以上の内容から、「How」の「知識」に固執しないこと。を大事にしたい。

色々書いたが、プロダクト開発においてどんな考え方に基づいてアウトプットを行うか、職種を超えた共通言語があったほうがコミュニケーションが円滑になるので共通言語は欲しい。

とはいえ、DDDはあくまで開発者視点で成熟してきた手段なので、何から何まで他の職種の人に理解してもらうのはやりたくないなあ。などと考えていた。

今日はここまで。