23時に寝て1時半に起きてそのまま断続的に寝て起きての繰り返しで6時に起きた。本当は非稼働日だけど、昨日作った pr の機能を検証するための環境を用意してもらったのでそれを動かしたら要件漏れに気付いてその改修をやってた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせの日。今日の議題は2つ。

見積もりの雑談

先日、見積もりについての 私の考え を整理した。それについて第3者の意見も聞いてみたいと考えた。

いろいろ雑談したけど、結論としてはバーンダウンチャートもストーリーポイントも運用が形骸化したら役に立たないという当たり前の話しになった。従来の期限や工数を見積もる方法と比較して得られるメリットはそう多くないという私の印象である。ストーリーポイントが優れている唯一の点は、タスクの見積もりについて話し合う場ができるという、その機会そのものがあげられる。その機会を使ってメンバーとの情報共有や教育の場にもできるという点がある。それ以外のところでストーリーポイントのメリットはさしてないと私は感じた。

ストーリーポイント(以下SP)について雑談していて、あるチームでは事前に見積もったSPをタスク完了後に実績ベースで上書きする運用をしていたという。その理由は見積もったSPに対して進捗や実績が悪いと偉い人からお叱りを受けるため、SPが正しくなかったという解釈で実績から変更しているという。

— Tetsuya Morimoto (@t2y) February 18, 2022

来期の予算策定

ざっくり試算すると来期は少し赤字になる。経営者として赤字にならないようの対策を講じる。私が予め用意した施策は次の3つ。

1. 既存顧客のお仕事の単価をあげる
2. 赤字分の売上を別のお仕事で稼ぐ
3. 赤字分の経費を削減する

はらさんから役員報酬を下げてはどうか？という提案もあったけど、これは却下しようと思う。もともと役員報酬は高くないし、役員報酬を下げると必然的に健康保険や社会保険の再計算やそれらに関連する事務手続きが発生する。いま私は会計士も税理士も雇わず自分ですべてやっているのだけど、専門家に依頼するにしろ、自分でやるにしろ、経費を下げるために別の経費を発生させてしまう。これは本末転倒な気がしてやりたくない。

したがって、お仕事の単価をあげる交渉からまず始めることにする。私はずっと開発者で働いてきたから交渉ごとはほとんど経験がない。交渉の経験を積むという側面でも自分のキャリアにとって新しい取り組みになってよいと考えている。次の契約更新は3月末になるのでそれまでに交渉のための準備を進めていく。

1時に寝て3時過ぎに起きて6時半に起きた。

ふりかえり

今日はスクラムのふりかえりとプランニングの日。1週間が終わり始まる。ふりかえりをしていて、2週連続でスプリントゴールが未達になって、原因を追求する空気になって、最終的にはリーダーを糾弾するみたいな雰囲気になった。昔の私だったら論理的に問題を掘り起こそうとがんばったかもしれないけど、いまはもう歳をとってスラムダンクの安西先生みたいになったのか、もしくは外部パートナーとしてのお手伝いだから真剣ではないのか、その両方かもしれないが、一歩引いたところからできなかったもんしゃーないんちゃう？みたいな心境で見守っていた。うまくできない人や状況に「なぜできなかった？」みたいに迫ると「努力が足りなかった」とか「もっとがんばります」みたいなやり取りしかならないので不毛にみえる。経営者のくせにこんなことを言うと怒られるかもしれないが、仕事なんてやりたい人やできる人が楽しめるように好き勝手やって、そうじゃない人は最低限やるとか、邪魔しないように配慮するとか、もうそれでいいんじゃないとか思ったりもしている。もう人類は会社の半分ぐらいの社員が遊んでても暮らしていけるぐらいの生産性を手に入れたと思うよ。半分は言い過ぎか。いずれにしても私はもう無理なく自分のペースで働きたいと思うようになった感じ。

backlog の管理者権限

お手伝い先で backlog を課題管理システムに使っている。私は課題管理システムのスペシャリストとして、ああしたい、こうしたいといくつも注文を付けて、チームの開発やワークフローを改善している。これまでは管理者権限がなかったのでもっている人に依頼するしかなかったけど、そろそろ私の相手をするのが面倒くさくなってきたのか、私にも backlog の設定を変更する管理者権限をもらえた。さっそくカスタム属性をいくつか作って実験的な検証をしていた。カスタム属性は backlog のフリープランでは使えない機能なので、お手伝い先の実地で用途や振る舞いを検証するしかない。同じプロジェクトでも種別ごとにカスタム属性の設定有無を切り分けられる機能があって、この機能は他の課題管理システムでみたことがない実用的で珍しい機能だと思った。チケットに PR とコミットのカスタム属性を追加して、github actions でコミットや PR のタイミングでそれらの属性に URL を追加すれば github 連携もできそうな気がしてきたところ。週末に時間があったら作ってみる。

22時に寝て0時に起きて5時に起きて7時に起きた。なんか体調が微妙。

