天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

アジャイルコーチとスクラムマスターの集い（2023年11月16-18日）に参加してきた(Day2)

www.attractor.co.jp

昨日に引き続き、こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

朝食

ryuzeeさんと一緒に(途中から工藤さん天野さんも近くにいらっしゃいました)朝ごはんを食べていきました。朝ごはんでも目から鱗の学びが得られるのがリトリートのすごいところで、以下のような話をしていきました。

  • ryuzeeさんが早起きに至るまでの変遷(子供ができて自分の時間を作るために早起きしはじめたということでしたが、「自分の時間を作ろう」というのは誰もが思っていることなので、そのモチベーションだけで本当に早起きができるようになったのか？というのを聴いたり、早起きになるまでにどんなstepを踏んでいったのか？という話を聴いたりしていきました)
  • 子供の睡眠事情
  • 次出てくることが予定されている翻訳書に関しての話
  • 翻訳レビューのパターン(大人数にレビュー依頼をするような場合、粗々の状態でレビュー依頼をしてしまうと同じような指摘が膨大に来たときのコストがめちゃくちゃかかってしまうので、例えば翻訳者同士で一旦レビューをしてしまい最低限の品質を確保するようにしてからレビュー依頼する。一方で、少人数にレビュー依頼をするときは、粗々の状態でレビュー依頼をする)
  • 翻訳レビューで挙げられるIssueの数の目安
  • とにかくブログをがーっと書いてみるという姿勢が大切になってくる話(本を執筆するときも、まずはいい文章を書こうみたいな気持ちを捨てたほうがうまく書けることが多い話)
  • とにかくブログをがーっと書いてみるのが大切な一方で、ある程度人に見られる前提で文章を書くことの重要性や意義
  • 睡眠負債や睡眠タイプ、昼寝の話
  • 実はショートスリーパーはいないという話
  • 翻訳を10年続けてきたことで得た資産(自作の校正ツールやスクリプトなど)
  • ryuzeeさんのブログメンテナンス術
    • スクラムガイドなどのバージョンアップに対応しやすいようにはてなブログなどを使わずすべて一つのテキスト形式で保存している話
    • 自作の校正ツールをブログにもかけるようにしている話
    • 前と考え方が変わったときや技術が現代のトレンドに追いついていないと考えられたときは積極的にブログ記事を非表示にしていく話
    • コードと同じようにブログをメンテナンスする話(一つの変更があったときに複数変更箇所があるような状態を作らないようにする)
    • GAでみんなの興味やよく見られている記事を解析し、解析結果をもとに定期的に内容をメンテナンスしていく
  • ブログのメンテナンスやObsidianを活用したナレッジマネジメントのTips
  • ryuzeeさんが子供にもObsidianを勧めている話
  • kiroさんの異次元の記憶力

bonotakeさんと雑談

bonotakeさんと会い、「昨日はあまり会話できなかったので今日どこかで会話しましょうー」という話をしていたら、昨日の過ごし方の話からそのまま会話がスタートし、色々と雑談をしていきました。

最初はお互いにどのような過ごし方を昨日していたか？テーマを今日は出さないのか？という話をして、自分がOSTで意図的にテーマを出さずに、今このメンバーでこのテーマを話したら絶対に面白いというタイミングを見計らう(&ちょっぴり自分自身で話題転換する)ようにしているという話や、bonotakeさんが昨日のOSTでテーマを出してみたところ得られた学びの話をしていきました。

bonotakeさんが昨日のOSTでテーマを出したという話の流れから、どんなテーマを出したんですか？という話になり、ウミガメのスープをスクラム版で行ったという話を聴いていきました。ただ、bonotakeさん的にはウミガメのスープをスクラム版で行うのみならず、問題を新しく作るところもやれるとよりよかったということで、OSTの続き的な感じで、どんな問題だと面白そうかな？という話を二人でしていきました。

その過程で、スクラムをしていてあるあるな状況ってこういうものがあるよねーという話をいくつか二人で出し合ったりしていって、そこからいくつか問題の種を考えていきました。

問題の種を考えている過程では、スクラムをしていて勘違いされがちな要素の一つしてMVPがあるよねという話になり、ちょうど先日角さんからの話があったMVPにまつわる誤解を紹介し、現場でもあるあるだよね、やっぱりあのMVPの図はコンテキストが切り取られて紹介されがちだよねという話題*1で盛り上がったりしていきました。

結果的にウミガメのスープのアイデアが一つ思いついたというところで、OSTでテーマを出すよりも雑談から引き出すアプローチのほうが意外とやりたいことを達成できるのかもね、という話で最後は終わりました。

マーケットプレイスづくりを眺めながら洋さん森さんと雑談

朝食後は少し時間が経った後にマーケットプレイスづくりが始まりました。

初日はみなさんあまりテーマを出したりせずにその場で起きる雑談を楽しむような形だったのですが、2日目はエンジンがかかったのか、がんがんテーマを皆さん出していて、マーケットプレイスが埋め尽くされる勢いでした。

作られていく様子を眺めていたところ、洋さんと森さんに声をかけられ、自分がテーマを出さないのか聞かれたので、上のbonotakeさんとの雑談でも書いたようにここだ！というときに準備している話をしたところ、自分が話を聴きたいと思っているようなメンバーが思わず集まってしまうようなテーマを出すように森さんに煽られてしまいました。

洋さんは、マーケットプレイスづくりを遠目に見ながら、テーマに対して意図的に(??)斜に構えたコメントをされていて、テーマに対して毎回一言何かしら呟いているのが面白かったです。(現場ではそのようなコメントをめちゃくちゃ優しく伝えるようにしているということ)

