ichy’s diary

バイクとか、写真とか、アジャイルとか

#RSGT2024 day3 memo

day1/2に続き、終了直後に直さないままとりあえず投稿。

バックナンバー

ichy.hatenablog.com

ichy.hatenablog.com

day3

Quality and Attractive Quality Creation Learning from the Kano Model - Kano Modelと魅力品質理論

Regional Scrum Gathering Tokyo 2024 - Quality and Attractive Quality Creation Learning from the Kano Model - Kano Modelと魅力品質理論 | ConfEngine - Conference Platform

  • 品質とはなにか?
    • 漢字って知ってるつもり。
    • 国語が大の苦手で考えてもなかった。
    • 漢字は英語の単語と比較するものだ。アルファベットじゃない。
    • importantってimportと似てる
      • 舶来品。価値が良いものだと思ってた時代があった。
      • 輸入したもの、大事なものという意味合い。
      • そういうふうに考えれば漢字と合ってる。
      • 漢字はごくわずかわかっている
      • 木と林とか。
      • 品質の「質」とは?
      • 斤が2つはいっている。中国では重さの単位。パン一斤とか。中国語のこんちんはkg
      • 斤が2つでバランスを撮っている
      • 貝はお金。お金とバランスを取る。
      • 質屋。人質。お金と釣り合うもの。
      • 他の例
        • disports=娯楽。sportsの語源
        • 頭が落っこちるはよくある話。
        • portは運ぶ。disは散らかす
        • 仕事でつらいことを運び、散らかす→娯楽
    • 品質の歴史的変化
      • 50年ぐらい前の自動車の話。
      • 自動車の質問題で大きかったのがエンスト問題。
      • 自動車がエンストすると走らない。一番レベルの低い問題。ここから始まった
      • このときの質は製品の基本的要件が満たされない。
      • その後、窓の開閉がスムーズに行かないとかいろんな話が出てくる。客の要求に対して満たせてない
      • ここから品質は顧客満足に繋がっていく。
      • 最近はお客様もいろいろ潜在的にいる。
      • 30年前は自動車の問題と考えてなかったが、しょっちゅう路肩にとめて地図を見る。
      • アメリカの夫婦喧嘩の原因1位はルート問題
      • お客様の状況をみて潜在的要因。顧客歓喜に変わっていった。
    • 今日の品質
      • まず顧客の苦情や基本的要件を満たす
      • いろんな声を聞いて満たす。顧客満足
      • 行動分析から潜在要求を満たす。顧客歓喜
    • 顧客歓喜
      • これを満たそうというムーブがあった。
      • しかし、基本的要件を満たさないということがあった。先端だけをやった結果として。そういう話がちょこちょこと耳にする状況になった
    • 研究者時代、女子学生がBFの3レベルを考えてきた。
      • lv1: 必要最小限度のプレゼント
        • 誕生日のみ
      • lv2: ほしいといったものは何でもプレゼント
      • lv3: ほしいとも行ったこともないプレゼント。しかし使ってみると嬉しくて飛び上がる
    • 狩野モデル
      • 品質機能展開QFD
        • ソフトでも一番役に立つ品質管理手法
        • 赤尾先生
      • Googleで調べると250k結果がでる
      • GoogleScalarでも引用件数が6500
  • なぜこの話がはじまった?
    • 子供のころ、おもちゃがよく壊れた。ドイツの製品は頑丈だった。
    • 大学で石川先生の講義で、消費者が満足するのが品質だという話。
    • 不良品とか言うイメージではない。
    • そんなこと本当にできるの?
    • 大学院で石川先生は大学院ではなく工場にいけと言われた。
    • 不良品にぶつかれば満足にならない
    • しかし不良品がなくなっても満足にならない。どう扱った良いのか?
    • あまり文献を見るのがすきではなかった。当時の品質管理は統計が主だった。数学も苦手だったのであまりピンとこなかった。
    • でもなぜやったのか。化け学の場で品質だと石炭化学だった事情があってそこにしか空いてなかった。裏看板で品質管理があった。そこから始まった。
      • そこしか無いところからたまたま始まった。
      • なぜか第一人者のごとく扱われるようになった。人生何が起こるかわからん。
    • Doctor取ったあと、品質をどうやり続けるか。
    • QCサークル
      • 日本の質が良いのは現場の作業者がすごいという世界的な認識がある。
      • エンジニアリングが強いわけではない。本質は現場のしごとにあった。
      • 1975年頃、ロッキードのメンバーが日本の品質管理を調査し、その流れでアメリカにいって色々しった
      • 日本はエンジニアが品質管理をやってる。アメリカでは産業心理学、行動科学の人々がやっていた。
      • 組織の作り方に関して、QCサークルが色々助けてくれるんじゃないかと期待した。
      • アメリカの行動科学を学び、ハーズバーグにであった
      • 仕事に対しての動機づけを与える要因
        • 上が部下を褒めるのが動機づけ
        • お金は衛生因子
      • ここに着目した
    • 工業製品に適応して論文を投稿したら却下された。
      • 面白いけどスタディが不足している。品質管理の中でしかやってないと言われた。
      • 手伝いに来ていた東京女子大哲学科の小野さんがアリストテレスをだした
        • 質についての記載があった。2,3ページ
      • これのお陰でヒントになって狩野モデルが始まるようになった
  • アリストテレスの品質論
    • 実態が持つ種差であるという
      • 人間と馬は違う。足の数が違う。気性も違う。
      • 種差の違いが質である(???)
        • 品質とは、ある物事に関して2つの品種が存在するとき、それらの種差を指す
      • カラーテレビの例
        • 故障する時間が短いやつと長いやつがある。
        • 漏電などの安全上の問題。
        • テレビのチャンネルを変えること。リモコン(1980年代〜)の発現
      • 種の区別
        • リモコンが付いていないテレビ、付いているテレビ、これらは別の種。つまりリモコンは品質といえる。
    • 品質の多次元図示
      • 品質と品種を分ける
        • 品質はスクリーンサイズ、フィルムサイズ、柔軟性
        • 品種はプロジェクターとOHP
        • これを品質を軸とした空間にマッピングする。そうすると、ベクトルが現れる
        • 多くの製品の空間の中に入っているのは良品、その空間外にあるものは不良品
      • いろんな品種のものを説明するために品質がある
      • 新しい品質をどう作るか?
      • 品質問題は高いレベルで色々差がある。バグもその一つ。
  • ここでQA
    • Q: 顧客満足と顧客歓喜。ソフトを扱うという仕事をしている以上、境界線が曖昧になるときがある。顧客満足と顧客歓喜の境界線はどこにある?
      • 品質のライフサイクルという話がある。
      • テレビを例にすると、リモコンは出てきたときは魅力品質。テレビは変化に時間がかかる。当たり前品質に移行するのは10,20年かかる。
      • 携帯電話でいろんな機能が追加されたが、これは数ヶ月で変わっていく。何ヶ月のレベルで追っかけていくのか、もっと長く追っかけるのか、基礎研究のレベルで行くのか、応用研究のレベルで行くのか
  • 我々の味方はアリストテレスから始まったがそれだけでもない
    • ジョン・ロック(1632-)という英国の哲学者
      • シェークスピア(1564-1616)よりちょっとあとの時代。
      • イギリスは経験哲学。
        • うまれたとき、赤ちゃんは何も知らない。どんどん経験を通じていく
      • フランス・ドイツは関連哲学(デカルトとか)
        • 生まれたときに先見的になにかを持っている
      • 物の品質って何か?
        • 我々がどう認識するかと言うのと関連を持っている
        • プライマリクォリティ
          • 客観的明らかな品質
        • セカンダリクォリティ
          • 主観的明らかな品質
      • アリストテレスが言ってる良し悪しの話と、種差
  • 品質のライフサイクル
    • 時間とともにかわるもの
    • スマホは以外に時間が変わる。2007に出てきたが、ぶーむにはならない
      • 43/80人が2011-2015にかった
      • 結構登場からあとに。
      • 2000-2010まで無関心品質だった。
      • 2011-2015に魅力的品質になった
      • 時代とともに品質の種類がかわっていた。
  • 先生は学生の出来が悪いというが、先生の質が悪いと言わない
    • しかし品質管理を研究にしてるならそこを見てしまう。
    • 以下に教え方が下手くそかに向き合った
    • ライフサイクルは以下に経験を積まないとわからない
  • 魅力品質のライフサイクル、恋のものがたり。
    • いるもいないのも無関心品質
    • 20年経って…
    • ジョンはメアリーとあうことで非常に満足する
    • 一元的。
    • 結婚して20年後
    • 一緒に暮らすことが極めて日常的
    • これをやったらめちゃくちゃ反響良くて学生の成績が上がった。
  • Q: 製品企画に導入することで方向性を明確にできるといっていた。価値の高いプロダクトを作るために企画で品質をしっかり計画しようとしているが、どうなると良い?
    • 魅力品質は認識論。品質要素があって、狩野の様式に従ってやっていただくとそれぞれの品質要素がそれぞれどういう品質に当てはまるかはわかると想う
    • なにか理論をつかって新しいものを作りたいとなりがち。そのとき魅力品質をつくりたい、と想うもの。それが見つかればやれば良いと思う。
    • とにかく新しいものをやるのが得意な会社だと思うけど継続的かどうかはちょっとわからん。色々あると思う。
      • コニカの話。1902に初めて国産カメラをつくった。
      • 1960年にカメラブーム到来。50社ぐらいでてきた。
      • 競争に乗れなかったのはコニカだった。乗れたのはキヤノンニコン
      • それまではトップメーカーだったのに。5%ぐらいまでシェアが落ち込んだ。
      • 挽回したいために調査をやった。
      • 若い人がなぜ我々の調査はカメラに付いては色々聞いてるのに、撮影者の話はきてない。どういう撮影し易いかめらを聴くのが良いんじゃないかとなった。
      • お客さんが写真がうまく取れたかどうかをどう認識するか?
      • 1970はカラーフィルムに変わる頃。
      • 問題は露出不足とピンボケだった。カメラの問題と感じた。
      • しかしカメラには問題はなかった。
      • 露出不足はカメラというより撮影者の不注意だった。露出計を使わなかった撮影者の問題だった。
      • ピンボケも連動式が導入された頃。普及率上がった頃インターロッキングシステムがうまく使えない人がおおかった。
      • 露出不足を補うためにフラッシュを内蔵にすれば問題ない、など、撮影者の不注意は潜在的要求といえる。
      • 製品について色々お客さんの要求を聞いてみてるのではない。
      • 周辺状況を観察するの大事。
      • 「米山モデル」
      • 魅力品質は相関が出るように感じる。
      • 魅力品質になったやつで企画を行うと、もうそれは他社が実現しているもので、間に合ってない。
      • 大事なのは無関心品質にアプローチする。
      • スマホは2007に売り出したときはみんな無関心だった、それを魅力に引き上げるような企画が良い
    • iphoneってむしろ逆品質だったよな…?
      • 普通そういうのってエンジニアリングの問題と認識しがち
      • ぺんてるの例
        • 5年で打ち切って成功したものはない。
        • 一つを投資し続けなければならない。経営者のしごとでもあるけど。
        • 経営者の腹の座るためには技術者も根拠を示さなければならない。
  • Q: 長く魅力的品質を持っているところ、要因としてブランドがあると思う。ロレックスとかわかりやすいけど、長くやってると思う。魅力的品質とブランドの関係の話って合ったりしますか?
    • 避けられないのはSonyの事例。
    • 普通はブランドの名前が重要と思われる。アメリカの会社と最初は思われていた。ブランドになってから日本と認識されるようになった。
    • 昔からフランスのシャネルとサンローランとか。最近のものって色々あるけど、ブランド自体も変わる。
    • MadeinJapanというのは1970はまだ粗悪品だった。だったが、Sony,Canoon, Toyotaは別だよって話になっていた。
    • しかし現在はMade In Japanは良いもんだと思われている
    • ハードの製品の良さは1kgあたりの値段たと思っている。
    • 輸出統計で金額がわかる、輸出品の総重量。2010まで上がってたがその後下がってる。
    • ブランド力=昨年のブランド力 +営業力+製品価値+ブランド方針
    • リカーシブに増えていく。
    • 調子が悪くなるとブランドが問題になると言われる。
    • なんでもブランドにするのはおかしい。
    • 毎年ブランド力が上がったのか、下がったのか、これを追うのが重要。

感想

  • あまり狩野モデルを知っているわけでは無いが、歴史的な部分が聞けたのはイントロとしてめっちゃ良かった。
  • 品質に関する概念の詳細化ができた。プロダクト全体をドリブンする存在として扱っていきたい。
  • 新しい分野に対する切り開き方の苦労の話ってだんだん聞けなくなってきてるような気がするなぁ。

#RSGT2024 day2 memo

day1に続き、終了直後に直さないままとりあえず投稿。

前日(day1)

ichy.hatenablog.com

day2

Keynote: Solving The Value Equation

