お酒飲んで新幹線乗ったせいか、新幹線の中であまり寝られなくて暑くていつもより移動に疲れた。その後1時に寝て何度か起きて7時に起きた。2日酔いではないが、寝起きの気分はよくなかった。

issue を作ることによるストレス軽減

昨日の打ち合わせのメモから議事録を作ったり、そこから新しい issue を作ったりしながら来週の打ち合わせの資料作りをしていた。資料を作っている途中、割り込みでメンバーのコードレビューが入ったりして、あまり資料作りは進捗しなかった。

打ち合わせした内容から issue を作る作業を、私は好きだったりする。何をやってよいかわからない状況というのは苦しい。issue を作ること、要件を言語化したり、背景を調べたり、他の issue との関連付けしたり、そういった手を動かすことがきっかけになって、その issue を明確化していく作業を積み重ねれば時間の経過とともに課題が解決するということを経験的に理解しているからだ。

大雑把に言えば、私にとって、issue さえ作れればその課題解決は優先順位付けと (解決までの) 時間の問題に置き換えられる。あれやらなきゃ、これもやらなきゃ、なにか抜け・漏れがあるんじゃないかと頭の中でもやもやしているものを issue という概念に変換することで考えなくて済むようになっていく過程がストレスを軽減している気もする。

コンテナ勉強会

先日公開したテックブログ とプラスアルファで勉強会をした。コンテナという汎用的な話題だったので CTO から社内向けにアナウンスされて (半業務命令っぽい雰囲気で) いつもより参加者は多かったように思える。10人前後は参加されていた。40分ぐらいで話し終えて20分ほど雑談の時間をとって盛り上がりは微妙だったけど、いくつか意見や質問が出たのでよかったのではないかと思う。

チームのメンバーが発表するときは私がモデレーターの役割をしている。私が発表するときはモデレーター兼発表者になってしまう。モデレーターと発表者を兼任するのはとても難しい。おそらく脳の集中力を向ける先が異なるからではないかと思う。モデレーターは質問者の質問を広げたり、コミュニケーションがうまくいくように手伝ったりする。回答から次の質問を考えたりもする。一方で発表者は自分の調べたことや伝えたいことを聴衆にわかりやすく伝えることのみに注力する。

モデレーターと発表者が同じになってしまうと、自分の説明のどこが伝わっていないのか、質問者の意図を組むにはどうすればいいかといったモデレーターの視点がなくなってしまう。以前 tenntenn さんの個人カンファレンス に参加したときに1人2役でパネルディスカッションをされていて、そのときに同僚からあまりやり過ぎると人格崩壊するから気をつけた方よいといった忠告を受けたと冗談で話されていた意味が理解できた。役者が他人になりきるように、これは兼任じゃなくて1人で2つの人格を演じないといけない。そんな器用なことはそうそうできない。

能のサイトを眺めつつ 世界を変えた“愚か者”フラーとジョブズ をみているうちに寝落ちした。0時過ぎに寝て何度か起きて8時過ぎに起きた。休日以外に8時まわるまで寝ていたという記憶が直近数ヶ月にはないので久しぶりに寝坊した。起きたら8時10数分でそんなことあるはずないとか思ってしまって脳が現実を受け入れられなくて起きた時間を認識できなかった。明らかに8時10数分なんだけど、時計が壊れているなとか思ってしまった。

開発課題の打ち合わせ

大きく時間を使って次開発の打ち合わせ。事前にいくつか開発課題を洗い出せているが、その優先順位付けをしていかないといけない。開発メンバー + 別チームのコンサルタントにも入ってもらって各々の意見を出し合うといった会議をした。私が議題の資料を予め作っておいた。その進行に応じて議論や意見が盛り上がったのでうまくいってよかったと思う。 大項目でまとまった機能をやるよりも、個々の機能単位に優先順位付けした方がよいだろうという話しになって小さい単位で担当者を割り当てて開発を進めていくことになる。いずれはすべてやるが、開発の順番を決めていくのは意外と難しい。

話し終えてからメモをまとめ直しているうちに私自身が要件を詳細に把握できていない要件があることもわかってきた。空中戦だとわからないままふわっと進んでしまうので、文字に落とし込んで整理した上で、本当に必要なものをさらに深堀りして議論しないといけないことに気付いた。

