フィードバックをイチから学び直す〜テスト駆動開発をやめて、なお残すべき習慣とは(4)

フィードバックの基本をおさえて、ソフトウェア開発の荒波を乗り越え、宝島に到達しよう

前回、テストの4象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。

フィードバックのおさらい

”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。

フィードバック(feedback)とは、もともと「帰還」と訳され、ある系の出力(結果)を入力(原因)側に戻す操作のこと。古くは調速機(ガバナ)の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89%E3%83%90%E3%83%83%E3%82%AF

フィードバックの仕組みは、調速機や負帰還増幅回路など機械やエレクトロニクスの特定分野で発展しました。フィードバックの仕組みを使えば、出力を増幅や振動を抑えるや一定周期にすることができます。フィードバックは、その後、サイバネティクスの登場で多彩な分野に広まっていきました。

フィードバックのメタファでよく使われるのが”舵取り””車の運転”構え撃て狙えです。サイバネティクスの語源をたどると、”ギリシャ語で「(船の)舵を取る者」を意味するキベルネテスにあたります。


ソフトウェア開発やスタートアップ分野でも、アジャイルな開発やリーンスタートアップなどにもフィードバックの仕組みが色濃く反映されています。動作するプロダクトの出力結果から市場にフィットするか否かユーザの期待に応えるフィーチャか否かを評価し、その情報を入力に戻して開発を続けます。

エクストリームプログラミングの場合、フィードバックで調整したい対象は動くソフトウェアとエンドユーザの関係性の改善だけではありません。調整したいのは、コードとプログラマの関係性、見積りに参加するときの参加者の気分、個人とチームの成長、開発に関わる人々の信頼関係など様々です。リリース計画、計画ゲーム、受け入れテスト、デモ、ペアプロ、TDD、ふりかえり、etc…どのスケールでも、どの時間を切り出しても自己相似的にフィードバックの仕組みがXPには多数内包されています。

https://en.wikipedia.org/wiki/Extreme_programming — http://theleanstartup.com/principles

フィードバックの仕組みのポイントは、現状を評価し、目標やその先のゴールに向かって小さなステップを踏み、再評価し、小さなステップを踏み…を繰り返しゴール達成へと着実に近づくことです。初期段階で、中長期の計画をすべて出し切り、計画どおり実施して1回だけ評価して終わりとは異なります。また、フィードバックは、目標やその先のゴール達成を目指す1次フィードバックだけではなく、仮説の間違いや状況の変化に気づき、目標やゴールの再設定を行う2次フィードバックの活動も含まれます。冬の寒い日に冷房27度を設定する人は少なく暖房に切り替えるでしょう。(ただしこれも常に妥当な判断ではありません。暖房が嫌いな人はどうするでしょうか?南国の場合は?部屋がサーバ室の場合は?)。


リーンスタートアップやソフトウェア開発の場合、ゴールの変更は、”思い込みを捨てよ”や”プランAは捨てよ”や”ピボット”や”ムービング・ターゲット”の言葉で表現され、プロダクトバックログの優先順位の入れ替えで明確に現れます。間違った方向に走るムダを防ぐため、プロダクトオーナーはスプリント停止の判断をすることもあります。

ソフトウェア開発においてゴール変更に対する俊敏な舵取りで対応できるようにするため、開発ではコードをシンプルに保つこと、ビルドやテストやデプロイや環境構築等を自動化しておくことが欠かせません。重たい技術的負債を背負いながらでは、ビジネス上の俊敏な舵取りはできません。

正のフィードバック、負のフィードバック

フィードバックには正のフィードバック、負のフィードバックがあります。正と負が名前わかりにくいですが、別名として正のフィードバックを自己強化型ループ負のフィードバックをバランス型ループと呼ぶ場合があります。(正≒良い、負≒悪いではありません。)

正のフィードバック

正のフィードバックが働いている場合、フィードバック系の増幅率は裸の増幅率より大きな値となる。ここで特に系のループ利得が1を越える場合には、何らかの破綻が起こるまで出力は増大しつづける。

時系列グラフにすると、出力結果が上昇(または下降)傾向が出ている場合、そこに何かしらの正のフィードバックの機構があります。ビジネスのコンテキストでは事業拡大や顧客や従業員の幸福度の向上を生み出すフィードバック機構を経営者と従業員と顧客が協力して作ろうとしていることになります。

ソフトウェア開発の場合、継続的なデモを通じて開発チームとプロダクトオーナさらにはスポーンサーや営業やカスタマーササポートやユーザと信頼関係が深まっているのであれば、好循環の正のフィードバック≒自己強化型ループが働いていると言えます。そうではなくて、デモの結果で関係が悪化しているのであれば、悪循環の正のフィードバックが働いています。限界に達すれば決別や定期デモの活動が停止し、プロダクトは死を迎えます。

