2時に寝てあまり眠れなくて6時半に起きた。スマホで ゴブリンスレイヤーⅡをみてから寝た。

プロジェクトの進捗報告

出張したときの月例報告の12回目。前回の進捗報告はこちら 。

開発の中盤を過ぎて、これから追い込みへ入っていく。予定していたバックエンドの機能開発は完了した。私の頭の中ではもう完了までの見通しができていて、あとはフロントエンドの新規画面を構築したり、品質や堅牢性のための小さい改善をしていくといったことを残りの1ヶ月で行う。若いメンバーに経験を積んでもらうことも考慮しているため、サポートを最小限にしながらメンバーの成長を期待したいところ。見た目上の開発スケジュールは順調なのでマネージャーとしスケジュールの懸念はほとんどない。kit/vite アプリケーションの調査 を私が自らやっていて、これを一区切りつけないと次の作業に進めないところが、私の課題でもある。インターネットを検索してもみつからないことを、どのように考え、仮説を立て、調査して、意思決定していくかをメンバーに示したい。マネージャーが一連のワークフローについて業務の参考になるようものをみせることができればいいなと考えている。

以前 コミュニケーションのレベルについて考えたこと をベースにした方法論を社内の wiki にも書いてある。5段階のコミュニケーションのレベルがあり、多くの人たちはレベル4までしか到達しないのだけど、課題管理のスキルを身につけるとレベル5の「聞かなくてもわかる」というエスパーのような状態に達する。メンバーのうちの1人はこのレベルに片足を踏み入れていて、十分にうまく課題管理できているという話題も共有した。一方でレベル5に至るためのプラクティスや施策を、課題管理という文脈でもっとうまくできないか？というのはうちの会社のビジネスの中核でもある。とても難しい。いわば「気付き」を習得するための短期修行コースのようなものを作りたい、業務の中で。この話題を話し始めると、気付きの有無はその人の性格や動機づけにも関連するせいか、賛否両論の多様な議論に発散しやすい。私の立場としては、一定レベルまでは誰でも身につけられるスキルとして扱いたいが「気付き」が本当にスキルなのかどうか、実は確信がない。しかし、諦めることなく継続的に考えていきたい。

昨日は夜にいろいろ作業して、1時に寝て4時に起きて7時に起きた。

テックブログ執筆

先週から調査している内容 についてテックブログを書き始めた。マネジメントや実装をしていると筆が進まなくて書き始めるのが随分と遅くなってしまった。学校の試験前に、試験勉強やらずに部屋の掃除をやってしまったりするような感覚。午前中は昨日 go-ldap に送った pr がまとめてマージされた。その修正を取り込んだライブラリのバージョンで関連するところのコードをリファクタリングしていた。それでもようやく書き始めた。書き始めたら一気に 2/3 は書けた。本当は晩ご飯を食べた後にレビューできるところまで書いてしまおうと思っていたが、そこまで体力 (集中力) が続かなかった。なんとなく張り合いがなくて適当なところで妥協してしまう。

試行錯誤から学ぶ開発スタイル

たまたまみかけた記事でひどい内容の記事をみた。一読しただけでもやもやしていたのを知人と議論していて言語化できるようになったので書いてみる。

• エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう

もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。

