余白

lacolacoの余白は無限である

『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んだ

シビレたフレーズ

放っておかない力

「技術的負債の返済に必要な腕力」について、すずけんさんとtwadaさんの一節。

す:腕力っていったい何でしょうね。

― 関係ないところに手を出す力、放っておかない力、というのがまずあると思います。 重要だけど緊急でないから誰も手をつけないところをゴリゴリ巻き取っていくためには、カッとなる力、放っておかない力が必要です。

フルサイクル開発者の仕事はビジネス

Zucksのフルサイクル開発思想について、河村さんとtwadaさんの一節。

― これだけ多様な技術が使われているシステムでフルサイクル開発者であることが求められるとしたら、場合によっては「言語を学ぶ」ところからスタートすることもありそうです。

河:ある言語が好きで、ほかの言語は絶対に使いたくないといった人には、耐えられないかもしれません。 フルサイクル開発者の仕事はコードを書くことだけでなく、ビジネスなんですよ。

業務として向かい合うシステムへの誇り

レガシーな大規模システムをゼロから作り直すことに決めるまでの過程について、ねこやさんとtwadaさんの一節。

ね:...これがもし自分たちで作ったシステムであれば、どんなに足をすくわれるような状態であったとしても、腹をくくって本気で対処できます。でも自分たちが作ったわけでもない、データベースの構造を含めて問題が多いシステムに立ち向かい続けることには、エンジニアとして辛いものがありました。

― 開発チーム本来の実力が発揮しにくい状態だったのですね

ね:その意味で、自分たちが業務として向かい合っているシステムに、開発者が誰も誇りを持てていなかったと思います。 この状態が長く続けば開発チームとして回していくのが難しくなるという危機感みたいなものがありました。

ギバーのジレンマ

他者に対して惜しみなく何かを与えるギバーがもてはやされる昨今、しかし与える者はそれを受け取る者がいてはじめて成り立つ。

自身がギバーでありたいと望むならば、他者がそれを受け取ってくれることを望まずにはいられない。 そのとき、利他的でありたいという欲望は、他者の利己的な姿勢を求めるという意味において利己的な欲望として現れる。

多くのビジネス書などでは、成功する確率が高いのはテイカーよりもギバーであると言われている。 そのような状況でみずからテイカーになろうという者のほうがむしろ自己犠牲的とも言えるのではないだろうか?

つまり、利他的であろうとすればするほど他者の自己犠牲を求める利己的な姿勢として現れてくるのではないだろうか?

ヒーローであるためには世界に悪がいなければならないヒーローのジレンマのように、ギバーでいるためにはテイカーにいてもらわなければならないギバーのジレンマがそこにあるのではないか。

読んだ本 2022-Q2

2022 4月〜6月に読んだ本・読み始めた本

まだ読んでる

読んだ

これから読む本

NOISEは積み続けている。『省察』を読み終わるとようやく17世紀哲学に区切りをつけて18世紀へ迎えるので楽しみ。

スピノザ『エチカ』とライフハック本

スピノザ『エチカ』を読んだ。『エチカ』を読み終わったあとに、参考書として上野修スピノザの世界』もあわせて読んだ。

www.iwanami.co.jp

bookclub.kodansha.co.jp

表現は確かに異質なものではあったが、その中身は不思議とすんなり入ってきた。

そのタイトルの通り、『エチカ』は倫理についての哲学であり、「善く生きるとはどのような生き方か?」という問いに答えた本だと思った。 結論をざっくりまとめてしまえば、第5部に書かれているように、自分の感情を理解すれば感情に振り回されること少なく幸福に生きられる、それが理性的に生きる賢者の道だということだ。

だが、こんな風にまとめてしまえばまるで自己啓発本のようだ。これではあまりにも安っぽい受け取り方なのではないか? そこで思い出したのが、先日読んだ千葉雅也氏のインタビュー記事。

