Posts for: #Book

大晦日の帰省

#morning activity  #book  #life  #day off 

0時に寝て6時に起きた。朝活やってからまたちょっと寝てた。午後から高速バスで実家に帰った。

朝活: バッタを倒しにアフリカへ

金朝ツメトギ 2021-12-31 AM 6 金曜朝6時開催のもくもく会 に参加した。厳密には朝活のときは、はらさんの振り返りを聞いてた感じで、終わってから「第2章アフリカに染まる」「第3章旅立ちを前に」を読んだ。アフリカでの生活のあれこれが書いてあって、日本に住んでいる自分からは斬新でおもしろい。なにかの記事でアフリカが経済発展しない理由の1つに賄賂や汚職が横行していて云々みたいな記事を読んだことがある気がするけど、本書の中でもちょくちょく賄賂を要求されたり、不正に給料をもらおうとぼったくりされたこととかが書いてある。日本人からみると賄賂やぼったくりの金額もそんなに高くないので払ってしまったりしてそれが返って社会に歪みを与えてたりするのかな？とも思えた。

モーリタニアの公用語がフランス語で著者は英語しか話せなくて、言葉の通じない国で現地の人たちと仲良くなるのは相当の苦労が忍ばれる。著者は文章を読んでいてもおもしろい感じだけど、言葉のスキルとは別にコミュニケーション能力が高い人なんだろうということも伺える。言葉が通じなくても仲良くなれる雰囲気の人はいると思う。あとは日本と比べると生活環境がよくなくて、いまの自分は外国で暮らすとかできないだろうなと読んでて思うこともあった。

高校の同級生と飲む

毎年、大晦日に集まって近況報告をしたりしてた。コロナ禍があって自粛していたので3年ぶりに集まった。とくに変わりなくみんな元気でいた。18時頃から飲みながらだらだらしてた。私は前に焼き鳥屋さんのマスターのおすすめで飲んだ だいやめ を持っていった。そのとき飲んだお湯割もおいしかったけど、今回はソーダ割りを試してみて、それもおいしかった。友だちも初めてだいやめを飲んで、これ芋焼酎なの？と驚いていた。初めて飲んだら驚くという意味でもこの焼酎はお土産に向いている。

友だちの1人はゴルフにはまっているという話。調子がよかったら80台でまわれるぐらいで、私にはわからないけど中級者と言えるだけのレベルに達しているらしい。ゴルフは接待や出世のためのツールみたいなイメージが私にはある。したがって私とは無縁でやることはないような気がする。かなり歩くから健康のためにもよいという話もあるのでゴルフ自体を忌避しているわけでもない。スポーツとして楽しんでやっているのはよいと思う。

夜はテレビで RIZIN をみていた。出場している選手は全然わからないけど、大晦日っぽいなと思いながらみていた。

目標はもうない

#thought  #book 

0時に寝て5時に起きて2度寝して8時に起きた。前日やや飲み過ぎて軽い2日酔い。

目標考察

この前ストレッチを受けているときにトレーナーさんから「来年の目標はなんですか？」とふと聞かれた。目標という単語に私は忌避感をもっているなと感じた。というのは、普通の規模の会社でサラリーマンやっていれば、期首に目標設定やって期末に評価して昇格やボーナスの金額が変わるといった制度になっていることが多いと思う。私は昔から目標とか意識して働くよりも、働いている過程や状況の変化の中でそのときに大事だと自分が思ったことに注力するような方だった。なので、期首に立てた目標とは全然異なる業績をあげたりすると、目標とか無関係に評価が決まることが多かった。この評価には高い評価を受けたこともあるし、低い評価を受けたこともある。そして、評価は上長やより上位の人たちのさじ加減で決まることも多かった。目標とか組織の論理よりもプロジェクトの状況にとって大事かどうかを自分で判断して行動するから目標が有名無実化しやすい方だった。そういう働き方をしていると、目標とか評価とか無駄な労力よなと思ってしまう。いまマイクロ法人として独立して、目標と評価という無駄な労力を費やさなくて済むので、そういったストレスからは解放された生活を送れるようになった。

