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人集まったので開発合宿の企画をしてみることに決めた。

0時に寝て5時に起きた。今日はがんばって起きた！久しぶりに7時半から始業してた。

トヨタの5S

スクラムイベントのふりかえりをしていて トヨタの5S の話題が出た。聞いたことがあるようないような、スクラムを勉強しているいま見返すとじわじわ聞いてくる。玄人ぶって「そうそう、こういうのが大事なんだよ」とか言いたくなりそうな雰囲気がある。普通にやっていたら当たり前のことなのに、忙しかったり複雑な問題に対応してたりすると、普通の状態を維持できなくなって混沌がもたらされる気がする。そういう状況のときに初心に戻るにはこういった原則や標榜を使って啓蒙することに意義があるんだと、いまは思うようになってきた。これ自体をよいとかわるいとか言うのは適切ではなくて、うまくいっていない状態からより戻すときに活用するといった考え方の方が正しいのかもしれない。

23時に寝て6時半に起きた。昨日は疲労困憊だったのでなんもせずすぐ寝た。

スクラムイベント

お仕事のスクラム開発で木曜日はスプリントレビューとプロダクトバックログリファインメントを行う。主にステークホルダーとプロジェクトオーナーがプロダクトバックログアイテムの優先度を議論したり、タスクに細分化されていない課題をタスクにしていくための作業に当てたりしている。本当はタスク化されたイシューをさらにリファイメントするイベントなのだろうだけど、まだそこまで業務やチームの体制が成熟していないため、タスクの細分化のための時間になっていたりしている。

これらのイベントで開発者がイニシアティブをとることはないけど、プロダクトオーナーやその業務チームにいるメンバーたちがどうやって業務をタスク化しているかのやり取りもみえたりする。開発者にとってそのやり取りをみていることに意味があるかどうかはまだ私にはわからないが、業務チームのメンバーがどういった働き方をしているかを知るきっかけにはなる。業務チームは miro を使ってメンバーみんなで同時編集しながら課題を付箋代わりのメモに落としていく。その個々のメモがタスクに近いものになるのだろうけど、私からみたら業務すべてを知っている人がまとめて細分化してドキュメントに書き記して2-3回みんなでレビューすれば終わるようなものを、みんなで付箋紙に書いていって整合性が取れているのかどうかわからないメモの固まりを作っているようにみえる。この作業はみんなでやらないと進捗しないので1週間に1回とかになる。

• チームが扱うすべての業務を知っているメンバーはいない
• 業務に必要な機能の優先順位や優先度を決める権限をもっていない
• 情報が足りないと思ったときにメンバーが自律的に動いて補う体制が整っていない

あとステークホルダーが話す要件や仕様に関わってくる話の大半が口頭で行われていてドキュメントや課題管理に文章として書き記されていない。だから同じ話しを何度も繰り返し聞くようなケースも発生する。わからないことを聞くことも、繰り返し聞くことも問題ではないが、議事録以外にそこで話す内容がドキュメント化されないのはどうしてだろう？という気もした。もっともっと文章を書かないと情報共有やノウハウをためることにはつながっていかないだろうということも垣間みえる。

総括すれば、どんな開発方法論を使っても、リーダーやマネージャークラスが圧倒的に文章を書けないと、その配下のメンバーは自律的に行動できないというだけの話しでしかないが、どうやったら解消できるか？はまだまだこれからの私の課題でもある。

0時半に寝て6時半に起きた。水曜日は朝活の日だったけど、申し込み忘れてカレンダーに入ってなかったから忘れてた。カレンダーの予定に従って生活していることがわかる。

ふりかえり

今日はお仕事でスクラムイベントのレトロスペクティブがあった。最近は日本語でそのまま「ふりかえり」と呼ぶみたいやね。他の用語が英語なのであわせて英語で読んでたけど、ふりかえりの方が日本人的にはしっくりくるのでそれでいいと思う。

開発の情報共有のやり取りが活発になったという意見が出た。私は11月から働き始めてまだ3週間ほどなので以前がどうだったのかわからない。2週間前に本格的にスクラム開発に移行して、POや開発者のリーダーが新任したり、開発者に新規メンバー (私のこと) が追加したりと、いろんな状況が変わっている。なにか特別なことをしたというわけではないけど、自然にコミュニケーションがよい方に改善されているなら全体としてよい傾向に思える。私はまだ業務のことが全くわからないのでインフラやテストなどの非機能要件のタスクをやっているだけ。開発者からみて負債というほど大きなものではないが、やった方がよい技術的な残タスクのようなものを私がどんどん fix しているので開発環境がよくなっている気がするといったコメントを名指しでいただいた。スクラムマスターによると、ふりかえりでは、個人名で問題を指摘するのはよくないが、個人名で感謝を伝えるのはよいという。なので、よいことには個人名が前面に出る。褒められて悪い気がする人はそうそういないので、このプラクティスはチームの雰囲気をよくすることに寄与するのだろうと思えた。