哲学者・千葉雅也が語る、「哲学・思想」と「自己啓発・ライフハック」の意外な関係(千葉 雅也) | 現代ビジネス | 講談社(4/5)

多かれ少なかれ、人間をテーマにした哲学は人の生の本質を問うのだから、自己啓発ライフハック的側面を持つのは当然だろう。 哲学とは論理の学である。哲学書として読むのなら、結論が導かれるまでの抜け目ない論理の組み立てを追いかけ、疑い、たしかめることが必要だ。 だが、『エチカ』をライフハックとして<役立てる>ことができるのもまた事実だろう。その観点では『エチカ』は哲学書だろうが思想書だろうが自己啓発本だろうが、役に立つならジャンルはなんだっていいのだ。結局は、その本とどのように向き合うかというこちら側の姿勢だ。

17世紀ヨーロッパを代表する哲学書のひとつでもあり、2022年になってもまだ使える自己啓発本でもある。 『エチカ』はそういう本だといっても怒られはしないだろう。

『状態目標が隠された行動目標』がもたらす混乱

今日の種記事 いつもながらしんぺいさんは面白い種をくれる

nekogata.hatenablog.com

この記事で僕が引っかかったのは次の部分

「機能」は「できた」「できなかった」の二値なのだけれど、ユーザーストーリーは「めちゃめちゃ実現できた」「おおよそ実現できた」「少し実現できた」などのグラデーションがある、という見方はどうだろうか。

「機能」は「できた」「できなかった」の二値、ということは本当に真なのか?真だとすればそれは何によってか?ということを考えてみると、そこには『目標の到達度』の認識に混乱をもたらす『状態目標が隠された行動目標』という概念を言語化できた。

目標の到達度

目標は大きく行動目標と状態目標に分けられる。この違いは何をもって目標に到達したとするかによる。

  • 行動目標: ある行動ができたときに到達する
  • 状態目標: ある状態になったときに到達する

目標は到達することが目的である限り、つねに「到達したかどうか」を評価される。そしてその評価は少なくとも「到達した」「到達していない」の2値で評価可能である。この評価すらできないならば永遠に到達不可能なので、そのような目標は目標として存在しえない。

そして目標への到達度合いを、2値よりも小さな単位で段階的に評価したいという欲求から、到達度の定量的な計測が試みられる。 どのような目標であっても、その到達度が表すのは「目標までの距離が、スタート地点からと比べてどれほど短くなったか」であるはずだ。

さて、行動目標における到達度は、その工程の進行度合い(進捗度合い)であるはずだ。 その行動ができるまでに必要な工程のどれだけの割合を完了しているか、それは工程の個数ベースの割合もあれば、労力の負荷ベースの割合もありえる(登山と同じ)。 どのような基準にせよ、行動目標において段階的な到達度の評価には、工程の分解が必須である

一方で、状態目標における到達度は、その状態をなんらかの指標で定量化した比較評価である。 したがって、状態目標において段階的な到達度の評価には、中間状態を評価できる指標を持つことが必須である

行動目標ができた・できてないでしか評価されないのはなぜか

ある目標が真に行動目標なのであれば、上述のとおり工程の進行度で評価できるはずである。 逆にいえば、行動目標であるのに到達度が測れないときに考えられる要因は次の2つだけである。

  • 工程がそれ以上分解されない場合
  • 形式上は行動目標であるが、裏に暗黙的な状態目標がある場合

1. 工程がそれ以上分解されない場合

その行動が複数の工程に分解されていないなら、その行動目標の評価はできた・できてないの2値が限界であるのは当然である。 行動が複数の工程に分解されていない理由は、もはや分解できない最小の単位であるか、分解を怠っているかのどちらかであろう。

2. 形式上は行動目標であるが、裏に暗黙的な状態目標がある場合