閑話休題。トレーナーさんにはこう回答した。目標とかとくにないです。日々、健康で過ごすぐらいのことしか考えてませんと意識の低い回答をした。一方で私はやりたいと思ったことはすでにやっているところはある。サラリーマン時代の刷り込みからか、目標とは計画を指していて、すでにやっていることは目標に含めないように考えてしまうところがある。進行中であってもやり終えるまでを目標と設定して喧伝してもよいとは思うけど、私がすでにやっていることを目標とみなさないのは、上述したように、やっている過程や状況の変化にあわせて変えていくため、予め事前に立てておいた目標とは異なる結果になることが経験的に多かったことに起因する。もうこの歳になると目標を立てるというよりも、目標となることをやっているかどうかの方が重要になってきたという思いもある。

いずれにしても目標や評価のような行動を私は2度とやることはないだろうという話し。

実践知本の読み直し

課題管理における背景の理論考察を始めたとき、早い段階で読んだ本に 実践知 — エキスパートの知性 がある。8月頃に読んだ。当時は知識にもいろんな分野や研究成果があるとわかった程度だった。その後、認知心理学やスクラム開発の背景を学ぶうちに実践知とも関連があるように思えてきた。背景知識が増えた状態で、いまこの本を読み返せばまた違った理解があるのではないかと考えてまた読み直すことにした。

冒険をするチームにはコックが必要

#morning activity  #book 

0時に寝て4時に起きて、なんとなくドラクエタクトしてたら6時になってそのまま朝活に出てた。sns のタイムラインを眺めていると今日で仕事納めにしている人をちらほらみかけた。私は外向けには月曜日が仕事納めで、内向けには水曜日までは働くかな。30日は実家に帰るか、ゆっくり休むか、まだ決めてない。

朝活: バッタを倒しにアフリカへ

先日たまたまみかけた記事から購入した ことを書いた。積ん読状態だったけど、技術書ばかりも疲れるので気分転換に読み進めることにした。

第1章サハラに青春を賭けるを読んだ。著者はおもしろい人だというのは文章から伝わってくるので何を書いてても驚きはしないが、それでもアフリカ(モーリタニア)の生活や状況などは全く知らないことばかりなので何を読んでも斬新には感じる。モーリタニア・イスラム共和国 という国すら私は知らなかった。

第1章は渡航してフィールワークに出掛けた内容が書いてあった。砂漠へ行くチームにコックが必要というのは、ドラクエ脳の自分には出てこない発想で現実は旅をしながらおいしいものも食べたいという欲求は強いのだなぁという学び？があった。

slack のマルチチャンネルゲスト

これまでお手伝い先では slack のシングルチャンネルゲストで参加していた。必然的に1つのチャンネルにすべてのプロジェクトメンバー20人がいる。技術的な話題を気軽に投稿しにくいし、システム通知などもかなり制限されていた。

人間が会話するチャンネルとシステムが通知するチャンネルは分けた方がよい

と、私はプラクティスとして常々言っている。きっと誰もが言っている。システム通知が認知負荷となるという声は業務側のメンバーからも届いていた。これは外部メンバーをマルチチャンネルゲストにすることのコストだけの問題なので、その価値をどう測るかという視点から、中の人がその予算を確保して外部メンバーがマルチチャンネルゲスト化された。その判断を支持する意図でも、slack のチャンネルが複数扱えることでどういった情報共有やシステム間連携の価値があるかというのを、私の経験からも提示していきたいと考えている。情報を監視するという概念、ならびに情報の一元管理にも関わってくるので、課題管理と並ぶ情報共有という文脈で私の強みが活きる分野でもある。いろいろやっていきたい。

課題管理システムの一本化

#morning activity  #book  #scrum 

0時に寝て4時過ぎに起きて2度寝して6時前に起きた。

朝活: バッタを倒しにアフリカへ

【三宮.dev オンライン】今年最後のリモート朝活もくもく会 に参加した。スクラム本を読み終えたので気分転換に バッタを倒しにアフリカへ を読むことにした。主に雑談してたら序文しか読めなかった。

課題管理システムを一本化する