続: 年末調整と住民税の納付

昨日 の続き。eLTAX のソフト版をダウンロードして年末調整の給与支払報告書の申請、住民税の特別徴収の納付も行った。アプリケーションの操作方法と手続きのドキュメントは懇切丁寧な内容なので、アプリケーションそのものの使い勝手はいまいちだけど、とくに手続きに迷うこともなく、順番に操作していけば問題なく申請や納付を完了できた。この2つの手続きは、昨年は紙で申請したり納付したりしていたのが、今年は電子申告になったのでちょっとクラスチェンジしたような感覚で気分がよかった。定期的な行政手続きを毎年やりながら少しずつやり方を洗練させていったり、異なる手続きに挑戦してみたり、制度の仕組みを理解したり、そういう少しずつ改善して学びを深めていくことそのものに幸せ感がある。人に依るんだろうけど、わりと私はマイクロ法人の行政手続きを楽しんでいる。

22時に寝て4時半に起きた。昨日は勉強会を連日でやって疲れ果ててからバテてすぐに寝た。久しぶりによく眠れた。起きてから1時間ほどドラクエタクトやって、ストレッチやって、7時半にはオフィスに行って8時からお仕事してた。

スクラム談義

お仕事で本格的なスクラム開発に参加することになった。スクラムマスターのかわのさんと少しスクラムで雑談した。アジャイル、スクラム、チケット駆動、課題管理などの話題であれこれ話してた。かわのさんはスクラムやアジャイルのアーリーアダプターのようで、かなり昔からやっているから経験や実績が多そうなので私の疑問や懸念に的確に返答をくれた。実際の現場でどう応用するかは別の話題としても、スクラムはそもそも「良い結果」を出すためのものではく「現状をありのままに見る」ものらしい。うまくやろうと思ったらスクラムにプラクティスや開発方法論を組み合わせないといけないし、そのための軽量フレームワークになっているのに、スクラムだけ実践すればうまくいくと誤解している人たちもいるといった話題もあった。私がスクラムうまくいってなさそうなチームをみていて微妙だと感じたのは、自分たちの課題に向き合ったプラクティスや改善に取り組んでなくて、スクラムの方法論を守ることに注力しているようにみえたからかもしれない。

紙の契約書に挑戦

新しいお仕事の契約は紙の契約で結ぶ。実はこれまで クラウドサイン で電子契約しかしたことなくて、紙の契約書は初めてでどきどきした。言うても印鑑を押すだけなんやけどな。でも、印鑑押すのってきれいに押したいという気持ちが出てちょっと緊張するからあまり好きではない。

PMBOK セミナー

PMBOK®ガイド第7版 Quick Review に参加した。

参加者は60人で、すでに PMBOK ガイド第7版を購入またはダウンロードした人が十数人だったらしい。 PMBOK ガイドは4-5年ごとに更新されるものらしい。 本セミナーでは第6版と第7版の違いがどういったものかの概要を説明していた。第7版は第6版の拡張であり、実務で PMBOK ガイドが必要な人は依然として第6版も購入した方がよいと話されていた。

というのは、第7版は過去のガイドを更新したものではなく、PMP 試験は第6版の時点でアジャイルな要素も取り入れているため、第7版のために変更を加えるといった予定は現時点ではない。 つまり、少なくとも PMP 試験やプロジェクトマネジメントの国際規格である ISO 21500 は第6版をベースにした内容があるため、それらが急になくなったりすることはないらしい。第6版と第7版の違いとして次のような話しをされていた。

• プロジェクトマネジメントの節目の切り口が変わった？
  • 第6版: プロセスベース
  • 第7版: 原理原則
• 第7版でガイドに チーム が登場するようになった
  • 主語がチームとなり、チームが○○するための原理原則はこうであるといった内容に変わった
    • 主役はプロセスではなくチーム
  • プロジェクトにチームが寄り添うようになった

これらの違いは、第6版と第7版をテキストマイニングして、共起ネットワークを構築して比較してみるとよくわかると分析されていた。あとおもしろかったのが、第6版と第7版ではページ数は半減したものの、文字数は3割減程度となっており、箇条書きが多かった内容が説明ベースの文章に変わったためだろうといった話しもあった。