テーマを見たり洋さんのそんなコメントを聴きながら、学びの速度の格差はChatGPTでがんがん広がってきている印象があるという話や、自分が知っている概念に置き換えて理解できた気になってしまい原典などを調べない人がいる話などになり、自分から能動的に学べない人はどんどん淘汰されていくという話のオチには耳が痛い思いでした。(耳が痛い話だと言ったところ、洋さんからは「耳が痛いのはわかったけどじゃあどうするの？」と言われました笑)

アーニャ大会

せなちゃんのテーマでアーニャを描いてみる会が開かれていました。

すでにめちゃくちゃ上手なアーニャが描かれていたことに加えて、自分は絵がめちゃくちゃ下手なので、これに参加することはないかなーと思っていたのですが、絵がうまいかどうかで参加することをためらうことにはならないという話が出てきて、なんとなく自分も描いてみることにしました。(手本を見ながら描いたのですが、案の定めちゃくちゃ下手くそでしたw)

自分が絵を描いている様子を見て、「ディテールから作ろうとした結果、書くことができずに諦めているのが面白い」とKappaさんからFBをもらい、絵を描くのはウォーターフォール開発しかできないんだな、と思いました笑

フルリモートにおける顔出し問題

アーニャを描いた後は石井さんやKappaさんのフジロックフェスの話を聴いたり、最近の音楽の複雑性が高い話を聴いていたのですが、自分がtrebyさんに一緒に走らないかのお誘いをしたことがきっかけでその場にいたtrebyさんからフルリモートにおける顔出し問題に関する話が出てきて、途中から合流したAckyさんと一緒に思うことを話していきました。

フルリモートでお客さんを支援していると顔出しを自分以外みんなしてくれないことに寂しさを感じるという話から、顔出しをお願いするとどんなことが起きそうなのかな？という話になり、リモート会議の原則として顔出ししないなら顔出ししないに統一し、顔出しするなら顔出しするに統一したほうがいいと言われてはいるよね、という話になりました。
また、顔出しをしない背景として、大企業ならではのコンテキストって実はあったりするよねという話になり、例えばパワーが強い人がいるような状況では誰かが顔出しするとその人が見せしめ的になってしまうことが多いという話を聴いたり、お願いさえすれば顔を出すこと自体はよくあるよね、という話を聴いたりしていきました。

話の流れで、支援をしていると顔出し以前にそもそもチームと一緒に働きたくないという話がありがちだという話や、顔出しをする/しない以前に外部環境から負の影響を受けてしまうチーム自体の問題を解決したりしたほうがいいよね、という話や、バイトリーダー的な振る舞いをどうしてもしたくなってしまう理由とコンサルタントへの委譲に関する話などが出ていました。

責任の重さと給料

責任が重くなるにつれ、給料も伸びていきはするのですが、その際の給料の伸びは責任の重さにはあまり比例していないよね、という話が出ました。

森さんがふらふらと歩いていたので、評価関連の話題といえば森さんですよね、と無茶振りをしてみたところ、「責任の重さってなんだろう？何gなのだろう？」という前フリから、実際の現場で責任がどんどん重くなっていくことって実はそんなに起きていないのでは？という話になっていきました。

責任が重くなっていくというアンコントローラブルな認知ではなく、自分の認知として捉えてみるとよいのでは？ということで、具体的な認知の仕方の例として、「責任が重くなっているのではなく自分が嫌な仕事が増えていくだけ(例えば勤怠管理など)」「自身に完結した作業から自身にとってはアンコントローラブルな課題をどうにかして解決する仕事になっているだけ(権限も職位が上がると与えられるということは実は少なく、自分の権限でどうしようもできないところに対して何かしら働きかけをする)」という2種類の認知の紹介がありました。

スクラムマスターのしごとの何をやめようか？

なにか面白そうな話が起きている場がないかを探すためにふらふらと散策していたのですが、そこで今回のリトリートのために話すことを60個用意してきた田口さんから、「(田口さん自身の)スクラムマスターのしごとが多すぎるんだけど、何をやめようか？」というテーマに誘われ、こちらに参加しました。

最初は簡単な現場のコンテキストの説明があった後、田口さんが洗い出していた具体的なしごとに関して話があり、まずはJIRAの更新とスクラムイベントのファシリテーション&準備はやめたいよね(ファシリテーションか準備のどちらかは委譲するようにしたいよね)、という話をしていました。

田口さんと二人でスクラムイベントのファシリテーション&準備はやめたいよねという話をしていたところみほらぶさんが来て、先日みほらぶさんが参加したGlobal Scrum Gatheringで聴いた「スクラムマスターがスクラムイベントのファシリテーションをするのは、消防士が子猫を助けるのと同じことだ」*2というスライドを紹介してくれて、そこからbonotakeさんや亀沢さんtrebyさんも加わりながら更にOSTが続きました。

続きの話では、JIRAの更新とスクラムイベントのファシリテーション&準備以外にも辞められる仕事はないかという話になり、1on1とチームビルディングに関してもやめることができるんじゃないの？という意見が出ていました。

スクラムチームのメンバーとの1on1

スクラムチームのメンバーと田口さんで雑談的な話をする1on1を取り入れており、そこでコミュニケーションを取りながらレトロスペクティブではちょっと出しにくいような課題を吸い上げてもらったりするという話があったのですが、スクラムマスターが働きかけるのはあくまでもチーム全体であり人個人ではないので、そういう1on1はいらないのでは？という話がありました。(1on1したいんですけど...とチームメンバーから申し出があった場合にはもちろん話は別)

