こんにちは、エンジニアの谷口です。 2025年7月から予実管理クラウド「DIGGLE」のアプリケーション開発に従事しています。
先日開発チーム内で「モデリング」をテーマにした社内座談会を開催しました。 参加者はエンジニアリングマネージャー(EM)の北村さん、スクラムマスター(ScM)の上山さん、エンジニア(Eng)の藤田さん、そして私の4名です。
この企画は私の「AIコーディングがこれから先どう発展するにせよ、モデリングはこれからも重要であり続けるだろう、と私は思うけど、チームのみんなはどう思ってるのかな？」という疑問から発したものです。 また、普段は数チームに分かれてリモートワークで仕事を進めており、具体的な業務内容から少し離れた会話が自然発生しづらい環境ではあるので、チームを横断した対話の場を設けることで相互理解を促進したいな、という狙いもありました。
座談会の結果としては、私が思っていた以上に発散的な会になりました。
「何かしらの共通見解にたどり着くこと」よりも「お互いの考えやその違いを理解すること」が目的だったので、会としては成功と言えるでしょう。 本記事では、私が印象的だなと感じた部分を中心に、会の内容をかいつまんで紹介します。
「モデル/モデリング」の定義が人によって異なる
まず「モデリング」という活動の捉え方、「モデル」に対する焦点の置き方が、人によってかなり異なりました。 以下、各参加者のスタンスをよく表しているなと感じた発言を引用します。
藤田(Eng)： 自分はコードを書くとき、自分の中のモデルが前面に出るようなコードを書きたいって思ってます。ただ、実装上の都合でそれを引っ込めなきゃいけない状況もあって、そのせめぎ合いですね。
谷口(Eng)： 自分は「ユーザーに見せる抽象概念」に焦点を置きたいなって思ってます。開発者同士で話すとデータモデルの話に流れがちで、開発者以外の方には「モデル/モデリング」という語を説明なしには使えないので、そもそも議論の前提を揃えるのにハードルがありますね。
上山(ScM)： モデリングって、自分としてはPdMとかデザイナーとか、職種を越えて「概念をすり合わせるツール」として認識してるんだなって改めて気づきました。開発者の中では無意識にやっていても、コミュニケーションツールとしては使えてないなと感じました。
北村(EM)： 私はモデリングには開発プロセスの一部という側面の他に「投資」の側面があると思っていて。「来月潰れるかもしれないスタートアップはモデリングに時間をかける余裕はないよね」と。作るときに関係者間で握るために作ったもので今後も役に立ちそうなものもあるのに、今はそれを未来の人のための『構成物』として整理して残す運動はなく、構成物を探せばあるけど、見つけやすい、手に入れやすいまではいってない気がします。
これらは参加者個人の趣向や考え方の傾向から来る違いというよりも、エンジニア組織の体制上の役割・立場から来る違いが大きそうでした。 それぞれの観点を深掘りするとそれだけでまた座談会が開催できるなーと思いつつ、今回はその違いを相互に認識するに留まりました。
関係者間の共通語彙としてのモデル
前節で上山さんが触れているように、モデルには「関係者間(開発者だけに留まらない)の共通語彙」という側面があります。 これについて、藤田さんと北村さんの以下のやりとりが印象的だったので取り上げます。
藤田(Eng)： 「論理削除されたユーザー」とか「招待中で本登録してないユーザー」とか、システム上に統一された名前がないんですよね。実装上で属性で判断せざるを得なくて、語彙がない分、扱いが一貫しづらいところはあります。
北村(EM)： 確かに。ただ、そのユーザ周りのモデリングを一新して解消することへの期待は、開発の優先度が変わるほどには高まっていない認識ではいます。困り度合いが少ないものは、一旦判断や対応を先送りにすることは穏当な判断だと思います。ただ、無意識な先送りは事故の元だから「今は先送りでいいよね」という明示的な合意はしておきたいですね。
藤田さんの挙げてくれた課題は、「ユーザーの状態遷移の設計があいまい」という風にも、「別の概念とユーザーの状態が混ざってしまっている」という風にも解釈でき、どちらのモデルが現状では適切なのか？を整理するためには改めて業務フローから振り返ってみる必要があります。そのため結構コストがかかります。 今後ユーザー招待や削除周りの業務フローを大きく見直す予定があるなどでないと、北村さんの指摘通り、費用対効果的にちょっと手を出しづらいです。 北村さんの「困り度合い」という表現は、客観的指標というよりチームの肌感覚による合意形成することを含意しており、今の開発チームのスタンスをよく表しているなあと思いました。
また、DIGGLEの開発プロセスでは、明示的に「モデリング」と銘打った活動はなく「モデル」という言葉も普段ほとんど使われませんが、振り返ってみると暗黙にモデリングに類する活動は行っていて、それで開発プロセスとしては上手く回っているんだな、ということに気づきました。
上山(ScM)： 新しい「配賦」の機能をつくるときとか、いきなり「モデリングしよう！」って抽象から入ったわけじゃなくて。顧客の強烈なペイン(課題)が見えていて、ユースケースを洗い出して、そこから結果的にモデルに抽象化していった覚えがあります。
谷口(Eng)： たしかにそうですね。私は別チームなのでそれを傍から見ていただけなんですが、開発前の段階で、PdM/Des/Eng全員でFigmaを使って概念や仕様のすり合わせる会をやっていて、それが結構ワークしていそうだな、と思っていました。「ユーザへ提供する価値」にフォーカスした結果、自然とよいプロセスが選ばれてるかもしれませんね。
コアな部分ほどモデリングしたいが難易度も高い
DIGGLEにおいて「損益(PL)分析」や「差異分析」のコードは最も価値を生み出すコア機能なため、変更難易度が高い部分になっています。
谷口(Eng)： 一番よくしていきたいコアな価値を提供してる部分の変更難易度が高いのは、ユーザーが分析軸を自由に設定できる抽象度の高さがありますけど、それがゆえにモデルの理解が難しいのか、抽象度の高さとは別に、実はモデルが歪んでて不要な複雑さを産んでるのか、まだあまりわからないんですよね。
藤田(Eng)： そうですね。その高い抽象度に対して、さらに大量の数字を高速に処理するパフォーマンスを出すために、特別なデータ構造やキャッシュがコード内に存在していて、これらを整理して「理想的なモデル」を模索するのはめちゃくちゃ大変になるから、デリバリーがあまり遅くならないように既存実装を優先せざるを得ないトレードオフがあります。
コアな部分ほど、抽象度の高さ、コアロジックの複雑さ、デグレードに対する厳しさ、迅速なデリバリーへの期待……などなどの要素が重なるため、モデリングとリファクタリングを通じて開発者の理解とコードの整理を進めていきたいのに、なかなか手を出すのが難しいというジレンマがあります。 DIGGLEの実行基盤は「オンタイム中に小規模なリリースを随時行い、問題を検知した場合は即時切り戻す」のが可能な仕組みが整っており、コードの問題は細かく分割することで少しずつ前進していける、という手ごたえがありますが、モデルの問題は認識すること自体が非常に難しいな、と個人的には思っています。
モデルとUI
今回の座談会はバックエンドエンジニアが中心だったため、バックエンドに寄った会話が多くなりましたが、「フロントエンドにおけるモデル」というトピックについても少し触れました。
藤田(Eng)： そもそも、フロントエンドのモデリングってあるんですかね？ バックエンドのモデリングについてはよく語られますけど、フロントエンドのモデルって個人的にあんまり聞かないなと思っていて。
谷口(Eng)： 私は、モデリングって理想的には「ユーザーに提示するオブジェクトのモデル(抽象概念)」を作ることだと思っていて、バックエンドのモデルがなるべくそのままUIに出てくるのがいいなーと思ってますね。なのであんまりフロント/バックで分けて考える必要がないかなと。
今回はフロントエンドやデザインに強いメンバーが参加していなかったため深くは掘り下げられませんでしたが、「業務システムであったとしても、CRUDデータモデルを一覧/単票の画面でカットしてユーザーへ提示するようなUIのあり方で本当にいいんだろうか」という問いはここ数年来引きずっているところがあります(谷口個人の関心として)。
おわりに
最後に、座談会参加者4名の感想を掲載して本記事の締めくくりとします。
北村(EM)： 普段の業務とは少し違う視点で、みんなが何を考えて開発に向き合っているのかを知れるよい機会でした。まとまらないこと自体が、モデルやモデリングがカバーしている領域の広さを物語っていて面白かったです。
上山(ScM)： 自分は「概念のすり合わせ」に目が行きがちでしたが、実装や将来の資産という視点に触れ、モデリングの多面性に気づけました。問題空間のモデリング手法ももっとチームで探求していきたいです。
藤田(Eng)： 理想のモデルと、パフォーマンスを優先した現実のコードとの間にある葛藤は、エンジニアの永遠の課題ですね。改めて日々のリファクタリングの重要性を感じました。
谷口(Eng)： コミュニケーションのあり方にも色々ありますが、結局対話に勝るものはないなといつも思います。今後も定期的に開催していきたいです。
このような開発組織のあり方や、技術的な課題解決に興味を持っていただけた方は、ぜひ一度カジュアル面談でお話ししませんか？職種を越えてフラットに対話ができる健全な土台がDIGGLEにはあります。ご連絡をお待ちしております！