2時から Connect 2021 のイベントをみてた。3時過ぎぐらいには眠くて耐えられなくなってそのまま寝落ちしたら7時に起きた。本当は6時から金朝ツメトギの朝活の日だったのに寝坊して参加できなかった。なんか疲れて家に帰って13時から17時まで寝てた。生活のリズムを崩すと大きく集中力がなくなる。その後、またオフィスに行って作業してた。

Connect 2021

マーク・ザッカーバーグの基調講演を聞いていると、機械学習の次のテックの波はメタバースなのかなぁとか思ったりもしたけど、あとで メタバースはディストピアの悪夢です。より良い現実の構築に焦点を当てましょう。 を読んでいて、やっぱり違うよなぁとも思った。自分がメタバースの世界で活動したり、アプリケーション開発をやってないから他人の意見に引っ張らられる。いずれにしても自分でちょっとやってみて、メタバースとの今後の付き合い方を考えないといけないということだけは理解した。今日の時点ではこのツィートがおもしろかった。

pic.twitter.com/4UHSycJ9HR

— seya (@sekikazu01) October 29, 2021

みんなの Python 勉強会

あべさんから依頼がきて みんなのPython勉強会#75 で発表することになった。いつだったか忘れたけど、コロナ禍になる前だったと思うけど、いつか発表してほしいみたいな話しをしたりしながら機会がなくていまに至るというのもあって、内容があうならいっかという感じで引き受けた。20-30分程度でできるPyとエキPy第3版の話しを半々ずつみたいな内容でやるつもり。週末に内容を詰めて資料を作るつもり。Python は普段使いのツールとして使っているものの、お仕事で Go や Java で開発するようになってからあまり深く関わらないようになってしまった。ずっと Python コミュニティの勉強会に行ってたから、いまでも Python の人とみられるのは仕方ないかなとも思う。

フラクタルスプリント

ある記事で フラクタルスプリント というキーワードをみかけて、なんのことか分からなかったので調べてみた。47機関というチームが実践しているスクラムをベースにした開発方法論と言えるのかな？次の発表動画をみて雰囲気は理解できた。

• 15分スプリントの具体的な進め方について動画で話した #15min_sprint

フラクタルスプリントのやり方はこんな感じ。

• 基本はスクラムのイベントをそれぞれのスプリントで行う
• スプリントの中にスプリントを含めるという入れ子構造をとる
  • 1ヶ月 → 1週間 → 1日 → 1時間 → 15分の入れ子
• それぞれのスプリントの20%程度の時間は自由時間にしてバッファをとる
  • 例えば、1時間のスプリントに含むのは 15分 x 3 のスプリントと残り時間は自由なスプリントの時間にする
• 15分スプリントは10分タスクを1つだけやるスプリントと言える
  • 残りの5分をスクラムイベントにあてる

極端にイテレーション期間の短いスプリントをすることで、通常のスクラムの開発方法論になかったイノベーションが起きるのではないか？といったところを狙いに47機関さんが業務で実践的にやっているプラクティスと言えるみたい。実際にやってみてうまくいったことなどを話しているので、ある種の学習コストを要求するものの、よいところもあるようには思える。おそらくは意図的に悪いところを話してなかったようには思える。例えば、それぞれのスプリントのイベントにおけるオーバーヘッドは大きくなるので作業時間が減るとか、10分タスクですべてチケット化すると、チケット数が増えるので必然的に過程の記録はチケットに残ってないはず。スプリントバックログを付箋の代わりに使うだけというのはスクラム開発一般の話ではあるけど、このやり方では開発者が何をやっているかを書く場所としてチケットは適切な場所ではなくなる。代わりに wiki にまとめるとは話してた。wiki だとフロー情報を監視するのが難しくなるが、その分、短いスプリントでのイベント (プランニング、レビュー、レトロスペクティブ) が頻繁にあるのでそれをフロー情報の監視の代替として機能するようにみえる。いわば強制で。

15分スプリントと聞いて先入観でイメージするよりも、合理的なところも理解できたのでチームの学習コストとスプリントイベントのオーバーヘッドを受け入れるなら悪くない開発方法論かもしれない。良い・悪いといった是非ではなく、47機関さんが大事にしているチームの価値観や文化、そしてチームをよくするための実践的な方法論と一緒に理解することでこの開発方法論は活きてくる。開発方法論だけをみてあれこれ言うのは適切ではないとも思えた。自分たちの業務や働き方にあった開発方法論を開発チームはずっと考え続けていくべきだと私は考えていて、47機関というチームはフラクタルスプリントという手法を編み出して、それ自体が素晴らしいなと思えた。