プログラマの世界には「技術的負債」という言葉がある。ソフトウェアを開発していく中で、時間がなくて妥協したり、技術力が足りなかったりして、適当に作ってしまった部分が、後々になって不具合を引き起こしたり、改修にかかるコストをあげたりすることを言う。
後になればなるほど、悪影響が大きくなることから負債と喩えられる。そんな技術的負債と同じように、組織やチームのマネジメントでも、後になればなるほど悪影響が出てくるような「組織的負債」とも言えるような現象が起きてしまうことがある。
本記事では、私たちソニックガーデンで「組織的負債」を貯めないようにチーム経営してきた経験をもとに、プログラマの哲学を応用したマネジメント術について書いた。（今回の記事では「である」調にしてみた）
目次
技術的負債と組織的負債の生まれる背景
技術的負債が生まれるのは、スタートアップの初期段階に多い。その時期は得てして、経験豊富な技術者を雇うだけの資金もなく、きれいなコードを書くことよりも動くソフトウェアがあることの方が優先順位が高くなってしまうし、実際そうするしかない。それが現実的な選択だ。
ただし、そのままの状態で走り続けて、ソフトウェアの改修コストがビジネスの足を引っ張るようになって破綻するケースは少なくない。そうならないためには、ある程度のタイミングで負債を一気に返済するように、きれいに作り直すなり、土台を直す必要が出てくる。（実際にするかどうかは経営者の判断だろうが）
組織的負債も同様である。組織やチームが成長を続けている時こそ、組織的負債も貯まりやすい。チームの中で生まれる不協和音や、セクショナリズム、教条主義に事なかれ主義が生まれ、気づいた時には返済もままならなくなってしまうことがある。
一緒に夢見て起業した仲間たちが去って、ビジネスが上手くいって規模が大きくなった代わりに、起業当初のような自由闊達で、信頼できる仲間との楽しい働き方の出来ない、息の詰まるような組織の出来上がりである。本当にそんな働き方のために起業したんだっけ？
そうなってしまわないために、どうすれば良いのだろうか。私たちの取り組みを紹介する。
負債への取り組み方のシンプルな解決
技術的負債も組織的負債も、そもそも積み立てないことが取り組む上での、至極もっともな姿勢になる。たとえ一時的に負債となるような妥協をしたとしても、すぐに返済をしてしまうのが、一番なのだ。後からまとめて返済は、間違いなく上手くいかない。
もしかすると、営業出身の経営者だったり、なにを犠牲にしてもビジョン達成を目指すような経営者であれば、そうした負債があることも織り込み済みで、その上で成長することを選ぶこともあるかもしれない。それはそれで凄いことだが、エンジニア出身の私には出来そうにない。
技術的負債の恐ろしさは十分に分かっているため、常に動くソフトウェアと共に、常にきれいなコードの状態を保つように徹底している。きれいなコードに保つことができれば、どれだけ経ってもコードの改修にコストがかからないようになるからだ。
これは、組織的負債でも同じことだ。組織の成長に合わせて、少しずつ、少しずつ組織のあり方や運営方法を変えていく。組織的負債が引き起こすのは、優秀な社員の離職や、人為的な情報漏洩などといった、より企業にとってクリティカルな問題であり、予防していくことが重要なのだ。
プログラマの哲学を応用した組織的負債への対処
技術的負債を貯めない為に、プログラマの世界では幾つかの原則がある。KISS、DRY、YAGNIなどと呼ばれるものである。プログラミングをする上で、これらの先人からの教えは、良い設計、良いソースコードのために、非常にためになった。
そして、そこで得た知見や哲学は、マネジメントの実践にも応用が効くことが、これまでチームを経営してきた経験からわかってきた。それらは組織的負債を貯めないためにも有効だったのだ。
例えば、KISSとは”Keep it simple, stupid!”の略（諸説あるが）で、ソースコードは徹底的にシンプルに保つべきだという教えである。目指すのはメンテナンスしやすいソースコードで、シンプルであることが重要なのだ。
KISSの原則は、マネジメントにおいても通用する。組織やチームの運営を任されると、つい大げさな制度やルールを作りたくなってしまうが、大げさなものは誰も覚えられない。覚えられないものは運用されることはない。
だから、シンプルで最低限のルールに保つのが一番なのだ。
“DRY”と”Company as Code”（会社をコード化）
DRY。これは”Don’t Repeat Yourself”の略で、コードの重複をなくし改修は一箇所にするという考えだ。究極的には、文書化された仕様よりも動くソフトウェアこそが仕様とまで考えることもあるし、実際に、私たちの「納品のない受託開発」では、そうしている。
この考えを、マネジメントに応用すると、文書化された制度よりも動いているチームありきで考える、となる。そもそも、制度のすべてを文書化してしまうと、組織やチームの成長に合わせて変化させていくたびに全てを更新することになり現実的ではないし、改善しにくくなってしまう。
法的に用意しなければいけないものは除いて、制度の詳細は極力ドキュメントにしないようにしてきた。残しておくのは、抽象化した学びや原則のようなものだけで、それも継続的にアップデートするというよりも、社内であれば日記、もしくはこのブログに書き留めている。つまり、ストックではなくフローとして扱う。
また、文書にして守らないといけないものならば、プログラムを組んでシステム化してしまうことで、人の意識に依存しなくても出来るようにしていく。コードレビューをすべきならば、コードレビューを相互にしあうようなプログラムを作れば良い。文書にするより、よほど良い。
私たちは、”Company as Code”、つまり会社のことは全てプログラムにしていこうと考えている。
“YAGNI”と”リファクタリング”（現実から制度化）
YAGNIは、”You aren’t gonna need it!（そんなの要らないよ）”の略で、先を見通しすぎて拡張性はあっても複雑な仕組みにするよりも、必要になった時に改修しやすくするように今はシンプルに作った方が良い、という教えだ。
このYAGNIの精神が求められる場面は、マネジメントにだってある。３年も５年も先のことまで見据えた中期事業計画の立案や、組織の成長を見越した当初からの事業部制度など、未来の予測、しかも楽観的な予測を元に、事前に決めてしまおうとすることがある。しかし、これまで皮算用して、形や制度から先に始めた施策は、だいたいうまくいかなかった。
今の時代に数年先の事業環境や市場の状況など予測することなど、非常に難しい。方向性とトレンドは予測することはできるし、それを元に戦略やビジョンを考えるのは良いかもしれないが、計画や制度に落とし込むとなると、また別の話になる。
私たちの経営では、リファクタリング経営と呼ぶ取り組みがある。制度などの形を先に作るのではなく、自律的に動くチームの様子を見て、その現場で行われている実態に合わせて制度を作り変えていくようにしている。これはプログラミングの世界で「リファクタリング」と呼ばれる、外から見た機能を変えずに中身を直す行為に似ているため、そう呼んでいる。
また、YAGNIは人事採用にも言える。だいたいどこの会社でも人手不足で、人を採用すれば解決すると安易に考えてしまいがちだが、下手にフィットしない人を入れると、会社の生産性もカルチャーも悪くなってしまう。安易に人を入れてうまくいったこともない。だから、人が欲しい、と思ったら「それYAGNIじゃないか」と考えるようにしている。
長く見ていく前提だからこそ負債を貯めない
技術的負債にせよ組織的負債にせよ、それに立ち向かう背景にあるのは、作ったプロダクトや組織、チームと末長く関わっていくことを覚悟していることにある。
もし作りっぱなしで良かったり、短期的なプロジェクトでよければ、負債を貯めることを恐れる必要はなくなる。解散すればゼロに戻るのだから。しかし、私たちのスタンスは、サービスが動き続ける限りメンテナンスしていくつもりだし、会社もどこかに売ってしまうつもりもない。
私たちにとって会社とは、どこかで完成して終わりがあるものではなく、ずっと未完成でずっと改善を続けて、変化し続けるものだと考えている。だから組織的負債に気をつけているのだ。
「小口化」という価値観が、私たちの会社の根底にある考え方だ。なんでも大きな単位にせず、少しずつ行うことで、大袈裟になってしまうことを避けるのだ。究極に小口化すると、それは習慣になる。変化を小口化し、変化することを習慣にしてしまえば、組織は成長を続けることができるし、それこそが未来への担保になる。
組織的負債への対処も同様である。少しずつ変化し、その際に妥協をしないことで、負債のない組織を保つことができる。プログラマが「リファクタリング」をする際には、「コードの臭い」を嗅ぎ取るというが、組織やチームのマネジメントにおいても、「チームの臭い」を嗅ぎ取って、不吉な芽を早めに摘んでいくといいだろう。
