ひりひりする。

別に言わなくてもいいことだけど言っちゃうけど会社とかだとね、やっぱり利害が絡んでるんで、嫌いな人とかいるわけです。いやなこともある。そういうのを殴り倒し（＝解決し）ながら進めればいいですけど、人間は弱い。半分受け入れ（軋轢を起こしたくないから、負けたりやり込められたりしたくないし）、半分は不満として抱えたりどこかで吐き出したり（そこに巻き込まれる人はいい迷惑だけど）しながら生きてる。だれかに迷惑をかけつつ、自分も迷惑をかけられつつ、弱いところにしわ寄せをし、しわを寄せられ生きている。

「すべての人が最善を尽くしているものとして考え振る舞う」だの、「尊敬を価値とする」だのなんてのはまぶしすぎて、できないですよ。絵空事とまでは言わないですけど、そこまでまっすぐにはなれない。多くの人が、まあそこまでマジにならんでもいいだろうということでうやむやにして生きている。

そんなところに上司からやれって言われたからってちゃらく話を持ってこられちゃ困る、ってところですかね。

7つのムダ

さすがトヨタ、このクラスの人は誰でもトヨタ生産方式についてぶれなく話す。

で、先日のエントリにも同じようなことを書きましたが、ムダとは本質的じゃないものすべてです。トヨタの人が言う7つのムダってのはMECEでもなんでもなくて探求したり議論して工夫を重ねるためのきっかけのワードだから。誰か偉い人が決めるものでもないし、確定しているものでもない。システムやサービスの開発における要求と似てるっちゃ似てる。

請負契約とアジャイル

日本市場における一般的なSI契約の形態である請負。請負契約ではアジャイル開発はできない、難しいという声はよく聞く。

請負契約では仕事の完成を請負人が請負うわけで、最初に完成させるものが決まっていて定額で作業するのが請負だから、ゴールが変動するアジャイルとは合わない、という理屈だと思う。

まあ分かるのだが、ちょっと深掘りしてみたい。

そもそも請負契約における「仕事の完成」ってなんだろう。注文者と請負人の間で合意さえ得られればどうにでもできるのだろうか。 ということで、ネットで見られるソフトウェア開発委託契約の契約書をちょっと見てみる。

JISAソフトウェア開発委託基本モデル契約書2020(契約書雛形(条項のみ)・PDF版)

ウォーターフォールモデルで、まず要件を定義し、仕様を策定し、そしてソフトウェアを作成する。前工程のアウトプットドキュメントが次工程の完成の定義になるとしており、もうアジャイル開発（スクラム的な）を行う余地はない。

契約書ひな型「ソフトウェア開発委託契約書」 | さいたま・上野御徒町の法律相談なら弁護士法人 阿部・楢原法律事務所

こちらは軽量な契約書で、受託人はソフトウェアを作成し、注文者は別途定める方法で納品検査をする、としか言っていない。これなら、アジャイル開発を行える可能性がある。

例えば、契約時に列挙された要件は出発点であって、ある時点での成果物で双方が合意すればそれを仕事の完成とする、としてもいいように思える。

なんだかふんわりした契約に思えて本当にそれで大丈夫なんだろうか、という気がするかもしれないが、それは営業努力とか信頼貯金でなんとかするべきことかもしれない。

もうすこし具体的に注文者と請負人の利得について整理して、受託アジャイル開発の完成の定義について考えを深めてみたい。

アジャイルソフトウェア開発宣言と原則を再考する

アジャイルソフトウェア開発宣言

  • プロセスやツールよりも個人と対話を、
  • 包括的なドキュメントよりも動くソフトウェアを、
  • 契約交渉よりも顧客との協調を、
  • 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

これ本当に価値なのかという点で若干疑問がある。

△に価値があることを認めながらも○により価値を置く、としているときに、○が価値だろうか。 いや、○ over △となる□という価値(観)がある、なのではないかな。それを語った方がよりダイレクトな気がする。

で、考えてみたが、つきつめるとアジャイルの価値は「本質」ではないか。

と言ってしまうと、アジャイルの本質は本質です、と言っているかのようだ。目的はもちろん関係者のビジネスとか人生の充足でありまして、それを有意義に有効に行いたいという根源的なところは原本でも明記はされていないので引き続き略させてもらうとして、

  • 本質を外れたプロセスやツール、
  • 本質を忘れた生産物、
  • 本質を忘れた責任範囲論、
  • 本質を忘れたマネジメント、

そういうものが無駄を生みビジネスを失敗させ、関係を壊し尊厳を棄損するのをずっと体験してきた。もうそんなことはやめよう、という宣言なのではないかと。

  • 本質的な対話を
  • 本質的な成果を
  • 本質的な協働を
  • 本質的な行動を

本質を見つけ見失わず本質的な行いをするための、考え方ややり方、できることがあるだろう、と。なお、元本を要約して対話、成果、協働、行動ということばにしてみたけれども、それで全てでもない気はする。

さて、考え方のことを、原則と呼ぶ。

以下はアジャイル宣言の背後にある原則。

  • 価値のあるソフトウェアを早く継続的に提供することを通じて、顧客満足に最優先で取り組みます。
  • 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  • 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  • ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  • 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  • 動くソフトウェアこそが進捗の最も重要な尺度です。
  • アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  • 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  • シンプルさ（ムダなのでやらないことを最大化する）が本質です。
  • 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  • チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