少ない人数で会議をやる利点の1つとして、みんなの意見を順番に聞いていく余裕をもてることがあげられる。「誰一人取り残されない」とどこかの省庁がミッションにあげているように、うちのチームも課題管理を駆使して、それぞれのメンバーができることややりたいことでチームに貢献するような開発にしていきたい。もう半年やって課題管理に慣れてきているので、次開発は前回のようなやり方を教えるところからスタートにはならないはずだと思う。

打ち上げ

4月末にリリースを終えたので区切りとして打ち上げしてきた。うちのチームメンバーと偉い人の5人で行くのだと思っていたら直前に社内のメンバーにたくさん声を掛けたそうで10数人での飲み会になって送別会や部署のキックオフみたいな飲み会になった。賑やかでよかった。個人だとあまり行かないようなちょっとお値段のするコースでよいものを食べられておいしかった。日本酒もいろいろ飲んだ。神戸の酒どころに住んでいるので日本酒に関心をもつようになってきた。

• 山形 上喜元
• 愛知 醸し人九平次

18-20時と打ち上げやって、21時に新幹線を予約していたのでそのまま帰ってきた。このスケジュールの段取りもちょうどよかった。お酒を飲んで新幹線に乗ると思いの外眠れなくてそこだけ疲れた。

少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

• Docker とは何か？

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか？と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない？

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。

0時に寝て何度か起きて6時過ぎに起きた。休日は朝だらだらしてオフィスへ行くのが9-10時ぐらいになることが多いのだけど、今日は普通に8時過ぎに行けた。

法人決算

朝から法人決算の続き。昨日たまたま消費税の計算をして、祝日やのに e-tax 稼働しているんやと思いながら申告した。これまで休日や祝日は稼働していなかった気がするので時代の変化にあわせてシステムはなるべく24時間稼働するように少しずつ変わってきている。今日も法人決算の続きをやっていて、課税所得を確認して、カテゴリ的には3つに分類される法人3税と呼ばれる税金を算出した。具体的には6つの税金を算出しないといけない。

• 法人税 (=> 国税 => e-tax)
  • 法人税
  • 地方法人税
• 法人住民税 (=> 地方税 => eltax)
  • 法人県民税
  • 法人市民税
• 法人事業税 (=> 地方税 => eltax)
  • 法人事業税
  • 特別法人事業税

過去の法人決算の経験からまず法人住民税と法人事業税を確定させてから法人決算の申告をすべきだというプラクティスがある。というのは、法人住民税と法人事業税の数値になんらかの誤りがあると法人決算で提出する別表の数字も修正しないといけないため、先に地方税を確定させた方が手戻りを少なくできる可能性が高い。電子申請するとそれぞれの書類の数値のバリデーションが機能するので手計算や手入力で誤りがあったときに発見できる可能性がある。これは電子申請をするメリットの1つでもある。

地方税を管轄するのが eltax で国税を管轄するのが e-tax で別システムになる。いまとなっては、事前にチェックしておけばよかったなと思うところだが、あとの祭り。e-tax は5月3-4日が稼働していて5-7日が休止している。eltax は5月3-5日が休止していて6-7日が稼働しているというスケジュールになっていた。双方のシステムが稼働していれば今日中に終えられたものが、なんともちぐはぐなスケジュールで申告を完了させるのは来週以降に持ち越すことになる。また来年やるときはこのそれぞれのシステムの稼働スケジュールを事前にチェックして法人決算の作業日程を決めるように法人決算の issue に書き込んでおいた。来年はもっとうまくやる。

• e-tax e-Taxの利用可能時間
• eltax 令和5年度の休日運用日

今日のところは法人3税の税金を算出し終えて、それらと関係ない別表の大半を作成した。基本的には決算の試算表から数値を転記したり、特例措置の申請のための書類を作ったりでなにも難しくない。

iijmio と iphone で作るモバイル wifi ルーター

今年に入ってから 実家のオフィス化 の準備を着々と進めている。晩年は足が不自由だった祖父が生活できるよう、倉庫の一部を改築して車椅子でも生活できるような部屋になっていて、ある種の離れのようなスペースになっている。祖父が他界してからは誰も使っていない。トイレもお風呂もキッチンもついていて広さで言えば14畳ぐらいある。これまで使いにくかった理由は2つあってエアコンとインターネットがなかった。この前、母にお願いしてエアコンを購入してもらい、つい先日、設置が完了したらしい。