お仕事でスクラム開発を実践している。プロダクトバックログを backlog で管理し、スプリントバックログを GitHub Issues で管理している。課題を複数のプラットフォームで管理することは情報の一元管理という側面からよくないといったことをお手伝いを始めたときから機をみて指摘していた。そういう状態が2ヶ月ほど続いて、GitHub Issues は機能的に厳しいという共通認識が開発者にはあるため、backlog へ一本化されることに決定した。スクラムと課題管理との関係を追究したい私にとっては朗報で、今後は PO も含めて課題管理システムの用途をメンバーにアドバイスしながら課題管理の高みを目指していきたい。但し、backlog は標準で github 連携機能を提供していないため、チケット駆動開発をするには自前で連携機能を作らないといけないらしい。

スクラム開発の所感

#book  #scrum 

0時に寝て2時過ぎに起きてだらだらして7時に起きてだらだらして8時に起き上がった。休日は自然とだらだらしがち。

log4j2 の脆弱性対応

たまたま sns で新たに脆弱性が発見され 2.17.0 がリリースされたことをみかけた。Apache Log4j Security Vulnerabilities をみて、午前中に対応して pr を作成して dos 攻撃の脆弱性と書いた後に次のツィートをみかけた。私は詳細を理解できていないのでこの内容が 2.17.0 で fix されているのかどうかまでは調査できていない。いずれにしても rce 攻撃はこわいから緊急度が跳ね上がるなとみていた。

アジャイル開発とスクラム 第2版

昨日の続き。素晴らしい本だったので所感をまとめた。スクラム開発の理解がより進んだ。

スクラム本を読了

#life  #bizpy  #book  #scrum 

0時に寝て6時に起きてだらだらしてて8時に起き上がった。

ストレッチ

今週もお仕事に注力してた。ストレッチは2-3日/週かな。普通ぐらいの頻度。夜は寒くなって外に出掛けるのが億劫で1日ウォーキングしたかなぐらい。今日の開脚幅は開始前169cmで、ストレッチ後170cmで、久しぶりに170cm台に戻した。いい感じ。右股関節の不可動領域がよくなっているのが実感できるようになってきているので調子はよさそう。今日は全体的に右半身 (太もも後ろ、腰、大胸筋) と張りがあって疲労もやや溜まってそうに思えた。基本的に週末もなにかしら作業していて疲労が蓄積していないのは毎週のストレッチの効果も大きいと考えている。

次の bizpy 勉強会

1月の bizpy 勉強会のイベント、Python で機械学習をやってみる勉強会 を公開した。次回はわたなべさんに講師をやってもらう。このイベントページも作っていただいた。運営が2人になったのでお互いの忙しいときは分担しながらコミュニティを運営していける。本当にありがたい。わたなべさんが担当している間に私も次のネタの下調べや仕込みをする余裕がもてる。メタバースの勉強会やってもいいなとは考えているけど、私だけではコンテンツが弱くて、よそから詳しい人を招いてこないといけない。どうしたものか。

アジャイル開発とスクラム 第2版

読了した。全12章の後にもコラムと対談があって、この内容も読み応えがあっていくつも示唆を与えられるものだった。

  • コラム 野中理論とスクラム
  • スペシャルトーク 野中氏と平鍋氏の対談
    • イノベーションに必要なのは、対話を通じて共振・共感・共鳴する実践知リーダーシップであり、それがスクラムの心だ
  • おわりに

12章で出てきた実践知について、実践知とは何か、実践知リーダーシップとはどういうことかというのが対談の中でも繰り返し出てきてその理解が深まった。私の中では暗黙知と実践知の境界が曖昧だったが、暗黙知と形式知を行ったり来たりすること、そして身体性を伴っているというのが実践知であること。そこには「もの」や「こと」の目に見えない関係性を洞察しながら判断し、本質を考え抜く知力が必要であると述べられていた。昔は 知行合一 と言ったらしいが、90年代以降の日本は分析過多、計画過多、コンプライアンス過多になってしまったという。また時間のあるときに所感をまとめようと思う。

知識創造と実践知の考察

#morning activity  #book  #scrum  #workcation 

0時に寝て6時に起きた。ここ最近は晩ご飯作って食べてアイスクリーム食べてドラクエタクトやって寝るみたいな業後の過ごし方が多い。

朝活: アジャイル開発とスクラム 第2版

金朝ツメトギ 2021-12-17 AM 6 金曜朝6時開催のもくもく会 で第11章スクラムと知識創造と第12章スクラムと実践知リーダーを読んだ。