リファクタリングのチケット作成

これまでは業務に関係しないところの機能拡張をしていたので新規にコードを書くことが多かった。いま業務の開発にも着手し始め、その過程で既存のコードを読むことも多くなった。私からみたらコードの品質が著しく低くて、ただ動いているだけで堅牢でもないし、設計の意図も伝わらないコードが多い。そういうのを自分が変更するときに少しずつ出来る範囲でリファクタリングしたりしている。今日もコードを読んでいて enum の扱いについてチケットを作成した。

前に手伝っていた会社の契約を終了するときに java のコードレビューだけなんらかの契約で依頼できないかという話しはあった。そのときは別件のお仕事が火の車だったので断ってしまった。いまお手伝いしている java のコードをみても、java に慣れていない開発者の書く java のコードはたいていひどい。なぜひどくなるかというと、java は言語仕様が複雑で難しいからだと思う。java の経験が少ないと Effective Java を読んでも理解できないぐらいには java の設計は難しい。その結果として java で開発しているのに設計を練っておらず「動けばいい」コードが散見される。java で開発するなら「これ以外に動かない」コードを書いた方がよいと私は考えている。その意図が伝わるからドキュメントなんか読まなくても「動かすにはこう書けばいい」とわかる。さらにインターフェースが明確であれば、責務や拡張方法も明示的になる。

前から考えてはいたけど、sier や内製始めたばかりの事業会社向けに java のコードレビューのサービスを提供することも考えている。私1人だとたくさん受けられないし、コードレビューサービスのようなものは会社の信頼関係の方が重要なのでビジネスにするのはちょっと難しいかもなぁ。

見積もりのまとめ

先日 見積もりについて考察した 。もともとは社内向けに書こうと書き始めたが、内容の大半は社内に閉じたものではなかったので一般論の記事として書き直した。最終的には1万文字ぐらい書いた。

• 見積もりをがんばらない

0時に寝て5時に起きてちょっとだらだらして7時ぐらいにはオフィスにいた。

スプリントの期間とプランニング

いまスクラムのスプリントを1週間で運用している。スクラムのスプリントレビューをやっていて、今回のスプリントはスプリントゴールが未達となったという事実がありつつも、ある開発者が本来のスプリント計画にはなかった課題を少し工数を使ってやってしまってたという話題が出た。それはある機能開発の調査の過程でこういうツールがあると業務メンバーの作業効率が上がりそうだとわかって、それをヒアリングしていた開発者が PoC も兼ねてプロトタイプを作っているうちにすぐ運用で使えそうなベータレベルまで作ってしまったという話し。言うても2日ぐらいで作ったと思うのだけど、5日しかないスプリントで2日は40%という大きな工数を占める。スクラムマスターも否定はしなかったけど「スプリントの計画にないタスクに工数を割くのはよくないと、スクラムマスターの立場からはお小言を言わざるを得ない」と言及した。

先日、私も直接はスプリントの計画達成に直接寄与しない リファクタリングに半日を費やした ので、ツールを作ってしまった開発者の気持ちはわかるなと無言で聞いていた。それと同時にスクラムのスプリントは、運用によっては開発者のモチベーションを削ぐことも実感した。やる気の有無で仕事をするのはよくないと一般論では言うけど、実際のところ、人間のモチベーションは制御が難しいのと、知識労働はモチベーションが生産性に大きな影響を与える。開発者のモチベーションが高いときにそのタスクをやるのは理に叶うという側面もある。非開発者は次のプランニングで承認を得て来週のスプリントでやればいいじゃないかと思うかもしれない。でも、違うのだ。いまやってみたいという気持ちが大きいときにいまやるのと来週やるのではモチベーションが異なる可能性がある。この気持ちは開発者にしかわからないと思う。

その開発者がデイリースクラムでツール開発をやることを相談しなかったかの理由も理解できて、合理的に考えたら相談しても承認を得るのは難しいので、黙ってやってしまったのだろうと思う。そして、今回のスプリントのスプリントゴールが未達になったとしても、なにか業務に影響が出るというわけでもないことをメンバーが知っているというのもある。スプリントは全力でやるものだけど、全力でやらなくてゴールが未達になっても、なんら業務に支障がでない事実がスプリントの目的を減衰させている。

そういう業務と実情があっていない現実、ルールに則るとお小言を言わざるを得ない牽制機構、たった2日すら自由に時間を使えない開発者、なんかスクラムって窮屈だなと直観的に感じた。

0時に寝て4時に起きてドラクエタクトしたり twtter 眺めたりして金朝ツメトギで DX 実践手引書 を読んでた。

スプリントの残チケット

スクラム開発でバックログのバーンダウンチャートを表示させるために、スプリントに対して、同じ期間のマイルストーンを設定するように運用が変わった。運用変更に伴い、バーンダウンチャートも表示されるようになり、スプリントの進捗状況の見える化が進められた。そのバーンダウンチャートの運用について SM と話していて、私の過去の開発とスプリントの考え方の大きな違いを発見した。