形式上は行動目標であるが、裏に「その行動がなされた後に実現されるであろう状態」になることが暗黙的な状態目標としておかれている場合には、その行動目標の評価はできた・できてないの2値になってしまうことが考えられる。

なぜなら、その行動目標のための工程がどれだけ進んだとしても、「隠された状態目標」側の指標で評価すれば到達度が変わっていないことがありえる。 そのようにして最後まで中間状態が変化しないような工程を組んだ場合には、行動目標の到達と同時に状態目標が到達することになり、結果的に2値での評価となる。 つまり、本当は行動目標ではないために、行動目標としては到達度をあらわすはずの工程の進行度が、隠された状態目標としては無価値となるという現象が起きえる。

状態目標が隠された行動目標

そのような、『状態目標が隠された行動目標』は、いわば手段が目的化した目標であるとも捉えられる。 なぜなら、本当は状態を目標としているはずなのに、それを達成する手段のほうを形式上は目標としてしまっている。 このことによって、異なる手段を選ぶ余地を自ら閉ざしていることになる。

ただし、『状態目標が隠された行動目標』であったとしても、到達度を段階的に上げることはできる。 なぜなら、『状態目標が隠された行動目標』の到達度が2値になるのは、そのような工程を組んだことによる結果であるからだ。 状態目標が隠されていたとしても、工程の途中段階で中間状態が変わっていくのなら、到達度は行動目標としても状態目標としても段階的に評価できる。 2値になってしまうのは、工程の進行段階で状態に変化がなかったために、最後まで0から動かなかっただけである。

『状態目標が隠された行動目標』からみる機能開発とユーザーストーリー

ようやく冒頭の話題に戻ってきた。

まず、「ある機能を開発してリリースする」という機能開発は明らかに行動目標である。 そして いわゆるユーザーストーリーは「誰々をどのような状態にしたい」ということから明らかに状態目標である。 この整理と上述の『状態目標が隠された行動目標』から、冒頭の問いを解いてみよう。

「機能」は「できた」「できなかった」の二値なのだけれど、ユーザーストーリーは「めちゃめちゃ実現できた」「おおよそ実現できた」「少し実現できた」などのグラデーションがある、という見方はどうだろうか。

機能開発はリリースできたかどうかというのが基本の到達度評価であるが、上述のとおり行動目標であれば到達度は工程の進捗度によって段階的に評価できるはずだ。 ということは、機能開発をいくつもの工程に分解し、進行しているにもかかわらずその到達度を0とするなら、それは裏に隠された状態目標があるとしか考えられない。 そして多くの場合で、機能開発はそのリリースによる効果や価値を見込んでいるのであって、ほぼ間違いなく裏に状態目標がある。 つまり、機能開発という行動目標は間違いなく『状態目標が隠された行動目標』である。

このような場合、プロダクトマネージャーの心中ではユーザーストーリーという状態目標があるにもかかわらず、開発者は機能開発という行動目標を追跡するような認識のすれちがいが起こりうる。 それは状態目標として評価する人と、行動目標として評価する人は、物事を異なって評価しているためであり、「進捗しているのに評価されない」と「時間をかけているのに変化がない」が両立する。

また、『状態目標が隠された行動目標』は形式上は行動目標となっているため、工程を途中で見直すということは行動目標として到達度を下げる行為になり、負のインセンティブがある。 しかし状態目標としてはよりよい手段を選択しただけであるため、到達度に変化はない。この点でも物事の見方が大きく変わってしまう。

ところで、なぜ到達度を段階的に評価したいのかといえば、連続的な到達度の変化を追跡することで到達するまでの時間やコストの予測ができるからだ。 つまり、到達度の推移を分析することで見積もりの精度を高めようとしている。 コストやスケジュールなどのトレードオフを考え、計画を立てるにあたって必要とされているから到達度が2値では困るのだ。

そのことを踏まえると、『状態目標が隠された行動目標』というのは解消すべき問題であるといえる。 この問題を解消する方法は2つしかない。「真の行動目標にする」か「状態目標に置き直す」かのどちらかだ。