レトロスペクティブではちょっと出しにくいような課題をスクラムマスターが吸い上げてしまうとレトロスペクティブのテーマ承認係のようにスクラムマスターがなってしまうという懸念や、チームでの話がいつまでもできない点はチームにとってよくないのでは？ということです。

ただし1on1の活用方法として、自分自身の評価をラインマネージャーと決めるために行うような評価に関する1on1はよいのでは？という話もあり、その具体事例として、メンローにみほらぶさんが見学に行った際に行われていた、自分が信頼できる人を一人捕まえてその人と自分の評価を上げるための方法やKPIについて議論し、議論結果だけをラインマネージャーに共有する(ラインマネージャーは、どういう経緯かわからないけれどこのKPIを達成することができたらOKという情報だけ入手する)1on1の話が挙がっていました。

チームビルディング

田口さんのチームは最近新たに構成されたてということもあり、チームビルディングをしているということですが、これも考え方によってはやらなくてよいのでは？という話がありました。

スクラムマスター*3はチームが組成されたてというコンテキストやチームが解散されそうになるコンテキストだと頑張って障害を取り除こうとしてしまう*4ことがあるのですが、捉え方の一つによっては、組織の学習機会を奪ってしまっているとも言える(=チームを壊したらこれだけコストがかかってしまうということが分からないでいる)ので、あえてチームビルディングをやめるという選択肢もあるよね、という話が出ていました。

ただし、放っておけばいいというわけではもちろんなく、チームのレトロスペクティブでチームが解散したことや新しいチームになりたてで開発したことに関してどう思っているかをふってみたり、チームの解散を提案された際には「チームを壊すと一般的にこういうデメリットがあるのですがそれでもやりますか？」と一度事前に問いかけをするようにしたり、フォローは丁寧に必要だという意見が出ていました。

また、これだけ多くのことをやめてしまうと、スクラムマスター不要だと外部から捉えられかねないので悲しい気持ちがあるのは仕方ないけれど、Zuziがスクラムマスターにレベル分けをしたように、組織全体に対して関わり合うことも重要で、子猫を助けるのではなく火事場に向かう消防士になっていこうねという話でその場は締めくくられました。

ランチ

みほらぶさんkiroさん石井さん天野さん近くの席でランチを食べました。

kiroさんが今回のリトリートではせなちゃんとよく遊んでいるのですが、その際にただ遊んでいるだけじゃなくて実は本当に危ないことは阻止するようにしているよという話を聴いたり、子供事情の話を色々としたりしていきました。

その後、最近あって天野さんも参加されていたScrum Sunriseのイベントの話題になったのですが、一部の企業が誘われておらず、まあそれは当然だよねという話になり、しこから(近くのテーブルにryuzeeさんがいたこともあって)Scrum allianceやscrum.orgそれぞれの違いや研修の裏話に関する話になっていきました。

話の流れから、現状、特定の層が認定資格を取っているということもあり、ここから認定資格を受ける人の層は偏りが出てくるよねという話や、すでにちょっと偏りを感じるという話を聴いたりしていきました。
また、研修の第一回目はすごい雰囲気がよいという話や、雰囲気や時代の変遷という話などから、タクシーの体験が全然変わってきたという話(さすがに実名は出せませんが乗ってはいけないタクシー会社の話)になっていったり、タバコの取り扱いが交通公共機関やオフィスをはじめとした様々な場所で全然変わってきたよね、という話を聴いたりしていきました。

Ackyさんとみほらぶさんの共通点

川口さん高橋さんみほらぶさんryuzeeさんが雑談していたところに巡回をしに行きました。

巡回した結果、川口さんから昨日の雑談のおさらいとして、自分以外にもルンゲ警部がもう一人いそうだという話や、病人の話の正確な説明がありました。(昨日暖炉の前で森さんAckyさん自分が、全員暗めの病院服のような服を着て集まっていて、そこで勉強を早朝からしているというAckyさんや徹夜で勉強をついついしてしまうという森さんなどの症状を川口さんがそれは病気ですねと評価を下していた)

その話をしたところ、みほらぶさんがAckyさんと共通点があるんだという話をしだし、マインドフルネスとサウナに対して二人共全く共感できないということを聴いていきました。
話を聴いていたところ、ryuzeeさんも全く共感できない(自分には必要ないように思える)という話になったのですが、ryuzeeさんが共感できない理由はみほらぶさんの理由(副交感神経が優位に元々なりすぎてあんまり意味がない)とは全然違い、交感神経が優位になりすぎてしまい効果が全然ないように感じる&科学的に論理が通っていないように感じるもの*5はそもそもすべて苦手だという話があり、みほらぶさんからそれはマインドフルネスをやったほうがいいから教えるよと勧められていました笑

交感神経副交感神経に関しては、自分もryuzeeさんとどちらかという同じタイプなので、めちゃくちゃ同意しました。

ランニング

Open Style Trainingということで、trebyさんと一緒に芦ノ湖のあたりまでランニングをしてきました。
霧がもやもやしていたり、想定以上にアップダウンが苦しかったり、途中道を急に尋ねられたりと色々予想外のアクシデントには見回られたのですが、ランニング自体はすごく楽しかったのでよかったです。

川口さんによる狩野先生の講演の再演