私がこれまでやってきた開発はマイルストーンの日には残チケットがゼロになるように開発していた。開発が遅延してそのマイルストーンで完了しそうにないチケットはどこかのタイミングで次のマイルストーンに先送りさせることで、いまやっているマイルストーンの開発が計画通りに完了するよう調整していた。作業が期限までに間に合わないチケットは早めに検知して報告して対応を検討する。一般論として、遅延したときは期限を延期するか、次のマイルストーンに先送りするかのどちらかしかない。

スクラムの場合、PO はスプリントを中止する権限をもっているが、基本的にスプリントの計画は変更しない。スプリント内でマイルストーンに間に合わないチケットがわかっていても、マイルストーンは変更せず、次のスプリントプランニングまで放置して、次のスプリントプランニングで遅れたチケットの作業を中止するか、引き続きやるかを検討するという。このやり方だと、スプリント終了日 (マイルストーンの日) に遅延して完了できないとわかっているチケットがすべて残ってしまう。当然バーンダウンチャートはバーンダウンしない。

一方でこれまでマイルストーンこそ設定していなかったものの、様々な理由でスプリントでやる予定だったチケットが遅延することは度々あった。それはデイリースクラムで遅れますとか、予想外のタスクが出てきましたとか、そういう報告をもって実運用では次のスプリントに持ち越ししていた。実運用では持ち越ししているのに、マイルストーンを変えるのは計画の変更だからやってはいけないという話しになって、見える化したのにバーンダウンしないチャートがあって、この運用に何の意味があるのだろう？わからなくなった。

0時に寝て5時に起きた。昨日は早く寝たので早く起きた。

ふりかえり

お仕事でのスクラムのふりかえり。課題管理システムの一本化 や slack のマルチチャンネルゲスト移行 について、メンバーのよかったコメントがいくつか出た。私は経験者なので、これらの結果がどうなるかは最初からわかっていて、移行中に運用面からもあれこれプラクティスを提案しながら結果が出やすいようにサポートしていた。まだまだもっとうまく運用できるけれど、経験則では、他のメンバーの運用がついてくるには半年ぐらいかかるだろう。仕組みを取り入れただけではまだ効果が半分で、適切な運用を継続することでさらにその効果を実感できるようになる。これからも注力していく。

ともあれ、私がお手伝い始めた初日から非効率だと考えていた3大課題のうちの2つは2ヶ月経って対応された。ついでに書いておくと、最後の1つはカレンダー共有の課題がある。お手伝い先の社内で使っているカレンダーを協力会社のメンバーはみることができない。その逆も然り。したがって、正社員と協力会社でカレンダーを共有できない。これがスケジュール調整コストやコミュニケーションコストを高くしている。カレンダーを共有していると、例えば、slack でメンションして予定が入っていないならすぐに返信がくることを期待するけど、会議中だったらその会議が終わってからかな？といった予測が働く。仮に会議が3つ連続していれば、PR のレビューはすぐできないだろうと推測される。プロジェクトメンバーでカレンダーを共有できないと、相手の行動予測の精度が下がり、結果としてコミュニケーションコストが高くつく。

生産性をあげるには特別なことをやらなくても、当たり前のことを当たり前にしていくだけでも効果がある。同じ職場でずっと働いていると、当たり前じゃないことがわからなくなってしまって非効率になってしまうことも多々ある。そういうところは外部の人間が指摘することで改善できる余地となる。

datadog のログ管理

お仕事で datadog の ログ管理 機能を調べている。メトリクスしか使ったことがなかったけど、ログ管理も一通りの機能は揃っていていろいろできる。なぜか私が手伝う会社は datadog を使っていて、他のサービスも試してみたいという気持ちもあるんだけど、やっぱり datadog は優れたサービスということなのだろうか。

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

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

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

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

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

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

log4j2 の脆弱性対応

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

【悲報】log4jのRCE脆弱性、2.15で緩和策としてlocalhostにしかlookupできなくしたはずが、127.0.0[.]1#example[.]comのように#を挟むことにより回避可能ということが判明。これにより任意ドメインへのリクエストが可能になり再びリモート実行可能に。みなさん最新版の2.17にアップデートしましょう。 https://t.co/uQhJSnjv7m

— たいしょー（Hiromasa Ihara） (@miettal) December 19, 2021

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

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

• アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

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

ストレッチ

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

次の bizpy 勉強会

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

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

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

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

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

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

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

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

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

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

ワーケーション準備

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

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 がなかった時代もあって、そのときは物理的な付箋紙をホワイトボードに張りながら作業をしていたから、本来は同期したいという概念もなかったはずという意見も出た。たしかにツールがデジタルになって電子データとなった瞬間からデータの再利用を考えるようになるんだなと私も思えた。あと付箋紙をホワイトボードに貼り付けていた時代は何週間もその状態のまま放置するといったこともなかったのではないか？という気もした。