はじめに
この記事では、ビジネス職しか経験していない非エンジニアが、エンジニアと一緒に働くなかで多大な影響を受けた、「活動負債」という考え方をご紹介します（受け売りです）。
一個人としての経験ですが、私はこの概念に触れたことによって、エンジニアに開発などの相談をする際の生産性が高まったという感覚があります（定量的に計測はしていませんが…）。
また、ビジネス職としても「このアクションがうまくいかなかった場合、先々にどんなことが起こり得るか？」といった、中長期的な観点も重視するようになりました。
ビジネスサイドは四半期ごとの売上などを目標として追っているケースが多く、「スピード優先」という形で、ともすると近視眼的な発想に陥ってしまうこともあるかもしれません。
一方で開発サイドは、保守性やスケーラビリティ、あるいはセキュリティなど、長い時間軸でリスクと向き合う必要性が高く、ゆえにビジネスサイドとのコミュニケーションギャップが生じやすく、場合によっては組織のコンフリクトに繋がってしまうケースもあるように思います。
どちらも必要な視点であり、プロダクトを継続的に発展させていくためには多角的に論点を評価したうえで、見込める利益と損失のバランスを取って意思決定することが重要ではないかと考えています。
そういった文脈で「活動負債」という考え方は、職能や専門領域を超えて組織の生産性を高めるために、効果的な考え方だと思っています。
少しでも参考になれば幸いです。
非エンジニアが、エンジニアから影響を受けた「活動負債」という概念
目次
活動負債の概要
「活動負債」とは、利益や価値を生み出すために行った生産と引き換えに、必然的に生じる負の側面やコストを指します。
どのような活動においても、必ず負の側面が存在します。自動車の運転には常に事故のリスクが付きまとうように、避けようがないことです。
住宅の購入を例にします。
住宅を購入する場合、住宅ローンや固定資産税の他にも、定期的なメンテナンスや修繕にかかるコストや、地震や台風などの自然災害に見舞われた場合のリスクがあったり、はたまたご近所トラブルに見舞われた場合、その解決に動いたり、事態の悪化を防ぐための対策が必要になるかもしれません。そして最終的には、相続や売却なども考えなければなりません。
それらを処理する手間が「活動負債」のイメージです。
住宅を購入した場合と賃貸の場合を比較すると、生産に近い側面がある前者の方が、何かしらの問題が生じた際に必要となるコストが高いと言えるでしょう。
この「活動負債」という考え方は、「技術的負債」に近しい文脈ではありますが、ソフトウェアの開発を対象としている「技術的負債」よりも広い事象を指す、抽象度が高い概念になります。
ちなみに「活動負債」という言葉は、この考え方を説いてくださった方による造語だそうです。
活動負債の特徴
※記載している事例はフィクションです
①結果論である
- 最初は潜在的な負の側面を持っているだけ
- あるとき突然、実損に変化する
たとえば、新規取引を行う際の諸手続きには問題がなかったものの、
- 明らかに契約内容を理解していない（説明しても聞いていない）
- ITリテラシーに懸念がある
- オフィスが妙に散らかっている
などの違和感があったとします。
実際に取引を開始したところ、契約外の要求をいただいたり、あるいは料金の滞納を起こしたり、債権回収が困難になったとします。
起こった結果から、取引開始時点で不安要素があったことに言及することは可能ですが、その時点で起こり得る事態をどれくらい予見できるかというと、困難な部分もあると思います。
②実損になるタイミングは先のこと
- 生産から時間が経過して実損になる
- その処理をするのは生産に関わっていない人であるケースが多い
たとえば、優秀なセールスパーソンが、たった1人で事業を拡大してきたとします。
申し分ない成果を創出し続けていたので、長らくノーマネジメントで本人のやり方に一任してきました。
しかしある日突然、何の前触れもなく、そのセールスパーソンが退職してしまったとします。
属人的なセールス活動に終始していたので、クライアントとのやり取りや取引の経緯がわからず、セールス手法などのナレッジの類も一切残っていません。
後任としてセールスを行う方は、何もかもすべてを手探りで行わなければなりません。
結果的にクライアントからの期待に応えられなかったり、避けられたはずの無用なトラブルを起こしたり、何かしらの実損が生じる可能性は高いと言えるでしょう。
③雪だるま式
- 小さな負債が絡み合い、複雑な依存関係をつくり巨大な負債になる
- 問題の解決に莫大な時間や費用がかかり、気づいたときには手遅れということも
たとえば、提供しているプランをユーザーニーズに応じて、1つから2つに増やしたとします。
好評だったため、さらにきめ細やかにユーザーニーズを満たしていく方針に舵を切ったとします。
月日の経過とともに、2つだったプランが3つになり、5つを超え、とうとう10個を超えたとします。
各プランの仕様の違いから、適切にサービスを提供するうえで管理しなければならない項目は数十倍に膨れ上がってしまいました。
ともなってプラン毎の設定や処理のミスが相次ぐようなり、その事後対応で追われるようになってしまいました。
ユーザーにこれ以上ご迷惑をおかけしないように、一度、提供プランの種類を縮小させることに決めました。
しかし、無数の条件に対応できるよう、増築に次ぐ増築を重ね、複雑性を増したシステムの改修は一筋縄ではいかないことがわかりました。
また、削減対象とするプランを利用しているユーザーへの対応も考える必要があり、その方針によってはユーザーからの信用を失ってしまう可能性もあるでしょう。
結果、時間をかけて段階的に、提供プランの削減を検討する必要があるかもしれません。
活動負債との向き合い方
①安易に生産しない
生産しなければ負債は生じません（しかし、生産しなければ売上や価値を生み出すこともできません）。
生産時点での工数やコストだけでなく、中長期的に必要なケアや、考え得るリスクと天秤にかけて、バランスを取ることが重要ではないでしょうか。
そのためには、「本当にやるべきなのか？」と考えることが欠かせないと思います。
とくに、「運用でカバー」のような議論になった際は、
- いつ、誰が、どうやって運用するのか？
- 運用を助ける仕組みはあるのか？
- 運用状況をどう可視化するのか？
- 状況が変化しても運用できるのか？
- 運用ができなくなった場合、どんなリスクが生じるのか？
など、慎重に精査したほうがいいと思います。
②一時的な対応をやめる
「一旦」のようなワードが出てきたときは要注意だと思います。
恒久的な対応が取れず、その時点では一時的な対応しかできない場合、それなりの理由があるはずです。
そのうえでですが、その場しのぎ的な対応ではなく、抜本的な問題解決に時間をかけて取り組む必要性を検討することも有効だと思います。
また、先延ばし的に一時的な対応を積み重ねることにより、あらたな問題が生じ、その解決にかかる労力が増大したり、中長期的に見たら事態の悪化を招く可能性も考慮したほうがいいでしょう。
③投資活動で相殺する
「活動負債」を完全なゼロにすることはできませんが、継続的な投資活動によって部分的に相殺することは可能です。
エンジニアリングで言えば、保守やテストコード、CI/CDなどが挙げられるでしょうし、非エンジニアもクリティカルシンキングを磨くなど、スキルを伸ばすことによって、「活動負債」を局所的に打ち消したり、抑制することが可能でしょう。
④やめる・捨てる
やめるか、もしくは捨てれば「活動負債」はなくなります。
しかし、やっているからにはそれなりの理由があると思います。規模の大小があるにしても、何かしらを停止させる場合も踏むべきステップあり、計画的に進める必要があるでしょう。
とくに実施していたことをサイレントで停止してしまうと、関わる人の中で認識齟齬が生まれたり、混乱が生じる懸念もあるので、合意形成したうえで停止することが重要だと思います。
余談ですが、キャパシティーが大きい人は、例外なく取捨選択がうまいように感じます。
まとめ
活動負債の特徴
- 結果論である
- 実損になるタイミングは先のこと
- 雪だるま式
活動負債との向き合い方
- 安易に生産しない
- 一次的な対応をやめる
- 投資活動で相殺する
- やめる・捨てる
「活動負債」は誰もが常に生み出しているものですし、なくすことはできません。
だからこそ、負債になり得ると気づくことができる潜在リスクへの感度と、問題の根本解決にも目を向けることが、生産的な時間を確保するために重要なのではないかと思います。