インターネットの回線をひくことも検討していたが、どうやら5000円/月ぐらいかかることがわかってきた。母はインターネットを必要としていないので月1回ぐらいしか使わないのに5000円も支払うのはもったいないなと一旦ストップしていた。スマートフォンのテザリングでお仕事できないわけではないから当初はそれでもいいかと考えていた。私の個人のスマホとインターネット回線は iijmio を使っていて iij さん好きなので同じように pocket wifi 的なものはないのかな？と調べたら正にそういう記事をみつけた。

• 格安！IIJmioでポケットWiFiを作る！料金・手順・注意点まとめ

よくよく考えたらデータ専用の sim を購入したらあとはモバイル wifi ルーターだけあればよいことに気付いて、それって iphone でできるやんということに気付いて、過去に使っていた古い iphone 11 を再利用できることに気付いた。さらにいまは esim という物理 sim を必要としないソフトウェアベースの sim もあるようで月額の料金も esim の方が安い。 音声通話なしのデータ専用プランで税込で次の金額になる。さらに使わなかったらデータ量は翌月以降に繰越できる。プランによって繰越できる期間が異なる。例えば2GiBなら翌月末まで繰越できる。繰越という概念はたまにしか使わない私の用途にぴったりでひとまず2GiBプランを選択してお試し運用してみることにした。

• 1GiB: 165円/月
• 2GiB: 440円/月
• 5GiB: 660円/月
• 10GiB: 1,100円/月
• 20GiB: 1,650円/月

esim というソフトウェアベースのものだと、申し込みして5分後に設定できましたというメールが届き、すぐにアクティベートして iphone 11 に esim の設定をしたら10分後にはインターネットに接続できるようになった。その後 apn の設定を行ってテザリングもできるようになって、30分後には iphone 11 をモバイル wifi ルーターとして macbook からインターネットにアクセスできるかの疎通確認を終えた。

つまりソフトウェアベースで業務を行うことのワークフローの効率が半端なく高い。これが物理 sim なら数人の人手と待ち時間がかかることは容易に想像できる。物理的にしかできなかったことをソフトウェアベースにしてワークフローを洗練化させることの強力さを実感した。常々、私が課題管理の文脈でコミュニケーションコストを減らせれば生産性が上がると開発者に啓蒙していることと同じで自分がやろうとしていることの概念を追体験するような経験となった。ワークフローの効率を極端に落とすのは人間である。

22時頃から寝て何度か起きて7時に起きた。久しぶりに夢をみた気がする。オフィスに着いた頃にはもう覚えていないけど。

リリース前日

プロダクトの開発、テスト、パッケージングとすべて完了していてドキュメントや社外に提供するためのインフラの仕組みの作業を行っている。これはリリースまでに出来ていなくてもプロダクトが動かないわけではないのでリリース後もしばらくは継続する。今日は運用ツールのちょっとしたリファクタリングをしたり、コードレビューをしたり、windows インストーラーの調査をしたりと、なんやらかんやらで忙しかった。

示唆を与えなければならない

ここ1ヶ月ほど私がクリティカルパスの作業を担ってきたのでメンバーの作業を落ち着いてみる余裕がなかった。たまたまというか、私がクリティカルパスから脱したことでメンバーのレビューやアドバイスを行うときの余裕も戻ってきた。CSK の新人研修で習うことに社是と経営理念とサービス精神という言葉がある。

サービス精神

• お得意様にあくまでも満足していただく技術を提供しなければならない
• 技術は高度で専門的でなければならない
• 仕事は正確に、かつ迅速・効率的に行なわなければならない
• 常に、お得意様の利益を考え、示唆を与えなければならない

新人研修ではこれらを暗唱して暗記させられる。20年以上経ったいまでも覚えている。もともと私の考え方にあっていたのか、それとも新人の頃に刷り込まれたのか、その両方なのか。いま見返すと私の課題管理の考え方とこのサービス精神には共通しているところもある。その上で最後の 「示唆を与えなければならない」 という言葉を、今日メンバーとやり取りしているときにふと思い出した。