第11章では知識想像モデルとして SECI モデルが紹介されている。ふと読んでいて、私が課題管理システムでやっていたのはこの「表出化」の活動で、多くのスクラムをやっているチームは「共同化」を主にやっているように思えた。ソフトウェア開発方法論の歴史的に、チケット駆動開発 → イテレーション開発 → アジャイル開発/スクラムの時系列に発展してきた経緯から、私のようなチケット駆動開発をがっつりやってきた開発者が言う対話が重要だと言うことと、最初からスクラム開発で「共同化」しかやらず「表出化」していない開発者が言う対話が重要だと言うことは、背景事情からして根本的に指している内容が違うのではないか？という仮説を思いついた。対話が重要だと言う開発者がドキュメントや文章を書くことをなおざりにするのを見かけて違和感を感じていた。チケット駆動開発をがっつりやってきた開発者は文章を書いた上でそれだけでは解決できなかった問題を解決するために対話が必要だと言っているわけであり、文章すら書けない開発者は対話だけで開発を進められるわけではないと考えると、これまでスクラム開発に抱いていた私の違和感の正体に近づいたように思えた。

第12章では実践知という概念とそのリーダーシップが紹介されている。以前 実践知 — エキスパートの知性 という本を読んで、メタ認知も含めた認知心理学の知見を踏まえた知識創造や実践知を獲得するに至る背景や教育と課題管理との間にある関係性を考えていたことがあった。スクラムにおいても実践知という概念を扱っているのを読んで、ここにはなにかしらの関係性を見出したり体系化を行う余地があるように考えている。やや哲学的な話題も出てくるので人によって賛否がわかれるかもしれないが、私は自分の考えている中長期的な思考や教育への考え方の価値観が合致していて、これが日本的な経営スタイルの鍵だという意見には一定の同意ができる。自分自身も中長期的な展望を大事にしながら課題解決していきたいという想いもあるからだ。

ワーケーション準備

ワーケーション準備 の残タスクを少しずつやっていく。宿泊先の きのいえ に電話してチェックイン前に駐車場にレンタカーをとめさせてもらえないかを問い合わせた。当日に宿泊客がいれば13時以降、いなければそれよりも早めにとめてもよいとのこと。スタッフがいれば声をかけていなくても勝手にとめてよいと教えてもらった。先方からも ふるさと応援！ひょうごを旅しようキャンペーン が本来は12月末で終了だったのが2月28日まで延長されたため、宿泊者が兵庫県在住であればその手続きをしたいとのこと。一旦、オンラインで決済済みの予約をキャンセルして、現地決済で兵庫県の割り引きの手続きをしてくれるという。メンバーは4人中3人が兵庫県在住なので4,000円/人の割り引きで合計12,000円の割り引きになった。

データと業務の変遷

#morning activity  #book  #scrum  #data 

23時に寝てこわい夢をみて1時半に起きて、そのまま寝たのか寝てないのかよくわからない仮眠状態で5時半に起きた。

朝活: アジャイル開発とスクラム 第2版

【三宮.dev オンライン】リモート朝活もくもく会 で第10章 竹内・野中のスクラム論文再考を読んだ。1986年に竹内氏と野中氏によって書かれた The New New Product Development Game から得た概念や理論的背景をスクラム創設者のジェフ・サザーランド氏がソフトウェア開発の方法論として体系化したものがスクラムになる。そのため、原点はこの論文にある。第10章ではオリジナルに書かれている内容とスクラム開発を比較している。オリジナルの論文にある TypeC (キヤノンやホンダの新製品開発) のようなチームの特徴として次の6つをあげている。

  1. 不安定な状態を保つ

    最初に綿密な計画や指示があるわけではない、チームは自由な裁量と同時に困難なゴールを目指す

  2. プロジェクトチームは自ら組織化する

    チームは不安定な状態から自己組織化し、対話の中で自律状態を作り出す

  3. 開発フェーズを重複させる

    開発フェーズを重複させることで、メンバーは専門分野を超えてプロジェクト全体で責任をもつようになる

  4. 「マルチ学習」

    メンバーはグループ全体として学習し、専門を超えて学習する

  5. 柔らかなマネジメント

    無管理でも強い管理でもない自主性を尊重した柔らかなマネジメントが重要である

  6. 学びを組織で共有する

    過去の成功を組織に伝える、もしくは意識的に捨て去る

