2023/11/20 このエントリーをはてなブックマークに追加 はてなブックマーク - リアーキテクチャはROIと共に語っても良いんじゃないか

リアーキテクチャはROIと共に語っても良いんじゃないか

カテゴリ: ,




なんか、ずっと腑に落ちてないことがあって。
「XXで生産性を上げる」とか「技術的負債をなくす」とかよく言いますよね。

その志はとても良いのですけど、じゃあ実際にやってみて、その結果どのぐらい生産性が上がったのか、負債がなくなった結果どういう効果が得られたのかというのはあまり聞かない。

そういう心意気でやる、というのは良いことなんですけどね。
実際、たとえばリアーキテクチャをするとして

  • それにどのぐらいの時間がかかるのか
  • 費やした時間はどこでリターンできるのか
  • どのタイミングでプラスになるのか

その、損益分岐点みたいなものとかROI的なものとか。
それがどのぐらいに、ビジネスインパクトとかユーザー価値に寄与するのかとか。

結局、リファクタリングにしろリアーキテクチャにしろ、「やった改善による期待する効果」を明確にしないとセカンドシステム症候群やアーキテクチャ宇宙飛行士と変わりないのではないかと思ってしまうのです。

セカンドシステム症候群やアーキテクチャ宇宙飛行士は、個人開発とか趣味コードとかで、いくらでも出来るしなぁ。


結局、それをやる意義をCEOとかプロダクトオーナーやプロダクトマネージャーとかに堂々と言えますか?みたいなところかもしれない。
まぁ、リファクタリングに関してはそんな堅苦しいものではなくて、朝起きたら歯を磨くみたいなもんだとは思ってます。


ここまで書いて、いやちょっと待て、と聞こえてきそうな気もするようなしないような感じもします(どっち)。

全てが生産性やビジネス価値になるわけではないよ、と。
まぁそれはそう。

Leanとdevopsの科学とかFour Keysとかは、まぁまぁ妥当な指標な気がしています(ちょっと古いか)。

その他、例えば
「開発チームの認知負荷を下がりストレスが無くなる、ミスが減る」とか
「これを採用した方が開発チームのモチベーションが上がる」とか
「これしておいた方が、今後のマイグレーションコストが下がる」とか
「この部分の開発効率が上がる(結果1〜2日短縮効果がある)」とか
なんかしら 説明が出来れば良いんでしょうけどね。

リスク or コスト or 満足度 みたいなものだったら妥当な感じはしてきました。


リアーキテクチャや改善と言われるものが全て正義かと言われれば、自分はそこまでは思っていなくて。
改善し続けても売れなければ意味がないし、サービス終了したら改善したものは虚無だし。
どれだけ実際のプロダクトに変化を加え続けるかというのと、改善を続けるかという両輪を回さないといけないなと思っている。
なので、リアーキテクチャを掲げるのは良い、と。
一方でどのぐらいそこに投資するかという話ですね。

資産形成とかもそうですが
消費と収入みたいなものがあって、余剰の部分で投資するみたいなのがセオリーなのではないかなと思っていて
余剰の見極めみたいなのが大事なのではないかなと思います。

余剰を、いかに最大限にするか。余剰の範囲で効率的な投資をするかということになるのかなと思っている。


ここまで書いてみて、結局プランニングで頑張れって話のような気もしてきた。
「これは今やらない方が」とか「今やった方が良い」とかを個人の感覚で定義するのではなくて
明確に「ここが境界点だからここまで出来る」とか「ここの部分が今投資すべき」とか、そういう定量数値なり定性の指標を定義をしていった方が良い気がしている。
結局個人の判断とか感覚でやっていると、ブレやすいし
セカンドシステム症候群やアーキテクチャ宇宙飛行士に近づいていくような感じがする。


徒然なるままに書いたのでグチャっとしてますが

  • 投資に対しての効果、ゴールは明確にした方が良さそう
  • 指標は リスク or コスト or 満足度 あたりかもしれない
  • プランニングなどで 投資 と ビジネスを回すためのデリバリーのバランスをとるのが良さそう

みたいな、よくある話になった。

なんか、このあたり詳しい方ツッコミあればください。
もしくは、効果測定までやってるような事例とかあったら知りたいのでソッと教えてくれると喜びます。




思い出したけど、ちょっと前も似たようなブログ書いてたわ…
技術的負債じゃなく、もはや技術的不良債権

おじさんの記憶は揮発性


0 件のコメント:

コメントを投稿

GA