アドバイスをしていると、なぜこの懸念を考えずに作業を継続してしまったのだろうか？と思う機会がちょくちょくある。そのときに質問してその背景を尋ねたり、効率や保守のための考え方を教えたりする。ふと私が指摘しなかったらそういった効率や品質の低い結果のまま進んだのだろうと推測される。当たり前の話しだが、意識的にしろ無意識にしろ、個人では気付けなかったフィードバックや示唆を与えてくれる人がいなかったら個人の能力では限界がある。気付きがないところに学びも改善もないから成長もしない。いまお手伝いしている会社はこれまで個人でやってきた働き方を、チームで協調して働くように変えていきたいという話しから始まった。私自身、どちらかと言えば個人主義の働き方をしてきた方でチームでの働き方をちゃんと教えられるか、当初はあまり自信がなかった。半年やってきて、チームで働く上で必要なことはメンバーのアウトプットに対して質問するだけでよかったんやと理解できるようになってきた。個人の視点しかない働き方と他者の視点から常にツッコミが入る働き方はまったく異なる。うちのメンバーをみていて、まだまだ道半ばではあるが、それまでの状況と私が啓蒙している課題管理は、おそらく根本的に働き方を変えてしまっていることにようやく私の理解が追いついてきた。

0時に寝て6時に起きた。午前中は掃除したり買いものへ出掛けたりムック本を買って読んだりして午後からもくもく会に参加してきた。昨日から休日って心地よくて素晴らしい時間だということに改めて気付いた。

いまがわかる地政学

やぎさんからおすすめされて オールカラー図解 いまがわかる地政学 を読んだ。ちょうど余裕もあったので読んでみることにした。私も過去に地政学の雑誌を気分で買って読んだことがあった。教えてもらってなければいまは買ってなかったと思うが、関心のある分野ではある。

見開きの2ページで左ページを地図で図解しながら右ページにその説明が書いてある。読み始めてすぐにドキュメントランドスケープを構築できるので読みやすい。地政学なので地図で説明するのがわかりやすいのと、特定の地域の限られた国で、且つ話題を限定して説明するから簡潔でわかりやすい。過去にはアメリカ／イギリス系統とドイツ系統の2つの地政学があり、地政学はナチスドイツの御用学問となり、ドイツが敗戦したことによりドイツ系統の地政学は封印指定された。日本で学ばれていた地政学もドイツ系統だったようで、戦後 GHQ により封印指定されていまに至るらしい。

地政学の解説を読んでいて、なにかを分類して、そこから得られる知見に方向性や解釈を与えて、さらに歴史が積み重なると立派な研究や学問になるという印象を受けた。観察して分類して仮説を立てて記録を取り続けるとそれはもう科学である。課題管理につながるヒントもありそうな気がしている。課題管理は事象が発生した記録を取り続けて、ある程度溜まったところで分類したり分析したりできる。

もくもく会

【三宮.dev オフライン】もくもく会 に参加した。昨日の続きでプロダクトのドキュメントを2時間ほど書いてた。集中してドキュメントと mermaid のフローチャートを書いた。初めて参加された方も何人かいたのでいろんな人の話しを聞くこともできてよい機会だった。参加者の1人から 芋屋HUG のスィートポテトをもらった。お店の存在は知っていたが、1度も買ったことがなくて初めて食べておいしかった。調べてたら神戸発祥のお店っぽいので東京出張するときのお土産に買って行ってもよさそう。よいお土産を知ることができてよかった。

0時に寝て7時半に起きた。そろそろ出張バテしてきた。

プロジェクトの進捗報告

出張したときの月例報告の5回目。前回の進捗報告はこちら 。私のマネジメントの不手際で1ヶ月延期 (元の計画通り) して、未だに開発は完了していないものの、今月末にリリースできる見通しでプロジェクトを進めている。おそらくあと1-2回は私が休出するのだろう。これからメンバーにはできる限りの QA テストを3週間に渡って行ってもらう。