これも原則じゃないものも混ざっているような気がする。これも再整理のために、ケント・ベック風に言い直してみる。何が本質かを問い、見出し、迫るには、以下のことを心がけるといい（ただし文脈依存）、というように読むやつ。

  • 優先順位
  • 小さな成果
  • 継続
  • 繰り返し
  • 変化
  • 人間性（これは価値かも）
  • 協働
  • 尊敬（これも価値かも）
  • 安全
  • 対話
  • 結果で評価する
  • 持続可能
  • 技術的卓越性
  • シンプル
  • 自己組織化
  • ふりかえり
  • 改善

加えて、アジャイル宣言の背後にある原則にはでてこないけど、これもあるじゃろ、と思うのは、

  • 仮説検証
  • 透明性
  • 品質を作り込む
  • 宣言的
  • テスト
  • 学習
  • 流れ
  • 習慣

やっぱりこれもまだまだあるような気がする。

（雑感）

組織運営のレフトウイングとライトウイング

モチベーションとかコミュニケーションのマネジメントは組織運営のレフトウイングですね。アジャイル開発のスクラムがカバーしているところもそうだと行ってもいいかもしれません。

組織運営はもちろんそれだけでは片手落ちで、事業を行っていく武器や商品も要ります。商品やシステムやノウハウなどがいってみればライトウイングでしょうか。

ライトウイングは業務知識と経験値の塊なわけで、レフトウィングはそれらの運用に役立たなければ意味がない。ここのところ現場毎にケースバイケースなので、本を読んだり講演聞いたそのままでうまくいくわけもないですよね。難しいのは当然かなあと思ったり。

書籍「JOB理論」に書かれていた、トヨタ生産方式が標準化にうるさい理由

標準化ができておらずばらつきがあると、価値あるメトリクスが取れない。標準化がしっかりなされていれば、生産がすなわち実験とみなせる。だから分析がしやすく、改善もしやすい、というわけ。

なるほどね。ばらつきを許さないというのはかなり厳しい要求なので、そのかわりラインを止める権利を与える、ってわけね。

非認知能力は能力か否か

「非認知能力」を「育てる」「評価する」ってどういうこと？ | あすこまっ！

興味深い。「非認知能力」と呼ばれているものを育むことはできると思うんだけど、他の能力の開発と違って、というのは一般的に能力開発には非認知能力が必要だから、非認知能力を育むにも非認知能力前提のトレーニングはできないのでね。それでも非認知能力が全くゼロでなければそのときあるものを前提に、あるいは非認知能力以外の使える能力を使ってトレーニングするのでしょう。ヘレン・ケラーの伝記みたいな感じ？

意見と、その背景にある経験、価値観、感情

なぜあの人と意見が合わないのか？　自己理解や1on1に使える「メンタルモデル」という考え方 - ログミーBiz

認知の枠の4点セット、つまり、意見には、その背景となる経験、価値観、感情がともなっている、それらとセットで意見を把握することがより的確な理解につながる、ということですか、これはよくわかる。

これはストーリーとかJOB理論のJOBなんかとも通じるものがあるような気がします。

（雑感）

アジャイルへの疑問はすべていままでのやり方の問い直し

会社で社内講演会的なものがあって推進部署の人がアジャイル開発について説明してくれた。質問や疑問はチャットに流してくれってことでそのチャットを見てると、工程完了判断はどうなるの？とか、品質はどうやって確保するの？とか、従来のやり方でプロマネやってきた人ならではの質問が並んだ。

従来のやり方ではこうやっていたのはアジャイルではどうなるの・どうするべきなの？その質問の答えは明らかで、あなたが今までやっていたことの目的はなんで、どういう仕組みでそれは有効だったのです？フィーチャー毎の短期開発の繰り返しで同じ目的を達成するには、なにをどうしたらいいと思いますか？と考えてもらうことです。できれば一人で考えるのではなく、チームの人たちと一緒に考えてみるといい。

そういうことをせず、リーダーの独断と、あまり説明と納得なしに空気読んでもらうことでチームを回すのは、大いなる無駄を許容する多重請負構造的ウォーターフォールだからできたことで、アジャイルはそうではないのですが、ウォーターフォールプロジェクトを回せるくらいのリーダシップと対応力のある人だったらできることだと思いますねー。

メタ・メンタルモデル

センゲの「学習する組織」を読んでいます。

メンタルモデルの整備が必要だろう、どうやって組織として「よい」メンタルモデルを持つのか。

  • ふりかえりの実践
  • 信じる理論と実際に用いている理論の対比
  • バイアスの認識
  • 本音の認識
  • 主張と探求のバランス

ふむ。

で、よく構成されたワークショップを行えば、ダイアローグによってメンタルモデルの開示、客観視、上書きは可能と著者はさらっと言っている。

おいおい、本当かよ。人間そんなに簡単にこころの仕組みを開示したり改めたりするか？

これだからローコンテキスト世界で育ったやつは。。。メタ・メンタルモデルがお気楽すぎるんだよ、と思った。