フォトラクションでは先日、地域医療連携のDXに取り組むスタートアップのメダップ（以下メダップ）とエンジニア座談会を実施しました。お互いにバーティカルSaaSに取り組む両社の共通の課題やそれに対するアプローチ、生産性の高い開発組織等について話されました。本記事では座談会のイベントレポートをお届けします。
地域医療連携という領域でDXに取り組むスタートアップ。
特に急性期病院と呼ばれるいわゆる病院は収益を最大化させるためにその医療圏のクリニックからの患者紹介を営業活動として実施するが、そのための顧客管理システム（foroCRM）を開発し、提供している。
フォトラクションに関しては以下の記事をご覧ください。
メダップ
馬場（CTO）、小玉（エンジニア）
フォトラクション
黒田（テクノロジーサービス部長）、南風原（エンジニア）、脇田（エンジニア）、野田（採用責任者）
馬場（メダップ）
本日はどうぞよろしくおねがいします！
メダップCTOの馬場さん
最初のトピックですが、メダップの地域医療連携やフォトラクションさんの建設の領域って普段の生活ではなかなか接する機会がないので、新しく入ってきたメンバーがどうやってドメインの知識や業務プロセスにキャッチアップしているか気になります。
ユーザーの業務や心理の理解をオンボーディングや教育の中に組み込んでいるのか等、工夫されている事があればお聞かせいただきたいです。
黒田（フォトラクション）
おっしゃる通り建設の業務プロセスってエンジニアはなかなか知る機会もないですし、知ろうとしても知る術がないというのが実情です。
フォトラクションテクノロジー・サービス部長の黒田さん
ただフォトラクションの場合は代表の中島もそうですし、現場出身でドメイン知識を豊富に持った人間が営業やPMにたくさんいるんです。なので、彼らがユーザーストーリーを組み立てて開発に落とすというプロセスになっています。
一方でこのやり方には課題もあって、建設のドメイン知識は豊富にある反面プロダクト開発の知見は専門的にPMを経験されてきた方と比較すると歴も浅いので、今後開発体制を強化していく中では、専門的にPMの経験を積んできた方に入っていただけると心強いですね。
馬場（メダップ）
PMの知識も建設の知識も完璧に備えている人なんて果たして世の中に存在するのかって感じですもんね（笑）
小玉（メダップ）
ドメイン知識のキャッチアップという意味では、メダップではエンジニアがセールスの商談に参加して、セールスが実際の顧客に対してどんな売り文句で販売しているかを肌で感じるようにしています。フォトラクションさんではそういったことはやられてましたか？
メダップの小玉さん
黒田（フォトラクション）
フォトラクションでもアーリーフェイズだった時は、エンジニアも展示会に駆り出されて、見込み顧客に対して自分の口でプロダクトを説明する、みたいなことはよくありました。
いまのフェイズではそういう機会は減ってしまっていて定常的に実施できているわけではありませんが、時々CSの操作説明会の際に同席してもらったり、ときには実際の建設の現場に連れて行ってもらったりもします。
どのようにプロダクトが使われているのかをエンジニア自身がしっかりイメージできるかどうかは非常に重要なので、意識的に機会を作っていきたいところです。
馬場 （メダップ）
エンジニアがサービスの使われ方を理解して開発できているかどうかってすごく大事ですよね。
開発するときって一つの機能に特化して開発するので、どうしても機能間のつながりみたいなものって失われがちじゃないですか。
セールスやCSの人は顧客に話す時、機能単位ではなくプロダクトとして話すので話すので文脈があって、それを知っていることは非常に重要だと思っています。
私は週に一回くらい商談同席する機会があるのですが、その商談で得た気づきをどうやってエンジニアに理解してもらうかって難しいなと考えた結果、エンジニアが直接営業同行して理解するのが一番いいという結論になりました。
なのでエンジニアは入社したら必ず商談に同行する、その後も定期で参加するという決まりになっています。
あとは定期的にCSのリーダーからユーザー事例勉強会というのをやってもらっていて、この機能がこういう風にユーザーに使ってもらえててよかったとかを教えてもらったり、CSにたくさん質問を投げかけて答えてもらうという会を実施しています。
その中で機能間のつながりや、ユーザーの「ここ見た後にここ見に行くんだ」みたいな気づきの部分を得られる機会を大切にしていますね。
馬場（メダップ）
フォトラクションさん位の組織規模（2021年10月現在で60名強）になってくると、部署間の連携に課題が出てきそうだなと思うのですが、特にリモートワークで部署を超えたコミュニケーションって上手く出来きてますか？
南風原（フォトラクション）
なかなか難しいですね。以前は出社していて隣の島のCSの方の電話の声が聞こえてきたりとか、そういう部分でキャッチアップできていた面もあったのですが、リモートになってからは無くなってしまいました。
フォトラクションの南風原さん
野田（フォトラクション）
組織の縦割りは結構課題として顕著になってきていますね。
フォトラクションは組織のエンゲージメントスコアをWevoxを使って計測しているんですが、カスタマーサポートみたいに顧客と直接接している人たちはサービスへの誇りの数値がかなり高いんですよ。一方でエンジニアやPMは相対的に低い。
脇田（フォトラクション）
フィードバックとしては、不具合の報告とかのほうが接する回数が多いので、そういう気持ちになりやすいのはありますよね。
フォトラクションの脇田さん
野田（フォトラクション）
本当は顧客はサービスに満足しているのに、エンジニアまでそれがなかなか伝わってなくて、自信が持てていないみたいな感じですよね。
なので、先日の全社の締め会の時にCSから顧客の声を全社にフィードバックする企画を用意して実施したのですが、結構好評でした。
フォトラクションって5大ゼネコンの内4社が利用していたりするんですが、エンジニアの中にはそういう基本的な情報も知る機会がない人もいたりして、ただその事実を知るだけで「意外とフォトラクションってすごいかも」みたいなコメントを感想としてもらえたり。
すでにそういう意識的なコミュニケーションが必要なフェーズに差し掛かっているんだなと感じましたね。
馬場（メダップ）
メダップではSlackで意識的にコミュニケーションとるようにしています。
新しい機能をリリースするとSlackで@hereをつけて投稿するんですが、その後すぐCSから「ユーザーからこういう反応があったよ」とフィードバックがもらえるような感じで、それでテンション上がったりしますね。
セールスやCSが自信を持って売っている、紹介している様子を見るだけで結構自信につながったりするので、その雰囲気を見るためだけに出社するのもありだなと思ったりしますね。
黒田（フォトラクション）
メダップさんの開発体制についてもお聞きしたいんですが、プロダクト開発を進めていく上でどのようにして優先順位を決めたりロードマップを引くようにされていますか？
馬場（メダップ）
こちらの図がメダップが開発に入るまでの行程を図解したもので、いわゆるトリプルトラックアジャイルという方式を取っています。
プロブレムディスカバリー、ソリューションディスカバリー、デリバリーっていう概念があって、プロブレムディスカバリーは、何を作るのか発見する課題発見のサイクル。
ソリューションディスカバリーはその課題をどうやって解決するか、そしてデリバリーはどう開発していくかという話なんですが、そこに落とす時に事業戦略から落ちてくるもの、技術戦略から落ちてくるもの、そしてユーザーの声から落ちてくるものという3パターンがあって、それらを開発のロードマップに乗せていきます。
事業責任者や開発責任者、CS責任者やPdMが集まって各立場からの意見をぶつける場として開発バックログ・リファインメントというイベントを月次で開催していて、ここでロードマップの組み換えなどが発生します。
ここで作ったロードマップから、今度は開発のバックログ、つまり開発の単位に落としていきます。
カンバンで管理するようにしているのでカンバンに落として、そこからデザイナーとPdMが主体になってユーザーインタビューなどを通して要件定義書のレベルまで落としていき、要件定義書まで落ちたら開発の準備が完了なので、開発チームに引き渡して開発を進めてもらうというフローです。
まとめると、大きな流れのロードマップを事業責任者や各ステークホルダーと一緒に月次ですり合わせて、そこから落ちてきたバックログはPdMに権限を持たせて優先順位を決めて開発しています。バックログの見直しは週次です。
野田（フォトラクション）
月次のリファインメントはディビジョンマネージャーが集まってやるとのことだったのですが、マネージャーから実際に手を動かすメンバーへの說明と合意形成の部分も非常に重要じゃないですか。その部分はどうされていますか？
馬場（メダップ）
まだ取り組み途中の部分もあるのですが、会社として四半期の目標を掲げて、三ヶ月毎に追うものを明確にして全体合意をとり、それがより具体的なものになったのが開発ロードマップなので、大きな方向性はすでに合意を取られているので根本が覆ることは基本的にはなく、その方向性に沿って說明をして納得してもらうイメージです。
馬場（メダップ）
また、開発としてもう一つ大事にしているのが、このバックログを決める時に、バックログアイテムにオーナー制をを導入していて、バックログアイテムをリリースに持っていくまでの全責任をオーナーが持ちます。このオーナーはメンバーレイヤーのエンジニアが3人で同時にやっています。なので同時に3つの機能開発を進めることが可能です。
黒田（フォトラクション）
PdMとオーナー、オーナーとメンバー間の連携が非常に重要そうですね。
馬場（メダップ）
はい、なのでまずオーナーが自分の言葉で何故この機能開発をする必要があるのかを語れるくらいにPdMから引き継ぎをします。
その後でその開発アイテムのオーナーがメンバーを集合させて、より開発寄りの用語で「なぜやるのか」を語るようにしています。
メンバーからしても、エンジニアから「こういう風にやろう」と伝えられるので、しっかりエンゲージメントが上がって良い形で開発に入っていけています。
小玉（メダップ）
全体合意を取るという意味では、メダップではバーチャルオフィスツールを導入していて、経営陣が優先順位を決めている会議をオープンな場でやっているのですが、これが効果的に感じています。
バーチャルオフィス上で近くに立ち聞きしにいくというか、ラジオ代わりに聞きながら仕事をすることで、経営陣の考えが自然と刷りこまれている感じになっています。毎週何処かで会社の方向性について耳にしているのでなにか発表があっても違和感なく理解できますね。
僕は北海道に住んでいて物理的に出社できないため、バーチャルオフィスに住もうという気持ちでずっとバーチャルオフィス上にいます。
そこにいるとCSの人とも知り合いというか、毎日挨拶する感じになるんですよね。今日も先ほど「このあとフォトラクションさんとこういう会やるんですよ」みたいな話をして、向こうも「今日この後大事なMTGで緊張してるんですよ」みたいな話をしてました。
そういう情報交換をしている中で、これから作ろうとしているプロダクトの話とかもしておいて、自然且つ緩やかに多方面から情報が伝達されている状態ができて自然と合意形成ができる側面もあります。
黒田（フォトラクション）
オーナーはある程度固定でやるんですか？
小玉（メダップ）
今だと正社員のエンジニアは馬場さん含めて4人なので、正社員は全員オーナーをしていて、業務委託のエンジニアさんとタッグを組んで進めるような形を取っていますね。
馬場（メダップ）
メダップの開発はかなり密なコミュニケーションが必要なフローだと思っていて、どうしてもオーナーはフルタイムで入れるエンジニアに限られてくると思っています。
自分が参加しない開発のキックオフとかにも必ず招待が来て参加する必要があるので、今の自分の手元の開発にだけ集中したいんだという人には合わないと思います。あくまでチームで如何にデリバリしていくかというところに振り切っていますからね。
南風原（フォトラクション）
次の質問なのですが、フォトラクションは案件ごとにPMやエンジニアがアサインされて小さいチームを組んでそれぞれで案件を開発をしているんですが、結果的に開発チーム全体で開発をするということが少なくなってきています。エンジニア同士の繋がりが薄くなってしまっているのでメダップさんがどのように開発しているのか知りたいです。
馬場（メダップ）
開発チームの規模の違いもあると思いますが、チーム開発という意味では一週間に一回のスプリントを全員でやっていまして、そこで一体感の醸成をしつつやるべきことの洗い出しとその週の目標を設定して、みんなで共通の目標を追うようにしています。
共通の目標を追えるようにケイパビリティモデルという組織構築のやり方を採用しているのですが、これは現状の自分たちのパフォーマンスを可視化するためのモデルで、1スプリントでどれだけのポイントを消化できているかだったりとか、更に詳細に緊急対応やサポートタスクにどれくらいのポイントを費やしているかだったりとか、ありとあらゆる指標を計測して管理しています。
各指標ごとに目標値を設定していて、目標値との差分を出して、この差分ってどうやって埋められるんだっけっていうのを組織面と技術面の両方から考えていくようにしています。
例えば、開発パフォーマンス確認として現在の平均のリードタイムが0.685ptで、目標が0.6なのですが、その差分の0.85ptはコミュニケーションの問題なのか、開発の生産性の問題でCIの時間を短くしていかないといけないのか等みんなで徹底的に洗い出して議論すると言った感じです。
このように、開発組織全体として追う指標を設定することで、開発するものが分かれたとしても全員が同じ目標を終えるようにしています。
メダップのKPTでは良い面、課題ともにたくさんの反省がでる
結果的に、KPTの振り返りではすごい数のKeepやProblemが出るんですが、これはわかりやすく現状把握できているので、差分に対して何をすべきかが考えやすいんだと思います。
馬場（メダップ）
日々開発する機能毎の振り返りだけではどうしても停滞してくるので、スプリントとは別に月次で分科会というのをやるようにしています。分科会とは、技術軸で開発チームの生産性を上げるような取り組みです。
フロントエンドの分科会、バックエンドの分科会という形で実施するのですが、フロントエンドであればフロントエンドの観点で生産性を上げるためには何ができるだろうかという話をして、施策に落として技術戦略に入れて、ロードマップに落とし、バックエンド目線で全く同じことをやります。
まとめると、まずはみんなで共通して追える指標を定めること。そしてそれを組織軸で解決していけるようにするのがスプリントで、技術軸で解決するために分科会を月次でやっているという感じですね。
黒田（フォトラクション）
技術負債との向き合い方についても聞きたいのですが、どうやって開発のフローの中に負債の解消を取り入れていますか？
馬場（メダップ）
技術負債に関しても先程のケイパビリティの指標をベースに経営陣と会話していて、この技術負債を解消することによって、例えば半年後のケイパビリティ指標が達成されるのであればやるべきだよね、というようなコミュニケーションをしています。
だいたい時間軸としては1年位先までの時間軸で話していますね。
南風原（フォトラクション）
チーム開発にすごく力を入れられているんですね。
馬場（メダップ）
そうですね、私が今年の1月にメダップに入社して、それまでは開発は完全外注で進めていたんですが、最初の三ヶ月位は全然成果も出ず、共通認識が持てていなかったので、何なら個人個人で開発していたほうが成果出るような形だったんですよね。
ただ、地道に輪読会をしたり勉強会をしたり、日々のスプリントの中でちょっとずつ調整していって、最近ようやくスピード感を持って開発できて週次でリリースできるくらいにはなってきました。
黒田（フォトラクション）
今回お話聞かせていただいて、フォトラクションもまだまだ開発でやりようがありそうだなと感じて勇気が出ました。
馬場（メダップ）
私たちとしても、まだメダップのほうが規模は小さいので、これからぶつかりそうな課題を色々知れてとても勉強になりました、ありがとうございました！
/assets/images/6192680/original/ae5d6bfe-de11-42ba-af91-ebe844b27c65?1612168066)
/assets/images/6432857/original/a7a9bbac-22de-4912-b0b9-3feae0f05045?1616147522)