チームが fix した3月の issue 数は47、そのうちの34を、enhance ラベルが付いたものは12でそのうちの9を私が担当した。クリティカルパスになりそうなものは、一旦はメンバーにアサインするものの、進捗をみて遅れていれば私が issue を引き取って対応している。先月から引き続き、やばそうな芽が出てきたら私が本気出して対応する。見た目上のスケジュールには影響を与えないようにしている。先月の反省で早めに引き取ることにしたのでずるずる後ろへ延びることはない。このやり方をすると、私がボトルネックになりかねないが、私の工数は調整次第でメンバーよりも大きくできるのでいまのところ問題ない。リリースまで1ヶ月を切った中で取り得る手段は限られてくる。

2月から ハドルと雑談 の試験運用をしていた。ほぼ毎日午前中は私が slack のハドルに在籍 (オフィスアワーに近い取り組み) するようにして、メンバーから雑談する機会は増えるかどうかを試していた。約2ヶ月やって結果は次の通りとなった。

• 対象日数: 34日
• 雑談人数: 10人
• 雑談時間: 5.75時間

3日に1日ぐらい軽く雑談するといった結果になった。おそらく私がハドルにいなかったら話す機会はなかったのでこの価値をどう見積もるかは人によって分かれると思う。うちのチームはリモートワークが中心なので雑談する機会があるほど望ましい。それほど強く提案するわけではないが、slack のハドル活用をもっと展開してもよいのではないかと経営者に推奨した。

聞いた話では着任前にこのプロダクト開発は2年近く迷走していたらしい。それによって要件は整理されていたと言える。私がこの半年でリリース (予定) できる状態にしたのを評価してもらえているようにはみえる。余談だが、自分のスキルを社会の役に立てられるのがいまは嬉しい。前職では、誰でもできる簡単なお仕事しかできず、開発もあまりつまらなかった。いまは自分がよいと思うものを一定の裁量で判断し、さらにマネージャー経験も積めて、今回のお仕事は私の中でも達成感は高い方でもある。

あとは今後の開発の話し、販売戦略の話しなどもしていた。4月末で初期開発の区切りもつく。今後は毎月1週間も出張しなくてよいのではないかという話しもして、5月は会議を2-3日に集中してやったらいいんじゃないかということになった。出張はそろそろ疲れてきたのと、私がオフィスにいてもメンバーは半分以上リモートワークなのでオフィスに来る意義があまりない。うちのチームはリモートワークで開発に支障が出ない仕組みを構築できているとは思う。

18時から20時半ぐらいまで寝て、それから晩ご飯を食べに出掛けて、23時頃に戻ってきてまた寝て、4時に起きて、6時に起きた。出張の初日は不規則な寝方になる。

定例会議とふりかえり

リリースまであと3週間。一部の開発がまだ完了していないことに大きなストレスと懸念を感じつつ、進捗はしているそうなのでその対応が完了するのを待つ。いまは日々の進捗や発生する事象に注意を配りつつ、メンバーは QA レベルのテストを、私は淡々とリリースの準備をしている。外部からアクセスできるプライベートなコンテナレジストリを docker hub でお金を払うか、自社で運用するかの決めの問題や外部向けにドキュメントを公開するための決めごとなどを確認したりしていた。

毎月のマイルストーン終了後にふりかえりをしている。今月は対応した issue のうち、70%超を私が fix しているのであまり話題がないかなぁとか思っていたけど、全然そんなことはなく、活発にふりかえりのコメント (付箋に書く) が出てよかった。当初は付箋に書いた内容に対して関心のあるものをメンバーに投票してもらっていた。そして、メンバーの関心の高いマークがたくさん付いたものから掘り下げて聞くようにしていた。最近は3人でふりかえりをやっているため、すべての付箋をみていっても10個未満程度、すべてヒアリングしても時間がちょうどよいので投票をやめた。そうすると、メンバーが自分のやったことや思ったことを他者へ話す機会になっていて、これは内省を促す意図でとてもよいことじゃないかと思うようになってきた。

ふりかえりをしない人やチームは成長しない

これは私の持論だ。うまくいかなかったときにふりかえりすると、当事者が嫌な気持ちになったりしんどかったり、責任を感じたりとネガティブなイメージから、私の経験則ではふりかえりを行わないチームの方がずっと多かった。こういう小さい積み重ねを継続的にやるのは後になってその人の価値観や成長に影響を与えるのではないかと最近は思う。うちのチームでは厳しく責任追及はしないのでメンバーが率直的にこれができなかったとふりかえることはできるようになっているとは思う。