『状態目標が隠された行動目標』を本当に行動目標にするということは、工程の進捗度を到達度として評価することだ。 まだリリースされていないが、確実に工程は進んでいる。そのことを評価基準とすることを選ぶなら、真に行動目標となる。 しかし多くのプロダクト開発、サービス開発では、結局ユーザーにどれだけ影響があったのか?ビジネス上の効果があったのか?ということを問わずにいられないだろう。 したがって、この方法は現実的には選択できない。

残された方法は、『状態目標が隠された行動目標』を明確に状態目標であると置き直すのである。 状態目標であることが明らかになることで、工程がどれだけ進捗していてもそれだけでは価値がないことが明確になる。 そうすると、段階的に状態が変わるような工程を組まなければならないことが目標を共有する人々の間で共通の認識になる。

世にいうアジャイルな開発というのは、そのような認識を共有していることが前提となっているのではないだろうか。 到達度を上げるためには状態を変えなければならないので、リリースをなるべく早く行おうという力学が働く。 リリースを早く行うためには、小さな単位でリリースしようとする。 小さくリリースするたびに中間状態を評価し、工程が最適ではないなら組み直す。 行動目標を追いかける立場としては「手戻り」としてリリースが遠のくため避けたい判断だが、状態目標を追いかける立場では最適な判断になる。

スコープ調整とは到達度のコミットメントを変更すること

このように考えれば、手段の「スコープ調整」を自然なものとして可能にするための条件は、前提となる目標が状態目標であることだと言えるのではないだろうか。 行動目標にとって手段とは工程であり、達成度そのものである。その上で「やることを変える」は工程を破壊する行為になってしまい負のインセンティブがはたらく。

冒頭のしんぺいさんの記事でも触れられている次の記事に書かれたことは、僕が言いたいことを別の視点から言っている。

mactkg.hateblo.jp

でもスクラムのスプリントゴールっていうのは多分そういうことなんだと思う。今のところこういう仕立てがいいと思うんですよね、とPBIを使ってPBLに表現されているけど、達成したいことはスプリントゴールに書いてあることである。スプリントゴールに書いてあることが達成できるんだったらこういう方法でもいいじゃん。という「スコープ調整」を毎日していくことがスクラムとかでやっていきたいことなんだろうなと思う。

スコープ調整とは何か、それは本来見込んでいた「このスプリントではここまでいける」という到達度のコミットメントを変更することだ。 したがって、行動目標であっても状態目標であっても、到達度が段階的なのであれば調整できる。当たり前だが、到達度が2値の目標について、到達度のコミットメントは調整できない

たとえばスプリントゴールが「○○をリリースする」という行動目標だとすれば、それが間に合わないということはイコール到達できないことになる。その上で行われるスコープ調整とはリスケジュール以外にない。なぜなら「○○をリリースする」のが目標なのだから。ところが機能のリリースは『状態目標が隠された行動目標』なのであって、どれだけギリギリまで進捗していても状態目標としての到達度は0である。このようなスプリントで何が検査できて、何が学習できるだろうか。

達成したいことはスプリントゴールに書いてあること

つまり、この「達成したいこと」は段階的に到達度を評価可能な目標として書かれていなければならない。そしてそれは多くの場合、状態目標を書くべきなのである。 状態目標の到達度をコミットメントとするのなら、そのコミットメントさえ果たせるのなら手段をいかようにも変更可能になる。そして、そのコミットメントを果たすのが難しいとなったときに到達度を調整することができる。

コミットメントを維持した手段の可変性と、コミットメントのレベルの可変性(トレードオフスライダーに加えられるということ)、この2つを確保することが多くの場合で求められてるのであろう。 そして『状態目標が隠された行動目標』の二重性をそのままにすることが、それらを強く阻害しているのではないだろうか。