良いソフトウェアを速く作るには(アジャイルのおさらい)
Timers inc, CTOのアマドです。久しぶりのnoteです。
この1~2年は人の数もプロダクトの数/規模も大きくなってきて、楽しさと同時に経営としての緊張感も高くなってきてる。
プロダクト/事業を推進するPOと技術開発を推進するCTOとしての両輪に悩みながらも、今日はそこの交差点にあたる「速度と質」話を整理する。
先に種明かしをするとアジャイル開発の考え方を改めて言語化してるだけなんだが、改めてゼロベースで「どういう理想状態を目指して、なぜ、こういう考え方に至ってるのか」を言語化するのは意外に大事。
特にアジャイルやリーンスタートアップに疎い人、開発に疎い経営者に技術投資の価値を理解してもらうのには有用だと思う。
強いソフトウェア開発組織の理想状態
ソフトウェア開発組織が究極的に達成したいことは何かというと、
顧客価値が高くて、高品質のソフトウェアを、速く出したい。
それに尽きる。
ここで「速さと良さはトレードオフだ、そんな指示はデスマ一直線だ」と思考停止してしまわないように。これから上記の理想に辿り着く方法を解きほぐしていくので。
自動車を作るとして
ソフトウェア開発の特殊性を考える前にちょっとハードウェアに寄り道。
最近自動車工場の動画をひたすらYouTubeで見るのにハマってるのだが、自動車というプロダクトはそのまんま人の命を預けて動くハードウェアなので特に品質を徹底しなければいけない類であり、工場や生産ラインの設計にはその本気さが伝わってきて面白い。
自動車(量産型)のような製品の開発体制としての要件をすごく簡単にまとめると:
・決まった仕様の製品を
・高い品質で
・大量に作る
ことである。
R&D部門が長い時間をかけて辿り着いた完璧な製品仕様を忠実に複製していく活動。
フレームやボディなど均一に作る型も決まってるしネジなどの材料の規格も統一されていてブレは許されない。全く同じ動作を正確に繰り返すことが必要なのでロボットが多く活用される。
組み上げたあとのテストも念入りに行われる。自動車はテスト走行で何キロも走らせられ各種操縦系の確認も入念に行う。生産ラインからランダムに車を引っ張ってきてテストコースでしっかり走行テストも行う。
これらの生産→テストの工程を経て顧客の元に車が届く。
ソフトウェアを作るとして
ではソフトウェアはどうかというと、ほぼ真逆。
・毎回仕様の違う製品を
・高い品質で
・一つずつ作る
共通するのは「高い品質で」だけ。Facebook初期の「Move fast and btrak things」というマントラを思い出すとそれすら疑うカルチャーもあるのかもしれない。
さらに「仕様の違う製品」というのもまた曲者で、その仕様が顧客価値や事業価値にとってプラスかどうかの保証がない。ハードウェアのようにR&D部門の人たちがじっくりことこと煮詰めた魔法のレシピなんてない。
「速い」と「良い」はトレードオフではない
こうして整理してみると、なぜソフトウェア開発の現場がアジャイルだのスクラムだのリーンスタートアップだの心理的安全性だの「人」中心の開発管理手法に重きを置いてるのかがわかる。ソフトウェア開発は結局のところ、R&Dと実製品生産がほぼ同時で行われているプロセスなのだ。
そしてそれは速く作れば作るほど価値が上がる。その理由を説明する。
まず、前提状態として:何かソフトウェア実装依頼の要件を受けて「さあ作るぞ」と思い立った時点ではそのソフトウェアの正解の姿がわからない。お客さまの求めてるものなのかもわからない。事前のユーザーリサーチ、PRD、仕様書、設計書など様々な資料が用意されるがそれらは予想でしかない。乱暴に言うと「たぶんこれでいけると思う」という自信度の資料。それはなぜかというと、機能実装の依頼をするたびに「実際の提供予定ソフトウェアを一つ完璧に作り上げて入念な顧客とのテストをする」なんてしないからだ。というかそれが出来てるならそれはほぼ最終成果物そのものだし。
ではどうしよう?確度の低い仕様書とエンジニアの想像力に任せて「これがお客さんの求めるものだと良いんだけどなー」と祈るしかないのか?
ぶっちゃけそう。祈るしかない。
なので何をするかというと、顧客にぶつけるソフトウェアの単位を小さくする。超最低限のソフトウェアだけ作って、顧客にぶつける。そしてその結果を定性分析&定量分析をすることで「顧客の求めていたもの」の解像度がちょっと上がる(そして大抵自分たちが自信満々で描いてたものがズレてるのだと実感する)。
それをいかに速くとっとと出すかどうか、そしてどの程度の頻度で出すか、どれぐらいレベルの高い分析ができてるかが最終的なソフトウェアの品質を向上させていく。
つまり、「速い」方が「良い」ソフトウェアを作ることにつながってるのがわかる。「速い」と「良い」はトレードオフどころか正の相関なのだ。
時間をかけてとことん品質にこだわってても、それが顧客に求められないものならそれは「良い」ものではない。残念。できあがったのは綺麗な骨董品でしかない。
さらに「リーンスタートアップ」もこれと同じ考え方。こっちはそもそも開発着手前から高頻度で顧客からフィードバックをもらうサイクルを回して実際の製品の打率を高めにいくという発想。
※これがアジャイル開発においては Extrinsic Quality (日本語では「製品品質」と言われてるのを見かける)と呼ばれる。
速さとトレードオフになる品質
一方で、速さを理由に妥協してはいけない品質というものも実際にはある。それはソフトウェアが意図通りの振る舞いをするかどうかの軸での「品質」だ。
残念ながらこっちの品質は速さのために雑な開発プロセスを経てしまうとおろそかになってしまう。せっかく顧客が求めるものがわかったのに、急いで適当に作ったせいでそれが顧客の手に渡った時にロクに動かないガラクタなら意味がない。
「バグや脆弱性のないソフトウェアを作るにはどうしたらいいか」という命題で数えきれないほどの本や研究がこの世にはあるのでここでは特に言及しない。
だが大事なのはとにかくここは自動化・仕組み化をすること。ここの光景はどちらかというと工業製品を量産する工場に似てくるはず。エンジニアおよび開発チームとして「とにかくこのフローを通ってこことこことここで青信号が出れば大丈夫なはず」というフローを構築するのだ。それはCI/CDやDevOpsの話もそうだし、手動テストも必要ならフロー化する。
そうすることで全員がクリエイティビティを発揮する活動に集中できる割合が高まる。
そしてこのフローを構築する(つまり工場を作る)ということにもエンジニアやPMの工数がかかるということを忘れてはいけない。CI/CDフロー構築に対して十分な技術投資ができているか?手動運用になってるところはないか?そもそもテストは書けてるのか?
自動車のような工業製品では工場の設計クオリティがそのまま車のクオリティに直結するように、ソフトウェアにおいても「どれだけちゃんとした実装〜品質担保までのパイプラインを設計・構築できているか」がその組織のソフトウェアの競争力に大きく関わると思っている。
ここに時間がかかってしまっては前述してた「速く作って顧客にぶつける」というサイクル自体が遅くなってしまうからだ。
特にCTOのようなポジションの人間はこの実装〜品質担保のパイプラインが出来ているかどうかに責任を負わなければいけないと思う。
※これがアジャイル開発においては Intrinsic Quality (日本語では「技術品質」と言われてるのを見かける)と呼ばれる。
速い・良い・高品質の関係
まとめると、速い・良い・高品質 の関係は下記の通りになる:
・顧客にとって良いソフトウェアを作るにはひたすら速く小さく作って顧客にぶつけなければいけない
・品質担保に時間がかかってしまうと、良いソフトウェアの正解を見つけ出すサイクルを遅めてしまう。速さの阻害にならないようひたすら自動化と仕組み化をしなければいけない
これらが全て地続きでつながっている概念であることを理解し、この関係性を常に頭に入れた状態でプロダクト開発体制を構築すること。これが冒頭の
顧客価値が高くて、高品質のソフトウェアを、速く出したい
という理想に辿り着くための道しるべだと考える。
この記事が気に入ったらサポートをしてみませんか?