ふとふりかえりをしていてこんな言葉が私の口から出た。

作業の進捗をストリームとして確認できると嬉しい、ストリームを眺めているとメンバーが考えているのかどうかが分かる

エンジニアリング組織論への招待 に次のような節がある。

「悩む」と「考える」の違い

「考える」は行動であり、「悩む」は状態なのです。考えているのであれば、それはメンターがその行動を見ることができます。しかし、「悩む」であれば、メンターは心の状態を観察することはできません。

悩んでいる状態は手が止まっていて、頭の中で思考がぐるぐる巡っていて、もやもやしている状態。考えているとは、課題を書き出したり、分解したり、調査したりと忙しく行動していると言える。当然、考えないと優れた品質のアウトプットは出せない。正に私がやっている課題管理も、そのための課題管理システムも考えていることを確認・監視するために有効な手法とシステムであることが伺える。チームのふりかえりをしながら、そういった話しをメンバーに共有したりしていた。

1時に寝て7時に起きた。いつも通り夕方にホテルに戻って2時間ほど寝て起きたらテレビで WBS をやっていてそのままみてた。そしたら晩ご飯食べるタイミングも作業するタイミングも逃して日記を書いたり雑多なことをしていた。

プロジェクトの進捗報告

出張したときの月例報告の4回目。前回の進捗報告はこちら 。1月にリリース前倒しを提案して颯爽と1ヶ月前倒しをしたのにその翌月に現時点ではまだリリース可能かどうかを判断できないといったことを報告した。まったく情けない。サーバーサイドとフロントエンドの開発はすでに完了しているのに。しかし、もともとこのプロジェクトの開発対象に入っていなかったもので、ほぼ完成していると聞いていたモジュール群の半分が機能不足や低品質で作り直すことになった。残りの半分もそのままでは動かない。

経験の浅いメンバーに1ヶ月以上の時間を与えて作り直してもらうようにお願いしていたが、うまく進捗せず時間だけが過ぎていって、結果的に2月の半ばから私が引き取って大半の機能を開発している。結果的にそのメンバーにお願いしていた開発の8割を私が2週間でほとんど実装した。2月の中旬から私がずっと休祝日に開発のお仕事をしていたのはこの開発遅れを補填するためだった。チームが fix した2月の issue 数が57でそのうちの30を、enhance ラベルが付いたものは28でそのうちの13を私が担当した。今月の半分の開発を私が代替わりして帳尻を無理やりあわせた。もはや遊撃のレベルではなく、私が本気出して全部作っておきましたみたいなことをした。

本当はメンバーに開発経験をつけてもらうために私がいるので私が主担当で開発するのはよくない。とはいえ、このままいくと2ヶ月ほど開発遅延する、しかもこのプロジェクトの中核でもない機能のために、それも悔しいし、うちの会社の信頼にも関わるのでズルしてしまいましたと経営陣へ正直に報告した。自分がやるよりも他人に教える方がずっと難しい。先方からは咎めるものではなかったし、私が開発して帳尻をあわせるのを止めるものでもないという承認は得た。

難しい開発課題を経験の浅いメンバーに担当させてしまった私のマネジメントの誤りであることは、チームのふりかえりでも、経営者への報告でも伝えている。なにが起ころうとプロジェクトの責任はマネージャーの私にあることは理解している。その遅れはマネージャーが責任をもって対応するのだとメンバーが学ぶ機会にもなったんじゃないかという意見も出た。私も過去にそういう上長をみて思うところはあったのでそれはそうかもしれない。なぜ1ヶ月以上も時間を与えているのに芋づる式にスケジュールが遅延するのか。その要因もメンバーの行動や進捗をみていて理解できた。第一に経験が浅いために開発の見通しや見積もりを立てられない。例えば課題が3つあるとして、1つしかみえていないから「できそうです」と言っていても、1つ終えた後にまた1つありましたと報告があり、その1つを終えてもまだもう1つありましたと報告が来る。一定の経験があれば作業を開始する前に3つあることを整理して、その上で納期にあわせて3つを対処する。納期いっぱい使って1つだけやろうとするところの意識の差は大きい。第二に期日までに実装できる一定のスキルをもっていないとコードレビューが1週間とか続いてしまう。そういった開発者にクリティカルパスとなる issue を担当させてはいけないように思えた。