Regional Scrum Gathering Tokyo 2024 - Solving The Value Equation | ConfEngine - Conference Platform

  • 今日の話は他と違う。いつもはレガシーコードとか技術負債の話が多いけど。アジャイルアジャイル言われる前から携わってる。
  • 今日は価値について、ソフトウエア開発で価値がどのように発現するかを語る
  • より良い組織化や働きかたから始める必要がある
  • システムで起こる問題は市場や組織からおこる。
  • マッキンゼーが記事を書いた。開発者の生産性は測定できると言ってるが、賛否両論あった
  • アジャイルコミュニティで2つの議論がおこった。ケント・ベックらは反論する記事を書いた
  • 個人をを測定すると悪い作用が起こる。競争を生む、という主張
  • 一人が問題を解決するのではなくたくさんのスキルを持った人々が解決する。
  • 生産性そのものは価値では無い。ここが今日のスタート。
  • 価値とは?
  • スクラムでもソフトウエア開発でもよく起こる。ビジネスでも話がある。
  • 開発者の生産性についての疑義
  • まずお客様の課題を特定し、コードをかいてFeatureを本番化し、デリバリーして解決する。
  • お客様が受け入れることで価値が発生する。
  • チームのモラルが上がるなどのことも発生する。
  • 努力し、アウトプット、その結果アウトカム、インパクトと続く
  • インパクトが重要だが、多くのエンジニアはアウトプットを測定したがる。どの程度のコード量かとか。
  • アウトプットを改善するためにトレーニングとかそういう対応をおこなう。
  • 価値というのはなにか?生まれたものから喜ばれるもの。価値には様々な共通点があって、見えて感じ、測定できること。
  • 会社が小さいと開発者のしごとぶりはよく分かる。小さな会社では生産性に問題が起こることはあまりない。
  • 開発者の生産性を見るに当たって、どれだけうまく開発できているか、底に見えていないものは?
  • 価値の発現の距離が見えていない。
  • 距離の側面。社会的な距離、他の人に引き継がれ、最終的に勝ちになるまで時間がかかる。
  • 構造的な距離もある。マイクロサービスの一部がお客様に対面しているが、背後には様々なシステムが絡んでいる。
  • 時間的な距離もある。誰かがほしいといったときからデリバリーされるまでの時間。
  • 様々なタイプの距離が我々から価値を遠ざけている。
  • 負荷の側面。クライアントが複数アレば、プライオリティが下がってる可能性がある。負荷が大きければ大きいほど。
  • システムの設計をする際にはこれらを考える必要がある
  • 価値の種類について
    • お客様に対する価値
    • ビジネスとしての売上、市場についての価値
    • 技術的の価値。システムが壊れれば影響するという価値
    • 倫理的・社会的価値。社会やユーザーに対する影響の価値
    • イノベーションと学びの価値。継続する必要がある。
    • 文化の価値。
    • ROI。投資対効果。計測できるように、めりっとが出るのかを見る必要がある。
  • これらの価値の種類の共通性はあるのか?
    • 何れにせよこれらは計測していきたい。
    • しかし難しいものもある
    • 運が良ければ組み合わせれば構成できるものがある
      • 複利で増えていくみたいな形
      • 健全的にのび、自身の複利がある
    • 合成
      • 複数の価値を満たせれば良いのか、
      • 自分たちが責任を持っている分野と外での価値を見ていく
  • 計測と連携
    • 目標にちゃんと連携しているのか?はみたほうがいい
    • オーバーエンジニアリングみたいなパターンがある。目標に連携していない。良いことと思えるけど。お客様の価値に連携していない。
    • しかし最善を尽くしたいという気持ちがエンジニアリングにはあるのでそういうトレードオフをしながらいい方向を目指さなければ行けない
    • ぐっとハートの法則
      • プロクシーふぇいりあ
        • あるところで効果的でも別で問題がある可能性(副作用的な?)
        • 他のものが犠牲になるというのは否めない
      • 機能は短く小さくするのが良いと言える。でも…
        • 例えばとても小さい関数でも、関数名は内容と合致していない。関数が15行以上書いてはいけないというルールがかかれて、犠牲をこうむった
      • 継続が目標になっちゃうこともある
        • 特定の目標があるとして最終的に着地はするが。思ったところに着地しないことがある。
    • 干渉
      • 組織の一部で問題が見えなくなる状況がアリ得る。他では見えるのに…
  • 問題のドメイン・レイヤー
    • 価値の障害になるのはプロセスの摩擦。
      • 複雑になりソフトウエアデリバリーが難しくなる。
      • 対応策: アジャイルはプロセスの摩擦を取り除こうとしている。
    • 設計のブロッカー
      • アーキテクチャーがうまく行かないと市場を失う。技術的負債。
      • 対応策: より良い設計。DDD、やデザインを学ぶ  
    • 組織編成が適していない
    • チームの能力
      • 離職につながる
      • 対応策: もっと学ぶ
      • 対応策: 採用で学ぶ
  • みんななにか一つを解決すれば全てが解決すると思いがち、しかし、すべてのレイヤーで問題に取り組まないと行けない
  • 価値の発現
    • 何度もやることで解決に近づく。
    • 問題の解決する方法は大きな問題を小さな問題に分割する
    • 問題の大きさは組織の大きさに比例する。
    • チームが大きくなるとコミュニケーションコストが高いので小さく分割する。
    • チームが大きくなるとトレードオフが発生する。
    • チームサイズのスイートスポットとして、
      • ダンバー数
      • チームサイズ
      • モジュール数
      • デリバリーインクリメント
      • Experimentation
    • 大きなソフトウェアを小さく分解し、どうピースをはめるかと同じように組織も同じ様に解決しようとした。
    • お客様と近いことが重要。価値の発現までの距離を縮めることが重要
    • 様々なピースを作らなければならないが、重要なピースでも価値を見出すのが難しい。バリューチェーンが長い。
    • こういう部分に分ける場合に辛さがあるときがある。分割するのが良いとわかっていてもやリたくないと想うことが多い。どんなシステムも大きくなると、複雑になるが、迂回するにしてもサイズ制約はどうしても発生してしまう。
    • 大きいプロダクトに機能を入れるのは時間と技術的困難がある。
    • プロダクトを小さく保つのは成功すればするほど難しい。顧客はより多くの機能を求める。
    • アマゾンは非常に大きなECの会社だが、興味深いのは早い時期にくらうどこんぴゅーてぃんぐが必要と発見した。
      • 社内でクラウドを作るろうとしたが、非常に巨額の投資をしなければならない。ECサイトなのに。このような対立する問題が発生する。
      • アマゾンはAWSを作り、クラウドコンピューティングの会社をつくり、販売をおこなった。これが成功しなければならない。
      • 業界のために仕事した。
      • 投資してECビジネスとして使うとなると、価値の距離が遠い。業界のために出すことで価値の距離を引き寄せた。
    • テスラ
      • バッテリーのサプライヤーを選ぶより、バッテリーをつくるようにした。
      • 優れたバッテリーを作ったら自分の車に使えるし、それをサプライできる。
    • 価値をどう届けるのか、最大限活用できるのか。
  • 何を最大限にするのか?
    • アジャイルは時間あたりの質を最大限にしている。
    • (ちょっと追いつかない)
  • バリューチェーンのマップ。わーどりーマップ
    • 自分が使っているテクノロシーは自分で作る必要があるのか、もうすでにあるのかがわかる。
    • 誰かが作っているというのはコントロールを放棄するトレードオフ
    • (ーーーー)
  • ケーパビリティの問題
    • より良いことを多くやれという要求
    • 緊張というものがある。
    • ケーパビリティがバラバラになる
    • シナジーが得られない。
      • グリーンホテルの例、アメリカではホテルでメモ書きにタオルを洗わなくていいみたいなサインがある。環境もそうだが、コストを節約することもできる。シナジーの例として適切。互いに良いと感じる
    • 内部的な衝突
      • コンサルの会社がプロダクトカンパニーになろうとしているところ。非常に良い製品ができたとき、他の人に提供したいと想う。
      • 人をクライアントにアサインをする。プロダクトには人が配置されないので投資が減る。両立できない。
      • 採用の能力があるので、クライアントアサインとプロダクトとそれぞれ人材を振り分けることができる
      • 価値の連携をしっかり取る必要はある。
    • ケント・ベックいわく
      • XPはソフトウェアクォリティが上がりすぎるのでどうすればいいかわからない
      • オーバーエンジニアリング
      • しかしその側面には価値を生み出すこともある。複利の価値
      • 解釈するに、投資のやり過ぎで別のことに投資すべきではないかということもアリそうだ
    • 価値をどのように作るか、顧客満足を新たな価値を生み出す。
    • 間の依存関係を作る必要もある。
    • (ーーーーー)
  • 結論
    • アジャイルスクラムはプロダクトや戦略が始まる地点までしかみんな考えない
    • コミュニティの外で起こっていることを知っておけばサプライズは少ない
    • それを知ることで新しいプロセスを設計し易い
    • 新しい価値が生まれ、生成すると緊張が発生する。それは良い悪い影響が発生する
    • シナジーを見つけること、価値のラダーはしごを見つけること
    • ソフトウェア開発のプラクティスは有用でもある。うまく作れることをやってみてうまくいくことは他のドメインでも起こりうる。
    • ロケットが墜落しても、墜落から学ぶことでよりよい状況を次につくる、いてれーティブな開発
  • QA
    • Q: 成長と熟達度のどちらを取るか?ビジネスにおいて成長を期待することがほとんどだと想うけどすべてのビジネスを持ってる事業者は成長すること、ソリューションではなく、熟達することが成長(ーーーーー)
      • アジャイルカンファレンスで初めて感じるのはみんながワクワクしている。発見し、持ち帰る、そして抵抗が起こる・摩擦が起こる
      • 熟達した企業は必ずしも新しいことをやる必要がない。回せてしまう。
      • そこそこに楽しみたいって人がいる中で少ない中にカンファレンスに参加する人がいる。
      • そういう成熟した企業にいる人がスタートアップにいったら何が起こってるかわからなくなってくるうう。
      • 逆にスタートアップの人が成熟した企業に行くとつまらなくなる。ゲームしたくなる。
      • それぞれの会社にはそれぞれのライフサイクルがあるからそれを考慮する必要がある。
      • 成長を是が非でもと進めるのは問題。安定的な会社になれば成長しづらくなる。
      • アメリカの航空会社の事業内容で国内の規制によってマージンが薄い。結局金融機関とおなじになってる。マイレージが副次的なビジネスになる。そしてこれを売買することによって大きなビジネスになり、本来の輸送が二の次になっている。
    • Q: 安定=サスティナブルでは無いと思っている。様々な変化は起こる中、歓迎をもって受け入れる状況にしなればならない(なのかな??判別できない)
      • 価値の提供手法はどんどん変わっていく。
      • 今日のアジャイルは未来に影も形もない形になっている可能性がある。
    • Q: ラダーについて。それは期待されてるものか、そうでないもの、探索するもの、作り上げていくものなのか?
      • 概念としては大きいものがいい。マルチユースのほうが価値の選択の幅がある。
      • 企業の問題として、お客様の言う通りに作ってしまうという状況になっている
      • +alphaをもっていくことがじゅうようでは無いだろうか
    • Q: 一段づつ上がっていくのがアジャイルっぽいのかな
      • アジャイルでは探査的・後発的に詰めていくけど、目標を持って進めるのが良いのかなと。
      • やるべきことはやるけど、保険を掛ける形で同時に価値を持てないか、という。
      • 大きいやらなければいけないことと別に小さいものを並行していけないか、先を見据えていこう
      • 何を将来プロダクトに入れていくかを考えていこう。
    • Q: VCみたいなところと付き合うとなると、成長しろというプレッシャーが強い。人数増やし、拡大するために価値を置き去りにするみたいなムーブしがちだけど、どう見ている?どう離れればいい?
      • 何年も前からこういう状況になるのはわかっていたと想う。
      • 我々はおごりをしてしまっていた。
      • インクリメンタルな開発を辞める必要は無いが、目標に対してもっと配慮する必要がある
      • 課題を解決するという事業がどんどん伸びていく。
    • Q: 会社の中でも価値や価値創造、価値検証など、価値というのはつまり何なのかというを説明できる人がすくない。冒頭のOutcomeやimpactがそうなのか、とおもうけどどう考えてる?
      • 価値定義は困難。
      • 主体は人や人の集まり。そこから発生する。
      • 一例として、砂。集まればシリコンチップができる。集まれば価値が発生する。熱意が集まる。
    • Q: スタートアップは市場が拡大する課題を見つける必要があると言ってたが、VCから投資を受けるためにはスケールする可能性の課題とかを認知してもらう必要があるが、必要な価値に対するアクションはなに?
      • VCを説得する立場に居なかったので、考えてこなかった。
      • 我々が置かれているVC環境は相当違う
      • 既知の課題は新規性を求められているとおもう
      • ビジョンを広く持つことで価値を獲得しやすいのでは。そうなれば価値を拾いやすくなる
      • ビジョンをもつ必要がある。
      • しかしVCはそれを認識しない可能性はあるが、無いより良い(??)
      • VCは人ににお金をはってるは街はいない
    • Q: 最初のキャリアは一人のプログラマーや技術的課題を解決するところから、が多いと想うが、そういう人たちはビジョンやチームとどうこれから付き合えば良い?
      • ぜひ問題解決係として臨んでほしい
      • 仕事で抱えている背景をよく知り、よく学ぶ。そのことでより良い解決手法を提案できると想う。
      • 技術的な能力を磨くのも必要だけど、いろんな業界の手法を学ぶのが必要。
      • 技術的な単純な問題を解決することもあるし、ビジネスサイドの問題を解決するんだということもできるかもしれない。
      • 総合的に問題解決をできるように研鑽しよう

感想

  • 価値の距離の話が面白かった。アマゾンの例はめっちゃわかりやすい。
  • 作っているものの価値のシナジーを考えるという視点はあまり考えたことがなかった。短期的視点を脱するのに良い思考だなぁ
  • ドメイン・レイヤーの話は分析とアクションを説明するのに使えそう。あと、過去自分は一つのレイヤーだけを解決しようとした感があるので反省した。

Living Process -ビジネスとチームと組織が自律的に連携と成長するフレームワーク-

Regional Scrum Gathering Tokyo 2024 - Living Process -ビジネスとチームと組織が自律的に連携と成長するフレームワーク- | ConfEngine - Conference Platform

  • 組織全体の話をする
  • チームの外の話
  • 組織変革。
  • どうやって我々は具体的に組織の壁を超えるのか、組織のきっかけとなるか
  • スプリントで行う行為はどうやって決定しているか?
  • 各種イベントいろんな側面で発生するよね
  • どうやって意思決定しているのか、もしくはしていないのか。
  • よくある議論
    • ビジネス側で、次の四半期に売上1.3xしたいけど難しいかな。
    • 技術的負債返さなきゃ
    • こういう話をしてるだろうし、やるのが難しい
    • リーダーがわかってくれるとやりやすいので経営陣もエンジニア出身だと…
  • ビジネス側の問題、エンジニア側の問題、組織の問題を話すのはなかなかなかった
  • 我々のチームはそういうことに直面することが多くなった。そこの解決策やアイディアの話をする。
  • 思ったのは自分たちも相手も組織に不満がある、ならば自分を変えればよいが、立ち向かえない場合もある。目と耳を傾けるというのが今日機能のキーノーt−
  • そういう課題に直面したときどういう状態になるか:硬直する
    • みんな本気で向き合っている。
    • 経営層の中で、チームで、意見が食い違う。困ってる、どうやって合意形成している?
    • そもそも合意形成という言葉に頼りすぎている。
    • 会話は前提だけど、会話で硬直状態を溶けるかというとそうでもない。
    • ポジション争いじゃない、大切なのは世界をより良くすること
    • 課題の全体を素早くことが大事
      • そうじゃないと自分の殻にとじこもり、会話ができない人達になる
  • リーンキャンキャンバスでまとめて、全体をみえるようにしている。
  • なぜ課題か
    • ヒト・モノ・カネが全て枯渇していく世界になる。過剰な状態は終わっている。
    • 今までの手法・示唆はヒト・モノ・カネがあることを前提としている。その前提が成り立たない。
    • これは日本だけではなく、世界で起きる。しかし日本が一番最初にぶち当たるのはチャンスではある。
    • 揮発性が低い、コントローラブルな要素は順調だけど、その逆は不調。
    • 揮発性が低く、コントローラブルな技術的な課題は今解決するべき課題ではない
  • スクラムから離れようとした
    • スクラムアジャイルはパッションが無いとできない
    • そこで言ってるやつって、実態としてはすぐに反応や対応してくれる振る舞いの話になる。
    • フラクタルスプリントで、自分たちが細かく、大きくピボットできる方法を検討した。
    • アリの超個体をどう自分たちにとりこむか、そのためにアンラーンする必要がある
    • パターンをつむぎ、使えるようにしなければならない。パタン。
    • コンサル会社の中で経営層からチームまでどうやって同一のプロトコルではなせるか?
  • 実際はどうだったか
    • 夜と霧に包まれたようなチーム。強制収容所の話。収容者はつらいのに楽しい話しかしない。
    • まさに夜と霧に包まれていて、なにかをやっても、改善していてもある種郷愁につつまれて、進化しない、逃れられないのでは
    • あらんけい
      • 1996
      • 地続きだとゴールを設定できる
      • しかしそれを脱却したいはず
      • そのさきの感動を持った世界をどうやって作るのか
      • ゴールを設定できる=コンテキストが一緒になっている。
      • スクラムから脱却したいと思っても、適応型というコンテキストはガイドではあるが、ある種の呪縛で、青い世界を作れなくなってると感じた。
  • Living management
    • いろんなマネジメントはみえるようになった
    • はっきりとした構造は見えなかった
    • どのように関連し、作用し、行動を促すのか?
    • 時系列も見えるようになったが、既存の振り返り手法では見えない、
    • 既存の振り返り手法はタイムライン性が低い
    • それぞれの意見や立場があるからコンフリクトしてしまう。こういうのはある種の自嘲?
    • 対立してるひとどおしのプロトコルがないことに目を向けていない。
    • プロセスはあってもプロセスをデザインするツールが無い。
    • リーダーはがんばって読み取りをしている、それでもできなければ、専門家を雇うが、しかし専門家も隣の領域は知らない
    • しかし我々はヒト・モノ・カネはこれから使えない。
    • 新しい人、価値観が出てきても想像範囲外のプロセスをデザインする方法
    • プロセスを生成するためのプロセス、何かをデザインするための仕組みを作らないと対立はのこったまま。
    • まずは特定領域で用意されたプロセスからジェネラルなプロセスを作る。
    • どんな手法が来てもジェネラルに取り組める枠組みを作る、。そして次にメタプロセスを作る
  • すべてを一つにまとめて見れる。個別にダッシュボードを作らない、本当に集中するべきことにリソースを踏む
    • 大量のメトリクスをどうせいりするか?
    • 揮発性とコントローラブルの軸で整理した。
    • 技術負債を解消としても全体をみて決定できているのか、そういう会話ができるマトリクス
    • メトリクスを見て課題をアイゼンハワーマトリクスで優先順位付け
    • エンジニア向けのHMWQでアイディアを作って優先順位付け
    • 全体制を保ち、ロードマップで判断する
      • 一部だけ変えることが重要。キャンバスのこの一つを変えるを生成し、あらいんしているかを見ていく。
  • まとめ
    • 既存概念や手法は整合させるためのプロセスがデザインされてない
    • アジリティを保った形でデザインされている組織なのか
    • 常に全体と部分をデザインできる必要がある
    • まずはジェネラルなプロセス・プロトコルを提案した
    • 次回はまた来年
  • QA

    • Q:このプロセスを作り上げるに至るための苦悩は?
      • 今回のモデルを作るために、2回モデルを変えた。
      • 最初は振る舞いの振り返りをやった。メトリクスで振り返りをやった。
      • どうもうまく行かない。なぜかと思ったらカテゴリが良くないという形になった
      • 各ロールが興味のママに見るだけの振り返りをしてしまう。これは非常に無駄だと感じた。
      • 組織として成長が鈍化する。
      • 全体を見る必要があると感じたのでリーンキャンバスにのった
    • Q: どうしても各領域の組織にマネージャーがいて、マネージャーとしてのチームがあるのですが、やはり言語が違うと感じてしまっています。これを一致させないと全体が一致がしないように感じています。何かいいやり方はありますか?
      • そういったことをまとめるために何らかのキャンバスが必要。
      • いろんなチームがあると想うんだけど、今はビジネス・チーム・オペレーションだけど、ほかの領域があるなら乗っけていけばいいともう。多くなったら階層化する必要はある。だいたい3つまでぐらいが認知負荷がひくいとおもう。まず全部乗っけて、階層化する。
    • Q: キャンバス見たいけど来年?
      • Yes。進化したすがたを見せます。
    • Q: 当事者として、それぞれがやっていることに課題意識をもっているのでアレばプロトコルを作ろうとなるが、多くの会社は自分の領域ぐらいしか見れないと想うけど、どうやったら働きかけをできる?
      • ヒト・モノ・カネがすべて枯渇するという話をする。
      • 三者からどう見えるというモチベーションをつくるのはできなくは無いが、多くの企業を動かすという感じではない。そもそもお金払わない可能性。
      • そもそももうそんなに世の中ハッピーではないのことをどう伝えるのか。5年でたたむなら良いけど、続けるならどうする?
    • Q: あなたの組織はもっと使えるものがなくなるんだよ、だから備えたほうがいいと伝えるということ?
      • Yes

        感想

  • いろんな指標や手法が合ってもどっかで歪があるのを認識はしていたけど、そういうアプローチで検討していくかーという発見。

  • 間をつなぐプロトコルが無いので、職人感覚でじゃあ今回はこれをとるかみたいなアプローチが多いイメージだけどこれがまとまれば、より自分たちにとって意味のある手法を選択し、計測し、意思決定できる期待感がある。
  • 最後のQAで働きかけのためにヒト・モノ・カネの枯渇を出すのは、小さい企業にとってタイムスパンが長い話なのかなぁ。来年不便なく生き残るぐらいしか考えられない小さい組織だとどうなんだろうか。

