ソフトウェア開発組織における "持続可能なやり方" とは
ファンズ株式会社 CTO の若松です。弊社のプロダクト開発チームでは、開発組織のバリューの中で、「持続可能なやり方を採用する」というバリューを入れています。
開発組織のバリューについては、以下の記事でも触れているのでご興味があればご参照ください。
ただ「持続可能なやり方」というだけでは少々抽象度が高く、次のような点でそれなりの解釈の幅があると感じています。
なにが持続可能なやり方なのか？
どのような場面で持続可能なやり方であるのか？
もちろんバリューが抽象的なのは、幅広い事象や課題に対しての指針となるようにしたためであり、意図的ではあるのですが、それゆえに解釈の差が出てきてしまうこともありえます。そこでこの記事では、そんな「持続可能なやり方」について私なりの考え方を整理してみました。
なぜ持続可能なやり方が必要なのか？
まずはじめに、そもそもなぜ「持続可能なやり方」を取る必要があるのか？ということを述べておきたいと思います。
大前提として、顧客に対して価値のあるサービスを提供することがなによりも重要なことです。しかし同時に、以下に述べるような理由から、サービスは持続可能な形で提供する必要があると考えています。
顧客の期待に応えられるようにするため
持続可能な形でサービスを提供することは、顧客の期待に応えることにつながると考えています。
顧客がサービスに対して価値を感じてくれているならば、サービスが短期間で終了してしまうことなく、将来にわたって利用できることも期待されるはずです。
こうした期待に応えるには、サービス自体も持続可能なやり方で提供していくことが求められます。サービスを提供するのに持続可能なやり方が取れていないと、長い目線で見たときには何かしらの理由でサービスを停止しなければならなくなり、結果的に顧客の期待にも応えられないことになってしまいます。
継続的な改善を実現できるようにするため
プロダクトの開発効率や生産性を維持するということも重要な要素の1つです。顧客に対して提供するサービスは、短期間で一気に開発をすれば終わりというわけではなく、長期にわたって開発を継続していく必要があります。
もし継続的に開発することができないと、サービスを改善し続けることができなくなり、競合に対して遅れを取ってしまったり、結果的に顧客のニーズにあわせた付加価値を提供できなくなってしまう可能性があります。
長い距離を走るときには、短距離走のように一気に駆け抜ければよいわけではなくペースを守りながら走り切ることができる必要があるように、開発においても持続可能なやり方をとることが、継続的な改善の実現につながると考えています。
開発における持続可能性とはなにか？
持続可能性は個人ではなくチームとして考える
ソフトウェア開発では一般的に、技術的負債が積み重なると、保守や拡張のためのコストが大きくなり、持続可能性が損なわれると考えられています。
こうした技術的負債を考えるときに考慮したいのは、誰が見ても明らかという判断ができる場面は限られているという点です。
ある要素が技術的負債であるかどうかは、現在、そして将来のチームメンバーが共通して理解しているコンテキストやスキルを踏まえて評価されるべきだと考えています。
部外者の視点でみたときに、コードが読みにくいと考えられるようなことも、チームメンバーの中で共有されているならば、そのチームの中では負債であるとは考えづらいかもしれません。
もちろん別の視点で考えると、新しいメンバーが参画するときのオンボーディングにおいて困難が生じる可能性はありますし、その観点では技術的負債と言ええます。しかしこの点も、共通するコンテキストや考え方を持つメンバーのみを採用する前提があるのであれば、とりわけ大きく問題視する必要のないものとも捉えられます。
このようなことから、持続可能性という点の課題に対し、チームメンバーの中でこれが持続可能なのか、持続可能ではないのか、といった認識を揃えていくことが重要だと考えています。
持続可能であるための構成要素は普遍的ではない
事業のおかれる状況や環境、チームの方向性が変わることで、負債と考えられるようなものが変わることも考慮しておきたいポイントです。
例えば弊社の場合、バックエンドの開発では Scala を採用しています。（Scala を採用する点においての良否は、こちらの記事に書きました。）
仮にもし、組織の方針として Scala ではなく別の開発言語を中心的に採用するとした場合、その後に入社してくるメンバーは基本的に Scala の開発経験をもたない想定となり、結果的に Scala で開発できるメンバーが限られてくる容易に想像できます。そうなると、 Scala で書かれたコードベース自体が技術負債だと考えられるようになることも十分考えられます。
またチームメンバーがみな日本語を話すメンバーにより構成されており、ドキュメンテーションも日本語のものだったとします。こうした状況下でグローバル化を志向してさまざまな言語を母国語とする人材を受け入れるという方針に転換した場合、日本語で記述されている資料が大半だと、その中でも情報格差が生じてしまいます。とりわけ日本語があまり堪能ではないメンバーにとっては、ある意味これも負債と考えられるのではないかと思います。
このようにチームを構成するメンバー内で共有できているコンテキストによって、持続可能性というのは変わりうるものだと考えています。
持続可能なやり方をとることで属人性を排除できる
開発における取り組みが属人的になっていると、あるキーパーソンとなるメンバーがいる間は安泰でも、ある人がいなくなった瞬間に組織としての仕組みが維持できなくなるということが起こり得ます。
持続可能なやり方を採用することで、属人性を排除することにもつながると考えています。
スタートアップの創業期であったり、新規事業の立ち上げなどをはじめとするプロジェクトのスタート時期など、一定属人的にならざるを得ない局面もあります。
しかしそうだとしても、将来的に属人性を排除できるような仕組みにしておかないと、その代償としてあとで払うコストが生じてきたり、キーパーソンが抜けた時にうまく回らなくなるといったことが起こりえます。
このような状況は "持続可能なやり方を取れている" とは思いません。
反対に、持続可能がやり方が取れているならば、必然的に属人性も排除することにつながるはずです。
開発組織における "持続可能なやり方" の具体例
ここからは、開発組織における持続可能なやり方として、どれも典型的なものではあると思いますが、いくつかのアプローチを述べてみます。
暗黙知をドキュメントや図などで形式知化する
暗黙知となっていることをドキュメントや図などにまとめておくことで、知識が形式知化することができます。形式知化しておくことで情報が必要になった人に対し、スムーズに情報をシェアすることができます。こうしたドキュメンテーションなどは、 "持続可能なやり方" の一つです。
時が経つと、自分自身で取り組んでいたことでも、その詳細については忘れてしまうものです。このようなときに、ドキュメンテーションや図を用意しておくことで、将来の自分自身にとっても有益な資料になることもあります。
コードのリファクタリングを行う
拡張に対してのコストが高かったり、保守コストが高い場合に、コードベースのリファクタリングをすることも "持続可能なやり方" です。リファクタリングを行うことで開発者の認知負荷を下げ、将来の開発効率を向上させたりすることもできます。
ただし、"認知負荷が低い"、"わかりやすい" という感覚が、個人の主観に依存していることは注意したい点の1つです。
高度に抽象化されたコードのほうがわかりやすい、という人もいれば、手続き的でプリミティブなコードのほうがわかりやすいという人もおり、バックグラウンドやコンテキストの理解度によって異なるはずです。
そのため、わかりやすさ（認知負荷）という点を考えるうえでは、その開発チームにおける最大公約数的なわかりやすさを目指すのが望ましいのではないかと考えています。
手動で取り組まなければならないことを自動化する
手作業でやらなければならない作業について、手順書やマニュアルなどのドキュメントに落とし込むことで属人性を排除することができます。
ただそうしたルーティンワークのような作業は、作業が増えると次第に1人で賄うことが難しくなります。人間が介在する必要が必ずしもない作業については、できるだけ自動化してしまうことも、 "持続可能なやり方" にあたります。
ただし自動化もブラックボックス的になっていると、その作業自体は自動化されていてもその変更をしようとした時に、だれも直せないといった状況が発生する可能性はあります。
そのため自動化を実現するための構成や設定はできるだけコードベースで管理したり、どのように自動化されているのか、などのマニュアルを残しておくこともあわせて必要と言えるでしょう。
個人のノウハウや知識を、チームの共有知とする
上記に述べたような方法以外でも、個人として持っている知識やノウハウを、チーム内で共有できている状態にすることは "持続可能なやり方" といえます。
先に述べたようなドキュメントや図など資料化するという方法のほか、勉強会や共有会の場を設けて知識を共有にすることで、知識やスキル・ノウハウなどを継承し、属人性のあるものからより確固たるものにすることができます。
持続可能なやり方をあえて選択しない場合
ビジネス上の課題解決のためには、ときには持続可能ではないやり方を取ることも必要です。これには、例えば次のようなケースが考えられます。
持続可能である必要性がない場合
１つは、そもそも持続可能性が必要ではない場合です。
例えば概念実証（PoC）としてソフトウェアを開発したりする場合、それはあくまでコンセプトの実証が重要なわけで、コンセプトさえ実証できれば持続可能性を追求する必要はありません。
なんでもかんでも持続可能なやり方を取ろうとすると、ときにはオーバーエンジニアリングのような状況を招いてしまう必要もあるでしょう。原則的な考えとしては持続可能なやり方になっているかを注視しつつも、それだけではないことを考えるのも必要だと感じます。
持続可能性よりも重要な要素がある場合
別のケースとして、持続可能性も重要ではあるが、それ以上に重要な要素があるという場合も考えられます。
例えば、プロダクトをリリースするまでのスピードが決定的に重要であるというケースです。いつまでにリリースができないと経営や事業において決定的に重要、というタイミングでは、トレードオフの観点からスピードを重視せざるを得ないケースです。
またソフトウェアによっては、保守性よりもレイテンシーやスループットなどの応答性能のような、パフォーマンスが決定的に重要であるソフトウェアもあるでしょう。このようなときには、認知負荷などの保守性を犠牲にしたとしても性能を追求する必要があると思います。
このような局面では、トレードオフを考慮して明確に "持続可能性よりもほかの要素を優先させる" という認識をもったうえで取り組むことで、影響範囲を限定的にすることが望ましいと考えています。
まとめ
今回の記事では、開発組織において "持続可能なやり方" として考えられる少し具体的な方法について書いてみました。ただし "持続可能なやり方" として特定の手法が銀の弾丸となるわけではなく、またなにが持続可能なのか？という点ですら、組織内で共有されるコンテキストや共通のスキルによって変わり得ます。
ファンズの開発組織でも以前、バリューの解釈について考えるワークショップを実施したことがありました。そのときにもメンバーーごとにさまざまな解釈があったことが記憶に残っています。
持続可能な自分だけで判断するのではなく、チーム内で "持続可能なやり方とは何か？" という状態が共有できているような状況を作っていきたいなと思います。
前回までの記事はこちら
最後に
いつもの通り、現在ファンズで採用中のポジションについてご紹介させていただければと思います。
人材募集について
現在募集中のポジションについてはこちらです。もしご興味のある方は、ぜひご連絡いただけると嬉しく思います。
ファンズの採用に関する情報については、以下の内容もご覧ください！
この記事が気に入ったらサポートをしてみませんか？