ある issue がクリティカルパスになってしまった時点で、私かスキルのあるメンバーのどちらかへ引き継ぐように2月中旬に調整していればいまの状況は変わったのではないだろうか。その判断が2週間遅れたことに今回は気付けた。結果論ではあるが、厳しい判断をもう少し早めに下さないといけなかった。

23時に寝て何度か起きて8時に起きた。疲れていたせいか、いつもよりよく眠れた。18時過ぎぐらいまで調べ物をしていて、それから実家へ車で帰った。初めて夜の高速道路を走ってみたらわりと道がわからなくて怖かった。昼間よりは速度を出せないので夜に帰るならゆっくり帰るのが安全にはよさそう。20時頃には実家について晩ご飯を食べ始めてた。

ストレッチ

今日の開脚幅は開始前156cmで、ストレッチ後160cmだった。出張帰りだったのもあって腰に張りはあってやや疲労が溜まっている感はあったものの、前月に比べたら全然ましだった。やはり前月が葬儀の後に事務手続きと出張が重なって特別に疲労していたことがわかった。トレーナーさんといつも通りの話をしていた。最近はサッカーの三笘選手が大活躍しているので毎週その話題が定番になっている。

こってり天津飯

天津飯は日本発祥！カニ玉との違いとは によると、天津飯は日本の中華料理屋さんが考えた料理らしい。麻婆春雨と同じ類の料理。

少し前に天下一品の新メニューでこってり天津飯ができた。天津飯は日本の中華料理屋さんならどこでも食べられる料理だが、こってり天津飯は「こってりスープ」がある天下一品でしか食べられない。天津飯というコモディティを、こってりスープという天下一品独自のプロダクトで再発見または再発明したような商品とみなせる。

課題管理という分野もそれ自体はどこにでもある概念やスキル体系でしかないが、うちの会社独自のプロダクトを作ったり、プラクティスを構築できれば、再発明できるんじゃないかとたまたま食べていて思った。いつか課題管理ビジネスが軌道にのってインタビューされるようなことがあったらこってり天津飯を食べていて気付きましたみたいな、カッコいい談話にしたい。

1時に寝て7時過ぎに起きた。やや飲み過ぎて、2日酔いではないけど起きたときは気分が悪かった。

go-winio を触ってみた

windows 向けのモジュールを作り直すにあたり、有識者のサポートをお願いしているものの、私も最低限の知識はないとあかんやろと調査を開始した。microsoft/go-winio というライブラリが ms 社のリポジトリで公開されている。公式ならよいのだろうと安易に考えて触ってみたものの、ドキュメントがほとんどなくて、まず使い方がわからん。いまのところ、windows に詳しい人向けのライブラリみたい。ひとまずリポジトリにある pipe_test.go のテストコードを読みながら名前付きパイプを介したプロセス間通信をやってみた。一応は動いたのでここから内部の windows api の仕様や設定などをみていく。その過程で go-winio のチュートリアルがないのであれば、私がテックブログを書いてもよいのかもしれない。

チュートリアル的に書いてみたコードは次の通り。

• https://gitlab.com/t2y/misc/-/tree/main/winio-send
• https://gitlab.com/t2y/misc/-/tree/main/winio-receive

課題管理勉強会

出張のときに毎月の課題管理勉強会。とくにネタが思いつかなかったので エンジニアリング組織論への招待 を題材にしてみた。資料はすでに作ってあった 。私にとっては課題管理をやる意義や価値の大半がこの書籍の中で解説されている。用語や考え方のところでとても参考になるし、いまメンタリングの技術の章を読み直したりもしている。昔はマネージャーやってなかったからその章は読み飛ばしてた。開発組織向けの組織論を解説した書籍でこれ以上のものは、いまのところ、私が読んだ本の中では知らない。4年前に読んだ本を、今回の勉強会を開く機会でまた読み直すきっかけにもなってよかった。本はコンテキストがきれいに構成されているので他の人の所感や意見を聞いたり雑談したりする題材としてもよさそうに思える。