こういうこと言い出すマネージャー (PO) 多いし、意見そのものは一理あるんだけど、これをエンジニアがイニシアティブとってやっていたらマネージャーいらないでしょ？ということを自覚していない。もっと言うと、PO という責任のある立場の人が大変という理由で責任放棄しているようにみえてしまう。(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 という記事では実際にテックリードまたはエンジニアがプロジェクトのイニシアティブを取っていると書かれている。もしそうするなら、まず自身のスキル不足や未熟さを受け入れないといけない。

マネージャー (PO) にとって大きな役割は意思決定であって、仕様案や計画において技術的なところがわからないのであれば、エンジニアに委譲したり相談して事前にいくらでも調整できるはずだし、その調整作業そのものはマネージャーの仕事の1つと言える。そういった調整をマネージャーがやるからエンジニアは実開発の設計や実装に集中できる。結果的に生産性も上がる。この文章から伺えることはリファインメントや計画に臨んだときにダメ出しされてやり直すことを手戻り、大変、効率が悪いとネガティブに捉えている。逆に言えば、最初から完璧に仕様案を作れるはずだと思い込んでいるふしがある。

そして、誰もが知っていることだが、最初から完璧な仕様案や計画など作れるはずがなく、不確実性を許容しながらスクラムやアジャイル開発といった開発方法論の取り組みで調整していくというのが、モダンな開発のやり方である。その試行錯誤や手戻りは無駄なことではなく、チームやプロジェクトが学ぶべきことの1つだという考えがこの文章からは読み取れない。そして、自分が仕様案を適切に作れなかったのを自分のスキル不足だと認めず、チームのエンジニアが議論に参加していないからだと責任転嫁している。それはマネージャーが技術的に大事なことを理解できていなかったとふりかえり、計画を修正したり、次に計画するときは同じようなことが起こらないよう、努めていくというのがスクラム的なプロジェクトの進め方になるはずだ。手戻りはアンチパターンではなく、学びの過程や必要な試行錯誤であると認めて受け入れるところから始めるべき。

能をみて帰ってきた後に晩ご飯を食べたらオフィスへ戻ってもよかったんだけど、なんかだらだらしているうちに22時になって、もういっかという感じでさぼってた。それから寝て1時に起きて4時に起きて7時過ぎに起きた。

ストレッチ

今週はのんびりしていた気がする。お昼もずっと自炊していて健康によいような感じがあった。実際ストレッチを受けていて、いつもよりも負荷も疲労もないように感じた。強いて言えば、左ふくらはぎと二の腕の辺りがやや張りがあったぐらい。あとコロナワクチンを接種して2週間以上経って、いまの自分は無敵だと思うストレスの無さもあってか、体調がよい。今日の開脚幅は開始前155cmで、ストレッチ後157cmだった。お尻の筋肉を鍛えるエクササイズを教えてもらった。

もくもく会

神戸でもくもく会 に参加した。ON PAPER というコワーキングスペースで開催された。うちの会社から徒歩2分ぐらいの場所にある。窓際は西日でやや光が気になったが、10階で外を眺めながら作業できるのはそれなりに快適で、広くて設備が新しくて雰囲気のよい施設だった。またイベントがあれば参加してみたいと思う。主催者がこのコワーキングスペースのメンバーまたは関係者なのかな？よく分かっていないけど、とくに参加料は受け取らずにコミュニティイベントを開催されていた。もくもく会のイベントを今後も続けるかどうかはまだ分からないとのこと。

主催者の関係者で異業種からジョブチェンジを考えている方が2人いていくつかやり取りした。1人は26歳でまだ若いので実績がなくても第2新卒枠でいけばいいのではないかと思う。もう1人は30歳でちょっと第2新卒は厳しそうだが、プログラミングスクールに通ってちゃんと勉強していて、自分で cms っぽい web アプリケーションを rails で開発されていた。デモもみせてもらったが、web アプリケーションでよく実装する機能を一通りは実装されていて、パッとみた感じはよさそうにみえた。

RUNTEQ というプログラミングスクールで勉強しているとのこと。話を聞く分には浮ついたスクールではなく、自分で調べて考えて作れというスパルタ的な方でキーワード以外あまり教えてくれないといったことを話していた。それはそれで自分で調べて理解して実装しないといけない。あと chatgpt に聞きながらも実装していると話していて、いまどきの未経験者は chatgpt に頼るのもよいと思う。最初は誰もがコピペで振る舞いを検証しながらそのコードが正しいかどうかを自分で理解して書けるようになればよい。未経験から半年ちょっと学んで、rails でここまで動くものが作れるなら十分に自分で学んで作る能力はあると思う。ポテンシャル採用でよい会社に入れればうまくステップアップできるのではないかと思う。

IT 業界へジョブチェンジしたい人たちも増えたように思う。未経験の方々が最初に経験を積むよいお仕事はないだろうか。前にもこの話題を誰かにしたか、どこかで書いた気がする。お金をもらう以上、発注者がいて、責任をもって成果物の納品を期待している人がいる限り、いくら価格調整をしても未経験者にシステム開発してほしくないだろうし、してもよいけど責任者が品質を担保してほしいと思うのは自然だと思う。普通の会社なら先輩がついて経験の浅い開発者の面倒をしっかりみている (はず) 。私もいま若い開発者を少なくない割合の時間を割いて指導している。経験の浅い開発者を同時に面倒をみることは物理的にできない。せいぜい2-3人といったころだろうか。教えるというドメインは労働集約になるのでスケールしない。実務のシステム開発を教えるビジネスというのはちょっと成り立たないとは思う。

0時に寝て何度か起きて7時過ぎに起きた。眠れたような、そうじゃないようなよく分からない起き方をした。お昼ご飯を食べる間もなく、打ち合わせとコードレビューで1日を終えた。連休明けでよい慣らしになった。

税理士さんとの打ち合わせ2

税理士さん探し の続き。今回話した方は公認会計士だった。監査ができるのが公認会計士で、税務の申告ができるのが税理士という役割の違いになる。会計監査も含めてチェックしてほしかったら公認会計士さんにお願いするといった役割分担になるかもしれない。話してみて、若くて理路整然として悪い印象はなにもなかったのだけど、逆にこの人がうちの会社の会計／税務を親身にやってくれそうにもみえなかったし、ホームページの事業内容をみても公認会計士だから税務のビジネスだけではなく、もっと大きな会計のお仕事の方がを目指しているようにもみえた。同じ質問をして、前回の税理士さんの回答の違いなども考慮しながら選定の判断材料にはなるなと思いながらやり取りしていた。選択する側の打ち合わせはおもしろい。

アーキテクチャの再考

お手伝いしているシステム開発で、私の中ではもうアーキテクチャは固まったかな？と考えていたのが、お客さんと話していて、さらなる要件や展望を聞いているとそうじゃなかったことに気付いた。どうやら最初の実装としてはいまのアーキテクチャを堅牢に作って、その次の要件として待っていてくれたようにみえる。

私の認識を正す意味も含めて、さらにお客さんの要件や世の中の競合製品に対して競争力をもつにはどうするかといった視点をざっくばらんに雑談した。もう1段階アーキテクチャを見直す必要があるなと思えた。開発に着手して今月末でちょうど1年が経つ。これまで大きなアーキテクチャの変更もなく、順調に開発は進んできたものの、ここらで見直しやズレの補正が必要になってきてもなんらおかしくはない。いまの開発フェーズでは対応しないが、次の開発フェーズに向けてのアイディアの1つとしてアーキテクチャの再考が必要なことを認識した。

1時に寝て何度か起きて7時に起きた。エアコンを入れていると夜は寒くなってきた。

feedly pro+ にアップグレード

前からやろうやろうと思っていながら忘れて放置していた feedly のサービスに課金した。基本的に sns をやめていく方針でいるため、情報収集のソースを rss リーダーに戻そうと考えている。これまでも sns と並行で feedly を使ってはいたんだけど、もうちょっと feedly の機能も使ってインプットの効率を上げられないかと考え始めた。Pricing をみると、pro, pro+, enterprise の3つのプランがある。真ん中のプランが推しのようだったのであまり調べもせず Pro+ プランを選択した。いまのところ、検索の機能を使うぐらいでしかないが、そのうち ai 機能的なものも触ってみようと思う。

次開発の優先順位付けと担当者の割り当て

先週の要件発散会議 の続き。発散させた要件を整理して優先順位を決めて、担当者まで割り当ててしまった。課題管理がうまくできている必然なのか、なにも迷わずに自然にこのモジュールは○○さんでといった棲み分けもできて、それぞれが役割を果たせば開発の要件が満たせる体制になっている。全体像としての要件一覧は概ね用意した通りではあったものの、要件や設計の詳細の話しをしていると、私の要件の誤解もいくつかあって、それらは訂正しながら設計していくことにはなる。それでもメンバーも成長してきて、私がお膳立てしなくても、メンバーが自ら考えてうまくいくように設計してくれそうな雰囲気もみえてきたりしていて、それによって、私は面倒で厄介なインフラの再整備に注力できたりもしている。前開発がうまくいったので、なんとなく次開発もうまくいきそうな、始まる前から気を抜き過ぎにも思えるが、もう始まる前から開発が終わっている (うまくいくことが分かっている) ような感覚をもっている。できることは分かっていて、あとはどれだけの量を次開発で実装できるかといった、私が区切りの線をどこに引くかだけ決めればいいんじゃないかと考えている。よいチームになってきたなとちょっと誇らしい。

23時に寝て何度か起きて7時に起きた。

開発方法論／開発ガイドの更新

前回の改訂 から約4ヶ月ぶりに開発方法論と開発ガイドを改訂した。

• 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
• 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

近いうち、チームに新規メンバーが入る。今回の開発を経て新たにわかったことや変わったところなどを更新するつもりで全体を読み直してみたが、大きく変わったところはなく小さいアップデートに留まった。開発方法論に 情報共有とコミュニケーションのレベル というタイトルで5段階のレベルについての考え方を追記した。この内容は私もまだ完全に言語化できているわけではない。「聞かなくてもわかる」という価値観の存在をまったく疑っていないが、その背景にあるコミュニケーションの在り方や人間関係や組織での運用についてまだ曖昧なところが多い。それも含めて考えるよい機会だと思ってうちのチームに向けた内容に整理し直してまとめてみた。もう2-3回ぐらいこのテーマで話しをしたりすると、より言語化できてもっとよいものができそうな気配は感じている。

fun/done/learn のカスタマイズ

昨年からふりかえりの手法として fun/done/learn という手法を採用している。2週間のイテレーションが終わったときに毎回このフレームワークを使って、やったことをメンバーに共有するといった用途のために使っている。大きな開発のふりかえりを行ったときにマイルストーンごとの fun/done/learn の個数の変化などもふりかえってはいるが、そこの統計値がなにかに役に立つようには、いまのところ、うちのチームでは思えない。

今回のふりかえりをしているときにメンバーから done はいらないのではないか？という意見が出た。この手法の発明者のオリジナルの記事 ファン・ダン・ラーン(FDL)ふりかえりボード と読むと、done = deliver だし、done しなかったことも含めてのふりかえりを実践していたことが伺える。うちらはやったことをふりかえるためのフレームワークとして活用しているため、done がデフォルトでプラス fun/learn が付くといった運用になっていた。その通りだなと納得して done に置き換わる、うちらの開発の運用にあうカテゴリを考えてみて give を採用した。ゴロがよいように fun/give/learn と呼ぶ。

give とは、このマイルストーンでやったことを形式知として、他のメンバーに共有可能な状態にしたという意図を表す。wiki を書いたりするのもよいし、テックブログを書くのもよい。暗黙知を形式知に変えるには少し手間暇がかかるのでちょうどよいカテゴリに思える。3つのカテゴリに属するときにもっとも価値が高いような運用にも向いている。そのためのボードも作って、これを jamboard の背景に設定してふりかえりをしている。何ヶ月か運用してみて、うまくいきそうだったら fun/done/learn の亜種としてどうだろう？といった提案のテックブログを書いてみたい。

0時に寝て何度か起きて7時に起きた。飲み歩いてお腹いっぱいでお酒もい飲んで寝たから連日でよく眠れなくて初めて泊まったホテルの部屋の印象が悪くなってしまった。ホテルに非があるとは思っていない。

3次開発の要件打ち合わせ

前回の開発課題の打ち合わせはここ 。2時間をとって要件を発散させる。

次は3次開発になるため、2次開発でできなかったこと + アルファな要件を発散させる。概ね予定調和にもなってしまって、私の中でモチベーションコントロールが難しい。私が準備していった展望や構想がブレていないことはよいことでもあるのだけど、会議がつまらないというか、私が緊張感を失ってしまう。私は自分の構想を一番理解しているのでそれをもっと明文化して関係者やメンバーに伝える必要がある。そこに私にはなかった刺激がいくつか入るとよいと考えている。1人の人間の考えることなんか、せいぜいうまくいって8割だと思う。残りの2割は誤っていたり、意味をなさなかったりするのではないか。だからこそ、他者の反論や別の視点の意見には注意している。

今回は用途の違う管理画面をどう設計するかが最も難しい意思決定の話題だった。いまも管理画面はあるが、一般ユーザーが使う情報更新のための管理画面を既存の管理画面に付加するか、独立した管理画面として新規に作るか。話し合った結果、後者のやり方で進めようと私は考えている。もともとの私の意見もそちら側であるし、次の開発体制やマイクロサービスに近いいまのアーキテクチャの構成を総合的にみてそれがよいと考えている。もうちょと突っ走ってやってみてメンバーから反発が起きないかを伺ってみることにする。

深夜に1-2時間仮眠をとったものの、あまりうまく眠れなくて、3時に起きて準備して5時に家を出た。新幹線でも寝ていたが、夕方にはやはり眠くなった。

約4ヶ月間の開発のふりかえり

前回のふりかえりのふりかえりはここ 。2時間をとってこの約4ヶ月間の開発のふりかえりをした。

今回は2次開発というのもあって、メンバーも開発に成熟したし、1次開発でできなかったことのいろいろが改善できそうな見通しが立ってきたし、最高ではないものの最善ではあったんじゃないかと思う。私からみても十分によいものを提供できたと思う。8月の後半に私がテンパっていたのはなんだったのか？と思うぐらい、私が後半に詰め込んでやり過ぎたところもあったりはしたものの、それも終わってみればきれいにすべて回収できたのでよかったと思う。課題管理システムから情報を抜き出して1次開発のときと同じ指標の比較もしてみた。それによってメンバーのパフォーマンスが上がっていることも定量的に確認できた。これはまた会社のブログにもいずれ書きたい。これでメンバーも自信を付けて次の開発もがんばってくれるといいなと思う。今回はよい開発になったなと思う。

今回はいろいろ事情があって、私が東京へ出張してそのオフィスで1人でテレビ会議でふりかえりをするといったやり方になった。本当はこういう区切りになるふりかえりにもっと積極的に参加してほしい、オフラインで会議に参加してほしいと思う気持ちはある。それはそれで私の古い考えかもしれないし、メンバーからしてみたら、マネージャーがふりかえりにやかまして疎ましく思っているのかもしれない。若い人たちの考え方にあわせるという意味では、大きなふりかえりをテレビ会議で行うのも構わないのだが、オフィスで1人会議は私のテンションが上がらないことにも気付いた。先週から準備して資料を作って、わざわざ出張して会議をして、会議の場に誰もいないというのは、どう繕っても、私も出張せずにリモート会議した方が合理的だったと思えてしまう。その自分の中の違和感なのか反感に対して新しい答えを見い出さないとこの体制はうまくいかないと新たに思う一時でもあった。

大崎に泊まる

五反田のいつもホテルに泊まるのも飽きたので気分転換に大崎の ニューオータニイン東京 に泊まってみた。五反田から大崎は一駅の距離で川沿いを歩いていける。この川にかかる橋が夜はライトアップされていて散歩していて気持ちがよい。まだちょっと暑かったけれど、15分もあれば歩ける。宿泊プランを朝食付きプランにすると素泊まりに比べて500-1000円高くなる。それでもいつも泊まっているホテルの料金と比べて大差なかったので試しに朝食付きにしてみた。料理の種類の多い朝食ビッフェでとてもよかった。外食が多いと野菜が不足しがちになる。私はこういうところで基本的に野菜サラダを大盛りにしてたくさん食べるようにしている。その野菜の種類やコンビネーションのやり方が増えるほどアレンジする楽しみも増えて楽しい。これはいいなと思って今後もしばらく大崎に泊まってみようと思う。

0時に寝て何度か起きて7時に起きた。昨日は晩ご飯食べてからだらだらしているうちにいつの間にか寝ていた。今日はオフィス暑くて14時から帰ってきてお昼寝して19時過ぎにまた戻った。

ストレッチ

先週末は実家や四国へ出掛けていたため、ストレッチをお休みしていた。2週間ぶりのストレッチとなる。右足がパンパンでひどいことになっていた。休んだことと出掛けていたことの疲労が重なったのか、右足のどこの部位も調子が悪くて歩くのもやや辛いと言える。相対的に左足が大丈夫なように聞こえるが、普通の感覚ではそれなりに張りがあるので左足も疲労している。あと腰も左右ともに負荷がかかっているように思えた。今日の開脚幅は開始前155cmで、ストレッチ後157cmだった。週末はちょっと休もうかと思ったぐらいの疲労度と体調の悪さを実感した。

工事業者の訪問

先日の 暑さ対策委員会 の続き。

ストレッチを終えてオフィスに向かうと、ちょうど同じエレベーターで工事業者さんと鉢合わせになった。いまから作業するところだったらしく、作業前にオフィスに入ってもらって通気口の状況を確認してもらった。いまの室温は30℃を少し上回ったところ。通気口からエアコンの風は出ているが、室内がまったく冷えないことを伝えた。そのときになにかの機器にガスを注入したという話しをしていた。これでダメなら (エアコンの？) メーカーの担当者と別の調査か対策を行うといった話しをされていた。何であれ、調査して原因の切り分けをして、次の作業へ進展している話しを聞いて安心した。但し、今日のところは、夜になっても室温の変化はみられなかった。まだ改善するかどうかはわからない。

遺産分割協議書の契印・割印の要否

弁護士さんから以前、作成した遺産分割協議書に割印をしていないことに気付き、税務署の手続きを進められない可能性があるから、もう一度、相続人全員の割印を取得してほしいと書類が届いた。すでに銀行・法務局の手続きは滞りなく終えている。こんな面倒なことを可能性があるという不確かな情報でやってられないと思って、本当に必要な手続きかどうかを税務署に確認してほしいと返信した。それと同時にググってみると、あるほうが改ざん防止になるので望ましいが、必須ではないという記事が多くみつかる。書類を作成するときに依頼されていれば応じるが、書類作成後になって大半の手続きも終えていて、相続税を払うためだけにそんなことやってられるかと思ってこのまま進めてほしいと押印せず書類も返送した。

• https://www.souzoku-zei.jp/souzokuzei/souzoku-tetsuduki/%E9%81%BA%E7%94%A3%E5%88%86%E5%89%B2%E5%8D%94%E8%AD%B0%E6%9B%B8%E6%96%87%E4%BE%8B%E9%9B%86/
• https://www.tax-tomoni.co.jp/blog/souzokuzei/stamp/

もちろん税理士さんや税務署に裏付けをとる必要はあるが、ちょっと調べれば分かることをベテランの弁護士さんが調べずに顧客へ工数を転嫁することにがっかりした。

ストーリーポイント再考

少し前にみかけたポストで「ストーリーポイントは機能しない」というものがあった。

Story Points don't work.

Even Ron Jeffries, who invented them, said he was sorry years ago.

And not only did he apologize, but he called the whole estimation idea "Evil."

Unfortunately, too many teams still use these points to estimate their work.

Story Points is a made-up… pic.twitter.com/w62WJRU7lg

— Santiago (@svpino) August 31, 2023

私もストーリーポイント否定派の1人だが、その投稿に発明者ですら謝罪していると書かれていた。それでずっと気になっていたので発明者の元記事を読んでみた。翻訳に近いが、日本語でも要約された記事もある。

• XP創始者、Ron Jeffries氏による「ストーリーポイントの再考」
• Story Points Revisited

これを読んでみて、発明者も言っていることは真っ当だと思う。ストーリーポイントがいかに誤用されているか、それによって意味のない時間を費やしているか。そもそも見積もりは現実のプロジェクトマネジメントにおいて必要とされるが、実際の開発においてまったく無意味であるといったことなどが書かれていて、ソフトウェア開発を見積もろうとする行為そのものがそもそも間違っていて、それをさらに相対化 (抽象化) させたストーリーポイントが役に立つわけがないとすら思えた。誤用されるなら、スプリントプランニングのためにストーリーポイントを使うのはまったくの無駄とまで言い切っている。

この記事を読んで不思議なことの1つに、実際にスクラムでストーリーポイントを使ってみれば意味のない指標であることに気付く開発者は多いと思う。スクラムガイドにおいても、見積もりより経験主義の重要性を説いているにも関わらず、なぜこんな誤ったメトリクスがスクラムとセットで導入されているのか、私には理解できない。プロジェクトマネジメントては別の、政治力学においてストーリーポイントが使われているのではないか？という気すらしてくる。

課題管理の文脈だと、見積もりは勘と経験でよいというのが私の解になる (ストーリーポイントを使ったところで出鱈目なんだから) 。課題管理と見積もりというテーマもなにかしらコンテツになりそうな気がした。

23時に寝て何度か起きて6時に起きた。疲労も溜まっているのでなるべく早く寝るように努めている。旅行中ずっと早起きしていたから早起きするのは苦にならない。

今開発の大きなふりかえりの資料作り

ふりかえりのために課題管理システムの issue 情報から統計的な数値を取得する。

gitlab の cli ツールを使って issue 情報を取得して mongodb にインポートする。

$ glab api --paginate "groups/product%2Funicorncidm/issues?milestone=2023-09-05&not[labels]=Duplicate,Invalid,Wontfix" | jq -c '.[]' > 2023-09-05-issues.json
$ mongoimport --authenticationDatabase=admin --uri "mongodb://root:secret@localhost:27017" --db gitlab --collection issues 2023-09-05-issues.json

mongodb で aggregation (sql で言うところの group by 句に相当する) するときはパイプライン処理を実装する。例えば、最初にデータをフィルターして、次にグルーピングして、最後にソートするのは次のようなパラメーターになる。

$ mongosh --username root --password secret
test> use gitlab
gitlab> db.issues.aggregate([
  { $match: { $or: [ { "milestone.title": "2023-09-05" },{ "milestone.title": "2023-09-19" } ] } },
  { $group: { "_id": { milestone: "$milestone.title" , author: "$author.username" }, councount: { "$sum": 1 } } },
  { $sort: { _id: 1 } }
])

これで前回の開発のときに取得した数値と今回の開発の数値を比較してみると、いろいろわかることもあって、メンバーが成長していることも伺えて、課題管理をしながら開発を進めることのメリットを実感できる開発になったのではないかと思う。gitlab のアクティビティ図 (草生え図) をみても前回の開発よりも草がたくさん生えているので課題管理に習熟している様子が伺える。これをあと2-3年ぐらいすれば、課題管理を使いこなせる一般の開発者になるのではないかと思う。課題管理 + イテレーション開発でチームビルディングしていくところの、地盤のようなものはできたようにみえる。

この草生え図を匿名化して利用許可をもらって、うちの会社でいうところの課題管理ができるようになると、メンバーの働き方はこうなるというサンプルとして紹介させてもらうつもり。また来週メンバーにもその許諾を取ろうと思う。

次開発の要件打ち合わせの資料作り

今開発を始めるときに洗い出した要件の未対応のものと、今開発でやり残した非機能要件の開発課題を資料にまとめてたたき台とした。それだけでも3-4ヶ月分の開発課題になりそうだし、アーキテクチャとして大きな意思決定も1つある。私自身、7割型は決まっているが、考え方や要件によってはもう1つの案でいくのもよいかもしれない。機能要件は実際にお客さん先へ導入するときにもいくつか出てくるだろうけれど、非機能要件の運用に影響を与える懸念のところはなるべく早く改善しておきたい。次の開発期間にそこだけ対応すれば、一定の安心をもってお客さんへ提供できるようになると思う。

1時に寝て何度か起きて6時半に起きた。気分転換も兼ねた非日常の小旅行を終えてまた元の生活へ戻していく。

ドキュメント書き

昨日の続き。ドキュメントの一部レビューをお願いしているところがあるので別のところのドキュメントを書いていた。その過程で ldap の anonymous bind の設定ができないような制御になっていることに気付いてその設定を修正したりした。ドキュメントを書いていてバグをみつけた。

近況報告の資料作り

四国から帰ってきたばかりなのに来週は東京へ行かないといけない。開発はほぼ完了しているのでなにも憂いはないが、出張のタイミングで大きなふりかえりや次の開発フェーズの要件の発散などもやりたい。そのための資料の準備がまったくできていないことに昨日の夜、気付いた。明日・明後日ぐらいで準備して、できるだけ事前に参加者に共有したい。いまは忙しくないのだけど、なぜか空き時間をうまく作れなくても毎日バタバタしている感がある。

今日は月例の近況報告の資料を作っていた。客観的に、このタイミングで私を契約終了としてもよいだろうし、私の感覚的には次の開発フェーズを3-4ヶ月みて、その後にチームのメンバーにこのプロダクト開発を委譲するといった段取りがよいのではないかと考えている。そういった話しも来週はしてくるつもり。長く残ったとしても今年度いっぱいが区切りとしてよいのではないかな。