1897年(明治30年)設立、老舗製薬企業のスクラムマスター増産計画

Regional Scrum Gathering Tokyo 2024 - 1897年(明治30年)設立、老舗製薬企業のスクラムマスター増産計画 | ConfEngine - Conference Platform

  • 企業内でアジャイル展開をしている、しようとしている人のために具体的な手法。
  • オフィスワークへのアジャイル展開の話
  • 会社説明
    • 製薬系
    • 大阪と東京に本社
    • 連結5600名
    • 3500-5500億円
    • 合併あり
    • 医薬品以外の領域を持ったいる
  • 医薬品業界の特性
    • アジャイル展開を始めた理由
    • 製薬事業は成功確率は低いし、金はかかるし、時間もかかる。
    • 画期的な薬を早く患者さんに届けたい
  • 思いがけないこと
  • アジャイルが身近になる出来事
  • アジャイル展開を始めた理由
    • 厳しい事業環境
    • 高い目標の実現
    • 身近なアジャイル実践者
  • 何をやったのか
    • チェンジマネジメント手法。AIDMAを利用
    • レクチャー。改善・問題解決
    • 事例
    • 有識者レクチャー。SM読んだり。
    • 専用コミュニティーや体験会の窓口を持つ
  • 社内展開時の課題と解決策
    • アジャイルを展開する中での課題
      • 知らんはいらん
        • よくわからないものの抵抗感。
        • 知っているやり方で紹介する。アジャイルは全く新しいことではない。身近に経験していることの進化版。
        • PDCAとか、改善手法の一つだよ、とかそういう感じ
      • とかくいそがしい
        • 新しい取り組みを入れる隙間がない
        • 他の取り組みと抱き合わせる
          • いつも会社の中で改善活動はしているからそれと抱き合わせる。
          • 問題が起こった状況を打開する手段としてやってみよう
          • レトロスペクティブやってみよう、とか。
        • こだわりを手放す
          • あくまで手段。手放すことも必要
      • やらんとわからん
        • 体験しないと価値が伝わらない
        • 実績を積み続ける
          • 行動をつづける。傾きをつけつづける
          • 広報し続ける
        • 仲間を増やす
          • 一人でやるには実績の限界もあるので、仲間をふやしていく
  • スクラムマスター養成講座の概要
    • 選抜型。
    • 社内人事部の協力を得て、育成したいメンバーを出してもらった
    • 中期計画にも掲載した。
    • AIDMA二巡目
      • 全社プロジェクトとのコラボ
      • 管理職向け講座
      • 何聞いてもいいレクチャー
      • よろず相談
    • まっすぐにメッセージを届けることを主とした。
    • どういった人に受けさせたら良いかわからないというFBが合ったのでターゲット層をちゃんと明記している
    • 学ぶ項目
      • ファシリテータ
        • チームワークの促進
        • プロセスの整備推進
      • コーチ
      • マネージャーサポート
      • アジャイルマインド
      • 終了後実践の伴走。
      • 実践知をコミュニティに還元する。

感想

  • 製薬系のアジャイルというめちゃくちゃ大変そうな内容だった
  • レビューっていったところで難しい気もするのでそのあたりどうやってるんだろうというのを聞けばよかったというのを今更気づいた
  • アジャイル推進、やっぱりそれなりに根気よくやらなければなぁ。兼務でやるにはやっぱり難しい雰囲気を感じている。

「困っていることはありません」は物事の見方を変えるチャンス

Regional Scrum Gathering Tokyo 2024 - 「困っていることはありません」は物事の見方を変えるチャンス | ConfEngine - Conference Platform

  • 困っていることの背景に知らないことは知らないと仮定したところから。
  • 体験の共有。
  • 関わっているチームの状況
    • 頻繁にデプロイしてる
    • リードタイム短い
    • いい感じのよくできたチーム。
    • モブワークをやっている。他のチームからも参考にされるようなチーム
  • 「困っていることはありませn」という言葉がでるようになった
    • プロジェクトにアサインされて、フォーカスし、集中するというスタイル。
    • プロジェクトがリリースされると、落ち着くタイミングでそういう言葉が出るようになった。
    • なんとなくもやもやするところがあった。
  • 困ってることの例
    • ランタイムのバージョンが古い
    • テストコードstubしすぎ
    • などなど…
    • 結構困ってることってあるのでは…???
  • なぜ違いが出るのか?
    • チームはプロジェクトドリブンだけど、自分はプラプラしてるので視点がちがう
    • 視点が違うということは、プロジェクト以外の視点をもつともっと楽しく強くなるのか?
  • 困っていることはどんな状態?
    • 本当に困っていることがない
      • そんな状態はないと思っている
      • 理想を掲げてる以上、なにか困っているからそうなっているのでは。
    • 困っていることがあっても気づいてない
      • こっちが今回の本丸。
  • 問題発見力を鍛えるという本
    • 問題も答えもない、問題はあるが答えはない、問題も答えもある
    • 問題も答えもないから問題はあるが答えはないの状態に持っていくのが重要
    • 問題を発見するということ。
  • スコープを調節した問いかけ
    • 困っていることはアリませんか?ー>開発ワークフローで困っていることはありませんか?みたいに範囲を絞り込む
    • 問いかけに着目した理由:問のデザインにかかれている。問の基本性質
      • 問の設定によって導かれる答えは変わりうる
  • 1on1でやってみた
    • 最近困っていることありますか?
      • 特に無いですね
    • 開発ワークフローで困っていることはありますか?
      • 承認フローのAの部分が面倒
      • ー>答えが変わった。
        • 聞き方に工夫を与えると答える面白さ
  • 失敗例
    • たくさん質問を投げかけたら、その質問の意図はなにかと返された。
    • 連発するのも良くないが、意図が伝わっていないのはその通り。
    • チームと自分に距離があるからコミュニケーションが密でもない。
      • 理想のチーム状態が伝わっていないし。
  • チーム
    • 機能をつくってリファクタリングの計画もちゃんと組み込めるチームだから、課題にはちゃんと向き合っている。
  • 問のスコープは良かったと想う
    • スコープの調節に意識を向けることで問を発する側にも内省が促された。質問のタイミングを考えるようになった。
    • 意図が伝わっている状態の重要性に気づけた。理想の状態はきくがわも持ってると良かったと想う。
    • 現在の状態も知らなければならない
      • 理想に対して本当に必要な問いなのか?
      • まず観察する必要がある。
  • 困ってるけど、気づいているけど、言えない状態というのもアリうる
  • まとめ
    • スコープを調節した問いかけは部分的に有効
    • 意図が伝わっている状態の重要性を学んだ
    • 観察が以下に大事なものかを学んだ
      • 見立てる・組み立てる・xxx(問いの作法)

感想

  • 自分も1on1でよく「いやー特に無いっすね」って言いがちなので、自分もスコープを制限して思考するのは結構有効だなとおもった。
  • 逆も然りで、問いかけするときにあまりにもオープンなクエスチョンをするときってだいたい自分が用意してないときだなという感じがある。観察が足らないからふわっとした質問しかできてないなという感じ。
  • 問いがいっぱい出てくるようなチームの視点を広げる方法も考えてみたいなぁ

スクラムとデッドライン、壊れゆくチームをつなぎとめるもの

Regional Scrum Gathering Tokyo 2024 - スクラムとデッドライン、壊れゆくチームをつなぎとめるもの | ConfEngine - Conference Platform

kakehashi_Scrum and Deadlines - Speaker Deck

  • デットラインとは
    • ぜったいに超えられない期限
    • 12月に冷やし中華はてきせつでは無いよね。
  • どのようにデットラインが生まれる?
    • 法改正とか、繁忙期・閑散期とか、ステークホルダーの要望だったり、競合のリリースにぶつけるとか…
  • 荒ぶる四天王
    • 時間・予算・品質・スコープ
    • 時間に関わるのがデットライン
  • 効能
    • 優先順位を判断しやすい、集中、ほgへほげ
  • 課題
    • 品質犠牲。柔軟性を失う、ストレス
  • これらの課題は短い期限とか、非機能要件とか運用考慮されなくひかれる期限
  • ということは、ちゃんと時間だけではなくもう3つも見る必要がある
  • スクラムチームはどう開発するか?
    • プロダクトや自分たちの不確実性に対して検査と適応をつかい進める
  • デッドラインは何を生む?
    • 価値貢献を生む
      • 新生活シーズンに間に合わせたらその人の生活をより良いものにできるとか…
  • スコープと締め切りとリソースと品質
    • 単純に計算すると間に合わない状況で取りうる手段
      • スコープを絞る
        • 重要度の高い機能を絞り込んでデッドラインにミートさせる
      • スループットを強化
        • 何らかの手段…
      • 品質を落とす
        • テストをサボったり…まあええやろ
    • スクラムで陥りがちな罠24個
      • 時間は遵守、予算は増やせない、スコープは減らせない
      • 品質が犠牲になりがち。
    • そうなるとスクラムの機能不全を起こす
      • 使い勝手が微妙っていって、間に合わないから無理!と検査と適応が回らない状態
  • 我々はなぜここにいるのか?
    • スクラムチームはデッドラインは守る。透明性検査適応も守る。両方を守るのがスクラムチームのつらいところ
  • デッドラインのWHYを明らかにする
    • PO、ステークホルダーに聴く。
    • 「守る必要ありますか?」みたいなBoolな質問はだめ。意味は見出してるに決まってる。
    • なぜ今かを自問してみる。なぜそのタイミングか?後ろにずらしたら?ずらして失われる価値は?
    • 狙っている効果を教えてください、間に合わない場合の機会損失は?
      • これを明らかにすればモチベにもつながる
  • デッドラインはわかったけどスコープで調整した居けどいい?で通じる?
    • 自分たちの都合しかない
    • 人なら追加するから!みたいな話になりがち。間に合わせるのが君の仕事だよ!っていわれたり。
  • ブルックスの法則
    • 要因追加は長くすることは合っても短くすることはない。完璧な作戦だけど不可能。
  • ブルックスの法則を持ち出してもだめ。
    • 知識の披露じゃない。
    • こういう情報があって、健全性を保つやり方で合意すること。
    • 人を追加しない理由を丁寧に説明する
  • WHYに合わせてスコープ縮小を提案する
    • その狙いならこの機能はリリース後追加できるよ、もちろんフィードバックをもらって優先順位を変えることもできるという伝え方
  • トレードオフスライダーはどうする?
    • デッドラインが発生している場合は時間がMAX。
    • 予算品質スコープどうする?おすすめ
      • 予算は慎重にするために3番目。
      • 品質を2番目
      • スコープが一番低い
  • とにかく検査と適応。
    • 顧客の体験価値に悪影響を及ぼさない程度の品質の妥協は発生するのは仕方ない。リリース後の借金返済計画を立てていく必要がある。
  • デッドラインを乗り越えたら、トレードオフスライダーをもとに戻す。
  • デッドラインが複数発生した!
  • 複数ステークホルダーがチームに依存している場合に、別々の要望がやってきて、同じ締切を設定されるパターン。
  • 優先順位を決められるか?
    • 公平にやろうとしたら全部が間に合わない。
    • 一つづつやっていくか?でも間に合わないものがある。
    • 普段ペアでやってるけど、分業するか?コードレビューは適当に…?
      • プランニング
        • 独立したアイテムに着目してるから対話が発生しない
      • デイリー
        • 一応共有するけど、相手のことが全然わからないし、助けられない
      • レビュー
      • 振り返り
        • 頑張ってるねー大変だねーみたいな謎のねぎらい。学びが得られづらい
      • 結果的にスクラムイベントは機能不全を起こす。
        • 集まる意味がなくなる。開発に集中したいし、朝会やめようとかになる
        • どんどんコミュニケーション量が減る
      • なんとかデッドラインを乗り越えられた先に待つもの
        • チームはバラバラになってしまった。
      • そもそも前提としてデッドラインが間に合う見通しが立つのか?
        • チームはそれぞれの得意領域が集まった集合
      • 結果的にチームを殺す
  • 俺たちはスクラムチームだ。
    • 自分たちが一番パフォーマンスを出すやり方を知っている
    • ケーパビリティ以上のアウトプットを無理に出すとチームは崩壊する。
  • どうステークホルダーと向き合う?
    • まずはステークホルダーの意図を汲み取る。
    • ケーパビリティをもとにコミットメントする。
    • プロダクトバックログを公開する。何をデッドラインまでに完成させ、何を諦めるのかを公開する
  • 大事じゃないというふうにいわれたら?
    • 大事大事じゃないとかじゃなくて、緊急度の問題。
  • このやり方が最善だとわかってもらう
    • 過去の実績や自分たちのやり方を信頼してもらう
  • 他のチームは個別でやってるよ?っていわれたら?
    • 1スプリントください、このチームのやり方を見てください、レビューを参加してみてください
  • デッドラインが予測できるなら事前にチームを強化するのも手。
  • 実際のケーススタディ
    • ナビゲーションアプリ
      • 2023で法改正とか人流復活で季節要因に合わせたデッドラインが発生した。複数ステークホルダーから。
      • 以前分業制やったらレビューコストが高くなった。属人化も発生した。その学習結果からチームとしてはちゃんとスクラムチームとして動くことをきめていた。
      • ステークホルダー一人ひとりと話した。みんなうちが一番大事というので経営レベルの判断を仰いだ。
        • 「経営肝いりで…」と言われたものが実は違ったりしていたこともある。認識齟齬があっただけ。騙すわけではない。対話重要
      • 落ち着いて一つづつ完成させていった
      • 手の運用がのこるってのは実際あって、デッドライン後に借金返済をちゃんとやった
    • ヘルステック
      • EMとしてジョイン。
      • 他のチームからヘルプ要請があった。PMF目指していたのでデッドラインっぽいのはなかったけど、別のチームからエンジニアをヘルプしてほしいというやつ
      • ヘルプは賛成だけど一人ではなくちーむで行きたい。属人性になっちゃったりするし。
      • しかしチームで向き合うことは、自分のチームでやってることが泊まることを意味する。
      • 一人だけだとオンボーディングコストも良くない。チームも壊れる可能性がある。
      • 頭の中のPdMはなんとか両立してよ、って言ってたけど、実際にはいいよって言ってもらえた。
      • 4sprintやった。一人ではとても終わらないボリュームだった。
      • PdMは不安はなかったらしい。インサイトもできたし結果的には良かった。思った以上に早かったという感じ。
      • 断っていたら…
        • ビジネス的に厳しい
      • 一人だったら
        • 属人化がおこった
      • 結果的にチームがチームであり続けられた。
  • まとめ
    • デッドラインは価値貢献を生むけどスクラムを壊す。チームも壊すことがある。
    • ステークホルダーと向き合う、信頼してもらう。
    • 検査と適応は止めてはならない。

感想

  • 元気が良いTalkだったw
  • 過去を思い出した感じがある。検査と適応ができないよね、というのは当時も感じててメンバーにも伝えてたなぁ。
  • 頭の中でムリポより、実際の事例をみてると同じこと聞いてみても良いかもってきもちになった。あと煽らない。

プロダクトをあきらめるとき

