こんにちは、freee会計のプロダクトマネージャー（以下PM）をしております、gokiです。
皆さん、「ドメイン知識」という言葉、聞いたことありますか？
ドメイン知識（英: Domain knowledge）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。
freee会計での開発現場で例示すると「確定申告のプロダクトを作るには、開発技術だけでなくそもそも確定申告業務の理解というドメイン知識が必要だよね」みたいな使われ方をします。
freeeはスモールビジネスの皆さんのバックオフィス業務を改善するプロダクトを作っているので、このドメイン知識が開発においても必要な場面が多いです。
そこで、今回はドメイン知識が必要な開発をどのように進めるか、というコツをPM目線でご紹介しようと思います。
同じような開発に携わる方の参考になれば幸いです。
高度なドメイン知識を扱うことも
まず初めに、そもそもドメイン知識といってもどの程度の難易度のものなのか、直近で開発に携わりリリースされた「固定資産の複数台帳機能」「固定資産の減損会計機能」を例にご紹介します。
※いきなり難しい言葉が並びますが、適宜読み飛ばしてお進みください。
まず、1つめの複数台帳機能の方は、「固定資産を費用計上する際に、企業が算出した結果と税法を基準に算出した結果が異なる場合に、それぞれ別に管理する」というもので、
会計の世界の代表的な試験である日商簿記検定でいえば、2級で出題されるような内容です。
日商簿記2級：高度な商業簿記・工業簿記（原価計算を含む）を修得し、財務諸表の数字から経営内容を把握できるなど、企業活動や会計実務をふまえ適切な処理や分析を行える。
2つめの固定資産の減損会計機能の方は「固定資産に投資したが、その資産の収益性が低下したことで投資額の回収が見込めなくなった場合に、その資産の回収可能額まで帳簿上の価額を引き下げる」というもので、
これは日商簿記検定でいえば、1級で出題されるような内容に当てはまります。
日商簿記1級：極めて高度な商業簿記・会計学・工業簿記・原価計算を修得し、会計基準や会社法、財務諸表等規則などの企業会計に関する法規を踏まえて、経営管理や経営分析を行える。
と、要するにドメイン知識といっても「その領域を専門に勉強してる人でも割と難しい内容」を扱うこともあるということです。
しかしながら、開発メンバーは初期段階ではその知識をほとんど持っていません。
そんな中で、どのように開発を進めていけば良いのでしょうか？
その1 PMはとにかく勉強
まずはとにもかくにも、企画を作るPMのドメイン知識の習得が必要です。
また、ドメイン知識といっても、私は「お客様の業務の理解」と「関連する法令等の理解」の2種類に大別されると思っています。
このうち、前者の業務理解については、とにかく価値を届けたい現場へと足を運ぶことが手っ取り早いです。
バックオフィス業務については、だいたい20の現場を見させてもらい、社内のセールス・サポートチームに考えの壁打ちすれば、どの企業にも共通する業務の輪郭が見えてくるでしょう。
一方で後者の法令に関する方は少し事情が変わります。 法令や公的に定められた基準については、お客様もチェックを外部の専門家に任せていて詳しくなかったり、社内でも相談できる人は数が限られていたりします。そのため、PM自身で関連法令等を理解し、責任をもって企画を作る必要があるためです。
ここの学習に関してはコツというよりもう勉強するしかないのですが、強いて言うなら私はいつもだいたい次の手順で理解を進めています。
- 関連法令・基準を洗い出す（例：法人税法 第31条、固定資産の減損に係る会計基準の適用指針等）
- 関連法令・基準がどんな目的を達成しようとしているのか理解する（例：正しい納税、株主保護etc）
特に2が大事で、開発を進めていくと「法令・基準では明記されていないもののプログラム上は発生する」ケースが生まれたりします。 例えば、小数点以下の端数処理について条文には言及がされていないが、計算過程上発生してしまう、などですね。
その場合もちろん専門家の意見なども聞きますが、最終的にはPMが関連法令・基準をどう解釈するか決定することになります。
その時にサイコロを振って決めるのではなく、「そもそもこの法令・基準は〇〇の目的で作られているから、こう解釈する」というのが整理されていると、対外的に説明が必要になった場合にも役立ちますし、なにより似たような事象が発生した際に、同じ解釈を使うことでプロダクトとしての一貫性が保たれます。
その2 エンジニア・デザインチーム・QAとの勉強会をしよう
企画が固まり開発が始まるとき、必ず「開発メンバー向けの勉強会」を実施するようにしています。
当たり前ですが開発メンバーは技術の専門家であり、ドメイン知識はスタート時点では不足していますので、これをPMからインプットする目的で実施します。freeeでは開発はエンジニア・UI/UXデザイン・QAを中心に進みますので、このメンバーが対象です。
この勉強会を実施する上で、私が特に大事にしていることは「できるだけ低レイヤーから話す」ということです。
低レイヤーと言っているのは、今から作る機能に直接は関係ないけども、なぜその機能が必要とされているのか、という背景部分になります。ユーザーをとりまく外部/内部環境・ステークホルダー・そして歴史についてのドメイン知識です。
ちょっとわかりづらいので、皆さんもよく聞く「確定申告」の機能を例に、低レイヤーのドメイン知識の例示をしてみます。
- 日本にはいろいろ税金がある。消費したら消費税、相続したら相続税。そして稼いだら稼いだ分払う「所得税」
- 「所得」というのは事業的にいえば利益のことで、売上から経費を差し引いた額のこと。
- 確定申告とは、この所得税を納めるにあたり「私は今年いくら所得がありましたよ、だからこれだけ税金を払います」と国に対して提出する書類。個人事業主も法人も両方必要で、会社員なら”源泉徴収”という形で毎月給与から引かれてるので申告は不要。
- 税金の払い方には、申告と賦課（ふか）方式がある。確定申告はその名のとおり「申告方式」で、納税者が自分で納付すべき税額を正しく計算し、それに基づいて納付するという制度で、税額を税務官庁に勝手に決められることがないので、より民主的な方式と言える。所得税は戦後賦課方式から申告方式に変わった。
どうでしょうか、なんとなく「確定申告」の解像度が上がったように思いませんか。 これらは、一見すると直接関係がなさそうに見えますが、私は非常に大事なことだと思ってます。
UI/UXデザイナーがジャーニーマップを描きやすいように。QAがいろんなテストケースを思いつけるように。エンジニアが細かい挙動を自分達で考えて実装できるように。
そしてなにより、それぞれ自分の技術が、これから社会にどんなインパクトを与えられるのかイメージして、ワクワクできるように、という想いを込めています。
最初のうちは試験的にやっていましたが、やはりこの勉強会があるかないかで進み方が大きく違うので、ドメイン知識が重要な開発では必ず実施するようにしています。
開発メンバーが「何を作っているのか、誰のどんな課題のために作ってるかわからん」っていう状態は、なんとしても避けたいですね。
その3 デイリーミーティングは超有用
これはエンジニア・QA側から提案を受けて実施していたものです。
毎日最大30分、PMと開発メンバーで顔をあわせて困ってることや疑問点をぶつけ合います。 高度なドメイン知識が必要な開発は、実装も同時に複雑になりがちですが、この会のおかげでメンバー間での認識のすれ違いが早期に解消され手戻りをだいぶ抑えることができました。
実施する上で個人的に大事だと思ったポイントは以下の3点です
必ず内容を記録する。スプレッドシートや議事録に「質問・疑問の内容」「回答」を記載するようにして、後から確認できるようにする。
PM・エンジニア・UI/UXデザイナー・QA全員が参加する。たとえばエンジニアからPMに対する質問が、デザインチームの新しい疑問につながったり、QAが参考になる情報になったりする。
話すことがなくなったら即解散。そもそも議題がない日は会をスキップ。開発メンバーの作業時間を無駄にしない。
また、デイリーミーティングにQAメンバーを入れるのは開発が終盤になってから、という考え方もあると思います。私の関わるプロジェクトでは、QAの方からの提案もあり、仕様を決めて開発が始まる段階から実施することが多かったです。そして実際これはとてもうまく機能していました。
PMがQAを見ていての感想になりますが、やはり開発の背景を知っていたほうが「どこが技術的に困難があった」「PMはどのユースケースが一番利用されると考えているか」等がわかり、どこを重点的にテストすべきかの判断材料にできていたかと思います。
また、freeeではQAを実装できた部分からアジャイル的に実施することを試みていました。 この方式では、QAリソースが最後にだけ偏ることを防いだり、バグが見つかった時にエンジニアが実装したてなので対応が早い、などの効果があります。そのアジャイル的なQAを実施するためにも、開発進捗をリアルタイムで把握できるメリットがデイリーMTGにはあったと感じました。
最後に。結局メンバーに恵まれていた
と、ここまで、さも私が意図的に進めましたという風で書きましたが、結局は人に恵まれたことがなによりも大きいです。 恵まれた、というのは技術的にもそうですが、人柄的な意味でもです。
例えばですが、「その2 エンジニア・デザインチーム・QAとの勉強会をしよう」で書かせてもらった勉強会については、普通だと「ほーん、あんまり興味ないや」ってなってもおかしくない内容です。 それでも、freeeの開発メンバーは好奇心とユーザー価値（freeeでは”マジ価値”といいます）への探究心がとても高いので、どんどんドメイン知識を吸収してくれます。
全員が前のめりで、たとえ難しいドメインの開発であったとしても、楽しみながら、お互いをリスペクトしながら開発を進めてくれる、PMにとってこれほど頼もしいことはありません。
なので、宣伝っぽくなってしまいますが、たとえ会計などのバックオフィス業務に詳しくなかったとしても、好奇心が旺盛でユーザーにとって価値のあるものを作りたい、という人がいましたら、ぜひfreeeで一緒に働くことを検討してみてください。
エンジニアでも、プロダクトデザインでも、QAでもです。 その前向きさが、きっと新しいfreeeの価値、すなわち日本のスモールビジネスの活力につながると確信しています。