オリジナルの論文の解説を読んでいると、古きよき日本の家族ぐるみの職場やチームの働き方のように思えてくる。時代が違うのでいまからこういった働き方に戻るのは現実的ではないだろうが、その中で重要だった概念や要素を、いまソフトウェア開発方法論としてのスクラムで実践できるのはいろいろと私の中でも思うことがある。私の考える課題管理の方法論にも竹内・野中氏のオリジナルの論文の概念は影響を受けるように思えた。章末にコラムとしてジェフ・サザーランド氏のインタビュー記事もあった。マイクロファイナンスのプロジェクトを通して、小さなグループに小さくお金を貸し出すことが、貧困から抜けすための小さなきっかけ (ブートストラップ) になるという体験からスクラム開発の動機づけになったという話しは哲学として印象に残った。なにかを成すには哲学が大事だと思う。

データがあると同期したくなる

お仕事でスクラムのふりかえりをやっていて miro と backlog のデータ同期という話題が出た。業務チームはブレインストーミングで要件を洗い出したりする作業のときに miro を使っていて、miro ベースでメモを記述した後でバックログアイテムとして backlog に登録する。このとき backlog に登録した後で miro を捨てるならいいが、残したまま次の展望や要件の洗い出しにも再利用したりしていると、miro と backlog のバックログアイテムの内容が乖離したり不整合が発生したりする。チームとしてはバックログアイテムに書いてある内容が正という運用をしているため、miro のみに最新の情報がある状態が続くと課題になる。私の知る限り、miro と課題管理システムのデータ連携のツールはないと思う。

私からみたら最初からすべてバックログアイテムに文章で書けばいいやんで話が終わってしまうが、人によって使い慣れたツールは異なるため、そんな単純な話しでもない。一方で昔は miro や backlog がなかった時代もあって、そのときは物理的な付箋紙をホワイトボードに張りながら作業をしていたから、本来は同期したいという概念もなかったはずという意見も出た。たしかにツールがデジタルになって電子データとなった瞬間からデータの再利用を考えるようになるんだなと私も思えた。あと付箋紙をホワイトボードに貼り付けていた時代は何週間もその状態のまま放置するといったこともなかったのではないか？という気もした。

ワーケーションの思いつき

#morning activity  #book  #scrum  #event  #workcation 

0時に寝て6時に起きた。

朝活: アジャイル開発とスクラム 第2版

金朝ツメトギ 2021-12-10 AM 6 金曜朝6時開催のもくもく会 に参加した。今回はてらださんも来られていた。第9章を読んだ。KDDI さんの事例紹介で2013年から取り組みしているらしい。フラクタルスプリント を実際の業務で実践している稀な事例としておもしろかった。1週間のスプリントの中に1日のスプリントが4回あるといったフラクタル構造のスプリント。また金曜日は「仕事をしない日」としてレトロスペクティブと OST (オープンスペーステクノロジー、自由な発表と議論の時間) に割当てている。20%ルールに近いものと言えるかもしれないが、自己研鑽のための時間をスプリントの中に組み込むという、組織の理解があってこそできる取り組みを実践していてすごいなと感心した。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。スクラムの話題として だいくしーのスクラム Bar #1 や Scrum Masters Night! Online 〜第10夜〜 に参加してやり取りした内容や考察したことなどをいろいろ話してた。そのうちの話題の1つに、スクラムマスターの役割とは何だろうかがある。スクラムマスターはプロダクトをよくすることに責任をもち、メンバーが働きやすいように支えるような役割である。ここまでは共通認識として、その範囲がどこまでかは人によって意見が異なるように思えた。あくまでプロダクトやチームの範囲内で行動するスクラムマスターと、スクラムを組織全体に広めたり、人事・評価制度や経営にも参加していくスクラムマスターがある。スクラムマスターは社外の人間でもできるという考え方があるが、必然的に後者の役割も担うなら社内の人間に限定される。後者の役割は越権行為ではないか、いやいや、チームのために働いたメンバーの評価が下がってしまえば現場でよりよいプロダクト開発はできないから大事ではないかという意見も出た。便宜上、前者を (普通の) スクラムマスター、後者を「意識の高い」スクラムマスターと呼ぶ。私の考えでは、意識の高いスクラムマスターの言わんとしていることはわかるが、それをやりたいなら部長や役員などになってから職責とともに改善すべきであり、スクラムマスターという組織におけるラインではない人が経営に口出ししたりすることによる、組織の歪みはまた別の問題を引き起こすのではないかとも思えた。私も経営をやっていて経営側の視点でみるとやはりおかしい。