Regional Scrum Gathering Tokyo 2024 - プロダクトをあきらめるとき | ConfEngine - Conference Platform

  • 立ち上げる話はよくあるけど、逆の話をあえて。
  • 標準的なスクラムの話じゃない。
  • プロダクトのライフサイクル
    • 黎明期
      • 諦めたりしない。ひたすら次を確かめる
    • 成熟期
      • ユーザーが居て、大した機能作らなくてもお金はいる
    • 最後
      • 次の置き換えプロダクトのタイミングなので諦めない
    • 諦めるタイミングは2番めのグロース期
  • 多くのプロダクトは成功できない
    • 95%は失敗。
    • 想定の結果を得られない。
    • そう簡単にはすすまない
  • なぜコケるのか?
    • ニーズがないとか…資金が尽きたとか…チームの問題とか…
    • 最大はニーズがない。42%
  • キャッシュバーンレート
    • プロダクトが単黒になれば増えることがあるけど、基本は右肩下がり。
    • 経営者がめっちゃ無茶言うときはいがキリキリしているだろうなぁ
    • 着地すれば会社がぶっ飛ぶ
    • それまでに資金調達をする必要がある
  • プロダクトが失敗する理由は資金とニーズがないことによる
  • プロダクトデスサイクル
    • 誰も使わない
    • 不足機能をきく
    • 不足機能を開発する
    • (最初に戻る)
  • 買ってないユーザーに不足機能を聞いてもだめ。いずれにせよ買わない。
  • プロダクトは継続すべき?
    • どう判断するのか?ニーズがない判断は難しい。
    • キャッシュが尽きる前に成功できるのか?
  • 費用対効果
    • 取り戻すことではない。
    • 追加でかける費用にメリットがあるのか?
    • しかし「これまでいくらまで使っちゃったし…」と考える。
    • そこまでかけたことが無駄になるのがすごく人間は嫌。これまでにかけた費用にめっちゃ意識が向く(サンクコスト)
  • しかしどれだけ費用をこれまでかけたかはこれからのプロダクトの成功に寄与しない。
    • でもそういうことを言う人はキャッシュバーンレートを見ている
  • プロダクトバックログ
    • 知識を得るためのPBI
    • ユーザー獲得するためのPBI
      • 使ってくれる人を確保する
    • 収益を獲得するためのPBI
      • はやくかくとくする
    • 収益を改善するためのPBI
    • コストを削減するためのPBI
  • PBIの見積もり
    • どんだけ手間なのか
    • どれくらいメリットや利益があるのか
  • ニーズが無いことを判断するのは難しい
    • あることを証明するのは簡単。有償ユーザーの存在。
    • 悪魔の証明
    • 大企業で新規サービス作るとき、マッチングアプリに手を出しがち。やってみた感を出すのはめっちゃ良いけど…回すのは大変よ。
  • プロダクトリリースの半ばで
    • マーケットあるっぽいし、リリースもできた
    • ユーザーもまぁまぁ取れてる。しかし売上が足りない。プレッシャーがかかる中、どんなPBIを投入するか?
  • キャッシュフローの誘惑
    • なんとか石・なんとかクーポン・なんとかポイント…
    • 実際にやくにはたつ。キャッシュフローは良くなるしね。
    • しかしこのタイミングでやると大変しんどい状況に陥る
  • ローンチ前に諦めるのは比較的かんたんだが、お金取った状況ではなかなかいきなりやめられない。そのための仕事もある
  • ラーメン屋、1000-1500万で開店できるけどやめるとき…
    • 予告期間分の家賃
    • 従業員の解雇予告の給与
    • 原状復帰
    • 廃棄物
    • など
  • プロダクトを終了させるときの費用をPBIに計上する必要がある。
    • なんとか石とか…
    • 有償で出したら半年で止めるとか無理。お片付け費用
  • お片付けするPBI
    • 実行可能な状態で下の方に見積もっておく必要がある。
    • 店じまいするためのPBI
    • Tear Down PBI
  • プロダクトを諦めるとき
    • 諦めるときに慌てても間に合わない。
    • 諦めたときにやらなければいけないことを先に合意する必要がある。
    • 状況が悪化してからやっても洗い出せないし、その行為が嫌になる。
      • そうしないとずるずるいってしまう。
    • ほうって置くことでプロダクトは長くのこってしまい、会社のキャッシュフローを圧迫する
  • 解決したい話題
    • PoC死
      • マーケットに行きたがらない。めっちゃお片付け大変になるので。
    • ゾンビプロダクト
      • 生ける屍。やめられないので人を剥がせない。撤退費用に投資したがらない。
      • チームが専任できない一つ。兼任で乗り切ろうとする。新規プロダクトの足を引っ張られる。
  • 新規プロダクトの稟議でお片付け費用を稟議の対象にしているか?
    • 本当は乗っけなきゃいけない。稟議を通すというのはそのリスクを取ることである。
  • まとめ
    • あなたのプロダクトはいつでも殺せるようにしておけ
      • そうすれば続けられる。
      • 有耶無耶にすると、どこまでやればいいかわからなくなる。
      • 諦めずに頑張れる時間が確保できるよ。
  • プロダクトはたまたま継続的に会社に利益をもたらさなかったから、死んだだけ。
    • 次のプロダクト、なるべく諦めずに続けていけるようにしよう。
  • QA
    • Q: プロダクトの撤退費用を稟議につむより条件は出したりして遠ちゃってる場合、あとからその費用を出すためにできることは?
      • 本当にプロダクトがヤバい状態になる前に積んで置けば良い。バックログリファインメントでやる。
      • この機能やったら便利だけど、じゃあこれを撤退するときにこれが影響するのはなに?とか。
      • あとはころしやすいプロダクトにしておく。
        • 20個新しいフィーチャーを追加したら一番ヒットしないフィーチャーは消すみたいなことやると、撤退費用も抑えられるし、コードの質も良くなる。
    • Q: いろいろころしてきたが、終わらせるときって、そのときにどうやるかと考えてやってたりしながら翌週これも必要だったと気づくことが多い。知ってる範囲でどういうタスクが考えられるか?
      • サービスを終了するときのプレスリリースをかいてみる。
        • そのプレスリリースはいつまでにだして、どの程度時間をのこす?
        • 縮退の方針は?
      • 不吉な、って想うけどプロダクトの成功に集中できる手でもある
    • Q: すでにゾンビになったプロダクトをどう対応する?ずるずるになって引くに引けない状況になっているのでは。
      • ちゃんと辞めますが言えれば…
      • (オフレコ)というウルトラアイディア
      • 何らかの理由で止められると言えれば良いとおもう。代替サービスを見つけるとか。
    • Q: ニーズの見つけ方とかも改善できるのか?
      • できる。改善もしてきていると想う。
      • その結果、既存のサービスができる場所がどんどのできる。
      • 誰かが先に見つけるとそのスペースは取られてしまう。
      • アジャイルによる成功割合、30%超えたこと無い。そのリスクを取らなければならない。
      • 車輪の再発明をするなという大人の言うことは別に聴かなくて良い。
      • 練習をするしか無い。いろんなことは学ぶ方がいい。失敗プロダクトを恐れるな。ちゃんとそれでも身につくぞ。

感想

  • 新鮮な発表だった。なかなかない視点。先に費用を計上することで、逆に勇気をもらえるという発想は面白かった。
  • キャッシュフローの誘惑が発生したときに同時にそのお片付けPBIを検討するというのは結構重要な視点なきがする。
  • ユーザーに機能を聞いてはいけない…

RSGT2024 Day1 memo

終了直後に直さないままとりあえず投稿。

day1

keynote: Dynamic Reteaming, The Art and Wisdom of Changing Teams

Regional Scrum Gathering Tokyo 2024 - Dynamic Reteaming, The Art and Wisdom of Changing Teams | ConfEngine - Conference Platform

  • (翻訳なし)
  • タックマンモデル、キャッチーなフレーズだが、安定的に保っていればパフォーマンスが保てると聞こえは良い
  • そんなに簡単にできる?
  • アイディアは良い。うまく行けば簡単。
  • 時間が経てばパフォーマンスがあがって魔法のような成果が出る。
  • 一定にチームを保てれば素晴らしい。
  • 現実はリチームが頻繁に起こる
  • 新たなメンバーが加わったりいなくなったり。
  • 深く考えてみた、たった一人の増減でもチームを変化させる。以前とはチームの雰囲気も力学も変わる。
  • みんなの経験、過去一ヶ月どうだった?リチームあった?
  • ほら、よくあることだよね
  • こういったチームの変化は不可避である。
  • いろんな手法を使ってよりうまいリチーミングが必要であると考える。
  • チームが変わるのは時間の問題。
  • 別にカンファレンスのあとにチームを変えろとか頻繁に変えるということではない。
  • チームを変えるのも簡単ではない。僅かな変化が簡単でも大きく時間でかわっていく。、
  • しかし、チームが変わるのは選択肢として持っておく。避けられない事象でもあると認識する必要がある。
  • ソフトウェアで20年SaaSにいた。いくつかは上場や買収もあった。
  • 15->800、10->900で退社したことがあるが、最初は一つのチームでもたくさんのチームに分かれる。
  • 縮小することもある。
  • 今は変化を経験しているチームのコーチングをロサンゼルスにすみながらやっている。
  • 今回はダイナミックリチーミングを紹介し、どのようにコーチングするかを紹介する。
  • 過去四年では縮小する会社も見たことがあるのでそういうサポートもできる
  • チームの変化のエコサイクル、ダイナミックリチーミングの5つのパターン、どうやったらうまく変化できるか、アドバイスを今回はこれを伝える
  • part1 エコサイクル
    • リバりてィングストラクチャー?という本からの図
    • まず始まりは落ちたどんぐりが埋まり、うまく成長できなければ貧困のトラップにハマるが、水などがアレば成長する。若年期
    • 成長期。成長していく中で問題にあたり硬直の罠にハマる。
    • 雷や稲妻などの想像できない破壊ののち、再生の段階に入る。
    • これをチームに当てはめるとどうなるか?
    • 新しいチームがうまれ、誕生期。
    • 成長し、強力なチームに鳴っていく
    • 成熟したチームになっていき、ソフトウェアでお客様が大好きなものを提供できる
    • しかしプロダクトや会社が成長して採用で人が増えると意思決定がスローダウンする。硬直の罠。停滞している
    • メンバーにはチームを分けたほうが良いのではという話になり、変化が入る。創造的破壊。
    • その上で2つのチームが誕生する。この繰り返し。
    • チームが変わるのは当然ということをこれから話す。
    • 他のパターンもある。縮小とかも。後で話す
    • 個人レベルでも発生する。個人、チーム、チームofチーム、組織、会社
    • 様々な変化が様々なレイヤーで行われる。ダイナミックリチーミングは様々なレイヤーで発生する。
    • なぜチームは変わるのか?
      • 成長した、縮小した
      • 新しい仕事が発生した。
      • ナレッジ共有のため。チームの冗長性
      • 停滞や学習のため、
      • びっくりすること。コロナ禍みたいな事象。
      • あとは…
        • 新しいリーダーの就任。一緒に働きたい人を連れてくるとか
  • Part2 5 patuerns of ダイナミックリチーミング
    • one by one
      • 一人ずつ
      • 誰かが参加した、脱退したなど。
      • 参加したときにできること
        • 成功するためにオンボーディングでサポートする。逆のサポートもある。オフボード。
        • この場合は二人一組で働くことがおすすめ。
        • ペアプロなど。
        • ひとりではないんだということを新しく入った人に認知させることができる。
        • MarketOfSkillsActivity
          • 自分が共有できることのポスターを作る。スキルとか趣味とか、教えられること、何を教えてほしいかなど。
          • みんなが共通の話題を持つこともできる。ハイキングをしたりね。
          • オンラインでもできる。ホワイトボードでも。
      • 去るときにできること
        • ORSCという組織から学んだこと。
        • なにかをリリースしたら海辺で叫ぶみたいなことをやっていた。
        • PdMがやめるが新しいPdMは海に叫ぶという行為はJDに入ってないが、その慣習を残し続けることで、旅立ちを祝福できる。
      • 誰がはいるか、去るかによってやることが変化し、実行が困難になることがある
    • grow and spirit
      • なぜ成長したら分割するのか?
      • わざと大きくしたのかもしれない。
      • チームがあまりにも大きくなるとファシリテーションを忘れることがある。
      • ファシリテーションの仕方を変えなければ行けない。
      • プランニングが30->90minになったりする。特定の人しか喋らなくなる。意思決定が難しい。コンセンサスを得るのに時間がかかる、関連性の無い仕事が増える。
      • あえて戦略として、特定の仕事の仕方があって、違う仕事の仕方を取り入れたいという場合、分割するという手は使える。一部のチームがスクラムを使ってみたいみたいな感じとか。
      • 意識的に成長させて分割する。アイディアを広めるために分割する。
      • 仕事を覚えて分割する。
      • 色々なパターンがある
      • チームの分割をする前に
        • 誰がチームに入れるか、誰をどのチームに入れようかを考える。
        • チーム間で共有するメンバーがいるのか?
        • オーナーシップはどうするか?ミッションと責任範囲は?
        • チームを分割するならいつまでにやるかスケジュールしてタイムラインを作る。計画する。
          • チェックリストを作って分割をするパターンがあった(Appforlioの事例)
        • コードどうする
      • チームを分割したあとに
        • チームの分割と終了を祝う。
        • フェローシップのスプリット。
        • 貢献に対し感謝を示すいいタイミングといえる。
      • 分割はレトロスペクティブで出てきたことが多い。
      • レトロスペクティブでかけてるのはチーム編成に関する会話が少ない。
      • フィッシュボールレトロスペクティブをやったりしている。
      • チームメンバーの声はなんなんおか?どのように仕事をやりたいかアイディアを持っている。
      • 全く違うオペレーションをする必要もない。
    • merging
      • 成長分割の逆パターン
      • 会社が縮小するときに取りうる。
      • やることが一時停止したり、去る人が出たり、悲しさのストーリー。
      • 複数のチームが一つになる。
      • なぜ起きるのか?
        • スペシャリストがいない。機能横断的なチームをつくるために。
        • まとめたことでチームメンバーがペアプロをおこなって、機能横断的なメンバーになれる。
        • 社内スタートアップ
        • レイオフ
      • Story Owe Team
        • マージされたチームで、サポートするために、歴史を共有するために、チームごとのタイムラインを書く。個人がチームに参加した時期と名前を書き、何をおこない、何を達成したのかをスマホで録音する。何を誇りに思っていたのか。
        • 歴史を共有できる。そうでもしないと、歴史を知り得ない。
        • 1hぐらい。60名、ホワイトボードとかmiroでも良い。
        • 前向きさにつながる。状況の不安を取り除くこともできる。
      • Coach Larger Teams Of Organize
        • some teams can do this easily
        • other te.....
    • isolation 隔離
      • チームの脇につくる。
      • 他のチームと違うやり方を作るのが重要。その自由を与えることが重要
      • 緊急の問題を解決するために組織し、収束したら元のチームに戻る。
      • 新しいプロダクトを作るために。他のチームと違うリズムで働けることが重要。
      • より集中できる。気が散らない。
      • SoSに行かずともどくりつしたチームとして存在できる
      • サイロのメリットもある。一般に悪いみたいに言われるが良い作用を持つことがある。
      • AppFolioの最初のチームは不動産のためのソフトウェアを作っていた。別のプロダクトを作りたくなったので、隔離して別のチームをつくった。
      • そのチームにいることで特権のように感じる短所もあった。
      • 不動産チームは2wスプリントでやっていたがSecuredocsのチームはそれでは遅すぎるので、新しいチームを作り、1daySprintでやっていくということにした。
      • 不動産チームに合ってた方法はSecureDocsに合ってなかっただけ。
      • 自由を与え、ミーティングに参加させるなみたいな交渉をした。
      • 脇によったチームから始まり、新しいメンバーがはいって部署になり、別会社になり、買収された。
      • マクドナルドの事例
      • 1989のTeamworkという本
      • マックナゲットはインディアナ州でうれてなかった。製品に問題があった。
      • コンサルを雇ってコンサルが小さなチームを作り、全く違う場所で働くようにした。孤立したチーム。
      • マクドナルドの官僚主義に影響されない独立したチーム。
      • 隔離の戦術
        • 会議室の中で仕事をしていた。他のチームに邪魔されず、自由に仕事した
    • switching きりかえ
      • one by oneに近い
      • one by oneは新たな人の入退社。switchingは自分が情熱を傾けられることに向かっていく。やりがいと学習に向いている。
      • 違うことを学びたい、違う人と働いてみたい。
      • チームを変えないことは、喜びを制限しているのではないか。選択肢が合っても良いのではないか。
      • なぜおきるのか?
        • 戦略的に行うこともある
        • 情報を広めたい。
          • 誰かが情報を結果的に独占していて、やめるってなったときに失われることがある。
          • その場合はペアワークやグループワークで情報を広める
          • チームが情報を結果的に独占しているパターンもある。
        • 切り替わることでOpportunityを共有できる。キャリア構築やチームの空きがあるときに誰に話せばいいのか。切り替えでOpportuniyを見せることでリテンションすることもできる
      • Procoreのケース
        • 50のチームがあった。
        • チームが情報を共有したいという要求でプロダクトを開発していた。
        • 二週間メンバーを募集していた。そういうサポートをやったりしている
        • 二週間たってもっといたいとかの話をマネージャーと話したりした。
        • 別のチームを試したりできた。
  • Part3コーチング戦術
    • チームが変わることは避けられない性質
    • より良くするためにどうするか?
    • 変化を受け入れることも必要だが不快に思う人もいる。人間だしね。怖いだったりワクワクだったり。
    • なるべく平準化・標準化していきたい。適応できるかどうかは人それぞれ
    • 新しい始まりは凸凹するかもしれない。自分でやったり、気に入らない変化だったり。でもとりあえずやらなければ行けないときがある。
    • 80名くらいの人が2クラスタのTeamOfTeamで新しい人がはいり3つにさいへんしようとしたケース
    • どう適応し、どう採用し、どこに配置するか。
    • 永遠にこの検討が続くかと思った。
    • みんなが見れるところにこの議論を出しておいた。どう反応するか怖かったけど。他のチームメンバーもどのように感じるか、どうしたいかを考えてもらいたかった。
    • あるソフトウェアエンジニアがホワイトボードをみて、こうしたほうが良いみたいなアイディアを持っていた。それを表明したことで変わった。
    • 意思決定にみんなが関われる状況を作れた。
    • 最初は怖かったけど、いろんなフィードバックやアイディアをもらえた。
    • よりオープンにリチーミングする方法がある。
    • 徐々に変わることのほうが簡単ではあるが急激な変化を取らなければいけない。
    • リーダーは忍耐が必要である。
    • 変化をみんなにオーナーシップを持たそうとした。オープンスペースのイベントとかカンファレンスをひらいて問題を解決したり。
    • 共通のプロセス改善や課題がある。
    • OSCやったり。
    • コミュニティをクロスさせる。チームが再編したときに初対面ではない状態を作る。
    • お客さんの課題を解決するためにソフトウェアエンジニアを雇っているわけだが、お願いすれば、人に関する課題を解決するために動いてくれることもある。
  • QA
    • Q: 所属しているところで編成の権限がなく、リチーミングに対してアクションをおこせない。そういう状態で編成に対してアクションを起こす方法があるでしょうか?
      • なぜパターンとかで解決したい問題をきちんとする。マネージャーやメンバーとはなせるか?解決策を3つPro/conだしたり。
      • じぶんだけではなく、複数の人間でコンセンサスを取る。声を大きくし、自分自身にも勇気をもたせる
      • スペシャリストがたりないとか、依存が複雑ならマージしたら良いんですよというアイディアを出したり
      • 自分の興味のあるところを調べ、まわりを巻き込む。
      • 決済者に実験することを認めてもらう、結果をもって発表する。発表することで他の人が試したくなったり普及したりする足がかりになる。
    • Q: チーム編成に取り組んでいる。ビジネスサイドではどのように取り組んだら良い?IT系はスクラムよりにチーム編成できているが、ビジネスサイドはWFっぽい感じに進んでいる。成長路線にズレが生じて苦労している。ビジネスサイドはとにかく早く仕事を勧めていかなければ行けないという状況だが…
      • IT側にいるとビジネスからとおざかっている状況があるとおもう。
      • ビジネスサイドのプレッシャーをIT側でも共感する必要がある
      • 共感をもち、団結する必要がある。
      • 上層部経営陣のレベルでも起こる。事業部長が他の事業部長の状況を理解していないということだったり。
      • お互いどういうプレッシャーを感じているか、チームレベルでどう協力するかということを考えることが必要。
    • Q: リチーミングの検討状態を共有し、オーナーシップ持っているのやってみたいと思っていた。見れる状態にはしているが、アナウンスをしたことがなかった。他にオーナーシップを持つためにいいアイディアは?
      • レトロスペクティブで有益なことが出てきたらそれを外に発信することでより有益性がます
      • 発信することがとにかく大事
    • Q: QAの立場から。テスターというのは、アジャイルで大きく変わった。QA組織からチームの中に入り込む状況whole teamになったはずだが、チームがQAを弾き出すみたいな形になることがある。リチーミングでのトライとして、どういうふうに考える?
      • プロダクトマネージャーやエンジニアがシフトレフトする中で変わること。受け入れ条件やリファインメントを前倒しし、QAがより活躍できる範囲を広げることができると思う。
      • ランズワークというエクササイズがある。体制における関係づくりのためのコーチング。
      • 共感の気持ちをどう強めるか。役割が違うところで、このエクササイズが良い。

