日曜日は久しぶりに休もうと決意して、なにか本でも読もうと思っていたものの、機動戦士ガンダム00 を見返したりしていた。リアルタイムでみていたときはそれほど関心はなかったけれど、いま見返してみるとよい作品だなと思えるぐらいの印象が少し変わった。
日記書いて事務作業しただけ
目次
22時から寝始めて何度か起きて7時に起きた。燃え尽き気味でぼーっとしている。起きたら (しんどくはないが) やや喉が痛くて、出張帰りだし、とうとうコロナに感染したかもしれないと思い、外出するときはずっとマスクを付けてた。
ストレッチ
今週も東京出張してきて、さらにいつもよりホテルへ歩く場所に泊まっていたせいか、まずまずの疲労度だった。全体的に疲労はあるものの、それでも先週のピークよりは改善したかもしれない。右足は依然として悪いものの、腰の張りもややあったかなと気になった。今回初めて行ったストレッチで腰をひねりながら上下に引っ張るようなストレッチをして、右と左でまったく伸びや張りが出る部位が異なっていることに気付いた。トレーナーさんによると、左右で筋肉の硬さが異なることからそうなっているのではないかとのこと。右腰から臀部にかけての硬さがみられるとのこと。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。この数値はいつも通りかな。全体としてあまり体調はよくない。
また podman に苦戦する
目次
23時に寝て何度か起きて7時に起きた。出張帰りでなんかバテててなにもせず休んでいた。少し喉に引っかかりがある。出張で飲み歩いたし、そろそろコロナ感染？の疑いをもって生活してみる。
podman と dbus-daemon とsystemd の調査
2次開発の成果物をドッグフーディングの目的で社内へ導入する。メンバーが作業していて nginx が正常に動作しないという。ログをみろとすぐにコンテナネットワーク内の dns サービスが正常に動いていないということはわかった。podman は aardvark-dns というサービスを使って dns を管理する。但し、このサービスがまだまだ安定していなくて不具合があるのを以前にも確認した。このサービスの振る舞いがよく分からなくて、意図しない状況や状態に対して正常に動作してくれない。
他にも調査をしていて rootless で podman コマンドを実行すると次の issue で書かれているようなワーニングが出力される。dbus-user-session というパッケージを導入すれば解決するとある。
dbus-daemon のサービスは systemd で動いていて、systemd のユーザーモードと dbus が正常に動いていないというところまではすぐに分かった。その状態だと rootless な podman が正常に動作しないということもすぐに分かった。ここまではすぐに調査できたが、問題はどうやれば sytemd のユーザーモードを dbus を正常に動くように復旧できるのかがまったく分からない。systemd がそもそも難しいのに、そのユーザーモードは権限管理が関係するのでさらにもっと難しい。1日調べてお手上げで他の社員さんにも相談してみた。
今日は自分の作業は進捗しなかったけど、メンバーの作業の進捗をみていて、メンバーがはまっていたところを助言して、その問題は解決してうまくいって、それだけで満足していた。
次開発と要諦調和
目次
0時に寝て何度か起きて7時に起きた。飲み歩いてお腹いっぱいでお酒もい飲んで寝たから連日でよく眠れなくて初めて泊まったホテルの部屋の印象が悪くなってしまった。ホテルに非があるとは思っていない。
3次開発の要件打ち合わせ
前回の開発課題の打ち合わせはここ 。2時間をとって要件を発散させる。
次は3次開発になるため、2次開発でできなかったこと + アルファな要件を発散させる。概ね予定調和にもなってしまって、私の中でモチベーションコントロールが難しい。私が準備していった展望や構想がブレていないことはよいことでもあるのだけど、会議がつまらないというか、私が緊張感を失ってしまう。私は自分の構想を一番理解しているのでそれをもっと明文化して関係者やメンバーに伝える必要がある。そこに私にはなかった刺激がいくつか入るとよいと考えている。1人の人間の考えることなんか、せいぜいうまくいって8割だと思う。残りの2割は誤っていたり、意味をなさなかったりするのではないか。だからこそ、他者の反論や別の視点の意見には注意している。
今回は用途の違う管理画面をどう設計するかが最も難しい意思決定の話題だった。いまも管理画面はあるが、一般ユーザーが使う情報更新のための管理画面を既存の管理画面に付加するか、独立した管理画面として新規に作るか。話し合った結果、後者のやり方で進めようと私は考えている。もともとの私の意見もそちら側であるし、次の開発体制やマイクロサービスに近いいまのアーキテクチャの構成を総合的にみてそれがよいと考えている。もうちょと突っ走ってやってみてメンバーから反発が起きないかを伺ってみることにする。
稀な出張飲み歩き
目次
0時に寝てあまり眠れなくて7時に起きた、いつもと違うホテルのせいか、あまりうまく寝付けなかった。部屋も広くてよかったのになぜか落ち着けなかった。
プロジェクトの進捗報告
出張したときの月例報告の10回目。前回の進捗報告はこちら 。
概ね 事前に準備してあった資料 のまま次の3次開発へ進むことに決定した。いくつか経営者に確認することも用意していた。「よしなにはからえ」な方向で取り組めそうだ。1年近く開発を継続してきて、次の3次開発を終えれば品質面でも私からみて自信をもてるようにはなると思う。
そろそろ私の契約を終えてもいいんじゃないかと考えていたが、もう少し追加の開発に付き合ってほしいとのこと。それを受けて「もうちょっとだけ続くんじゃ」と自身のモチベーションコントロールをしていく。早ければ今月いっぱいで契約終了する可能性もあった。継続しても、あと3-4ヶ月程度で終えて、その後に私も3ヶ月ほど休もうとか考えていた。まだまだプロダクトの機能や品質に満足していない、私が長期休暇を取れる状態ではないぞという激励でもあったのかなと思う。
セルフ居酒屋
晩ご飯に 大崎一番家 さんへ行ってみた。
店主が1人でやっていて、お客さんはセルフで飲みものを手配する。冷蔵庫からお酒 (ハイビール、酎ハイ、瓶ビール) を取ってきて、氷も冷凍庫から勝手に容器に入れてもってくればいいと言う。あとで卓上に置かれた缶や瓶を数えて精算する。ボトルを入れているお客さんなんかはやってきて勝手に飲み始めたりもすると店主が話していた。食べものだけオーダーシートに書いて厨房にいる店主に声をかけて提出する。厨房の入口に置いていたら、都合のよいタイミングで受けとって料理を作ってもってきてくれる。こういうスタイルのお店を嫌う人もいるだろうけど、私は自分のできることが多いスタイルのお店は気楽で気に入ってしまった。店主も関西の人らしくて陽気な性格だった。料理が大皿なので1人だと2-3皿食べるとお腹いっぱいになってしまう。野菜サラダなんかは私は大皿でもりもり食べたいのでちょうどよかった。口コミでデミグラスカツがよいとあったので注文してみておいしかった。但し、1人で食べるには多過ぎで2-3人向けの分量だが。
こういう1人で全部やるという働き方そのものを私は好む。誰かと一緒に働くの、他の人間と一緒に働くのはどう繕っても気を遣う。居酒屋のような、本来は1人でできないことをお客さんの力も借りながら1人で成り立たせる工夫をあっぱれだと言いたい。以前 マイクロ法人のススメ に書いたが、1人で意思決定して楽しく働く、1人の会社が他の会社と協調して大きなお仕事や難しい課題を解決するという、新しい働き方に私も挑戦していきたい。
飲み歩き
大学の友だちに声をかけてみたら、そのとき浅草で働いていて、その後、ちょうどよい場所として新橋へ移動した。20時過ぎから新橋の居酒屋さんで飲んでいた。2-3年ぶりぐらいに会ったかな。社員が20人の頃に入社した会社がいまや社員が400人になっていて上場も視野に入れてお仕事しているとのこと。当然、その友だちも幹部社員になっていてすごいなぁと近況を聞いていた。マンションを3つ買ったとか話していた。
プロジェクトマネジメントやメンバーの育成など、私も最近はマネージャーをやっているからあーだこーだと話しをしていた。その友だちはもともとマネージャー職を目指していたので私よりもマネージャーとしての経験や知見が多い。その友だちも私に負けず劣らずのハードワーカーなので考え方は私と近いと思う。若い人に適正がなさそうでもどう教えるか、どこで見切るかといった話しが一番盛り上がった。その友だちは3年ぐらい面倒はみるが、それでダメなら適正がないと本人に告げて他の仕事に移ってもらうようにするという。適正がないと本人に告げることも優しさだという。たしかに大企業だと、まったくできない人が開発者として中堅社員になってたりすることもあり、それがプロジェクトの弊害になることを私は経験したことがある。あとお互いに年寄りでスキルもやる気もないのは無条件でダメみたいなところは一致した。以前、参加した オープンセミナーの懇親会 でも、成長しない社員に対してどう接するかの話しをしたことがある。そこでもこのままそのレベルで仕事を継続してもよいが、待遇はそれ以上あがらないことを伝えるとある管理職の方は話していた。
成長の度合いも個人差があり、どの程度をよしとして、どこで線を引くかは難しい。私はプログラミングが好きなら多少のスキルの個人差はあってもよいと考えている。しかし、会社になると組織に貢献しているかというのは大きな基準になるので必ずしも私の考え方は正しくはない。人間が人間を評価するのは本当に難しい。このまま小さい組織で評価とは無縁で働きたい。
ふりかえりのふりかえり、のふりかえり
目次
深夜に1-2時間仮眠をとったものの、あまりうまく眠れなくて、3時に起きて準備して5時に家を出た。新幹線でも寝ていたが、夕方にはやはり眠くなった。
約4ヶ月間の開発のふりかえり
前回のふりかえりのふりかえりはここ 。2時間をとってこの約4ヶ月間の開発のふりかえりをした。
今回は2次開発というのもあって、メンバーも開発に成熟したし、1次開発でできなかったことのいろいろが改善できそうな見通しが立ってきたし、最高ではないものの最善ではあったんじゃないかと思う。私からみても十分によいものを提供できたと思う。8月の後半に私がテンパっていたのはなんだったのか？と思うぐらい、私が後半に詰め込んでやり過ぎたところもあったりはしたものの、それも終わってみればきれいにすべて回収できたのでよかったと思う。課題管理システムから情報を抜き出して1次開発のときと同じ指標の比較もしてみた。それによってメンバーのパフォーマンスが上がっていることも定量的に確認できた。これはまた会社のブログにもいずれ書きたい。これでメンバーも自信を付けて次の開発もがんばってくれるといいなと思う。今回はよい開発になったなと思う。
今回はいろいろ事情があって、私が東京へ出張してそのオフィスで1人でテレビ会議でふりかえりをするといったやり方になった。本当はこういう区切りになるふりかえりにもっと積極的に参加してほしい、オフラインで会議に参加してほしいと思う気持ちはある。それはそれで私の古い考えかもしれないし、メンバーからしてみたら、マネージャーがふりかえりにやかまして疎ましく思っているのかもしれない。若い人たちの考え方にあわせるという意味では、大きなふりかえりをテレビ会議で行うのも構わないのだが、オフィスで1人会議は私のテンションが上がらないことにも気付いた。先週から準備して資料を作って、わざわざ出張して会議をして、会議の場に誰もいないというのは、どう繕っても、私も出張せずにリモート会議した方が合理的だったと思えてしまう。その自分の中の違和感なのか反感に対して新しい答えを見い出さないとこの体制はうまくいかないと新たに思う一時でもあった。
大崎に泊まる
五反田のいつもホテルに泊まるのも飽きたので気分転換に大崎の ニューオータニイン東京 に泊まってみた。五反田から大崎は一駅の距離で川沿いを歩いていける。この川にかかる橋が夜はライトアップされていて散歩していて気持ちがよい。まだちょっと暑かったけれど、15分もあれば歩ける。宿泊プランを朝食付きプランにすると素泊まりに比べて500-1000円高くなる。それでもいつも泊まっているホテルの料金と比べて大差なかったので試しに朝食付きにしてみた。料理の種類の多い朝食ビッフェでとてもよかった。外食が多いと野菜が不足しがちになる。私はこういうところで基本的に野菜サラダを大盛りにしてたくさん食べるようにしている。その野菜の種類やコンビネーションのやり方が増えるほどアレンジする楽しみも増えて楽しい。これはいいなと思って今後もしばらく大崎に泊まってみようと思う。
のんびり過ごす休日
目次
0時に寝て何度か起きて8時に起きた。今日も祝日だからのんびりしようと思ってのんびりしていた。
神戸マロン
季節ものでいいなと思った。神戸シェルブール さんの三木市の本店まで行ってきた。通販だと取り寄せに1週間以上かかる。三ノ宮から下道でも車で45分もあれば着く。高速道路を使えばもっと早く行けると思う。栗が丸ごと1個入っているので食べ応えがあるし豪華な1個のお菓子といった印象を与えられる。1つ試食してみて甘過ぎない上品な餡の雰囲気がする。
椅子の引き取り
一昨日ジモティーでたまたま椅子を探していたらコワーキングスペースで不要になったら椅子を処分したいといった出品をみかけた。これはいいなと思って早速問い合わせて、写真の背景をみたことありそうな施設だと思いながらメールを送って、その後に住所を確認したら、これ カフーツ さんだろ？と推測できて、その後にいとうさんに messenger でメッセージ送ったらそうだったw その後、ジモティー上のやり取りで受取日時を調整した。
お昼に引き取りに行ったら、いとうさんはジモティーでやり取りした人を私だと把握していなくて「えっ」ってなって、私は姓を一応は名乗ってたし messenger でもやり取りしたから伝わっていると思い込んでいて「えっ」ってなった。お互いに「えっ」「えっ」って感じだったw いとうさんは8脚出品していて、私は1脚譲り受ける予定だった。しかし、3脚譲り受ける予定の人が連絡がつかなくなったらしく、持っていってほしいとお願いされて、4脚ぐらいなら実家の離れにあってもいいなと思えたので譲り受けることにした。ちょうど椅子の買い替えらしく、明日に新しい椅子が9脚届くから早く処分したかったみたい。
車の荷室に入るのはぎりぎり3脚が限度で、一旦その状態で家に帰って自宅の部屋に2脚置いて、もう1度引き取りに行って4脚を受けとってきた。実家の離れへ持って帰るのも2回に分けて2脚ずつ運ぶことになる。4脚もあれば、次はまた机を探すのをがんばろうと思う。椅子よりも机の方が引っ越しのタイミングで処分に困る人が出品する傾向にあるように思える。つまり、入手しやすい。これで離れに椅子が5脚揃う。あとは4人で向き合える机を1つ入手すれば、仲間内で作業するだけのコワーキングスペースの体裁は整うように思える。同時に部屋にある不要な家具も整理しないといけない。
記事の拡散
昨日の翻訳記事 が思いの外、バズっているみたい。2019年の古い記事だし、多少は読まれるかな？とは思ったけど、はてブ100もいかないだろうと感覚的に思っていた。現時点でも150を超えてて、多くの人に読んでもらえること自体は翻訳した甲斐もあって嬉しい。その翻訳記事のリファレンスに、過去に私が書いた記事も紹介したところ、ついでに私の記事にも関心をもって読んでくれる人たちがいた。過去に書いた当時はまったく読まれなかった記事が、マーケティング的に多くの人の目に止まったことによって読まれることになった。自分でもよい記事を書いた手応えがあったので多くの人に読んでもらえること自体が嬉しかった。
昨年に マーケティングをやっていく宣言 をしたときに「映像研には手を出すな！」の金森氏の言葉を引用した。そのことを思い出していた。
休むつもりで翻訳作業だけやることにした
目次
3時に寝て何度か起きて8時に起きて、今日は休もうかとだらだらして、14時に起きて、お昼ご飯を食べてからやっぱりオフィスへ行って作業してた。
翻訳: ストーリーポイント再考
昨日たまたま読んだ記事 を翻訳しておくと、後々に参考文献として使えてよさそうだと思って著者へ翻訳したい旨のメールを送っておいた。いまどきメールはあまり使われていないし、翻訳の許可を求めても無視されることも多い。1週間ほどは返信来ないだろうと勝手にゆるく考えていたら、なんと1時間半後に返信があって快く許諾してくれた。
お昼にそのことに気付いて、これはすぐにやるしかないと思って慌てて準備して、オリジナルの記事を読み直しながら deepl を使って再翻訳した。本当は昨日 deepl を使って課題管理システムに下訳したものを置いてあったんだけど、もうちょっと丁寧に精読しながら翻訳し直すことに決めた。2回目の翻訳なので昨日のものよりは品質の高い記事を公開できたと思う。
昼に寝て夜に考える
目次
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.
— Santiago (@svpino) August 31, 2023
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
私もストーリーポイント否定派の1人だが、その投稿に発明者ですら謝罪していると書かれていた。それでずっと気になっていたので発明者の元記事を読んでみた。翻訳に近いが、日本語でも要約された記事もある。
これを読んでみて、発明者も言っていることは真っ当だと思う。ストーリーポイントがいかに誤用されているか、それによって意味のない時間を費やしているか。そもそも見積もりは現実のプロジェクトマネジメントにおいて必要とされるが、実際の開発においてまったく無意味であるといったことなどが書かれていて、ソフトウェア開発を見積もろうとする行為そのものがそもそも間違っていて、それをさらに相対化 (抽象化) させたストーリーポイントが役に立つわけがないとすら思えた。誤用されるなら、スプリントプランニングのためにストーリーポイントを使うのはまったくの無駄とまで言い切っている。
この記事を読んで不思議なことの1つに、実際にスクラムでストーリーポイントを使ってみれば意味のない指標であることに気付く開発者は多いと思う。スクラムガイドにおいても、見積もりより経験主義の重要性を説いているにも関わらず、なぜこんな誤ったメトリクスがスクラムとセットで導入されているのか、私には理解できない。プロジェクトマネジメントては別の、政治力学においてストーリーポイントが使われているのではないか？という気すらしてくる。
課題管理の文脈だと、見積もりは勘と経験でよいというのが私の解になる (ストーリーポイントを使ったところで出鱈目なんだから) 。課題管理と見積もりというテーマもなにかしらコンテツになりそうな気がした。
涼しくなる前に暑さ対策を
目次
0時に寝て何度か起きて7時過ぎに起きた。6時に起きようと思ったけど、気付いたら7時になってた。
ドキュメント書き
8月前半にやっていた非機能要件である差分比較の仕組みについてドキュメントを追加した。但し、この機能はまだ品質を保証できないところがあるため experimental という機能にした。そのためのドキュメントとサポートポリシーについても明記した。利用者からのフィードバックを得られることを目的にした開発途中の機能をプロダクトに追加する仕組み化した。あまりエンタープライズ向けの業務システムでそういった機能を多用するようなことはないと思うけど、QA を十分にできなくてまだ品質に自信がないといったときにも使えるかもしれない。
実務スタッフの訪問
先日の 暑さ対策委員会 の続き。
そろそろ電話しようかと考えていたところ、スタッフが訪問してくれた。7月の中旬からクレームを上げていて、初めてオフィスに来てくれて室温が高いことを確認してくれた。いまだと昼間は30℃ぐらい。その人は過去の経緯をわかっていないようで、フィルター交換と冷媒交換をしたが、まったく効果がないことを丁寧に説明し、エアコンのコントロールパネルの温度・風量設定もまったく機能しないことを伝えた。明日の午前中に工事の業者と一緒に調査してくれるという。ようやく人が来てちゃんと確認してくれた。明日の作業に期待。
クレジットカードの明細のリアルタイム連携
先週末の小旅行にかかった経費の領収書を会計システムに登録した。30分もあればできるのにずっと後回しにしていた。
唐突だが、freeeカード Unlimited がすごくよい。起業時に作った法人向けのクレジットカードは所持しているが、クレジットカードの盗難・紛失時の冗長化の目的で4月に携帯用のカードとして導入した。これが後発のせいか、freee のシステムとの親和性を考慮しているのか、まだ使っているユーザーが少ないからなのか、ほぼリアルタイムで決済情報が会計システムに連携される。
もともと使っていた旧来のクレジットカードと比較できるため、会計システムと決済情報のデータが迅速 (ほぼリアルタイム) に連携すると、実際に運用してみて事務手続き工数を削減できることに気付いた。旧来のクレジットカードは決済情報を取得するのに2週間ほどかかり、さらに先方のシステムの都合で月の負荷が高くなりそうな期間 (10-14日とか) は連携不可といった運用になっている。2週間経ってから決済情報をみても何にお金を使ったのか思い出すのに少し時間がかかったり、請求書などを調べて確認したりする作業が発生する。クレジットカードで支払った直後に会計システムに取引登録するのがもっとも事務手続き工数を削減できることに気付いた。
半年間ほど新旧のクレジットカードで運用してみて、旧来のクレジットカードによる決済を置き換えていくことに決めた。今後は Unlimited なクレジットカードを2つ使って冗長化した運用にしようと思う。
速さは正義。
資料作りの一日
目次
23時に寝て何度か起きて6時に起きた。疲労も溜まっているのでなるべく早く寝るように努めている。旅行中ずっと早起きしていたから早起きするのは苦にならない。
今開発の大きなふりかえりの資料作り
ふりかえりのために課題管理システムの issue 情報から統計的な数値を取得する。
gitlab の cli ツールを使って issue 情報を取得して mongodb にインポートする。
$ glab api --paginate "groups/product%2Funicorncidm/issues?milestone=2023-09-05¬[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つの案でいくのもよいかもしれない。機能要件は実際にお客さん先へ導入するときにもいくつか出てくるだろうけれど、非機能要件の運用に影響を与える懸念のところはなるべく早く改善しておきたい。次の開発期間にそこだけ対応すれば、一定の安心をもってお客さんへ提供できるようになると思う。