技術的負債にプロダクトマネージャーが向き合った話
はじめまして。
merpayでプロダクトマネージャーをしているさとじゅんと申します。
私は主に加盟店さま向けのProduct開発をしているのですが、2020年もあとわずかということで、忘れないうちに特に今年注力してきたことについてまとめておこうと思います。
その前に去年のトピック
去年はメルペイのコード決済が世に出た年で、メルペイが使えるお店を増やすことを一番の目標として、必要なProduct開発やアライアンス案件に参画して、主に大手加盟店さまでのメルペイ利用促進を裏方から支えてきました。
そんな「攻め」が続いた2019年ではありましたが、私個人としては、2020年はどちらかというと、「守り」のProduct開発を中心に行い、次の飛躍のための種まきをしてきました。
そのひとつが、技術的負債と向き合うということでした。
（他にも障害対応と向き合うというTOPICもあるのですが、それは今回は触れません）
はじめにまとめ
ここでは主に下記の3つの話をしていきます。
- 技術的負債の返済を推進するのに必要なのは熱意
- 技術的負債には種類がある
- 負債の返済は場合によっては、自社の優位性を築く武器になりえる
技術的負債について
例えば、やりたいことを実現するために誰かからお金を借りて、先にやりたいことを実現し、後から借りたお金を返済をするのと同様に、Productにおいてやりたいことを実現するために技術的な負債発生を許容してリリースすること。または、意図せず負債が発生してしまう場合があります。
当然負債なので後で返済が必要となります。
技術的負債という言葉はメタファーであり、Product開発の現場において、ステークホルダー（主に自分より上位レイヤーの決裁者）へコミュニケーションする上で必要になる言葉である場合が多いように思います。
引用元：エンジニアリング組織への招待
この図が示すとおり、技術的負債は目で見えるものではありません。
お客さまにわかりやすく価値提供できる新機能でもありません。
例えば、経営陣にとって、機能として見えないが確実に必要となる技術的負債へのアプローチは、「なぜこの成長が必要な局面でそんな対応をしないといけないのか」という点が理解できないことが多いため、議論が難航してしまうことが多いのではないかと思います。
そんな中、メタファーとしての技術的負債という言葉は、目的を伝えるための最適な言葉になってくれると思います。
（対応タイミングや対応すべき事項には優先順位があると思いますが）
自分が直面した技術的負債
技術的負債には大小さまざまなケースが考えられると思いますが、自分が向き合っていた課題は、わりと開発規模としても大きい案件でした。
具体的には、加盟店さまのデータを扱うコアなデータ設計に対して負債を抱えていたので周辺機能含めメスをいれることでした。
まず、メルペイをどこでも使えるようにするためには協力してくださる加盟店さまのちからが不可欠です。
そんな協力者である加盟店さまを増やしていく過程において、加盟店さま含め、外部ステークホルダーとの間でさまざまな種類の契約が存在します。
そして契約の種類によって、その事業者に対して行うべきメルペイの対応が異なり、当然システムも契約に即した処理が必要となります。
例えば以下をご覧ください。
メルペイのSalesが営業し、加盟店がメルペイの導入を合意してくださったとします。
メルペイ加盟店になるためには加盟店の審査・管理が必要であるため、加盟店審査および管理はメルペイが行います。
そして、審査通過後にメルペイを利用できるようになり、お店で発生したメルペイの決済売上は、後日メルペイから加盟店にお支払いをいたします。
これを直接契約といいます。
別の例として、
加盟店（包括元）はコンビニを運営している会社でフランチャイズ（以下FC）展開しており、FC社は100社を超えるような事業者だったとします。
この時FCの会社を加盟店（店子）とします。
この場合、先程の直接契約の加盟店とは異なる運用・お金の流れ・決済が発生します。
実際に決済が発生するのは、FCのお店ですが、FCへのお支払いは包括元である本社が一括して行います。そのため、メルペイの支払い先は包括元に対してのみとなります。
ただし、決済における加盟店審査・管理義務はメルペイにあるため、メルペイが対応します。
これを包括代理店契約といいます。
また、別の例として、
加盟店審査・管理までも包括元が行う契約パターンもあります。
これを包括加盟店契約といいます。
細かい話をすると店子加盟店が遵守すべき規約が異なるなど違いはあるのですが、今までの契約と異なる契約であることがすぐにわかると思います。
・・・といったように、さまざまな契約パターンによって、加盟店審査・管理の責務はどの事業者にあるのか？決済が発生するのはどの事業者か？決済が発生した後の振り込み先はどの事業者か？といったように、事業者別に役割が異なるという性質がありました。
この契約パターンをビジネス要件として正しく把握して、システムに反映し、データ登録、管理をできるようにすること。
それによって、正しい運用・正しいデータトラッキング・正しいシステム稼働が実現でき、スケールするProductおよびスケールする組織へと進化できるようにすることが必要でした。
実際には、このデータ構造やシステムに要件として不十分な部分があり、結果的に運用上、契約実体とシステムを無理やり合わせるために、本来Productとして意図しない形でシステムが利用されるケースが散見してしまいました。
リリース当時はよいと思われていたシステムが、ビジネス要件の拡張に伴い、改修が必要だということがわかり、また、リリース当時よいと思われていたシステムが、実はデータの持ち方として不十分だということが後からわかりました。
対応策
この問題を解決するためにやったことというのは、まず As-Isを洗い出すことからしました。
As-Is の書き出しの時におすすめなのが、システム構成を絵を書いてグラフィカルに理解することです。
（ER図とかシーケンス図とか）
そして To-Be をどうしていくかというのをとにかく現場の有識者とエンジニアと議論しました。
議論するたびに、経験豊かな有識者がたくさんのドメイン知識を教えてくれたり、エンジニアの誰かがぽろっと気づきにつながる一言を言ってくれたりしました。
最初はどうしたらいいか全くわからず、何度も議論が暗礁に乗り上げ、「終わった、、、」と思う日々もありましたが、議論を継続していくうちにどういうアプローチであるべきかということが見えてきました。
設計時に大切にしたこと
仕様検討時には、 抽象的で無秩序なシステム にするか、 具体的で秩序のあるシステム にするかという2択がありました。
前者の場合、抽象的なのでさまざまなシチュエーションに対応ができます。
例えばSalesがProductチームへ「これできますか？」という相談をせずに、自らシステムを使って対応ができる場合が増えていきます。
言ってみれば、部品だけ渡すので、なにを作るかは任せますというイメージです。
ただ、このパターンの場合、2つの問題が起き得ます。
- システムの管理ができない
- 正しいデータトラッキングができない
抽象的で自由度が高い分、運用する側に一定の規律がないとわけがわからないことになってしまいます。
また、そのデータがいったいどういう内容（契約）を指しているかわからず、正しいデータトラッキングができなくなる不安もありました。
結果的には後者を採用しました。
これは、今見えているビジネス要件を整理して、例えば、「これと、これと、これと、これのシステムを作ることで、今の問題を解決できる方法を説明できる」と設計するようなイメージです。
そして、このケースに当てはまらないケースが出てきた時に、追加開発が必要になりますが、正しい管理がされて、正しいデータトラッキングができるシステムを実現でき、正しい規律の元、ビジネスをスケールさせることができるようになります。
推進する上で大変だったこと
この技術的負債の返却をする上で大変だったことが４つあるのでそれもまとめておきます。
1. どうあるべきか（To-Be）を導くのが難しい
前述の通りですが、一度発生した負債は、さらに負債を積み重ね、複雑になっているケースが多いため、あるべき姿を導くのがとても難しいです。
さまざまなアイデアを出すことができても、要件をすべて満たすアイデアを見つけることは時間と労力と熱意が必要でした。
ただ、複雑化した負債の解決方法を見つけると、複数の課題を一気に解決できる可能性があります。
任天堂の宮本さんもアイデアとは複数の課題を解決できるものだと言っていますがが、そんなアイデアが出てくる場合も潜んでいます。
現に今回私がぶち当たった壁も、対応することで技術的負債の返却だけでなく、オペレーション負荷を軽減したり、正しいデータトラッキングを実現できたので、多くの課題を解決できるアプローチになれたと思います。
2. 社内決裁者の理解を得るのが難しい
技術的負債というメタファーが必要になった背景でもありますが、やはり実際にこの問題は大きかったと思います。
技術的負債は機能ではないので、目には見えないし、なぜ今その対応を労力を割いてやらなければいけないのか理解してもらうのはなおさら難しいです。
また、複雑に入り組んだ技術的負債の場合、一言で説明がつかないので、たくさんの資料を書いて、順番に問題点を説明していかないといけません。
やっと1ができたと思っても、2で苦労してしまう場合があります。
ここは現場のProduct関係者だけでなく、上司や関係各所を含めた総力戦として社内決済者を動かすことが必要だと思いますし、強い気持ちで推進していく必要があるポイントだと思います。
3. 負債の返済中に新たな考慮ポイントが出てくる
ビジネスが急拡大するフェーズにおいては、さまざまなお客さまからのさまざまなご要望をいただくことが多く、結果的に想定外の仕様や、新たに考慮しなければいけないポイントがたくさん出てきます。
特に技術的な負債の返却の開発規模が大きく、開発期間が長い、または、企画構想から開発着手までの期間に間が空いてしまった場合などにこの問題は発生すると思います。
私の場合は、全社的に別案件に力を入れていたので、企画構想から開発着手までの期間に間が空いてしまい、結果的に、その間に発生したビジネス要件や、システム設計を取り込んでいく必要があり、さらにPJ推進に複雑性が増してしまいさらに大変な思いをしてしまいました。
4. フェーズを切ったけど、完遂するには長い時間軸への覚悟が必要
これも技術的負債の規模が大きい場合ですが、細かくフェーズを切ったものの、ゴールまでの道のりが長く、乗り越えなければいけないハードルが大きく複数存在することがあります。
負債を返済しないと更に事態が悪化するのに、次Qは会社の戦略上、別のことを優先しないといけないといった場合もあると思います。
フェーズ1のリリースで燃え尽きることがないように、繰り返し必要性を語り、負債の返済に尽力する必要があると思います。
強い気持ちを持っていこう
とにかく技術的負債の返済は、複雑化しているほど、プロダクトマネージャー自身にもビジョンと熱意が必要であることを教えてくれます。
あるべき姿を定義して、少しずつその未来に近づける。
そんなシンプルなことの大切さを改めて教えてもらったような気がします。
技術的負債の種類について
ここまでは自分が直面した今年の振り返りとしての技術負債との向き合った結果を書きましたが、ここからは、技術的負債と向き合った結果、学んだことや思ったことをまとめていきます。
まず、マーティンファウラーは技術的負債には4象限あると言っています。
引用元：https://bliki-ja.github.io/TechnicalDebt/
左上から時計回りに説明すると、
Reckless(無鉄砲な) & Deliberate(意図的な)
- 時間の制約などなんらかの理由があり、意図的に間に合わせの適当な方法を選んだことで発生した負債
Prudent(慎重な) & Deliberate(意図的な)
- 慎重に考えた結果、リスクを飲み込み、負債を負債として認識した上で許容される負債
Reckless(無鉄砲な) & Inadvertent(不注意な)
- 一番よくない負債
- 無意識に無鉄砲なやり方をしてしまっているので、当然コードも汚くなる
Prudent(慎重な) & Inadvertent(不注意な)
- 当時はベストな判断だったが、お客さま・マーケットなど理解度が上がり、事業の解像度が上がるに連れ、さらによりよい設計を思いついた。その瞬間に負債になった
このように1つの技術的負債という問題は複数の問題に整理することができます。
私個人としては技術的負債の存在自体は決して悪ではないと思っています。
返せる負債であれば許容して事業の成長を優先することはあるし、多くの企業がそうやって成長してきたのだと思います。
大切なことは負債なので、いつか返済する必要があるということ。
返済を怠ると、いずれ大きく成長したい時に、うまく羽ばたくことができない足かせになってしまうことがあるということだと思います。
技術的負債に関する考察
前述のように技術的負債が４象限あるとします。
この場合、右下のシチュエーションによって発生した技術的負債というのは、他の原因で発生した技術的負債とは少し毛色が違うものなのではないかと思っています。
というのも、例えばスタートアップにおいて、まだ未開拓な市場において、当時は最適だと思ったが、市場の解像度が上がることで、より良い設計が見つかり、今稼働しているコードが技術的負債になってしまった場合、その負債を返済することが、さらなるProductとしての競合優位性につながるのではないかと思うからです。
例えば、自社の属する市場において、自社が市場の中でファーストペンギンだったが、競合他社が後から参入してきて、自社と同じ初期設計をしていた場合、その競合他社もいずれ、自分たちが直面している技術的負債にどこかのタイミングで向き合う時が訪れると想定されるからです。
これを乗り越えないとさらなる飛躍ができないという類いの負債であることが考えられるので、先に乗り越えた会社のほうが、スケールする土台を早く作ることができるのではないかと思うからです。
技術的負債とひとことで片付けてしまうと、どうしても短期的な事業インパクトに直結しない印象が強く難色を示す人も出てくると思いますが、中長期的にみると、事業をスケールさせる土台になるだけでなく、先行者優位をもたらすことにつながる施策になりえるのではないかと思っています。
つまりmoatになると思っています。
ということで長々と技術的負債というとてもマニアックな話題についてまとめてみました。
年の瀬の忙しい中、こいつはなにを言っているんだと思った人もいるでしょうが、読んでくださった方がいらっしゃれば幸いです。
また、この記事に関してご意見などなどありましたら、ぜひTwitterにご連絡ください。
2020年もたくさん働きました〜〜！
2021年もよりよい年にしていきましょう！！
それでは良いお年を〜〜！！！！
この記事が気に入ったらサポートをしてみませんか？