その後にワーケーションについて相談した。城崎温泉にある きのいえ でワーケーションをやってみようかと考えている。参加のお誘いややり方についていくつか相談しながら前向きに検討しようということになった。

忘年会

【初参加大歓迎】三宮.dev＆bizpy 合同忘年会 に参加してきた。忘年会の前に運営に入ってもらった、わたなべさんと軽く bizpy の運営について話してきた。1月はわたなべさんに機械学習の勉強会をやってもらう。私は昨年も三宮.devの忘年会に出てた。昨年は3人だったのが今年は4人になった。名物の大きなポークカツレツ。4人とも勉強会の常連みたいな人たちなのでお酒を飲みながらわいわいやって、コロナ禍になる前のコミュニティの勉強会の飲み会を思い出したりしてた。ワーケーションの話をしたら2人は興味を示してくれて、メンバーが4人集まったので開発合宿の企画をしてみることに決めた。

チームごっこ

#morning activity  #book 

0時に寝て6時に起きた。

朝活: アジャイル開発とスクラム 第2版

第7章の残りと第8章を読んだ。事例紹介なので軽く読み流した感じ。インタビュー記事のタイトルが気になった。

「合宿で、「仕事での同僚」から「チームの仲間」になれました

このタイトルと内容に私は違和感があるので反論としてそれを書いていく。

心理的安全性のつくりかた に書いてあったが、MIT のオスターマン教授によると、チームという概念は比較的新しいものらしい。

職場における、チームという概念は1980年以降、最も広まったイノベーションのひとつだ。

「心理的安全性のつくりかた」ではチームとグループの違いは次になる。

  • チームは共通の目標に向かってともに問題解決やアイディアを出す集団
  • グループはそうなっていない、ただの寄せ集めの集団

共通の目標に対して互いに対話や協働することでチームになっていく。この考え方は私の経験則とも合致するし支持している。実際の業務や作業を通してチームは築かれていくと私は考える。しかし、コミュニケーションの活性化や親睦を深めればチームになると誤解している人もいるように思う。

件のインタビュー記事では、次の内容があった。

合宿の最大の成果は、何だったのでしょう？

「仕事での同僚」から「チームの仲間」になれたことだと思います。昨今、ハラスメントやプライバシーの観点からなかなか個人の深い話ができないことが多いと思いますが、お互いを信頼した上で自分の生い立ちや経験から「私がなぜここにいるのか」を深掘りできたことが大きいと思います。

具体的には、誰とも話さず、自分を見つめる時間として三浦海岸の浜辺に全員を１時間放置しました（笑）。その時間で自分の今までをふりかえり、再集合したときに１人ずつ語り、お互いのことを尊重し受け入れることで心理的安全性が一気に高まったと思います。

私だったら転職を考えますね。浜辺に放置されて再集合して生い立ちとか語れとか言われて、そんな上司だと懸念を抱くと思う。その場で抗議はしなかったとしても。仕事を通して結果的に信頼関係が深くなって、同じ行動をするなら理解できるが、そうじゃない状態で職位の高い人がメンバーに合宿を半強制参加させてプライベートの内容を話させるのはハラスメントと紙一重かもしれない。おそらくこれはたまたまうまくいったケースだというだけで再現性のあるプラクティスにはまったく思えない。厳しい言い方をすると、偉い人の自己満足によるチームごっこではないかと思う。

本番リリース作業

