読者です 読者をやめる 読者になる 読者になる

Line 1: Error: Invalid Blog('by Esehara' )

または私は如何にして心配するのを止めてバグを愛するようになったか

>> Zanmemo

あと何かあれは 「esehara あっと じーめーる」 か @esehara まで

「組織的負債」というものを考えてみる

はじめに

 現在、自分はスタートアップをお手伝いしている。そして、現在はどんどんユーザーをスケールさせようということで、士気が上がっている。エンジニアも入れたい。そのような前向きな雰囲気になっていて、とても心地良いのだけれど、ただ、その上で、今クリティカルになっているのは、伝達経路であったり、あるいは振っているタスクが適切に配られずにいびつになっている状態があるよねということを、戦略の人と話したりする。

 周りを見渡してみると、実はこの問題は自分たちだけの問題ではなく、ベンチャーによくある問題であることに気がついた。例えば急成長しているベンチャーにおいて、評価制度が適切ではなかったり、あるいは他に適性がある人間がちゃんと配分されていなかったりすることがある。そのことによって、優秀なエンジニアが流出したり、あるいはプロジェクトの失敗率が上がったりする。

 これらの問題を、個人の問題として片付けることは簡単なのだが、そもそも自分たちの組織としての構造が、そのようなデメリットを生み出しているのではないか、という疑問が必要だということに気がついた。

 この認識は、意外と無いものかもしれない、とも思ったりした。なぜなら「今まで上手くいっていたのだから、これからもそれで上手くいかないはずがない」と思ったり、あるいはそもそも「組織の有りかた」ということについて、考える必要性がなかったため、そのまま考えずにいるということがある。

 そこで、これを「技術的負債」という言葉にならって「組織的負債」と名付けて問題として認識するといいのではないか、と思う。もしかしたらもっと適切な言葉があるのかもしれないけど、その適切な言葉をしらなかったので、そのように書いてみたいと思う。

組織的負債の前に、技術的負債について

 エンジニアの間ではーー少なくとも、Web系エンジニアの中ではーー「技術的負債」という言葉が使われることが多々ある。これは過去の場当たりと、とりあえずのプログラミング、及びそれを支えるサーバーを維持したり、変更したりするさいに、非常にコストが高くなっている状態のことを指す。つまり、技術的な観点から、工数などの部分において、利子が付いている状態といってもいい。

 とはいえ、完全に技術的に負債を作らないようにすることは難しい。というのも、開発方法というのは日々アップデートしているからだ。だから、そのときにおいては最適解であったものであっても、日時がたつにつれて、その最適解は「最悪」に落ちることもある。意外なことかもしれないが、開発というものは、効率性という観点からすると「腐る」ことを免れない。

 当然のことながら、経営判断上、そのようなコードの質を担保するよりも、期日のほうが優先される場合があるのは間違いないが、しかしそのように速度を優先した場合、なんらかのタイミングで負債を返済する必要がある。  

なぜチーム、あるいは組織の問題を「負債」と呼びたいのか

 恐らく多くのサービスというのは、余程のことがない限り、一人で創るものではなく、皆で作るものだと思う。しかし、最初の立ち上げ時においては、そもそも自分たちが作っているプロダクトというものが、本当に市場にとって価値があるものなのか、ということを見極めないとならない。

 そうすると、むしろ自分たちのプロダクトを素早く作ることのほうが問題なのであって、決してコードを綺麗に書いたり、あるいはインフラをガッチリ固めることが優先度が必ずしも高い、というわけではない(もちろん、これらは適切であるほうがいいことは間違いない)。

 たぶん、いわゆるチームの問題も一緒で、業務フローとか、情報の共有プロセスとか、そういうのを固めるよりも、むしろプロダクトを素早く作ることのほうが優先度が高いわけで、むしろその場その場で臨機応変にやっていくほうが、望ましいという場合はある。

 しかし、そのようにやっていくと、例えば共有プロセスが確立されていないために、例えば伝達ミスみたいなことが起こりえたり、そもそもタスクが把握できなくて曖昧なまま放置され、急にクリティカルな問題が浮上することが起こりうる。

 チームにとっても、その都度その都度で、適切なフローとして改善していかなければならず、それを怠ることによって、全体の動きが鈍ってしまう。

 それは、本来だったら徐々に改善されるべきものにも関わらず、それが放置せざるをえなかったりす場合、むしろ「負債」といったほうが、その問題に支払っている「利子」という存在がわかりやすくなるのではないかと思う。

で、どうするの?

 一つの回答としては、日時の始まりに、自分たちが昨日やったタスクであったり、今日やったタスクをちゃんと共有したり、あるいはそのチームの代表がメンバーと聞き取りを行ったり、あるいは定期的に問題が起きたことを洗い流して、チームのやりかたとして、その方法を改善できないかを考える時間を設けるなどがあると思う。

まとめ

 プログラミングの「負債」というものが、なかなか伝わりにくいのと同様に、このようなチームの「負債」というのも同様にわかりにくい。プログラマが、外部の挙動をかえずに、適切なコードに手直ししていく作業を「リファクタリング」と呼ぶけれども、それと同様のことが、たぶんチーム、あるいは組織にも必要なのかもね、と思ったりもする。