感想

  • Dynamic Reteaming邦訳だしてほしい
  • チーム形態の変化のパターンがとても良くまとめられていた。
  • 組織的な圧力で移動とかあるけど、この前提を持っていればもっとポジティブに組織変更を捉えられるんだろうなぁ
  • 古今東西意思決定にみんなが関わるというのはよく言われることではあるけど、チームサイズや互いの信頼がない状態でいきなりやっても崩壊しそうなので常日頃の互いの関係性をまずは整備することがいますぐできることなんだろうなぁ。

Badプラクティスを選んで失敗しながら進めた新規プロダクト開発

Regional Scrum Gathering Tokyo 2024 - Badプラクティスを選んで失敗しながら進めた新規プロダクト開発 | ConfEngine - Conference Platform

  • 新規開発事例をあまり聞いたことがない
  • 成功のためにBadプラクティスを選択していたのをコミュニティに還元したい
  • 自己紹介
    • ゆのまえさん
      • VPoE、EM
      • 去年3月入社
    • しいばさん
      • フルスタックエンジニア
      • 去年入社
      • 最近メタル気になってる
  • 会社紹介
    • 医療関係。
    • 医療社会をより良くするためのサービスを開発している。
    • 現在薬局向けをリリースしている。今後広げていく
  • 去年の4-10月の話
    • チームは3月結成。
    • フルリモート
  • 何をやったか
    • Readyを待たない
    • 見積もりしない
    • タスクがスプリントで終わらない
    • 仕掛中のUserStoryがいっぱい
  • 新規開発とスクラム
    • スクラムで新しいプロダクトを開発しようとした
    • しかし見積もりをしなかった。
    • 新規開発っていっぱいやることある。どのスプリントで何をやるかがきっちり決まりがち
    • 最初のうちはなんとかなるかなと思ったら、わかっていないことが実はたくさん入ってる。
    • 新しい情報がたくさん入ることもある。
    • わかっていないことを取り出して調査用のスプリントを設けた。
    • 調査と実装のスプリントが別れているので実装上で出てきたわからないことが調査スプリントまでまちになる
    • Readyになるのを待たないでやったら早くできると思ったが、不安になる。見通しがたちずらい
    • 不安は合ったが、EMからやってみようということでやることになった。否定されると思ったが…
      • なんで良いと思ったのか。
      • 本人がいいと思ったやり方をやるのが良いと思った。実際実装する人の経験を生かした方法をとった。わざわざ反対するより、間違ってたら振り返れば良いと思った
    • なのでReadyをまたない見積もりをしない開発を採用した
    • とはいえ見通しつかないので、全体マップを作った
      • ストーリーマップのようなもの。横軸がログインや、外部連携などの大きな機能単位
      • どういうものを作っていくかと言うのを共有していきたい状態にしたかった
      • 実際すごくいいなと思った。バックログは一次元で上から下まで並ぶ感じになるので、全体感がわからない。二次元になることで、プロダクト全体を俯瞰できるようになった
  • ユーザーストーリー以外のバックログをスケジューリングしたら、MVPの機能開発に一ヶ月しかなかった。全体3,4ヶ月あるのに…
    • MVPのスライスをおこなった。なんとか1ヶ月に収まるような感じにした。
  • どんなチームをつくったか
    • コンセプトは「ドリームチーム」
    • ゆのまえさんはEM、SM。
    • EMは組織の構築と成長に責任を持つ。人を集め、開発体制を作る
    • SMはスクラムの推進改善。集めた人で開発を進める・改善する
    • どんなチームにしようかなというコンセプト
      • いいチームが良いプロダクトを作るドリームチーム=>技術力x顧客価値
      • いつも顧客価値に楽しそうに向きあうチームをつくりたかった
    • EMとしてどのように魅力ある人を集めるか
      • 開発コストを可能な限り抑えること。
      • 方向性が定まらない中で失敗できるようにするために。
      • コスト要因
        • 方針転換が多い
        • 人が多くなると開発コストとコミュニケーションコストが高まる
      • 次の基準を設けて採用した
        • コミュニケーションが円滑
        • フルスタック
        • 技術力が高い
      • しいばさんは、バックエンド・インフラが得意。もう一人、フロントエンドが得意なフルスタックエンジニアがいた。
      • 少なくともMVPが完了するまでは採用基準を変えず、積極的にふやさないようにした
        • コミュニケーションコストがふえるから
      • ふやしたら?と言われても大丈夫!といっていたが、いうても不安ではある。
        • むやみに増やしたところで成功する道も無いので、これで行くという覚悟を決めていた
  • SMとしてチームをどう整備したか
    • ≒顧客価値にどう楽しそうに向き合うか?
    • 状況が変わることにチームを変化させる
    • リリースまでに4つのフェーズ
      • たちあげ 2m
        • 何が必要か不明瞭なので、調査をタスク化した。情報の透明性を担保。
        • 漏れ・ダブりなくゴールまでスムーズな道のりを作れた
      • リズム形成 2m
        • どれくらいで開発できるかが必要なので、おおよその見積もりをした
        • この時点で間に合わないことを気づけたのはポジティブ
      • 機能量産 2m
        • ある程度ベロシティが安定したが、機能開発以外のタスクが山積みだった。セキュリティ診断とか。
        • 機能開発以外SMが巻き取ることで開発スピードが安定した。
      • リリース 2m
        • いろんな予期せぬことが起きる。不具合とか。
        • とにかくバッファを設けて、気になることを気軽に話せるように整備した。
        • リリース直前にやばめの不具合を見つけてギリギリセーフした
    • チームの状況を見ながらなめらかに変化させていった
  • BADプラクティスを進んで勧めた新規開発
    • Readyを待たない・見積もりをしない
      • 土台作り
      • わからないことだらけ。方針も難しい。
      • 事前に調べてとかやったら、素早くできない。
      • 見積もりが終わった頃には実装が終わったりする。
      • とりあえず飛び込んで手を動かして、土台を構築できた
    • スプリント内でタスクが終わらない
      • そもそもそんなにスプリントを気にしていない
      • 一個一個終わらすことに集中した。
      • 一週間はちょっと長い。Dailyでプランニングする形
      • なので残ってるところであんまり気にならない
    • 仕掛中のユーザーストーリーがたくさんある
      • バックエンド開発は二回実装した。一回目で実現可能性をとにかく全部詰め込んで実装して、エラー処理もロギングもしないで、やった。
      • 二回目で構造を整備して、実装をし直した
      • 実現可能性を早い段階でチェックできた。全体を見ながら本番レベルの実装ができた。
  • 何れにせよ踏み外すと危ない。
  • スプリントレビューで動くものを見せるのは意識していた。
    • レビューの区切りとしてレビュを意識した。
    • 何ができて、何がまだできていないかをはっきりし、全体マップを見ながら現在地を更新した。
  • 動くもの・新しい情報・方針転換
    • 動くモックを早い段階でプロダクトマネージャーに見せていた
    • PdMが薬局にいってモックを触ってもらっていた。
    • こうしたほうが良さそうというPdMのことばですぐ仮実装する。
  • 6月終わった時点で半分終わってない感じで8月終わらない雰囲気がでた。
  • 計画づくりをするときの大原則
    • 最初の計画がうまくいくわけではない。
    • 計画を立てるときは基本的に情報が足りていない。
    • 現実を受け止め、今の延長線上でゴール達成できるだろうか、と考えた。
  • スケジュールの見直しは何度もやるものではない
    • そもそもリスケジュールは時間かかる。一回しかやりたくないので大胆に一回で済ます。
  • やばいのは早い段階でわかっていたが、見直しするためには条件を満たす必要がある
    • やらなければいけないことがすべて洗い出せているか
    • ベロシティは安定しているか
    • チームの危機感は十分仕上がっているか
  • 人入れればマネージャー的に体裁整えられるとかおもわなかった?
    • 負けだな、というのはあるが、オンボーディングコストと、コミュニケーションコストがかかる。採用にも時間とコストがかかるので、今のパフォーマンスでやることが大事
  • 再計画づくり
    • 全体マップを眺めながらストーリーの洗い出し
    • 3点見積もりをおこなって機能開発の着地点を出した
    • リリース準備期間をふくめ1mのバッファをとった
    • リリース予定日の肌感をすり合わせ
    • ステークホルダーへの説明
  • 結果として8末リリースを10中の1.5m延期。
    • このあとは大きなスケジュール変更リスクもなく、予定通りクローズドベータを10中でリリースした
  • エンジニアとしてバッファを積むのはしのびなかった
    • すでに送らせてしまっているので
    • EMが一ヶ月いるでしょ、といってもらえてよかった
  • まとめ
    • Badプラクティスも武器にする
    • 状況に合わせて最適化し続ける
    • 全体マップは有効だった
      • チーム全員が意識をもてて、助け合えた。

感想

  • ある程度安定したビジネスモデルの中で、新規プロダクト開発という状況下のなかでどう対処したのかという具体的なケースが聞けた。
  • 特に再計画とかは新規プロダクト開発やってると結構気分が重い話なので、そのケースが聞けたのは良かった。
  • Badプラクティスをあえて入れるというのは自分もやっている方法で、一歩踏み外すとやばいというのは結構共感がすごかった

Outcomeに向き合う中で出会っている出来事とその解決案

Regional Scrum Gathering Tokyo 2024 - Outcomeに向き合う中で出会っている出来事とその解決案 | ConfEngine - Conference Platform

Outcomeにフォーカスするチームへのジャーニー / A Journey to an Outcome-Focused Team - Speaker Deck

  • ゴール
    • Outcomeを中心に活動するための取り組みや考え方を一つ知る
  • Outcomeは結構話してる内容ではある
  • 特定の現場や組織の話ではない!!!
  • セッション中のOutcomeの定義
    • 利用者の課題が解決したか?
    • 利用し者のやりたかったことができるようになったか?
    • 利用者の世界がどう変わったか?
  • Outcome・Output・impactの違い
    • output: 提供した機能
    • impact: どれだけ儲かったか
  • 近い概念ではある。
    • Output/outcomeは対立構造ではない。outputが出てない中でoutputが、は説得力がない。
    • outcome/impactは関連している。impactはマーケティングとかにも影響されるけど。
    • outputがoutcomeをgenerateし、impactを次にgenする
    • 最小のoutputで最大のoutcomeを得るのが最高
  • outcomeにむきあわなかったら?
    • 誰得なプロダクト、
    • 気力を奪う
    • 事業継続できない
  • しかしoutcome向き合うのは難しい。
    • 関心も持たない・持てない
      • outputに関心が向いてしまってる、もしくはoutputに忙しい。
      • そもそも組織がoutputにだけ期待する構造になっている。チームスキルもoutputを出すものに偏っている
        • outcomeに関心を持てない負のサイクルが発生する
    • 計測が難しい
      • うまくいったことが定義するのが難しい、変化が遅すぎて定義してもわからない、結果がわかるまで時間がかかる
    • インセンティブが無い
      • 人事評価関連
      • コード書いてなんぼだったり、マネージャーもそういう価値観で会話する。
      • エンジニアがエンジニアリングを成長するのは悪いことでは無いけどoutcomeにパワーを残すのも重要
      • outcomeが人事評価に含まれない。outcome/impactが大きくても評価されない。
        • プロダクトめっちゃ良くなっても…って感じ。
  • どうやって向き合うか?
    • 領域を越境する
      • 隣接領域に関心を持とう。学ぶ時間を取ろう。プロ級になる必要はない。会話ができる、一緒に関心を持つぐらいの内容。
      • 薄い本でもなんでもいい。
    • 興味を持ってユーザーを知る
      • ユーザー行動の観察
      • 話を深く聴く
      • ユーザーになりきる
        • 自分の中にユーザーをおろす
    • 関心をoutcomeに寄せる
      • 作る前にoutcomeを考える。どう測る?とかも。
      • フィードバックを早く、前段階の一部でも得る方法を検討する。
      • 意思決定をoutcome中心に。
    • 向き合える環境を作る
      • 経営やマネージャーの支援
      • 機会を設ける、学習などの時間・金銭的支援
      • outcomeに向き合うような評価精度
      • ここまで来ると文化の話になる。
  • まとめ
    • 自分と違うロールの人の考えてることに関心を持って日常の会話をするのもアリ
    • 作る前に知ろう・考えよう・想像仕様
    • outputがユーザーにとってどうだったか知ろう
    • ちゃんと向き合うために自分の情熱や意思が必要。

感想

  • 軽く耳の痛い話ではあった。outcomeに忙しいというのもそうだけど、向き合おうとしてないというのはたしかになぁ。
  • 向き合わない人が悪いのではなく、その構造に着目したアクションが紹介されていたので明日から選択しやすいなぁというのと、自分が説明し易い形でまとめられていたのがよかった。

ブッダに学ぶ、いのちだいじにアジャイル推進するためのマインド