先日SQIPであった狩野モデルの講演に関して、川口さんから再演がありました。あまりにも似すぎていて、本人の話を聴いているかのような感覚になりました。途中からの参加になってしまったので断片的なのですが、以下に再演セッションの内容のメモを記載します。

  • アリストテレスに関して小野さんから学ぼうと思った。狩野先生をはじめとしたえらい人は偶然の出会いを大切にしている。

  • アリストテレスの品質論を勉強することにした。そこから人間と馬の差の例から事物が2つ存在して品種の差があるとき、それを品質と言うという定義を考えるに至った。リモコンのあるなしでリモコンは品質であると定義することができるといえる

  • このような話もあり、森崎先生は品種とは何か？という質問を投げたが、コンテキストを与えなかったので色々な回答が集められて面白かった

  • OHPとスライドプロジェクターの差が、種差ということができるだろうと考えられる。多次元の空間から抜けたところに、オリジナルの品質を持つ新規製品は存在する

  • 品質レベルの話として、第1レベル/第2レベル/第3レベル/第4レベル/第5レベルの5レベルで定義ができる。良品/不良品〜高性能のロボット掃除機と普通の掃除機でレベル差を表現することができる

  • 製品レベルだと粗すぎるけれど製品特性レベルと考えると細かすぎるので狩野モデルが誕生した。品質/品質要素/品質特性の次元から考えた

  • ジョン・ロックの経験的哲学やシューハートの関係でから二次元でマッピングすることが狩野モデルの誕生に影響した

  • リモコンって今の時代も魅力的品質なのか？と言われると怪しい。魅力的品質は移動するのではないか？と思っている

  • スマホは2007年だと無関心品質だった。高いし買ってどうするんだという感じだった。しかし、その後職場や学校でスマホを聞く頻度がどんどん増えてきて、魅力品質になっていった。最後には、そのうちスマホでないと不満になっちゃうことに気がついた

  • ないと困るものだからあって当たり前は当たり前品質になってしまう

  • 品質管理のプロフェッサーと普通のプロフェッサーは違う

  • MaryとJohnの恋人サイクル(最高潮の盛り上がりでした)と教え方の品質の違いで劇的な成績改善がされた事例

  • 顧客の基本的要求に対して適合することが重要

  • CCR 顧客苦情解決(エンスト)→CS 顧客満足(窓の展開)→CD 顧客歓喜(顧客が気がついていない要求)

  •  

    ボーイフレンドの事例で説明をすると、誕生日祝い→欲しいと言ったものはなんでもプレゼント→欲しいと言ったことないのに飛び上がるといったレベル変化になる

  • 物を購入する条件ってなんだろう？という疑問から、価値、実在、経済の話など学際的な話を展開するようになった

  • 安全な飛行機を作りたいなら飛ばない飛行機を作って欲しいとなってしまう(有用性と弊害性の話)

  • 品質特性は演繹的に導き出すこともできる
  • メモリサイズをどうやってあげるか？から生まれた非機能的特性は生まれた
  • どんなものでも成熟化すると当たり前品質になる
  • コニカの米山さんを参考にした米山モデル。コニカは日本のカメラのリーディングカンパニーだったが、お客はどうしてカメラを買うのか、所有するんじゃなくて写真を撮らせるのか？を研究した。このモデルは1970年のジョブ理論といっても過言ではないと思う
  • フラッシュ内蔵式とオートフォーカスの観点から考えると、撮影者の不注意こそ潜在要求であるという考え方が覆った
  • カメラについて聞いても抜本的なソリューションは出てこないよ、というのが米山モデルの話からわかった。潜在要求に繋がるニーズは実物の観察を重ねることで生まれるんだと知った
  • 全天候型赤ちゃん連れ主婦用のリュックサックに対して調査を実施した事例の話
  • 21世紀になったことによる品質の変化(現在品質/未来品質から過去品質/現在品質/未来へ
  •  製品は必ず空間を占有するがサービスは時間を占有する

お風呂

今日は洋さんとたまたま温泉が一緒になり、上で一緒に川口さんの再演を見ていた流れから狩野モデルの感想戦をしていきました。

1975年に日本で出ていた話だとは思えないよねという素朴な感想をはじめとしたそれぞれが面白かったと感じた部分からスタートし、狩野モデルの話をアジャイルコーチの現場で使うとしたらどんな感じで説明ができそうなのか？という話をしたり、現場で見ている光景は今日の講演で聴いた話からするとどういうところがずれているのか？という話だったりをしていました。

kiroさんAckyさん工藤さんtrebyさんと雑談

工藤さんが今回のリトリートを通して(体調的な観点で)危険人物であることを認識したKiroさんから、機能で要件定義はできなくてバリューストリームが大切だという話を聴いたり、「スキルが足りないなら身につければいい」という考え方がどうにも受け入れられなくなってしまう(加齢との戦い)といった話を聴いたりしていきました。

「スキルが足りないなら身につければいい」という考え方がどうにも受け入れられなくなってしまう話に関しては、Kiroさんの具体的な例で話しがあり、30代であれば文庫本レベルなら一冊2時間で読めていた(つまり新しい業界のドメインを知りたいと思ったのなら2週間弱あればそのドメインの基礎知識を獲得できた)のに、今では1年かかってもそのドメインをキャッチアップするのが難しくなってしまったという話を聴いたりしていきました。(今では目の動く速度の遅さにイライラしてしまい、そのストレスで本が読めなくなってしまった)

そのため、レガシーシステムの刷新は難しいんだよね、という話にもつながり、Kiroさんがやり残したシステムリプレイスの話なども聴いていきました。

最後の方は、工藤さんと自分が(体調的な観点で)危険人物だという話から、コミュニティをこうして継続していくことの尊さや、リトリートという環境をなんで用意しているのか？という話を聴いたり、工藤さんが主催したり企画したりしているコミュニティの同士メンバーの人たちとKiroさんがどういう関係性にあったのか？という話を聴いたりしていきました。
この話の途中にKiroさんから、自分が特異的な才能を持っていること(Kiroさんの場合はドメインモデリング)に関しては人に対して教えることができないけれど、自分が全然才能がなくて死ぬ気で学んだこと(チームビルディングやスクラム、アジャイルなど)は人に対して教えることができるんだという話を聴き、後の話の伏線となりました。

夜ご飯

今日は夜ご飯の開始時間に間に合い、夕食を満足に食べることができました。

最初は、ちょっと離れているけれど話せるくらいの距離の席にいたTommyさんとお話をしました。
今回のリトリートでは、Tommyさんと全然話ができていなかったので、「TommyさんOSTはどんな感じで参加していましたか？」と聴いたところ、「今回はOSTに参加しているメンバーが誰か？という観点でどのセッションに参加するのか？を選んでいた」という回答があり、それってつまり自分がTommyさんと全然話せていない原因は...と真理に気がついてしまいました(Tommyさんによると、新規にコミュニティ参加している人と話すことのプライオリティを上げるようにしていたということ)

その後の夜ご飯は、田口さん大友さん洋さん山根さんの関西アジャイルメンバー*6+高橋さん中佐藤さんというメンバーで食べたのですが、高橋さんの「ネガティブフィードバックが多くなってしまうように感じるのだがどうしたらいいのか？」というテーマに対して、関西アジャイルメンバーの皆さんがめちゃくちゃ軽妙なトークで対応し、笑いが止まらない時間になりました。

全員正解ゲームの話をしたり、関西アジャイルメンバーの特徴に関する話などを聴いたのですが、みなさんめちゃくちゃ仲が良さそうで、すごく羨ましいなあというのと、山根さんがとにかく優しい人なんだな、という2点を実感する時間になりました。

箱根のリトリートでやり残したこと

Ackyさんから、「aki.mさんは箱根のリトリートで消化しきれなかったバックログはなかったですか？」という質問をされたので、

  • EMに関する議論
  • ドメインモデリングをKiroさんに教えてもらいたい
  • 森さんから、自分の予想を遥かに上回るようなすごいエピソードを聞きたい

の3つを挙げました。結論から描いてしまうと結果的にすべて叶うことになるのですが、ブログを時系列でダンプしている都合上、以下ではこの話が混在する形で記録に残していきます。

EMに関する議論

消化しきれなかったバックログの1つ目として、最近気になっていた「EMはコードを書くスキルをはじめとしたエンジニアリング領域の能力を積極的に伸ばさなくても良いのか？(ピープルマネジメントをはじめとしたそれ以外の領域で貢献するのはありなのか？)」という話を、きょんさんAckyさんBonotakeさんとしていきました。

色々と話をしたのですが、以下に、議論で出ていたポイントをまとめていきます。

  • EMかどうかに限らず、hogeマネジメントという言葉があったとき、hogeを執行できている人がマネージャーになっているのか？というのは疑問が残ることが多い。(プロジェクトをあなたは執行できているからプロジェクトマネージャーになっていると言えるのか？というとたいていできていないことが多い)
  • hogeができないとそのマネージャーがいるチームや組織では絶対に事業が成功できないのか？というと、そんなことはない。ただし、hogeマネージャーという職位についている人がより評価をされたいと考えた場合、Noだと思う。価値をhoge以外で価値を発揮していたとしたら、それはプロダクトがたまたま売れているという偶然性や、hogeができていなくても自己組織化された人たちに支えられてチームが成り立っているという偶然性によるところが大きい。
  • hogeをエンジニアリングに限定した場合、エンジニアリング領域に関してはコードが書けない人が適切なアーキテクチャ(論理的アーキテクチャ、物理的アーキテクチャに厳密には分けることができる)を設計することなんてまずできないと思っている。つまり、アーキテクチャを形成したりコードを書いたりでバリューを発揮することはかなり難しい
  • エンジニアリングマネージャーがマネジメントするのはエンジニアなので、エンジニアの技術力を見極め、その技術力を評価して次のステップへの足がかりを作るのはエンジニアリング力がない状態の場合はかなり難しい。(ピラミッド構成で考えたとき、エンジニアを一個上のロールでマネジメントする人が、具体的な技術要素の話をできないというのはかなり厳しい)つまり、エンジニアの評価や育成という意味でも価値を発揮することは難しいと考えられる
  • エンジニアリングマネージャーはエンジニアリングをマネジメントすればいいので、例えばモチベーション管理などのピープルマネジメントをすればそれでいいというのは、エンジニアリングマネージャーができたコンテキストやEMBokをはじめとしたエンジニアリングマネージャーの定義とはずれている。それはもうマネージャーと呼べばいいのではないか？という話になる(利益を上げていればそれでいいでしょ、というのも同じ理由でエンジニアリングマネージャーと呼ぶ必要性は薄くなる)
  • エンジニアリングマネージャーがエンジニアリング能力は弱いとなった場合、エンジニアリング能力をどのようにして伸ばしていくのか？というテーマはきになる
  • エンジニアリングマネージャーが出てきたコンテキストは、ピープルマネジメントをはじめとした従来の(エンジニア以外の)マネジメントをすること以外にエンジニアに関してはエンジニア能力のマネジメントをする必要があるという話だと思うのだが、いつから別にエンジニアリング能力がなくてもいいですよ、となったのかは気になる。このムーブメントは結構特殊だと思っていて、例えばSMで言えばSMは「スクラムを必ずしも知る必要はないよ」といつの間にか定義が変わったということなので、何が起きていたのかは気になる。なお、プロダクトマネージャーに関しても似たようなことは起きているのでは？という話はあるのだが、プロダクトマネージャーは領域が広すぎて、すべてを求めるのは難しいため、複数のプロダクトマネージャーで求められる能力を網羅的にカバーしようという流れができがちなため、エンジニアリングマネージャーとは違うと思っている
  • 各会社が求めているエンジニアリングマネージャー像にエンジニアリングマネージャーがマッチしているかが大切だよね、という話はそのとおりだと思う。ただし、ジョブディスクリプションで求めているエンジニアリングマネージャー像が本来のエンジニアリングマネージャーと異なることに対して「それはその会社の事情なんだからいいじゃん」とするのは、SMを募集しているがそのSMに求めるのは進捗管理やベンダーコントロールですというジョブディスクリプションがあることに対して「それはその会社の事情なんだからいいじゃん」と言っているのと一緒なので、違和感を感じる。(本来の定義を捻じ曲げて職種を使うのを後押しする動きになっているのでは？)

77777777

森さんがジョイマンに似ているので、森さんの講演は8888888ではなく77777777を活用していこうという提案が川口さんからありました。

他にもAckyさんやきょんさんや自分に対して川口さんがどのような印象を抱いているのか？という話など別の話題もあるにはあったのですが、どう考えても77777777には勝つことができないので、フォーカスがぶれることを懸念して、詳細は割愛します。

怪しいアジャイル

bonotakeさんAckyさんと怪しいアジャイルに関して話をしていきました。

誰も教えてくれなかったアジャイル開発という本があまりにも間違いすぎていてやばいという話や、SAFeに関しての話(最近話題になっていたスケーリングフレームワークの比較論文でSAFeが意外とディスられていないが肯定はされていない)などをしたりしていきました。

誰も教えてくれなかったアジャイル開発という本があまりにも間違いすぎていてやばいという話つながりで、意外と解釈がめちゃくちゃだったり説明が思いっきり違う本(捉え方によってはこういう意見もあるとかいうレベルではなく、参照先をみたら明らかに違っていることがわかるような話)ってあるよね、という話もしていきました。*7

また、bonotakeさんからAlloy本に関して紹介があり、アジャイルをAlloy本は一行で批判しているけれどbonotakeさんから見ればめちゃくちゃアジャイルだよという話を聴いたりしていきました。

※なお、実態としては、機密情報すぎて書けない話で盛り上がっている時間がこの雑談時間に関してはほとんどでした(1時間半くらい3人で話をしていたのですが、書ける内容が上の話しかない笑)

AckyさんにGPT4を使わせようの会

Ackyさんから、「自分にGPT4を使わせるようなセールストークをしてほしい」という要望が川口さん森さん自分bonotakeさんに対してあり、セールストークをしていきました。以下のようなセールストークがされていきました。

  • なぜGPT4がない状態で生きていくことができるのか？(aki.m 芸術点 6点/5点 aki.m 技術点 2点/5点 Ackyスコア NG)
  • 読んだ本や読んだ論文に対して自分の理解度確認クイズに使う(Ackyスコア OK)
  • 仕事で何かしら資料を作成するとき、自分が資料の説明相手に対してインプットする情報が十分なのかを確認する
  • プロポーザルを書くときに使う
  • GPTで生成された文章に慣れると、GPTを使って文章を生成している多くの周りの人の文章が断然読みやすくなる
  • 文字数制限しりとり(aki.m 芸術点 5点/5点 aki.m 技術点 X(測定タイミングで加点を目指す動きがあった)点/5点 Ackyスコア NG)
  • SDSなどといったお作法的な文章構成を形成するのに使う
  • GPT4にどうやったら課金するようになるかをChatGPTに聞く
  • 今GPT4を買ったらこの場にいるメンバーから実際の使い方を実演してもらえるので今すぐに買ったほうがいい(aki.m 芸術点 -1点/5点 aki.m 技術点 5点/5点 Ackyスコア OK)
  • とりあえずGoogle検索みたいな感じでとりあえずGPTにわからないことを投げる
  • Googleの拡張プラグイン
  • LangChainをまずは使ってみたらいいと思う
  • 3000円あげるからその場で買ってみたらどうか？
  • 川口さんの話に対して自分が肯定から入るのがGPTっぽいという話
  • ムキになって買う人達(GPT4が出たらとりあえず課金してそのあと考えようという人たち)と現実を見て買う人達
  • ここまでの説得がすべて無意味になってしまった説

KiroさんにDDDを教えてもらう

消化できていなかったバックログの2つめとして、KiroさんにDDDやドメインモデリングを教えてもらいました。

最初に要旨だけまとめ、そのあとに詳細を書きます。

要旨

  • Problem/Solution×現実/仮想の4象限のサイクルを回すことが大切(スターウォーズのイメージ)
  • 正しいモデル(より正しいモデル)というのは存在しない
  • 仮想の世界では超高速な仮説設定ができる
  • エンジニアは仮説設定にとどまっている間に自己満足することが多い
  • ドメインエキスパートはソリューションに手をだしてはいけない。また、Problem×現実の領域にとどまり続けることが多い
  • 軽量DDDは絶対にありえない(Value Objectをはじめとした実装パターンの話はDDDにおいて本当にどうでもいい)
  • ドメインエキスパートの頭の中で描いているモデルが変わることができれば成功
  • 捨てると消すは些細な違いなんだけれど結構大きい違いがあるとも言える

図によるイメージ

DDDの全体像

DDDの具体例

Kiroさんが自動販売機をモデリングするなら

モデルの抽象化例

モデルの抽象化例その2

詳細

Problem/Solution×現実/仮想の4象限のサイクルを回すことが大切(スターウォーズのイメージ)

DDDを行う際には必ず問題と状況がセットであるという前提のもと、Problem×現実/Problem×仮想/Solution×現実/Solution×仮想という4領域があり、この領域を回していくことが重要だという話がありました。これはスターウォーズのストーリーに合わせて理解することができるということです。

領域の回し方としては、理想的には、Problem×現実→Problem×仮想→Solution×仮想→Solution×現実→Problem×現実...という流れでループを回していくことが望ましいのですが、現実的なプロジェクトだとソリューション先行のことも多いので、Solution×仮想→Problem×仮想→Problem×現実と一度巻き戻り、そこからProblem×現実→Problem×仮想→Solution×仮想→Solution×現実→Problem×現実...の流れで回すことが多いということです。ただし残念ながら、実際の現場だと、Problem×現実→Problem×仮想→Solution×仮想→Solution×現実で止まってしまうことが多いというぶっちゃけ話もありました。

正しいモデル(より正しいモデル)というのは存在しない

Problem×現実→Problem×仮想の過程で大切になっていくのは、如何にモデルを捨象するか？(何を捨てるか？)であり、絶対にすべてのモデルが間違っているという前提をおくようにする必要があるという話がありました。

これはつまり、正しいモデルなど存在しないと理解することであり、何をドメインモデリングの際に付け加えるのか？ではなくて何をドメインモデリングの際に消し去るのか？の方に注目を向けるということだそうです。

仮想の世界では超高速な仮説設定ができる

Problem×仮想→Solution×仮想の部分は実際は一方通行になることはなくて、いったり着たりするのが普通だという話がありました。

また、この過程のメリットは、めちゃくちゃ高速に仮説検証ができることであるという話が出ていました。(データの永続化などを考える必要もない)

エンジニアは仮説設定にとどまっている間に自己満足することが多い

Problem×仮想→Solution×仮想のいったりきたりは、非常に高速な一方で、エンジニアがここで行方不明になってしまうことも多いということでした。技術詳細に踏み込んでしまい帰ってこれなくなるというパターンと、"正しいモデル"を追い求めて帰ってこれなくなるパターンの2種類が存在するそうです。

ドメインエキスパートはソリューションに手をだしてはいけない。また、Problem×現実の領域にとどまり続けることが多い

ドメインエキスパートの役割は、Problem×現実→Problem×仮想の補助なのですが、ここで陥りがちな罠として、ソリューションに対して口を出してしまうというパターンと、Problem×現実→Problem×仮想の補助をしているに見せかけてProblem×現実にとどまっている(エンジニアが作ったドメインモデルに対してそれでは現実概念と足りないからXXという概念を追加してというFBを送る)パターンの2種類があるという話を聴いていきました。

軽量DDDは絶対にありえない(Value Objectをはじめとした実装パターンの話はDDDにおいて本当にどうでもいい)

軽量DDDもありなのか？という議論に関しては問答無用でなしだという話がありました。軽量DDDとは、Solution×仮想→Solution×現実の領域に移行する部分だけに力を入れるということなので、肝心のProblem×現実→Problem×仮想/Problem×仮想→Solution×仮想/Solution×現実→Problem×現実が全然語られていないばかりか、Evans本に記述されているよりももっとよい実装プラクティスを捨てることにもなっている可能性があるということです。

ドメインエキスパートの頭の中で描いているモデルが変わることができれば成功

ドメインエキスパートがユーザーからのフィードバックを受けて、自分自身の頭の中にあるドメインモデルを修正することができたとき、それはサイクルが一周した証拠なのでこれはまず成功と言ってよいと思うという話がありました。

捨てると消すは些細な違いなんだけれど結構大きい違いがあるとも言える

モデルは一度作ってしまうと、作ったモデルに頭が引っ張られることになるため、消すのではなくて捨てるようにしないといけないという話がありました。

消すでも捨てるでも表現としてどちらも間違ってはいないのですが、頭の中には一度作ったモデルがあるよ、という点は要注意ということです。

小話

話の途中には、説明を助ける小話がいくつかありました。以下、その内容を記載していきます。

  • デイリースクラムは仮想世界に引きこもりがちなプログラマーを現実世界に引き戻すためのプラクティスだったりもする
  • t_wadaさんが主催しているDDDのワークショップに関して、スクラムを推しているKiroさんからすれば自動販売機のお釣り計算から入るのはありえないと思っている。まずは100円のコーラを変えるようにする、というところからスタートする
  • DDDでループを回してプロダクトを作ることをゴールとするなら、モデリングで抽象化(例えば時間形式の駐車場→どんな形式でも使える駐車場にすること)はする必要がない。ただし開発速度という観点だと、抽象化することで得られるメリットはめちゃくちゃ大きい。Alloyと同じ原理で、スクリプトをちょっと準備さえすれば実例によるテストが自動でできる
  • 抽象化をするときは、具体的なものをいくつか出してその特徴を考えて抽象化してみる
  • EvansはおそらくドメインモデリングやDDDに関して理解をして本を書いたんだと思う。なぜなら、Problem×現実/Problem×仮想/Solution×現実/Solution×仮想のすべてが微妙に下手くそだから

Kiroさんがドメインモデリングを教えられない理由

ここまででDDDを教えてもらったところで、Kiroさんが今日の夕食前の雑談で話していた「自分が特異的な才能を持っていること(Kiroさんの場合はドメインモデリング)に関しては人に対して教えることができない」という発言がどういうことなのか教えてもらいました。

KiroさんはDDDはこういう風にやるんだよという一般論をここまで丁寧に説明してくれたのですが、Kiroさんはここまで話してきたアプローチを全く取っていないということで、ループを回す過程で「どうやったらKiroさんのようにできるようになりますか？」と聞かれたとしても、まったく説明ができないということです。
言い方を変えれば、Kiroさんは、世の中に存在するものであれば、最初から頭の中にモデルが浮かんでいるため、ループを回すことなく、自然と使えるモデルが出てしまうということでした。

Kiroさんは、はじめて企業情報システムの一般モデル―UMLによるビジネス分析と情報システムの設計を読んだとき、「もっといいモデル書ける気がするんだけど...」と思い、そこから世の中に存在するすべてのものをノートにモデリングするという活動を5年間-6年間くらいずっとしていたということで、世の中に存在しさえすればすでに頭の中にできあがっているモデルを基に頭の中でちょいちょい試行錯誤すれば有用なモデルを作ることができるということです。

なお、世の中に存在するすべてのものをノートにモデリングするという活動をしても、本当にそれが有用なモデルなのかのFBはどうやって得たんだろう？というのが気になり質問してみたのですが、それは、

  • 天才である児玉さんと一緒にDDDを実践していた(Kiroさん生産管理のドメインエキスパートとしての資質があった)
  • できあがったモデルをコーチングする企業のモデルと比べてみると、コーチングする企業のモデルとの差分が見つかる。この差分をもとにコーチングをすると、現場を見ていないのになぜか問題がばんばん見つかり、クライアントが「なんで現場を見ていないのにわかるんだ...」と驚いた

の2点による影響が大きいということでした。

話の流れで、KiroさんがDDDを教えられないのと同じ理由でKent BeckもTDDを教えられていないと思うよという話やTOCの限界の話、testとjigの使い分けに関する話もお土産的にしてくれました。

森さんから、自分の予想を遥かに上回るようなすごいエピソードを聞きたい

Kiroさんから濃い話を聞けて、この時点で深夜1時を回っていたこともあり満足していた&頭が疲弊していたのですが、自分がポロッと言った「森さんが1on1大全をどう生み出したのか知りたい」という話をきっかけに自分がこれまで聞いたことがない森さんの思考プロセスの話をしだしてくれました。(優しいのか鬼畜なのか分からない...)
以下、聴いた話をまとめていきます。

  • 先程のKiroさんのDDDの話でいえば、ONYを現実/仮想それぞれに適用するようなイメージで森さんは概念の理解や問題解決を進めている
  • なぜそのような名前がつけられたのか？を考えてみる。TOCなら「対立解消図」という言葉があるが、なんで対立解消図なのだろうか？と考える。この場合、森さんはコンサルタントが仕事をしたいがために意図的に対立関係を作っているんだと気が付き、別に対立がなくたって要望両立のために図を使うことができるんだ、と気づきを得た
  • 体系化しようという認知を森さんはしていない
  • 短期/長期という形をはじめ、離散化した概念(どっちも大切だからバランス取ろうね、と言われがちな概念)を森さんは考えるようにしている。この概念は、多くのメカニズムを説明できればできるほどよい
  • 離散化した概念はハーバード・サイモンをはじめとした天才の人たちがすでに考えついていることが多いので、そこを活用している
  • グラコロなら、グラタン×コロッケ両方を制御できるような小麦という変数に着目する
  • 事例収集を行って理解を深める際、実際のプロダクトを分解していくパターンと、離散化された概念を説明するような具体事象がないかを考えるパターンの2つがある

田口さんの伝説の講演

最後に、田口さん川口さん森さんと雑談をしていきました。このあたりでryuzeeさんが起きてきましたw

以下の話を聴いていきました。

  • シブサワ・コウと宮本茂に川口さんが感動した話(実態はしらないが少なくとも講演を聞く限り、100%内製かつ社員全員がプロダクトを作るのに必要なすべての仕事をすることができるように聞こえる。また、社員は基本的に全員新卒から育てている)
  • どうにかしてシブサワ・コウと宮本茂をRSGTに呼びたい話
  • 川口さんのメモがYammerのせいで消滅した話
  • CEDECで川口さんと田口さんが出逢った話
  • 田口さんの講演があまりにも素晴らしすぎて、発表があった2ヶ月後に強引に田口さんの会社に訪問にいった話
  • アジャイルの本を読んだら田口さんが実践していることと全く同じでめちゃくちゃ驚いた話
  • 田口さんの会社にkkdさんが取材に来た話
  • 田口さんのCloing keynoteを聞くためにあれこれしたい話

全体を通した感想

今日は21時間ずっとOSTをしていたので、昨日に増して話がたくさん聞けて楽しかったです。1100記事以上ブログを書いてきましたが、過去最高分量を余裕に更新してきました。

また、みなさんが「これはブログに書かないでね」と毎回言ってくれるので、書いていい部分と書かなくていい部分が結構クリアになり、とても助かっています。(田口さんだけ言うこと聞かずごめんなさい)

*1:MVPの図に限らず、Royceのウォーターフォールの原典しかり一時期炎上していた企業のマッピング然り

*2:消防士が側溝などに挟まった子猫を助けるのはすごくいいことだしほっこりする話でみんな好きな話だし、子猫を助けたことに対してそれを責める人は誰もいないけれど、消防士の本業は子猫を助けることではないんだから余裕が有り余っているのでなければ火事場に行ったほうがいいという話がスクラムマスターがスクラムイベントのファシリテーションをやる話とリンクしている

*3:特にスクラムの経験年数が長い人に多い気が経験上する

*4:チームが組成されたてであれば、チームビルディングやっていくぞ！となったり、チームが解散されそうになるのであれば「チームは安定していたほうが絶対いいですよ」と止めにかかったり

*5:例えばシステムコーチングなど

*6:大友さんは九州出身なので関西ではないという話を大友さんから聴きましたが、一旦関西メンバーとしています

*7:厳密には時系列は逆なのですがあったことの記録としてはどちらが先でも全然いいので気にしない