負のフィードバック

負のフィードバックが働く場合は、フィードバック系の増幅率は裸の増幅率より小さな値となる。この増幅率の余裕分の範囲で、出力の増加は出力を減少させるように働き、出力の低下は出力を増大させるように働くので、出力の変動を抑えることが出来る。

時系列グラフにすると、出力結果が定常の傾向が出ている場合、何かしらの負のフィードバック機構が働いています。人間の身体の場合だと体温は上昇し続ける(下降しつづける)のが良い状態ではなく36−37度に保つのが良い状態です。身体には、ある一定温度を保てる用に微調整が行われおり負のフィードバック≒バランス型ループが備わっています。サーモスタットも、目標温度を保つように自動調整しますが、これも負のフィードバックです。

ソフトウェアの場合、運用中のシステムはなるべく継続して稼働するように、一定の性能を確保できるように仕組み化を行ないますが、これも負のフィードバックの仕組みの具体例です。近年は、自動復旧やオートスケールといった自動制御が進んでいます。

フィードバックを積極的にソフトウェア開発に持ち込んだ書籍

ソフトウェア開発のコンテキストで、正のフィードバックや負のフィードバックを積極的に探求したのはワインバーグやケントベックです。ヘンリックもリーンソフトウェア開発の現場の中でも積極的に利用しています。

ワインバーグは人の営みレベルにおいての、いかにしてソフトウェア文化≒舵取り文化をつくっていくかにフォーカスが当たっています。理想状態に近づくには、現状の異常に気付くことが欠かせません。状況が悪化しているや、停滞の傾向があるなら、そこには悪い意味での正のフィードバック、負のフィードバック機構が働いています。その問題のフィードバックループ構造を的確に把握し、レバレッジポイントを見つけて変えていく活動のヒントがこの本に記載されています。ワインバーグの「ソフトウェア文化を創る」シリーズは4冊あります。出版が古いですが、スクラムマスターをマスターしたいなら読んでて損はありません。

ソフトウェア開発の活動は、仕様->設計->実装->テストのある決まりきったシーケンシャルな活動ではなく、トライ&エラーによる仕様設計実装テストの学びが多くを占めます。『テスト駆動開発』は、「動作するきれいなコード」に一歩でも近づくための舵取りの具体的なやり方を解説した稀有な本で、プログラマ必読書です。

25章以降の正のフィードバック、負のフィードバックの表記を使ってプログラマの心理面まで踏み込んだ解説は興味深いです。「時間がないからテストを書かない」から生じる悪循環の正体を知りたいなら、手にとってみて下さい。付録には正のフィードバック、負のフィードバックの図の読み方が紹介されているので参照すると良いでしょう。新訳が出たので別の機会に解説したいです。訳者、出版社に感謝です。

本の表紙がもう舵取りそのものです。後半に開発あるある課題を因果ループ図を使って明らかにし、対処する方法が記載されています。

まとめ

フィードバックについて解説しました。出力結果を入力に戻す機構のフィードバックは僕らの身の回りに多数存在します。ソフトウェア開発にもです。

ある調整したい値が上昇傾向もしくは下降傾向があるなら、そこには正のフィードバック(自己強化型ループ)が働いています。ある調整したい値が定常の傾向があるならそこには、負のフィードバック(バランス型ループ)が働いています。

フィードバック自体は常に良いものでもなく、悪循環、まずい状態の停滞、振動などの悪い状況もフィードバックの仕組みが生み出します。悪い状態を生み出すフィードバックの仕組みを把握し、ちょっとづつ試行錯誤しながらレバレッジポイントを見つけて、好循環や良い状態の維持ができるようにフィードバックの仕組みに手を加えていくのが、フィードバックとの向き合い方です。ケントベックは書籍エクストリームプログラミングやテスト駆動開発の中で、開発者としてそのフィードバックの向き合い方について解説しました。

テスト駆動開発をやめても、顧客に価値を届けることを妨げる問題のフィードバック構造を見極めること、顧客に届けるためのフィードバック構造に置き換え続けることは欠かせません。でなければ、メンテナンス可能なコードを維持することは難しいでしょう。運用中のサービスが不安定になるでしょう。市場にフィットしたプロダクトを生み出すことは難しいでしょう。事業拡大の途中に技術的負債の制限にぶつかり事業の停滞や縮小に向かってしまう場合もあるかもしれません。プロダクトを中心に集まる人々の信頼関係は崩壊に向かうかもしれません。etc…

次回は、書籍「実践テスト駆動開発」を使ってフィードバックについて更に解説を加えます。