Regional Scrum Gathering Tokyo 2024 - ブッダに学ぶ、いのちだいじにアジャイル推進するためのマインド | ConfEngine - Conference Platform

  • 宗教の話ではない。
  • もともとプログラミングが好きで入ったら、炎上案件にめっちゃご縁がある
  • 楽しく開発したいがなかなかうまく行かない
  • 最近はSMと社内で勝手にアジャイル推進
  • 6年やってるがしかし難しい
  • 一人ひとり主観が違う。アジャイルスクラムも一人ひとり違う認識。
  • アジャイル推進も下手すりゃ押し付けになる。
  • どうやって対話を進めれば良いのか疲れることもある。
  • ここでブッダ
  • 人の心を分析してきた。ブッダがどのように分析してきたかを考え、主観の違うことを乗り越える方法があるかを見ていく。
  • 主観はどのように生まれる?
    • 全経験領域(一切)が全体としてある。何かをインプットし、主観としてアウトプットする流れがある
    • 人の5つの構成様相。
      • 受(経験の影響を受ける)
      • 想(経験の影響を受ける)
    • input(六根)
      • 5感と意
    • 内部処理(六境)
    • output(主観)
    • これらが一瞬で回って判断している。
  • 例:スラダン
    • 絵を見て内部処理がすぐ走る。
    • 好きとか嫌いの印象を受ける。
    • 言葉では一言だが、その背景に色々な経験や背景がある
    • 背景は掘り出さないと分からない。ちなみに主観は間違ってるとかではなく受け入れるしかない。
  • 主観の違いを悲観するとつらくなる。四苦八苦
    • こんなにすごいのにつたわらない!!が強くなると自分でかってにつらくなる。
  • 主観の違いを乗り越えて命大事に緩やかに変化に向かうための3つのマインド
    • 相手の経験領域を知ろうとする
      • 経験領域を深ぼるインタビューをしてみる。印象に残ってるプロジェクトはなに?とか。どんな言葉が思い浮かぶ?心地よいものだった?どんなことを得た?自分が変化した点ってある?
      • 「泣いていた君を見なかったことにはしない」(ヒロアカ)
    • 人は変わる、私にできることはきっかけを作ることだけ
      • 受・想に働きかけることで人は変わっていく、
      • ちょっときっかけを作る、ちょっとさわるぐらいしかできない。
      • 新たな挑戦、一緒に体験、異なる主観の共有、一緒に考える
      • 「面白いものだな。その百分の一がお前を変えたんだ」(フリーレン)
      • 変わらなかったとしても私達のせいではない。きおうな。
    • 私が想う正しさにとらわれていないだろうか
      • 自分自身が変化し続けているだろうか?
      • 俯瞰的に自分たちの活動を見ていくと良いかもしれない
      • 「人は絶えず変化するもの〜」(攻殻機動隊
  • fearless changeとか良いかも。
  • 大事なこと
    • 人生一度、ロールバック不可。ゴール見すぎないように疲れすぎないように。

感想

  • 前職アジャイル推進っぽい事やってたのできょうかんが深い。自分は四苦八苦になった感じがあった(そもそも推進することに集中もできてなかった感じもあるが)
  • 相手と自分の主観の差というものをどのように分解し、どう寄り添うかというのは結構「他者と働く」にも通じるものがあるなぁ

よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること

Regional Scrum Gathering Tokyo 2024 - よいチームをよい雰囲気を保ったままよい組織にスケールさせていくためにできること | ConfEngine - Conference Platform

  • あるチームはアジャイルやプラクティスを用いて困難をこえ、良いチームが生まれた。平和が訪れた
  • 「チーム増やして」と言われる。
  • アジャイルはじまり23年、アジャイルは始めやすい、習熟しやすくなった。
  • 良いチームの事例もききやすくなった。
  • 良いチームを増やしたいという欲求。組織から。理解はできる。もっと増やしたい。
  • ニーズはわかるが、やってて個人としてはチームをスケールとかマネジメントとかにあんまり興味持てないとかある。
  • 大規模アジャイルとかぜんぜん違うもののようにも聞こえる。
  • 良いチームができたあとのアフターストーリー。スケールさせるためにできることとは?
  • 良いチームができたあとに何が起きるのか?のストーリー
    • SBC
    • 良いチームができた先の世界を見たい。
    • タックマンモデル。個人で見るとき、タックマンモデルはある程度それっぽい線を持つ。
    • 移動や、転職で最初に戻ってしまう。個人で転職してしまっては先の世界に行けない。
    • なにか問題があっていいチームができるが、移動・転職で一からまた作る。虚しい。
    • チームが解散するかもしれないというタイミングでチーム転職をやったりした。
    • チーム転職してよかったことは、オンボーディングもモブで進められたり、環境が変わってもスピーディーだったり。
    • チームとチームの外との境界が濃くなってしまって、自分たちがいくら気をつけても周りがそう対応してくる。
    • チームが長いと3年で生産性が降下する。外とのコミュニケーションが減る。
    • 周りから孤立した存在になる。
    • 良いチームができたということは、良いプロダクトができるみたいな他責っぽい意識になる可能性がある。
    • いいチームで問題解決をしたいのは当然として、チームの外に良い影響を与えられるチームになるという目標
  • ホロラボで、良いチームを増やしたいというニーズを受けた。
    • 自分たちはAgileコミュニティ、となりのチームはunreal engineコミュニティ
    • 今までは組織の配下でチームのしごとをしていたが、現在は組織を飛び出し、会社の範囲までカバーしている
  • 2022振り返りで、会社をハックしたいみたいな経営に関わりたいという発言がでて、狙い通りだったが、組織やマネジメントを聞いてうっとなった。
    • めんどい仕事が増える。本来やりたいことに時間をさけない。
    • そもそも本来やりたいこととは?
      • 良いチームができた先の世界。
    • 勝手につらいマネージャーのイメージが浮かんだ。
  • いろんな取り組みの中で手伝うなどの姿勢は主体性を放棄している。聞こえは良いけど。
    • その方針で行けば確かにチームは孤立していく。
  • チームメンバーが組織や経営に関わることで孤立せず、チームの範囲に組織やビジネスを入れてみようとなっている
  • コミュニティづくりは苦では無いという自己の特性
    • 目的は合ってもなくてもいい、一緒にワイワイできることが重要。目的とかおいておいて、やりたいことが場に放り込まれる状況が好き
    • もの・ことよりひとが中心の場であることに気づいた
    • 自分のチームもコミュニティっぽいなと思った
      • アサインされたチームではなく、メンバー自身がチームにいることを選択している。
      • 目的と嗜好が違っても、面白い人集まっているチーム。
      • チームやコミュニティの良い雰囲気を持った組織はワクワクする。
        • コミュニケーションの質は注目されているが、量が軽視されている。むしろ少ないほうが良いと言われたりしている。
        • スクラムでも15.4%ぐらいしかスクラムイベントはない。自分が誰かとそれ以外の時間で喋ってたりしている?コミュニケーション量って結構少ない可能性が高い。
    • 単純接触効果:触れれば触れるほど好きになりやすい。
    • 接触してなければ興味がないし、遠ざけたくなる。質ではなく、量の話
    • 知らないものは自信がなく怖いし遠ざけたくなる
    • どう量増やす
      • 短期的な目線だったら、開発時間が重要になりがち。中長期で考える。ミーティングの時間を増やすわけではない。情報に触れる機会を増やすアプローチ。
  • 期待しないことから始める。
    • ロールが変わったから何かが変わるわけではない。マネージャーだから1on1やるとかでもそういうかんけいせいではない。
    • 1on1やるけど、続けたいかは相手に判断を委ねる。あとは雑談。コーチングやってるので観察とか。
  • メンバーに共通していたもの
    • いずれのチームもコミュニティが好き
    • ものづくりが好き、喜んでくれると嬉しい
    • もっとうまくなりたい
  • そういう人たちのための場を作るためにやったこと
    • WeeklyOST
      • 定例じゃない。連絡事項と振り返りの共有はやるけど。
      • 残りの時間はテーマをだしてフリートークOST
      • 組織の定点観測。やったから何かが変わるのではなく、盛り上がるかを見ている。組織の状態が端的に見える化された感覚。
        • ワイワイできるような関係性か?
        • 関係性づくりは継続して組織活動全体で取り組む。単発ではない。
          • 人間性の関連が見える。中身は何でもいい。
    • 会社全体でOSTやる(未来会議)
      • 会社という単位で話したいこと。趣味とかなんでも。これを繰り返すこと。
      • もう一回やって全然盛り上がらなかったら、会社にいるメンバーの関係性に何かが発生しているかもしれないと気付ける
    • 何かに付けて感想戦
      • 顧客ミーティングとかしたあと。勉強会・研修とかのあと
      • あのときどうしてこうなったのかとか。同じ体験をしたからこそ、チームで共通のものにする。5,10分でも良い。
    • 経営・組織について議論
      • 会社の経営方針はオンタイムで共有。基本的にオープン。議論の結論ではなく、過程が重要。
      • 壁打ちや質問回。チームと組織や経営の距離を近づけたい。距離感。
  • 見えてきた変化
    • WeeklyOSTは継続している。
      • 盛り上がってしまってテーマトークで時間が足りない。
      • 忘年会しようぜとか。
      • 相談とか関心。企画が持ち込まれるようになった
      • コミュニケーションをうまくなりたいというOSTから生まれた取り組み。
        • コミュニケーションって練習する機会が実はあまりない。スピーカーは1分LTして、ファシリテーターが問いかけの練習のために3分スピーカーとトークする。
        • チャット参加している人は、観察とFBを行う。
      • チームでモブの行き来
        • ミーティングを開いて教えてもらうのではなく、モブで参加する。
    • 組織・チーム・個人の境界を超えやすくなり、声をかけやすい。エンゲージメント調査もよくなった。
  • なにやってたか:成功循環モデルをやった
    • 関係の質から始めると良い結果になる。バグ0を求める結果の質から始めると失敗の循環を起こす
    • 問題解決から組織づくりを始めない。組織から問や仮説が生まれるようになると良いかも。結果はあとから付いてくれば良いやぐらいの感覚であること。
  • たまたまいい人があつまっただけじゃね?ー>そうっすね
    • 底にいるための組織を作ればいいよ
  • プレイングマネージャーどう?
    • 優先順位の話だと思っている。
  • マネージャーとして意識してること
    • 水を運ぶ役割。相手に求めない。興味を持ってもらうように自ら働きかける役割。
    • うまく行ってから考える。再現性・属人化・組織論とか今考えても仕方ない。
    • 組織やマネジメントに過度に期待しない。
  • うまくいったというのはレベルが上がる。打席に立ち続けることが重要。

感想

  • そもそも自分がそこまでいってないのですげえ話だと思いつつ、たしかにループに陥ってる感じがあるなぁと思った。
  • 今はまだ小さいけど、OST文化はめっちゃ良いなぁと思った。内容よりも盛り上がりに着目するというところは発見だった。

ベロシティ Deep Dive

Regional Scrum Gathering Tokyo 2024 - ベロシティ Deep Dive | ConfEngine - Conference Platform

【資料公開】ベロシティ Deep Dive | Ryuzee.com

  • 勝手に仮説を持っている。スクラムチームのなかで生産性やベロシティという話が出るほど価値は反比例しているのでは?
    • あまり良くない状況なのでは
  • ベロシティにDeepdiveするのであればプロダクトに集中して
  • ゲームに勝つのはフィールドに集中する選手であってスコアボードではない
  • 適切な使い方とアンチパターンを紹介
  • ベロシティとは?
    • 1スプリントで完成したプロダクトバックログアイテムの合計値
    • スクラムはストーリーポイント使えとか言ってないがサイズを明らかにせよしかいってない。
    • ただストーリーポイントがよく使われる。
    • 完成しなかったのは計算に入れない。部分的に終わってるやつは半分入れていいとか聞かれるけど、半分終わってるって誰が決めれんねんとなる。完成したものだけ!
    • とっても簡単に計測できるので、計測したくなる。
    • 簡単だから測るでええんか?
  • よくないベロシティの使い方
    • 生産性の指標として使う
      • やめる。やめろ。やめろ
      • 生産性という単語の胡散臭さ。よく使われるけど。同じものをイメージしてるようで全然違うことが往々にしてある
        • 生産性= 算出/投入
          • 物的生産性: 生産したものの数や量をもとにしたもの
          • 付加価値生産性: 生産したものが生み出した付加価値をもとにしたもの。金銭とか
        • 一言で生産性は議論が噛み合わない元。DXとかビックデータと同じような言葉。きちんと定義を揃えることは重要になる。
      • スクラムは何を目指している?
        • 単語の登場回数
          • ベロシティは2010に一回しか出てない。
          • 生産性は減少傾向。
          • 価値はめっちゃ増えてる
        • スクラムはアウトカムやインパクトを目指している。
        • スクラムだとその文脈では付加価値生産性を目指さなければ行けない。物的生産性を高めてもアウトカムやインパクトが無いと意味がない。
        • ベロシティは物的生産性。
        • そもそもスクラムは効率は良くない。
          • スクラムは効率ではなあく効果・価値を目指している。イベントに20%も使うんやぞ。
    • 数字の上下に一喜一憂
      • すくらむにおける見積もりはだいたいいい感じを目指す。
        • フィボナッチ数列使っていると大きければ誤差がでかいという前提
        • 個別の誤差のお陰でだいたい収まる感じになる。
        • 厳密性を求めたら見積もりの精緻化に時間をつかって価値を生み出さない。
    • 目標ベロシティを設定して届かないと問題とみなす
      • 受託開発で起こりがち。
      • そもそもスクラムって経験主義。知識は経験から生まれ、意思決定は観察に基づく
      • 目標に届かない事実を踏まえて次にどうするかが重要になる。
      • 当たり前だが、能力を超える目標を立てたところで達成できるわけではない。
        • チームが悪いのではない。計画が悪い。
        • ありがちなチームの間違いはプランニングを頑張る。そしてインクリメントがない。
      • 目標を立てることはわるくない。詣でしたね、次どうする?が重要。
        • お客さんに約束してるのは救いようがない。
        • やってないことを約束するんじゃない。やってきた事実をみて、どうするかを重ねるのがアジャイルであり、スクラム
    • ベロシティを誰かに報告する
      • いくつかパターンがある
        • 開発者がPOに報告する
          • なんでそもそもPOしらないん?
          • スクラムガイドはスクラムチーム「全体」がインクリメントを作成する責任を保つ必要があるのから、POが把握してないのはその説明責任を果たせない。
          • そもそもその状態で次の計画建てられないしね。
          • 私考える人、あなた作る人だとそういうことになりがち。
          • 説明責任とは、事実を詳らかに伝える。
          • 結果責任とは、別に他の人に委託していいけど、その結果に責任をもつ。
          • 英語版ScrumGuideではそのあたりかき分けてるよ
        • POがステークホルダーに報告する
          • スクラムチームは自分たちで管理し、その権限をもつ。というガイドの話。
          • なんでその管理と権限を持っていて、ステークホルダーに報告するのか?
          • スクラムはプロダクトの価値を作るのであって、ベロシティの数値を報告したところでプロダクトの価値もリスクも何も見える化してない。
      • そもそもチームの外にベロシティを出すのは無意味と考える。
    • 評価に使う
      • 作ったものの量で評価できるのは量産品だけ。
      • スクラムチームは価値を追求する。
        • スクラムの価値基準の集中。だからプロダクトゴールもスプリントゴールも一つ。いちばん大事なことに集中しよう。
      • ベロシティを評価に使うと、チームの人はベロシティを余計に気にする。全く無視できない。
        • プロダクトの価値も含めて2つのことにフォーカスする状態。
      • 個人ごとにベロシティを算出するのは非常に問題。
        • 例えば、算出しようとするとなると、個人ごとにタスクをアサインし、何もインクリメントが完成せずレビューで何もできない。
        • 自分が頑張るために自分のアイテムに集中するためにレビューをため、スクラムチームの協力関係を阻害し、大量に仕掛が生まれる。
      • 「管理のために用いられる測定は全て信頼できない」グッドハートの法則
      • 「あなたが私を評価するか教えてくれたら、どう私が行動するか教えましょう」ゴールドラット
        • 評価基準ができたらそれに沿った行動をするもの。
    • チーム間で使う
      • 単純比較できない。見積もり基準も違う。
      • 「見積もりの基準をそろえたら?」
        • スクラムチームにメリットない。スクラムチームは自己管理である。見積もりの仕方も自己管理。
        • 「我々にメリットない!」
        • 同じバックログを共有している場合は基準を揃える必要があるので比較できるが、意味はない。
  • 「言ってることはわかるけど組織がいろいろ言うんです。定量的じゃないと報告できない」
  • 組織がSMARTを求める
    • 目標設定とかタスク分解のときに使われる。
    • やたらと計測可能なところだけ重要と言われる。本当は関連性が重要だよね
    • 「何も図らないよりなにか測った方がいい?そんなことはない。重要でないものの正確な尺度より、重要なものの曖昧な尺度のほうが必要」
    • 「測定できないものは管理できない、と考えるのはあやまりである。これは代償の大きい誤解だ」
  • 正確な数値である理由はあまりない。そこを脱却する。
  • アジャイルソフトウェア開発宣言の原則「動くソフトウエアこそが進捗のもっとも重要な尺度です」
    • 実物見せたほうが良いでしょ!
  • SMの出番では
    • 外側から色々言われてる状況は、SMの組織に対する働きかけの責務範囲。
      • 「複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう」
    • SMはちゃんと組織に対する働きかけ・教育をやる。
    • 数値出せと揉めてるとき、なぜそれが必要か、何につかうか、その数値を使うリスクはなにかをちゃんと整理しよう。代行して出すのも一歩踏み込みが足りない。
  • レビューに来てもらう
    • そんなに気になるなら来てもらおう。
    • インクリメントを毎回届けて、信頼されれば、数値報告は要求されてない。
    • 逆に言えば、数値報告を要求された場合は、インクリメントを出せてないし、信頼されてない。
  • それでも定量的な指標が必要なら?
    • Effort: 計画づくりなんかいやった。PR数 etc
    • Output: 出来上がった計画、、、、 etc
    • Outcome: ユーザー行動変容
    • impact: 生み出された価値
    • こんな感じで分解したときに、どこを測るか?
      • 最終的にはImpactが必要だけど難しければ逆順に辿っていく。Impact, Outcomeを狙うのが一番良い。
    • 「サイクルの早い段階で測定するほど測定は簡単だが、結果は予期しないものになる」ケント・ベック
    • プロダクトの価値と関連する指標(付加価値生産性につながる指標を選ぶ
      • NSM,KGI,KPI
      • しかし遅行指標が多いので、先行指標をチームで検討する。
  • SPACE FW
    • 満足度、パフォーマンス、アクティビティ、コミュニケーションとコラボレーション、効率とフロー
    • 選択した複数のカテゴリを計測し、定性も含めて全体像を適切に把握できるようにしよう。
    • (例はスライドで補足)
    • 多角的な観点でメトリクスをみよう。一つの数値だけで同行しようとするな!
  • いい使い方
    • スクラムチームが計画の材料に使う
      • 事実ベースの計画に使える。
      • 誤差があるのでだいたいこんなもんという目安。厳密に使おうとしない。
      • めいいっぱい積みたいというチームはあるが、スプリントの目的はスプリントゴール達成しか無いので、別にめいいっぱい埋める必要はない。
      • 単に数値を見るのではない。どんな出来事があったか、どんなコンテキストがあったかという情報を一緒に入れることで振り返りに使える。
    • スクラムチームが将来の見通しを立てるために使う
      • 直近の実績を平均して今後の見通しを立てるために使う。
      • 初めの方になればなるほど、あてにならない。常時見通しを更新する。繰り返しやる。
    • スクラムチームが自分たちの検査をするために使う
      • ベロシティのデータを見ながら自分たちのパフォーマンス改善のために。
      • 上下は激しければ、未完成を次のスプリントで完成させることが状態化してないかとか、特定のバックログアイテムの見積もり精度が変とか。
  • まとめ
    • 生産性の指標として使わない。

感想

  • ところどころ笑いつつ、わかり味が深い内容だった。
  • ふわっとそうだよねというのを見事に言語化した感じがある。
  • ちゃんとスクラムガイドに立ちかえり、解説できるあたりやっぱり、スルメのような文章だなぁとおもった。

エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜

Regional Scrum Gathering Tokyo 2024 - エンジニア組織の経営論 〜エモい開発と売上数字は両立するか〜 | ConfEngine - Conference Platform

  • 対立構造じゃないはずだけど、経営とエンジニア組織は遠そう
    • つよそう
    • 支配しようとしてそう
  • いい感じにバランス取れたらすてき
  • でも現実は甘くない
    • プレッシャー感じる。売上上がったの?
  • リーダーはジレンマある
    • 顧客の満足、自分たちの満足、どっちか一個しか取れない場合どっち取る?
    • 顧客の満足と自社の売上。どっちとる?
    • 自社の利益と自分の給与。どっち取る?
    • 自社の売上と、エモい開発。どっち取る?
  • 正解はない。
  • 今日は「お金や資本 v.s. ひとやチーム」について議論していこう
  • 超一流の研究
    • 天賦の才はあるのか?
      • すごい人っていっぱいいる。スポーツとか、才能に秀でてる人たち。
      • どういうものでそうなるのか?国籍?環境?遺伝?
      • 答えは無い
      • 共通していることは3つある
        • 1万時間(10年)没頭している。練習の差が能力の差。
        • 限界的な練習を続けている。ちょっと上の練習の継続。独自の工夫がある
        • 新しい方式を常に学び続けている。そしてフィードバックを受けている。アウトプットして自己評価。
      • 夢中と成長が重要。
    • 夢中の研究
      • 没頭力はなぜあるのか?好きだから。
      • 長期に渡って活躍できるためにはなにが必要か。アメリ陸軍士官学校の入学動機とキャリアの観点で研究した。
        • 内発的動機(好き・エモい)が強くシンプルなひとが長く活躍する。
        • 面接とかで「軸が3つもある」のおかしい
      • 夢中は最強。没頭し、上達する。
    • 夢中でエモいやつの特徴
      • 今が優秀ではない。
      • ずっと続けてるひとは長期的に外発的動機を凌ぐ
      • 圧倒的没頭で熟達
      • 内発的動機同士で惹きつけ合ってチームがある
      • 心が健康
  • 夢中でエモいエンジニアが本能的に嫌いそうな経営側の話題
    • 数値
    • マネジメント
    • 資本政策
    • 事業計画
    • 給与制度
  • すべて外発的動機っぽくない…?
  • 報酬の研究
    • 報酬とモチベーションの関係
    • 報酬で釣るとアンダーマイニング効果が発生する。エモさがなくなって、やりがいで始めたのに、報酬が目的になってしまう。3年ぐらいでだいたいそうなったりする。
    • 報酬はエンハンシング効果。単純作業とか一回目は効果的。
    • お金って心理的に大事にしたいワクワク感・エモさに繊細に反応する。
  • 報酬制度はエモさを破壊しかねない劇薬。経営陣はお金で支配した感じに行ってくるけどね…
  • 会社は伸びるが、現場は不幸なのがダサい経営。持って3年。
  • 夢中なひとの最高の報酬って?
    • エモい仲間と価値のある仕事と、自信の成長
  • 成長の研究
    • 技術屋もビジネスサイドも成長していかなければ行けない。
    • 技術屋がわかりやすいだけ。
    • ビジネスサイドのひとほどめっちゃ勉強している。そしてずっと維持しなければ行けない。
    • 一個に固執しすぎず、変化し続けなければ行けない。
    • 何かを成してしまったりしまうと、やらなくなるのは結構あるある
    • マインドセットで行動は変わる。いつでもかわれる。
      • グロースマインド(将来が楽しみな老若男女)
        • 何歳でもなんでも学べる
        • できるひとを尊敬する
        • 挑戦し、失敗から学ぶ
      • ーーーーー
    • 記憶力と年齢の関係
      • なかなか覚えられなくなってると感じるのは老化でもない。
      • エビングハウス忘却曲線
      • 年齢で実は大差がない。
      • 前頭葉が衰えることで意欲低下・復習不足に陥るのが原因。
    • 前頭葉を劣化させる環境
      • マイナスオーラを浴びたり浴びせたり
      • 単純作業を考えずに繰り返したり
      • ごまかす・妥協する・あきらめる
    • 逆に前頭葉が衰えない環境
      • 毎日プラスのサプライズ
      • 将来を楽しみにしている
      • 良い仲間と繋がっている
    • 未来を憂いてるやつは全員排除したほうがいい
  • 勉強方法の研究
    • 本読むだけじゃなくて、アウトプットすることが重要。
    • フルスイングで技術を社会実装する。ビジネス側に全力で投げ込む
    • ちょっと経験すると「PoCです」とかいって、本気で実装しなくなる
    • 外と繋がり、外部に発振する。コミュニティとか、異業種・異文化の人たちにアウトプットし、フィードバックをもらう。
  • 最初の一歩は色々ある。blogもinstagramも、twitterも、PRも勉強会の主催も、出社でも。
  • 良質なアウトプットは良いフィードバックを得られる。
  • ビジネス側って実際どう?
    • めんどくさそうって本当にそう?
    • 本当をしらないでビビってるだけじゃない?
    • お金の話ばっかりしてるって思ってる?それは本当?
  • そもそもエンジニアがお金の話をもちだしてない?
    • ゴールは?
    • 課題は?
    • 売上は?
    • ・・・・
  • 外発的動機っぽい話をさせてるのはエンジニア側では?
  • ビジネス側もちゃんとエモい。
    • 金だけ好きな人はシカトするとして…
    • 何がすきか?どれだけすきか?そういうエモい部分ちゃんと聞こうぜ
    • スタートアップと仕事しようとしているビジネス側ほどエモいぞ。
  • システム作ることばかりをゴールにしているのでは。
  • いうて全員オタク。(拝金主義はいない前提だけど)
    • 中身がわからないだけで。
    • 話は通じる。
  • ビジネスサイドはドメインの製品が好きでやっている。
  • 数値だけじゃわからない、デジタルビジネスの先にエモい魂がある。
  • オタク同士は感動できる。
    • 共感がアレばエモく繋がれる。
    • 向こうも本気。互いに真剣に取り組んでる。
    • 尊敬しあう。
    • この経験は金じゃ買えない。
  • お客さんも数値に侵されている、エンジニアはビジネスサイドに寄り添いすぎている。もっと没頭した、オタクの話。ビジネスサイドを洗脳する義務がエンジニアにある。
  • 経営陣をエモいDX人材に巻き込んじゃえ。
  • エモいエンジニア組織の経営
    • 金中心から人中心にシフト。
  • 資本市場を意識せず、内発的動機を邪魔しない環境を徹底している
    • 売上目標撤廃
    • 営業組織廃止
    • エモい仕事のみ受注
    • 最高の技術と品質
    • 顧客満足度至上
  • 結果:ちゃんと伸びた。裏では色々失敗してるけどいろいろ努力はしている
    • エモい開発と売上は並立できる。
  • エンジニアこそビジネス側に飛び込もう
    • 数字に従属しない。本気にエモく生きる。そうしたらエモい仕事がくる。

感想

  • エモい発表だったけど、勇気が出る内容だった
  • むしろエンジニア側が数値の話を持ち出しているという視点は新鮮だった。
  • そうだよなぁ、ビジネス側も数値とかじゃなくこれをしたいという動機からスタートアップやってるもんなぁ

Canon EOS R5を買ったのでレビュー

Canon EOS R5 + EF 16-35mm F4L IS USM

2023/09にCanon EOS R5(以降 R5)を買った。2020/07発売なので実に3年遅れで購入。

R5 はどんなカメラか?

詳細は キヤノン:EOS R5 | 概要 を見てもらえれば。ざっくり特徴を個人的な感覚でピックアップすると

  • 4500万画素(2023/11時点でEOS Rシリーズでは最高画素数)
  • ボディ内手ぶれ補正あり
  • 20fpsになる連射性能の向上(後述に注意あり。)
  • 被写体の種類を選べ、トラッキングできるAF性能
  • 8K RAW動画撮影(動画は使う予定がないでここぐらいで…)

なぜこのカメラを今のタイミングでかったのか?

2020/07発売で、もうすぐMark 2も出るというタイミングで結構迷った。今までEOS 5D Mark4を使っていたが、世の中のミラーレスへの移行圧力(とくにレンズ周りの発売)と、たまに5Dが調子悪いことがあって、新しいカメラを買うことを検討していた。

選択肢はいくつかあって、

  • R5を導入する
    • Pro: 順当な進化。性能は折り紙付き。
    • Con: 価格が高い。
  • R6 Mark 2を導入する
    • Pro: 発売年が新しい。R5よりは安い
    • Con: 5Dの3040万画素から2420万画素に低下する(ただし高感度性能は向上するだろう)。
  • Sony alphaシリーズに移行する
    • Pro: 最近使う人が多くなったのと、サードパーティレンズの選択肢が豊富。
    • Con: レンズ資産が若干活かしにくい(マウントコンバーターでなんとかなるかもしれないが不安がある)
  • Fujifilm Xシリーズに移行する
    • Pro: 色乗りが良い。カメラとしての楽しさはありそう。
    • Con: 速射性能とかの感覚がちょっとよくわからない。レンズ資産は行かせない。APS-Cか中判しかない

ということを考えていた。ミラーレスで共通してた利点はいずれにせよ今よりは軽く、小型化になるだろうというところで、欠点はバッテリーが持たないことにあった。バッテリーに関しては対処方法として、バッテリーをいくつも持つことと、USB経由の給電・充電が可能であれば、出先でもなんとかなるだろうという予想をしていたのでそこまで不安には感じなかった。ただ、連続して撮影しなければいけないようなシチュエーションに関しては不安があったのでそのあたりは後述する。

それで、いくつかの選択肢があって、なんで最終的にR5になったかというと、やっぱり5Dからの買い替えとなると、クォリティを落とせないという気持ちが強くなった。現代で写真を見るとき、多くはスマートフォンなどのデバイスなので実際のところ1200万画素(iPhoneのメインカメラぐらい)あれば十分で、それならばR6 Mark2でも良いわけだけど、仕事でトリミングとかが必要であったり、テレコンがなかったりするときに1.6倍クロップで撮影するとなると、画素数が大幅に下がる(具体的には4500万画素が1760万画素になる。R6だと2400万画素が940万画素)。記事で使うぐらいには問題ないが、いずれにせよ厳しい画素数になってくるので、なるべく最初の一台としては高い画素数が欲しくなる。他には風景写真とかを撮ることが多いので引きの画になることも多く、その割には低画素で低速シャッターを使うので、高画素機で有ることは必要だが、ノイズ耐性はそこまで求めてないというシチュエーションが主になるとどうしてもR5しか現状選択肢が無いみたいな話になる。一応暗所で高速シャッターが必要なシチュエーションでの画も後述する。

他のシステム(Sony, Fuji)に移行も考えたが、レンズ資産の問題と、通常撮る写真で必要な色乗りではないことを考えて一旦は優先度を下げた。そのうち欲しくなるかもしれないが(Fujiに関してはX100Fを持っていてその色乗りがとても良かったので今回候補にあがったぐらい)。

4500万画素はどうだったか

Canon EOS R5 + EF70-200mm f/2.8L IS II USM

3000万画素(5D Mark4)から4500万画素(R5)へ乗り換えたのでそのあたりの違いを見てみる。基本RAWでの話になる。

まずファイルサイズ的な部分から。ファイルサイズは5D Mark4が35MB/枚ぐらいだったのに対して、R5では48MB/枚ぐらいになる。 写真の描写する内容によって容量が増減するのであくまで目安。2500枚取ろうとすると90GBで済んでたものが120GBぐらい必要になるので、その量を撮るならカードを買い替えたほうがいいレベルになる。いずれにせよSDをのぞいて、CFからCF Express TypeBに記録メディアが変更になったので、新しく買うならちょっと多めぐらいの容量が安心。

データ量が増えたことで連射時のバッファ開放はどうかというのは結構気になるが、CF Express TypeB自体が転送速度が早く、1700MB/sec の公称書き込み速度だと、フルバッファからの開放は体感4-5秒ぐらい。いままで160MB/sのCF(SanDisk Extreme PRO)を使っていたので体感できる速さでPCへの転送が終わる。より早くするならC-RAW形式がより圧縮されるのでそちらを選ぶこともできるが、若干の画質低下を招くとの話もあるので試していない。

Canon EOS R5 + EF16-35mm f/4L IS USM

画質的な部分としては、ちゃんと比較できていないが、たしかに解像感は上がった感じがある。風景を撮っていて、細かい葉などがより描写されるような気がした。やはり高解像度と風景写真は相性が良い。

Canon EOS R5 + 24-70mm F2.8 DG OS HSM | Art 017(ISO2000)

ノイズ耐性に関しては、低解像度機(R6 Mark2やR3など)を試していないので分からないが、ISO2000ぐらいまでは概ね補正で普通にきれいになるぐらいなのでそこまで気にならなかった。低解像度機はこれより高い数値でも特に問題ないんじゃないかという期待はある。

バッテリーに関して

ミラーレス化するにあたって一番気にしていたのはバッテリー。Canonの公称ではR5は動体を撮影するときに必要な「ならめらか優先」モード(ファインダーfpsが向上する)でLP-E6NH(2130mAh)ファインダー撮影時約220枚という説明で、5D Mark4ではLP-E6N(1865mAh)使用時公称900枚と、単純比較で5倍電力を使うという計算になる。自分の実使用では30分の間に3000枚撮影するのが一番厳しい条件だが、5D Mark4の場合、バッテリーグリップをつけ、バッテリー二個でおおよそメモリ半分消費という状況で、5倍電力を使うとなるとバッテリーは5個ぐらい持っていく必要が出てくる。しかも30分の間に3回は交換しなければならないみたいな状況が予想された。

実際にバッテリーの持ちを確認するため、撮影をした。設定としては、

  • なめらか優先
  • 省電力モード切
  • サーボAF
  • ラッキングAF(瞳検知・頭部検知)
  • EF 70-200mm F2.8L II
  • バッテリーグリップ(LP-E6N(劣化済み), LP-E6(劣化済み))
  • 電子シャッター
  • 高速撮影+(H+)

この条件で、30分撮影したところ、撮影枚数3147枚で、バッテリーは84%, 83%という結果になった。その後そのバッテリーをつけたまま30分更に撮影し、総撮影枚数5552枚でバッテリーは73%, 72%だった。 単純計算でバッテリー1個につき9000枚超撮影できる計算になる。公称値の20倍撮影できることになるので予想を大きく上回った。ただ、今回の撮影は短時間かつ、電子シャッターだったというのが大きな要因じゃないかと思っていて、メカシャッターかつ、旅行のときのように撮影間隔が大きく開く場合ではない。試しに旅行で持って行ってメカシャッターで撮影したが、400枚ぐらいを撮影してバッテリー50%ぐらいの記憶だったので、撮影条件にかなり寄るとも言える。いずれにせよ、バッテリー交換が厳しい場面で頻繁な交換が必要かと言われると、そこまでではないというのが結論なので、通常使用ではそこまで気にしなくても良いとは思われる。ただし、あまり多くバッテリーを持っていくことができない場合は念のため頻繁に電源を切るであるとか、省電力モードを活用するとかを意識すると安心なのかもしれない。あとはモバイルバッテリーを活用するとよいと思われる。

シャッターに関して

5Dシリーズから使っている人にとっては一つ大きな向上性能として、シャッター連射速度が大幅に向上したというのがある。5D Mark4だと3fps/7fpsから選べるが、R5ではメカシャッター・電子先幕シャッターで3fps/8fps/12fps という、ちょっと前の1Dシリーズぐらいの速度になった。そして電子シャッターであれば20fpsという脅威の速度を達成している。しかも、電子シャッターであればブラックアウトフリーなので被写体を追尾し易いという利点もある。

しかし、気をつけなければ行けないのがいくつかある。メカシャッター・電子先幕シャッター・電子シャッターそれぞれで高速撮影+(H+)時(もしくは電子シャッターなら常に)で色の階調表現が低下する現象がある。通常メカシャッター・電子先幕シャッターは14bitで色が表現されるが、高速撮影+(H+)時には13bitに、電子シャッターはモードによらず常に12bitに低下する(ソース: Canon EOS R5 Specifications and Features - - Canon Europe )。

Canon EOS R5 + EF70-200mm f/2.8L IS II USM

最終的に8bitや10bitのJPEGに書き出すとはいえ、RAWで微妙な調整をやったり、風景であれば空の微妙な階調を記録しておきたい場面では、念のため、高速撮影(H)で、メカシャッター・電子先幕シャッターを使うのが安心になる。それでも8fpsの速度は出せるので、5D Mark4から考えたら少し性能向上できている点はとても良い。

もう一つ、電子シャッターに関しては、ローリングシャッター歪みとフリッカーが起こる。ローリングシャッター歪みに関してはよほどの高速シャッターでないとでてこなく、あまり気にしてないが、自分が撮影してて気になったのはフリッカーだ。

Canon EOS R5 + EF70-200mm f/2.8L IS II USM

白熱球だと問題ないが、とくに最近導入が進んでるLED照明で撮影をすると如実にフリッカーによる縞模様がでる。電子シャッターがグローバルシャッターになればこの問題は解決するはずだが、現状ではローリングシャッターを採用しているので避けられない。室内の照明光源でLED(色がついてる光源でわかりやすい)が使われれている場合は、念のため電子シャッターは避けたほうが無難かもしれない。

ラッキングAFに関して

5D Mark4でもゾーンAFがあって、トラッキングっぽいことはできたが、被写体を選択してトラッキングするのはR5で初めて体験した。普段は置きピンを使ったONE SHOT 1点か構図を決めてからのサーボ1点で撮影しているが、今回は人物(瞳・頭部検知)でトラッキングサーボAFで撮影した。なお撮影条件として電子シャッターを利用している。

撮影した感想としては、とても優秀で、これは今後も使っていきたい機能に感じた。

Canon EOS R5 + EF70-200mm f/2.8L IS II USM

電子シャッターでブラックアウトフリーな分、ストレスなく追尾と画の配置ができつつ、フォーカスは瞳、背を向けているときは頭部付近を追尾しており、暗所であったり、大きな帽子などを被っていてもしっかりと認識できているのが信頼感があってよかった。

Canon EOS R5 + EF70-200mm f/2.8L IS II USM

今までの撮影の中での歩留まりとしてはだいぶ改善した感覚がある。

2023/11時点で買いか?

わからん。仕事なら持っていて損はないと思う。噂のR1まで待てるなら待ってもいいかも。スタジオ撮影で使うぐらいならまだ5D Mark4で戦える。動体を高画質で撮影したいならR5はおすすめ。5D Mark4からの乗り換えとしてはこの選択肢にならざるを得ないが、趣味用途で直近撮影機会がそんなにないならMark2狙いしたほうが幸せになれそう。お金あるなら買ってもいいかも。実売50万超えるしね。

リファクタリングをする勇気を育むために

リファクタリングというのは、動作を変えずにプロダクトやソフトウェアの内部構造を整理・変更する行為を指します。この作業は実際にプロダクトを作っているエンジニアにとってはとても重要であり、自らの生産性を改善や、プロダクトのエンジニアリングの認知不可を低減するために行われる作業ですが、そのリファクタリングの特性によって、実施するまでに様々な困難が待ち受けていると思います。今回はその困難を少しでも減らす方法を考えてみたいと思います。なお、リファクタリングを行うことそのものの困難さは主に技術的な問題であったり、手間の話が多いです。その点に関しては個別具体なエンジニアリング手法が多いのでこの文章では取り上げません。この文章の関心範囲はリファクタリングを行うということを決定するまでのプロセスです。

Abstract

  • すべての仕事で「この仕事をすることでどうなるか」と「この仕事を実施しなければどのような状況になりますか」という、0からプラスへ、マイナスから0への観点の質問をすべての仕事で明らかにする。
  • リファクタリングした仕事はその結果が発揮できるタイミングが必ずあるのでそれを明らかにしよう。
  • 期日や目標日を決める必要がある新規機能開発がある場合は、期日や目標日を使わず、予測日でステークホルダーに状況を伝える

人間の意思は基本的に弱い(と思う)

プロダクトやソフトウェアを成長させていくと、早かれ遅かれ初期の設計からは想定していなかった問題が起こるのは誰しも経験あることです。可能であれば、その問題の原因である設計まで戻ってやり直したいと思うこともあるかもしれませんが(世の中には3回作り直すということをやっているチームもあると聞いたことがあります)、現実的にそれを行うのはビジネス上の問題や、モチベーション、作業のコストパフォーマンスを考えてやらない選択肢をとることが多いです。やらない問題に目をつぶって前に進むこともできますが、多くの場合はリファクタリング課題としてどこかしらに記録されており、例えばプロダクトバックログに置くことが多いと思います。そして、とにかく今は機能開発をすることが重要なので、一旦ここは目をつぶって、あとでなおそうと気持ちを切り替えます。

さて、更にプロダクトやソフトウェアを成長させていくことで様々な期待が寄せられることになり、要望や、バグ修正などが多く寄せられ、チームは初期の構築段階同様に様々な作業に取り組むことになります。様々な改修が施され、まさに「全速力で走っている蒸気機関車を走りながら改善・修正」する状態です。そこで更に「ここが少しこうなってると直しやすいんだけどなぁ」となるようなリファクタリング課題が見つかることになります。しかし、今は今使っているお客さんのためにもバグの修正を優先したり、次の目標にもなるべく近づいておきたいから一旦おいといて、目標が達成したらしっかりと時間をとってなおすぞ!という気持ちになります。

さて一旦機能開発が落ち着きました。今こそリファクタリングをするチャンスです。とおもったら、次の機能開発の案件が入ってきました。バグの報告もちょこちょこ(もしかしたらいっぱい?)あったりします。開発中に出てきた優先度の低いバグをサクッと直したい気持ちもあるかもしれません。とにかくお客さんが困ってるし、少なくとも再現性のあるバグは直しておきたいよね。あと新しい機能の設計もじっくり取り組んで、機能開発までに設計に自信をもちたい、そんなことを考えてしまうと、なかなかリファクタリングに取り組むことができません。

そこで妙案を考えます。「そうだ、もうこう考えてもリファクタリングには全然取り組めないんだから、週に20%はリファクタリングとバグの修正をするための保守時間としてちゃんと確保しよう。だいたい週5日稼働日があるなら1日ぐらいはそういう時間をとってもいいよね」と。早速上司やPdMと交渉に行きます。大体の場合は「あーそれくらいの時間ならまあだいじょうぶか。その分余ったら機能の開発にも回せるし、生産性も上がりそうだな」とかそんな感じでしょうか。

さて、明確に時間を分けたおかげで問題は解決し、はれて素晴らしいリファクタリングライフの幕開けです!頑張っていきましょう!

ってわけにはいかないことが多いです。もしこれで解決できているチームがあればこの先は不要になりますが、そうならなかったチームであればこの先を読む価値は少しあるかもしれません。

ついに明確に分けられた時間を使っていざ取り組もうと思いますが、時間を分けただけで、この枠ではバグとリファクタリング、そして保守作業を一緒に取り組むことになります。もちろんバグがなくなったわけではないので依然としてバグの修正をやることになり、バグが終わったらリファクタリングをやろうとなりますが、その間に何かしらの依存しているものがEOLを迎えるなどして、また違う作業が発生したりします。そして時間を区切ったことでバグやEOL対応などが終わり切ることなく、来週、そのまた来週みたいにどんどんリファクタリングの予定がずれていきます。

時間を分ける前にできることがあるのではないか

時間を分けるという解決策は、目的に追われているチームの目的に注力する時間を強制的に削ることで、目的外のこと、とりわけエンジニアにとって関心の強い物事に関する優先度をエンジニア自身で判断し実行したいという思いを実現するために生まれたものかもしれません。そこに保守作業や、バグ対応を含めるのは一種の罪滅ぼしや、バランスを取っている、という感覚が強いように感じます。もちろん目的のための機能開発、ユーザーのためのバグ修正、運用のためのEOL対応、これらはすべてとても重要です。どれを欠いても遅かれ早かれプロダクトを生かし続けることは難しいでしょう。しかしリファクタリングはどうなんでしょうか。今までの話ではリファクタリングはこれらの要素に比べたら優先度の低い、「やれればいいや」ということなのでしょうか。プロダクトを生かし続ける原動力の根本はそれを運用する人にあると考えることはできないでしょうか。人の行為に対する障害を取り除くことは機能開発やバグ修正、運用改善に劣る優先度でしょうか。

時間を分けるという行為は、優先順位をすっ飛ばして行動することに近いと言えます。現在の優先順位では下にあるものを引き出して実施する行為だからです。しかし、その時間を分けた中でも優先順位付けが行われているのであれば、その目的は達成できていない状態です。優先順位は物事を行う上で並行で実施できない状況であれば必ず欠かすことのできない尺度でしょう。であればそもそもの問題は優先順位付けにあるといえるのじゃないでしょうか。

どうリファクタリングの優先順位をあげ、実施する勇気が育まれるのか

よくある優先順位付けとして、新規機能開発、バグ、運用、リファクタリングそれぞれのカテゴリ別で優先順位を決め、プランニングである一定の割合で各カテゴリから課題をもってくるという方法が考えられます。しかしこれには難しい点がありそうです。まず、そのような形で運用してしまうと、新規機能開発やバグが多くの割合を占め、リファクタリングの課題を「一時的に」という理由で0にできてしまうのがあります。強い意志でリファクタリングの課題を必ず一定入れるという意思決定ができるのであればおそらく問題はないでしょうが、特になにかの締め切りが近くなってくるとこの「一時的に」という言葉が頻繁に使われるでしょう。それがいつしかリファクタリングは入れられるなら入れるぐらいのおまけとしての扱いにして良いんだという認識になり、そして永遠に実施されないでしょう。もう一つの難しい問題は、せっかく付けたリファクタリングの優先順位が無意味になってしまう可能性です。リファクタリングの優先順位を決めておくのは一見良さそうに見えますが、リファクタリングの効果が発揮できるタイミングはその優先順位で並べられる順番では発生しないことが多いでしょう。リファクタリングは定常的な運用の場合にも効果を発揮しますが、リファクタリングによって変更したコードや機能に手を入れるときにも効果を発揮します。つまり、新規機能開発やバグ、運用による開発・改修を実施する前に行うことが重要になります。これは、リファクタリング課題の集めて眺めても決められることではなく、リファクタリング課題に関連する開発を一緒に見てあげる必要があります。以上のようなリファクタリングの特性により、リファクタリング課題だけで優先順位を決めて一定のリソース枠で実施することは難しい印象があります。

リファクタリング課題同士の優先順位付けは意味をなさなく、リファクタリングは関連する開発によって優先順位を決めることができるというベースで立脚するのであれば、リファクタリングを含めたすべての仕事と統一的な優先順位を判断する尺度が必要になります。この尺度は仕事の質の例外なく決定される尺度で有ることが望ましいと考えます。新規機能開発も、バグも、運用も、リファクタリングもすべてを一つのものさしで当てはめるのです。しかし物事はそんなに簡単に考えることを許しません。わかりやすい話で言えば、新規機能開発は多くの場合、スコープと期日が決定されています。この決定されている事項が新規機能開発を最優先にさせる根本的な原動力になっています。CoD(Cost of Delay: 遅延コスト)がわかりやすいですが、このCoDが小さいほどよいので新規機能は素早く出す必要があります。また、バグはユーザーの評価に影響します。バグに依るユーザーの行動のブロッキングによって発生してしまうユーザー自身の機会損失は、人間が何かを提供していると自覚していればとても強く意識してしまうでしょう。運用もEOLという期限によってプロダクトやソフトウェアが危険にさらされるという明確にわかりやすい指標があるのです。リファクタリングの問題はここにわかりやすい指標がないことにあります。なんとなく、開発しやすくなるであるとか、ちょっと早くなるとか、そういう弱い根拠を使っている状況であれば、優先順位を決める話し合いにあげる勇気さえない状況です。

優先順位を決定するときこれらの何をみて決定しているのでしょうか。チームによって違いますし、違う尺度で書かれているので多少強引に決めている部分もあるとは思います。もしくは駆け引きやギブアンドテイクで決めているところもあるかもしれません。しかし、多くの場合において「この仕事をすることでどうなるか」という質問のやり取りはやっていると思います。それは例えば、ユーザーストーリーや、受け入れ条件などでも表現されているかと思います。リファクタリングが難しいのは、この質問に対する答えが弱いところです。もちろん答えることはできますが、リファクタリングは基本的にマイナスを0に戻すような内容が多いのです。であれば、すべての仕事の内容に対して、「この仕事を実施しなければどのような状況になりますか」という質問をしてみると良いかもしれません。まず、リファクタリングを含めたすべての課題で共通して答えられる質問を用意し、記録することが重要になります。どの仕事も、この2つの質問は必ず答えられるはずです。そこから具体的な根拠を考えてみても良いのではないでしょうか。その上で、そのリファクタリングがどのようになったら効果を発揮するかを明確にしましょう。これはリファクタリングを行うタイミングを決める上で重要な情報になります。これがなければ、「リファクタリングはいつかやるもの」という状態でズルズルと後ろにずれていきます。

そして、特に期日や目標日を決める必要がある新規機能開発がある場合は、期日や目標日を使わず、予測日でステークホルダーに状況を伝える必要があります。最初の方にも述べてますが、新規機能開発を行っているときでさえ、リファクタリング課題は積まれるのです。しかし、期日や目標日が決められてしまっては、リファクタリングの時間あれば新規機能開発を強行して安心感を得ようとします。自動車を組み立てたあとにネジを改善するような行為はやめて適切にリファクタリングを施す必要があります。当然予測日はずれる可能性があるわけです。その予測日がずれることで、ステークホルダーからスコープ調整や、リファクタリングを行わなかったときのリスクを説明するチャンスを得るようにしましょう。プロダクト開発は不確実性に富み、設計は漸進的であり、固定的でないこと、固定的な設計で発生するリスクを繰り返しステークホルダーに伝えましょう。プロダクトは最初の構築の段階より運用される時間のほうが圧倒的に長いのです。(このあたりは その品質は最初から間違っている! | ドクセル がとてもおもしろいです。)スクラム開発であればこれはスプリントレビューで実施することが望ましいです。

【日記】リモートのデイリースクラムが終わらない話

デイリースクラムが終わらないらしい。アドバイザリーとして関わっているフルリモートチームのレトロスペクティブを聞いてみると、デイリーに40分ぐらいかかっており、それでも話が終わらないらしい。スクラム開発をやっていると スクラムガイド を読むことがあると思うが、ここには、

デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。

としっかり明記されている。型通りやっていれば15分、チームサイズやスクラムをやってなれない状態であっても20分やそれくらいで終わりそうだが40分超えて終わらないのはなかなかすごい状況だ。

聞いてみると、様々な共有を行っていたり、PM(たぶんPdM)が共有したいちょっとした話題をすべて集約して話しているらしい。

スクラムガイドによれば、

デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。

(snip)

デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。

とあるので、このチームがやっていることそのものはたしかに正しくやっていそうだ。

そもそもなんで15分なのだろう。スクラム現場ガイド を読んでると、概ね「短い時間ほど集中できる」とか「迅速な共有で時間とお金の節約」とか、概ねそういったことが書かれていたりする。いろいろここにも思想はあるが、15分という時間制限をつける事自体は特に違和感はない。自分も一時間もミーティングをやっていると大体ダレてくるので毎日やるのであればそれこそ短い時間のほうが集中力は持ちそうだ。

よく考えると、スクラム開発はリアルな場にいることを前提としたTips等が多いイメージがある。デイリースクラムは(デイリースタンドアップって言ったりするぐらい)全員が立って15分で行うことで、身体的な負担も利用してファシリテーションを行おうとしている感じがある。さらには、アジャイル宣言の背後にある原則によれば、

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

と書いてあるように、面と向かって話すことも前提としている。実際面と向かって話すことが多いチームは、ミーティングとは別に常日頃話しながら仕事をすることが多いと思う。自分はこれを「非公式のコミュニケーション」と呼んでたりするけど、この非公式のコミュニケーションを全面に活用すれば、チーム内の情報共有はかなり効率的に実施できるので、デイリースクラムで話足りないことも、必要な人だけ残って話半分に聞きながらでも壁打ちすることは比較的簡単にできる。問題は、これがリモートだとかなり難しい。どうやってもミーティングをセットするという「公式のコミュニケーション」をせざるを得ない。おそらくこのチームはフルリモートであるあるなこの問題に真正面からあたってしまっているのだろうなぁと思った。

リモート下で非公式のコミュニケーションを実現するためにどうすればいいのだろう。常に何かのオンライン会議に入っておく?Google MeetやZoomなどWeb会議サービスはこういう雰囲気には少しむずかしいかもしれない。なんだかわからないがアレはなんとなく聴いている・話していることを前提としたサービスのように思える。Remo、Slack Haddleなどはたしかにサクッと話すために様々なインターフェイスを提供しているがなにか居心地が悪い。この居心地の悪さはなんだろう。

これ以上話すと色々脱線しそうなのと、眠いので気持ち悪いけどこのあたりで終えておく。