仕事仲間のエンジニアが貸してくれたので読んでみた。
この本は、ジョナサン・ラスマセンという人が具体的手法と併せて説く、開発者のためのカルマ・ヨーガ論。なんて無理矢理ヨガっぽく書いてみたけれど、本当にそんな本でした。手法のところなんかは、まさにヨガそのものに置き換えられることが多くておもしろかった。
今日の内容は、開発系の仕事をしながらヨガに興味を持っている人が読んだら、きっとヨガをしたくなっちゃうよ。気をつけて（笑）。
ヨガをサービスとして提供する側にいる人にも、ためになることが多いのではないかな。
いいかい、アジャイル開発とは旅そのものであって、目的地じゃないんだ。この旅に終わりはない。
（287ページ「この先どこへ向かえばいいのか？」より）
こんな独特の口調の翻訳本です。
アジャイル開発の原則
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
（153ページ「スコープを柔軟に」より）
依頼する側は、こんなこと言われたら、たまらないよね。グッときちゃう。とても大切なこと。
ポジティブ・コーティングの病理で逆に鈍性が強く出てしまうことに対する「事実」の提示もすばらしい。
でも結局のところ、できないものはできないんだ。それでもなお、見せかけだけの「奇跡によるマネジメント」を続けるのなら、それはプロジェクト運営として実に残念であると言わざるをえないし、顧客の期待をマネジメントする作戦としてもたちが悪い。
（10ページ「アジャイルな計画づくりがうまくいく理由」より）
「顧客の期待」を「奇跡の土俵」に乗せることを、さも前向きに語るエゴへの指摘。
自己組織化とは、自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせるということだ。そのとき、それぞれがチームの一員として（各人のスキルと情熱と資質を発揮しながら）、どう振る舞えば最善の成果をお客さんに届けられるかを考え抜くんだ。
（23ページ「自己組織化」より）
振る舞いを説くなんて、まるでベスト・キッド。Attitude!
ただ職場に来て着席して、「刺身にタンポポを添えるだけの仕事」をこなしたあとは、上から言われたことを粛々とこなしているだけのほうがよっぽど楽ちんなのに、どうしてわざわざそんな面倒なことをしなきゃならないいんだ？ ── そう考えている人たちは君が考えているよりもずっと多いんだ。
（25ページ「結果責任と権限委譲」より）
刺身タンポポの、訳のユーモア。
チームメンバーを探すコツとしていくつかの記述があったなか、ここはすごくいいと思った。2つの表現を、箇条書きで抜き出す。
- 変化球が投げられても慌てない人を、それを打ち返せる人を探そう。脱線事故が発生したなら、冷静に電車を乗り換えられる人がいい。
- 自分のありのままの姿を受け入れられるだけの度量があり、人と分かちあうことをためらわず、お互いに学びあって成長することを心から楽しめるような人を探そう。
（38ページ「チームメンバーを探すコツ」より）
おもしろいマントラの紹介もあった。
どのリスクには取り組む価値があって、そうじゃないのはどれなのかを決めあぐねたら、今から紹介する「ニーバーの祈り」でも唱えて心を落ち着けよう。
願わくばわたしに、
変えることのできない物事を受け入れる落ち着きと、
変えることのできる物事を変える勇気と、
その違いを常に見分ける知恵とをさずけたまえ
神秘的に万能感を願うよりも、ずっといい。
以下は、限られた時間のなかでサービスを提供するフォーカスの技術として、グッときた。
もしもお客さんがどうするかを決めかねているようなら、「あるといいな（Nice to have）」リストを用意して、お客さんにこう伝えよう。「もしもプロジェクトの終了までに余裕ができた場合は、あるといいなリストに載っているストーリーに取り組みます」と。ここではっきりさせておかねばならないことは「あるといいな」はあくまでも当面はスコープ外だということだ。
（172ページ「お客さんが新しい要求を発見したら」より）
段取りを踏まないと実感成果にたどり着けない段階で発生する要求というのは、ヨガのカリキュラムを構成するときによくあると思う。「とりあえず、やってから」というだけでは火種がつかないときに、「とりあえず、置いといて」よりも一歩進んだ、よい手法と思いました。
以下は、まさにアーサナを動きながら分解するときのこととよく似ていた。
テスト駆動開発の基本を身につけて、そのリズムとパワーを体験すれば、だんだん考え方も変わっていくはずだ。失敗する小さなテストを書いて、テストに通るだけのコードを書く。そしてリファクタリングする。そうやって書いたコードやテストをきっと君も気に入ると思う。
（266ページ「一体なにが起きたのか？」より）
続けてひとつのコードのなかに「メソッドの可能性」「メソッド名」「戻りの値の型」「引数の型」「仮引数名」が含まれる例があったのだけど、アーサナの構造とはまったく同じ。
テスト駆動開発（TDD : Test Driven Development）という言葉を初めて知ったけど、わたしはこんなふうに、身体の状況を分解しながら、アーサナの構造を借り置きとテストを重ねてやっている。なにごとも、極意は似ているのかもしれない。
ヨガの極意もまさにここにあると思う。思い込みは、テストを前提としないところから顕在化する。
続きにあった、この文章がそれをまさに言い表していた。
テストの手を抜かないようにして、着実に技術的負債を返済していくんだ。
丹田のバッファで担保していくんだ。
よくアーサナのことを「ヨガは、エクササイズじゃないんだ」という人がいるけれど、わたしはこういう取り組み方であれば、ぜんぜんエクササイズでいいんですよ、とかねがね思っていた。思わぬところに代弁題材が登場した。
アーサナはものすごくよくできたリアライゼーションの実践技法。キーボードを使うか身体を使うかの違いだけ。といってもいいような。
脳みそまで筋肉にしなければ、というポイントさえハズさなければ、モノづくりの極意も感じられる。ヨガやっぱりいいわぁ。
（と、久しぶりに強引にみなさんをヨガの世界にお誘いしてみましたよ）