今日は非稼働日なんだけど、インフラ周りの修正をしていたので本番リリースの作業を見守っていた。ハドルで画面共有しながらみんなでわいわいできるので、これはこれでリリース作業の雰囲気を学ぶ機会にもなる。私が本番リリースすることはないだろうけど、担当者がどういった作業でリリースしているかを知っておく方が運用に役に立つ仕組みも導入できるかもしれない。音声通話と画面共有さえあればフルリモートワークでもなにも困ることはない。よい世の中になったと思う。RabbitMQ と Dapr 周りで私が懸念に思っていたことを本番リリースを通して検証したり振る舞いを観察できたので新たな知見を得た。

朝から晩まで多忙な一日

#morning activity  #book  #github 

0時に寝て5時に起きた。昨日 slack で質問していた内容に5時頃に返信があるのをたまたまみかけた。この時間に起きているんだと思って返信にコメントしてたら別のメンバーからもコメントが書き込まれて、早起きは三文の得みたいな感じで朝5時から slack でやり取りしてた。いま私はだいたい8時から始業している。開発チームの半分ぐらいのメンバーはそのぐらいから始業しているのが課題管理システムや git のコミットログからわかる。このチームは朝早い人たちが多いなと感心した。

朝活: アジャイル開発とスクラム 第2版

2021-11-26 AM 6 金曜朝6時開催のもくもく会 で第6章と第7章を読んだ。第2部は企業において実際にスクラムを導入していったときの四方山話が出てくる。私はあまり他社の事例に興味はないが、対談の過程で本質的に大事なことや難しいことなどがあぶり出されることもあるので、実務を通しての話題も参考になる場合があることは理解できる。大半の事例は実業務で使われているという結論がわかるだけでも十分だと思う。とくに大企業は様々な厳しい制約や要件の中で採用していると推測されるので、それだけで大きなメッセージをもつ。斜め読みでざっと読み進めながら興味のある話題があれば精読するといった程度で読んでた。

大企業あるあるな話しでスクラムイベントを通してお互いの距離感が縮まってうまくいったといった内容があった。開発者からすると距離感の遠近に関係なく、必要なら適切な相手を探し出してコミュニケーションを取るのが普通だけど、みんながみんなそうではないだろうし、(同じ会社の社員でも)よく知らない人とは話さないといった考え方をもつ人もいるだろう。ある人はこれを単純接触効果で説明していたけど、業務ではなく人間の側面からみてスクラムイベントが多いことにも意義があるのかもしれない。

顧問さんと雑談

隔週で打ち合わせをしている。最近はお手伝いのお仕事が忙しいので今回は雑談になってしまったが、近況としてリーンキャンバス、スクラム実践の話題などを話していた。わりと盛り上がって1時間で切り上げるつもりが1時間半に伸びてしまって、別のお仕事の時間を圧迫したけど、それはそれで意義のある雑談になったので収穫はあった。

ある組織で新規事業を行う上で AARRR (あー) モデル をすごく重視しているといった話題が出た。バケツみたいなイメージがあって、そこに現実の数字を当てはめていってプロジェクト/プロダクトの改善やふりかえりなどに活かしているという。サービスのグロースに責任をもつ人には重要な概念だという。うちのプロダクトはグロースしなくてもよいけど、なんらかのフレームワークに当てはめて抜け・漏れがないかをチェックすることにも使えるかもしれない。世の中でよく使われているフレームワークを調査しておいて損はないと思う。私はビジネスに全く疎いのでリーンキャンバスを通じて、AARRR モデルの話題になって、それがどういった用途で使われているかというお話しは興味深かった。

具体的には AARRR モデルの他に、スクラムの話題からは野中郁次郎氏のオリジナルの論文、大規模アジャイルの方法論などが盛り上がっていくつかキーワードが出た。そういった雑談の中で感性に従って気になったことを深堀りしていくとおもしろい調査や知見になったりすることを経験的に実感しつつある。今後もそういう機会や内容を大事にしていきたい。

カスタム GitHub Actions の開発

先日 調査していたものをベースに、普通にやる方法と カスタム GitHub Actions の compoiste action で実装する場合の検討資料などを作って、カスタム GitHub Actions を実装してよいといった許可をもらった。企業における唯一の懸念は (原則) public リポジトリで運用するところで、CI のような処理に社外秘は含まれないが、public そのものに審査や承認を必要とするような組織では腰が重くなるようなこともあるかもしれない。ロードマップにも private リポジトリでカスタム GitHub Actoins を動かせるようにしようという課題は作成されている。