1時に寝て何度か起きて7時に起きた。23時に帰ってきて一昨日にお土産にもらったロールケーキだけ食べてしまった。あかんねんけど、おいしかった。

ドッグフードテストと運用談義

リリースしたばかりのプロダクトを社内に導入するべくインフラ作業をしている。社内の管理者が運用を考慮していくつか質問がくる中で、開発側としても運用の考慮の足りないところがあったりして、実運用における不測の自体に対する運用を想定しておく必要がある。こういうやり取り自体が、開発者だけでは得られない知見なので貴重と言える。追加の検証をして、場合によってはなんらかの機能を作ったりする可能性もある。

ドッグフードテストは本当によく出来た仕組みだと思っていて、仮になにか大きな障害が発生してもそれはお客さんのところで発生する前に自社でみつけられればよかったと考えられる。もちろん障害がなければそれはそれで構わない。障害が発生してもしなくてもどちらも開発にとって大きな資産となる。いわゆる win-win のような関係と言える。開発視点から言えばドッグフードテストを行うと決めた時点でうちらはすでに勝っていると言えよう。

プロダクト説明会

毎週やっているチーム勉強会の時間を使って社内向けにプロダクトの説明会を行った。リリースを終えて、その後のドキュメント作りやパッケージングの最適化なども行えた。インフラは十分に機能しているし、ドキュメントも一通り揃っていて、機能はまだまだ足りないけれど、プロダクトとしての体裁はうまくまとまっていると自画自賛している。リソースをかけた分だけスケールするといった開発体制に変化しつつある。おそらく私がマネージャーとして必要なのもあと3-6ヶ月といったところではないか？重要なことは 開発方法論/開発ガイド に書いてあるし、課題管理 + イテレーション開発は特別なことをしなくてもうまくいくことも立証された。メンバーが私と同じように振る舞えば誰でもマネジメントはできるはずである。

来週からは次開発のマイルストーンに入っていく。メンバーが成長して私のマネジメント工数が減るようになってくれば、私も開発に入って下支えすればいいと考えている。まずは3ヶ月でどのぐらいの追加の機能開発が出来ていくのかを見定めたい。

開発合宿の日程確定

そろそろ宿を予約しないといけない。冬の開発合宿 の予定を2024年3月1-3日に決めた。現時点で参加者は4名確定していて、前向きに検討してくれている人が3名いる。昨年が4名だったので倍増して今年は8名程で行ければいいなと希望をもっている。不特定多数に声をかけられるほどキャパシティはないけど、もう3人ぐらい声をかけてもよさそう。

遅く帰ってきたわけではないが、うまく眠れなくて3時に寝て7時に起きた。

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

今週が開発の谷間の最後の週。毎週いろいろ資料を作ったり、あちこちのドキュメントを更新したりしていた。最後に残ったものの1つ (を2つに分割した) として、うちのプロダクト開発における開発方法論と開発ガイドを仕上げた。開発方法論は開発のマネジメント手法やプロセスの概念などを抽象的な表現で説明したもの。簡単に言えば、アジャイル開発とかスクラムとか、そういった概念の説明やなぜそれが大事なのかの意図や背景を説明したドキュメントになる。当初はこの1つしかなかったのだけど、実際に課題管理システムを使ってイテレーション開発をする具体的な話しと抽象的な話しを一緒に書くのはまとまりが悪いように思えてきた。抽象的な内容と実務に近い内容は分けて書くことにした。

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

例えば、開発ガイドにはマージリクエストの運用について書いてある。どこの会社へ行っても私は次のような「マージリクエストを作成しなくてよいもの」という文章を書いている。

すべての修正にマージリクエストを要求すると開発がとても遅くなる。それは人間が介在するトコロがもっともコストを要求するからである。とくにコミュニケーションコストは開発の中でも最も大きいコストの1つである。レビューしなくてもコミット履歴は誰でも把握できる。修正内容が気になる開発者は自分でコミット履歴を確認すればよい。

従ってレビューの必要がないと想定される修正は直接 main ブランチに push してよい。例えば、軽微な修正は CI/CD の自動化により品質を担保できるように努める。テストを失敗させる修正を push してしまったとしてもデプロイできないために障害を発生させることはない。

この運用は軽微な修正だと思って push したものが不具合を発生させてしまうリスクを許容している。そのときは気付きの学びとして「ごめんなさい」で終わらせる。稀に不具合を発生させることよりも、開発の速度を上げる方を優先する。

カフーツさんイベント

カフーツ13周年Jelly〜カクサク（やりたいこと宣言）第1弾〜 に参加した。私がカフーツさんへ遊びに行ったときに人がたくさんいたことはない。記念イベントだったので参加者多いかな？と思って行ってみた。10人ぐらいいた。参加者の大半は私と同じぐらいか、それ以上の年配の方にみえた。やや年齢層が高め。13年やっているコミュニティなので同じぐらい歳をとったんだと思う。みんなでわいわい話しながら0時前まで飲んでた。ここ行くと基本飲み会w

YOHAKHU というクラフトジンがあってロックと炭酸割りで4-5杯ほど飲んでいた。これまでジンをあまり飲んだことがないので、普通のジンとの比較はできないが、強烈なインパクトのある風味で圧倒されてしまった。おいしいかどうかというよりもこれは強烈やなぁという所感が先にくる。さらに「余白」という名前がよい。いとうさんに影響を受けて私が「ゆとり」と呼んでいた概念にいくつか補強がされて、最近は私も余白という言葉を気に入って使っている。人生に必要な余白を忘れない飲みものがこれだと言えるかもしれない。なんだか酔っ払ったようなコメントになってしまった。

0時に寝て何度か起きて7時に起きた。雨降りだったので午前中はドラクエタクトしてた。午後から雨が小さくなったのをみて、オフィスで出張前の資料作りをしてた。夕方には雨がやんでお土産を購入するために出掛けたらすみよさんさんに偶然会った。

ソフトウェアライセンス事業を加速させる OSS 戦略

ビジネス法務 2023年6月号 という雑誌に寄稿したとなかいさんのタイムラインをみかけたので読んでみた。電子版は年間契約でないと購入できないようで仕方なく紙の雑誌を購入した。ライセンス契約の特集の中の1記事らしい。3ページの記事だったので OSS というソフトウェアのビジネス形態の紹介といった記事のようにみえる。OSS や web 業界の開発者からみたら目新しい内容ではないが、こういった雑誌に紹介されること自体がすごいことだと思いながら読んでみた。自社ソフトウェアを OSS とする戦略の特徴として次の3つをあげていた。

• ユーザーの開発者が動作を確認したり、カスタマイズできる
• 製品の透明性を証明できる (ソースコードを読めるから)
• 技術力のアピールできる

うちも近いうちに OSS でプロダクト開発を始めるので参考にしながらやろうと思う。うちは OSS で儲けようと考えていないが、うちで作るものは原則として OSS で公開していく方針で考えている。

近況報告の資料作り

4月末にリリース できているのでそれほど重要ではないけど、毎月出張したタイミングで報告会をしているので急にやめるのもどうかな？という気がして資料を作って打ち合わせする。リリースして GW を挟んで次の開発への準備期間という隙間時間がいまになる。ある種のゆとりになっていて、これはパッケージベンダーだからこそなのか、中小企業ゆえの労務管理や目標管理の緩さからなのか、いずれにしてもこういう隙間時間を使って自分で考えて、自分で調査して、自分でふりかえるといった自律性を養うのによいかもしれない。私もゆっくり考える時間を取れてよかった。

1時に寝て何度か起きて7時に起きた。昨日は23時半に帰ってきてから十割蕎麦を茹でて食べたけど、吐き気はなかった。蕎麦ぐらいなら大丈夫か。

開発方法論の見直し

開発が一区切りしたタイミングで開発方法論やガイドのドキュメントも見返して、過去に作ったときからみて現状の内容や気付き事項などを加筆修正していた。これを繰り返すうちに開発文化が言語化できていく雰囲気はする。その後は issue の洗い出しや1on1 やってインストール手順の検証やドキュメントの更新などをしていた。これと言って成果を出した一日ではなかったものの、wiki をあちこち更新して整理していたらいつの間にか時間が過ぎていたという所感。

歯科検診

17時から歯科検診へ行ってきた。いつも通り歯のお掃除をして1年ぶりに歯のレントゲンを撮ることになった。新たにレントゲンを撮る機械が導入されていて、台に顔を置くとカメラが顔周りを移動してレントゲンが撮られた。これまでは位置固定のための器具を噛んでパシャパシャ撮るやり方だったので面倒だったのが便利になっていた。帰りにカードリーダーが置いてあることに気付いて、受付の担当者さんに尋ねたら、マイナンバーカードに保険証を設定すれば使えることを教えてもらった。次回はマイナンバーカードで保険証提示をやってみたい。

0時に寝て6時半に起きた。朝起きてからドラクエタクトしてた。

リリース

今日がプロダクトのリリースとなる。先週前半にはテストを完了して開発作業も終えてインフラの整備やドキュメントの作成に注力してきたのでここ数日の様子をみれば無難に順調にリリースできたようにみえる。結果からみれば「余裕でしたね」とコメントされても大きく外れてはいない。6ヶ月でやってと言われた開発を、3ヶ月目に5ヶ月でできると勝手に短縮して、4ヶ月目にやっぱ間に合わないからもう1ヶ月待ってと6ヶ月に戻した。一人時間差攻撃みたいなマネジメントをして完了した。ここ2ヶ月ほど私がいくつか開発やデバッグを肩代わりをして開発の下支えをした。別に私がやったらいけないという制約はないけれど、メンバーの教育も含まれているプロジェクトなのでなるべくメンバーが経験を積んでスキルを磨くのが望ましい。この件はちょっとズルしましたと進捗報告している。まずはうまくいって安心した。

ともあれ、私がプロジェクトマネジャーという肩書きをもって臨んだプロジェクトで概ねスケジュール通りに開発を進捗させてお客さんの要件にあったプロダクトを作り上げたことそのものが、私のキャリアにおいても重要なことであるし、うちの会社では課題管理という分野をビジネスの中核にしていく上での最初の実績として大きな意義のあるプロジェクトだった。課題管理はチーム開発において強力な武器になる。これまでの自分と、そう大きく変わらない働き方をマネージャーでやっても結果を出せたことは自信にもつながる。

この後は6ヶ月間の大きなふりかえりも控えていて、課題管理に溜まったデータを分析して、次開発への改善などにもつなげていこうと思う。過去の経験則では課題管理の価値を実感してもらうのに半年はかかるというのが私の持論。それは比較的、最初から課題管理システムを使えていたうちのチームでも同じだと思う。私がやっている課題管理とメンバーのそれとの違い、その違いによる実際の業務における成果などを分析していくと示唆を与えられるのではないかと思う。

0時に寝て6時に起きた。昨日は晩ご飯の買いものに行こうと早めに帰ろうとしたら雨降りでそのまま帰って家でだらだらしてた。

リリース前テスト

来週の火曜日がリリース日になる。4月から3週間ほどかけて行ってきたテストケースを完了した。致命的な不具合もなく、テストの過程でみつかった不具合も修正済みで予定していたテストが完了となった。ここ2週間ほど、テストして issue が登録されると、私が細心の注意を払って内容を精査して、即日で fix して検証したりしていた。それもあってテストでみつけた不具合はほとんど fix した。あとはリリースのためのパッケージングやドキュメント作成、インフラ作業などへ移っていく。アプリケーションの振る舞いに影響を与えるものではないので私の中では肩の荷がおりてプレッシャーも軽減されて少し安心できた。よかった。よかった。

docker hub のプライベートリポジトリ

先日 docker hub の rate limit に引っかかったこともあり、docker hub の有償アカウントを使うことになった。team プランは5人以上必要らしいので pro アカウントで契約してもらった。有償アカウントなら無制限のプライベートリポジトリを提供できる。docker hub でリポジトリを作成していて、いまさらながらにリポジトリ名にスラッシュを含められないことに気付いた。基本的にはハイフン区切りでスラッシュの代替する名前になっていた。これまで自分で docker image を扱ってこなかったので今更ながらに気付いた。

社内のコンテナレジストリから docker hub のプライベートリポジトリへの promotion のスクリプトを書いていた。bash の連想配列を使ってコンテナレジストリのマッピングを定義してあとは pull/push するコードを書くだけ。

declare -A repos
repos["internal-my-repo1"]="external/my-repo1"
repos["internal-my-repo2"]="external/my-repo2"
for internal in "${!repos[@]}"; do
  external="${repos[$key]}"
  echo "pull from: $internal"
  echo "push to  : $external"
done

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。promotion のスクリプトを書いていたら20分ほど遅れてから参加。今日の話題は chatgpt だった。少し前に 雑談会 したので歴史や原理的な仕組みなど、調べたことを参加者と共有しながら今後の社会の変化などを議論していた。私も関心のある内容なのでおもしろかった。いまや私は日々の開発業務にも chatgpt を使って調べものをしたりサンプルコードを書いてもらうのが普通になりつつある。そのうち ide と連携してテストコードの叩き台なども書かせるようにしてみたい。

いとうさんは chatgpt をみて、人間は働く意欲がなくなるのではないかといった懸念を表明されていた。いまのところ、ドメイン知識をもっている人がより効率よく働けるようになるツールでしかないという私の認識だが、あと3年ぐらいしたら人間を遥かに超えていって、chatgpt の出力をそのまま業務に応用する日も来るかもしれない。llm というのは次にくるもっともらしい単語を膨大な学習データから統計的に選択しているだけで、実際には内容を理解していないし、人間のように創造的な行為もできない。大雑把に言えば、インターネットの空気を読んで発言すれば人間っぽいというのはすごいことだし、便利で役に立つし、働き方も変わっていくだろうけれど、その延長上で変わる世の中が、私の人生における行動に影響を与えるほどではないと考えている。そういった話をする過程であんちぽさんの言う「価値観を育てる」という文脈が頭の中に残っていて、llm ぐらいでは揺らぎそうにはない気がしている。

40代で大した強みもなくて不安みたいなのは共感はするけど、一方で、何歳であっても、他人との比較で生きている限り、一生不安は消えない。どんな年代であっても、自分の正しいと信じることをすればいい。もしそれがないのなら、問題の本質は年齢ではなく、価値観を育てやれてないことの方である。

— あんちぽ 🎨💙 (@kentaro) April 17, 2023

ただ it 業界以外にもこんなに話題が拡散しているプロダクトはそうそうないので世の中をどんどん変革していくのだろうというのは、異業種の人たちと話していても実感できた。

0時に寝て7時に起きた。午前中は洗濯して、昨日届いたお肉を焼いて朝ご飯にしながらドラクエタクトやってた。

yubikey bio の購入

デスクトップマシンが不調だった1-2ヶ月ほど m2 macbook air でお仕事をしていた。デスクトップマシンと比べて明らかに便利だったことがある。1password にログインするときに os のシステムアカウントも利用できて、具体的には指紋認証によりパスワード入力を必要としなかった。デフォルトでは2週間ごとにパスワード入力を必要とする設定になっているが、これも無効にすることもできる。パスワードを忘れないように1ヶ月に1回ぐらいは手入力してもよいかもしれない。生体認証はその精度にまだ懸念はあるそうだけど、こういった日常的な認証における用途ならそれほど高い精度を要求しないことに気付いた。私は個人でお仕事しているから日常でオフィスに保管している物理的なデバイスを盗むのは難しい。他にも linux で使える指紋認証のデバイスを探してみた。しかし、現時点では usb の指紋認証デバイスは windows 一択になっていて linux はサポートされていない。YubiKey ぐらいしか、私はみつけることができなかった。

YubiKey Bio - FIDO Edition をオンラインストアで購入した。船便で購入したので届くまで1ヶ月ほどかかる。急ぐものではないので気長に待つ。

YubiKey Bio - FIDO Edition
$90

Shipping & handling
Economy - 10-20 Working Days - No tracking available
$5

Duties, taxes and/or carrier subcharges
$14.68 USD

日本にお店がないので輸入扱いで関税がかかるのかな？また会計システムに登録するときに税金の計上方法を調べる必要がありそう。

自分たちでやろうとしないことを他人は助けられない

他社のプロジェクト開発のお手伝いでプロジェクトマネージャーとしてこの半年をマネジメントしてきて分かるようになったことが1つある。米軍がアフガニスタンから撤退するときの方便のようにみかけ、ロシアのウクライナ侵攻のときにウクライナ軍が善戦して西側諸国の支持を得たことでその正しさを再確認できた言葉がある。

バイデン大統領は演説で「当事国の軍隊が戦う意思がないのにアメリカが戦うわけにはいかない」という趣旨を繰り返した。

アフガニスタン崩壊と日本への教訓

2月からプロジェクトの開発遅れがみえていてスケジュール調整している。プロジェクトの開発がうまくいかないことの全責任は私にあることは間違いない。その点には一切の懸念も疑問もない。昨今の働き方改革で有休取得が大事なことも理解していて、平均して取得するなら毎月1-2日休むことになる。それは理解できるが、開発が遅延していても有休で休み、その遅延をマネージャである私が休出して開発を肩代わりするという調整を1ヶ月以上続けてきて、この歪みは開発やプロジェクトにとってよくないということもわかってきた。

私個人のモチベーション管理にも多少の影響はあるが、私は指示されて休出しているわけではなく、自分の目的のためにやっているのでこの影響はそれほど重要ではない。

なにが問題かというとプロダクトオーナーシップを開発者がもたないという点にある。私はお手伝いであるから、いずれいなくなる。周りからどうみえようと最終的にプロダクトオーナーシップは契約形態としてもてない。そして、お手伝い先の開発メンバーがもつようになるのが望ましい。しかし、そういう雰囲気はみえない。これまで他社の人間がマネージャーをやっているようなプロジェクトに私が参加したことがなかったためにそういった視点がなかった。そして、私は自分がイニシアティブをもって開発するプロダクトはすべてプロダクトオーナーシップをもって臨んできた。そのため、開発者に裁量を与えることで必然的にプロダクトオーナーシップをもつようになると信じてきたが、いまのやり方だとそうならない気がしている。なぜならば、放っておいても問題になる前に私が勝手に対応してしまうために開発者のインセンティブやモチベーションを阻害してしまうからだ。

プロジェクトにおけるスケジュールや品質を担保するためにはマネージャーである私が一定の尽力をするのは合理的ではある。一方でそれをやり過ぎることで開発メンバーのプロダクトオーナーシップを遠ざけてしまう。プロダクトオーナーシップをもっていない開発者が休出してまで開発に尽力する意味など普通にはない。仮に私が開発メンバーでもそう思うだろう。昔の上長 がやっていたことをみて私が学んだことを、外部の人間として開発メンバーに教えることはとても難しいことを理解できた。

0時に寝て4時に起きて6時半に起きた。最近は以前より眠れるようになりつつある。今日は定例会議とバグ調査とコードレビューと検証をしていたらすぐに1日終わってしまった。

ビルド問題の解決

2月の上旬 から問題を認識していて、ある c 言語のモジュールが正常にビルドできない問題がようやく解決されてビルドできるようになった。libtool を使ってライブラリをビルドしていて、歴史的経緯からシンボル名の書き換えが必要だったみたい。2週間後にリリースされるモジュールの開発前の状態でビルドが通ったのがいまという状況。ここから私がそのモジュールに対して追加の開発を行う。本来の私のお仕事ではないけど、このモジュール開発の私が負う方がチームとしての成果が大きいと判断した。

ビルドができるようになるまで2ヶ月程待ったことになる。普通に考えたらリリース延期だが、担当者の割り当ての課題もあって、もうこれは不可抗力としてそのままリリースしようと思う。おそらく誰もこの件に関して本来の開発の在り方についての言及しないと私は考えている。おそらく品質も信頼できないものだと推測する。残りの2週間で追加の開発を一目散に駆けて成るように成るのを私も受け入れることにしようと思う。

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個未満程度、すべてヒアリングしても時間がちょうどよいので投票をやめた。そうすると、メンバーが自分のやったことや思ったことを他者へ話す機会になっていて、これは内省を促す意図でとてもよいことじゃないかと思うようになってきた。

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

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

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

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

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

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

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

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

3時に寝て7時に起きた。昨日は遅くまで確定申告の準備をしてたから寝坊した。その分8時半に申告会場に立ち寄ってからオフィスに出社したので普段よりも朝はゆっくりできた。

windows インストーラー開発

windows のインストーラーを作る方法は2-3種類ほどあるそうだけど、もっとも標準的な visual studio に付属しているツールでインストーラーを作っている。特性の違う2つのアプリケーションを1つのインストーラーで扱っていると、アップデートやアンインストールでいろいろ不都合が生じるように思えたのでインストーラーを2つに分割したらよいのではないか？と先週末に助言をしていた。すると、1つのアプリケーションを2つのインストーラーを使ってセットアップするようなものを作ってしまって、複雑さはなにも解消していなくて、全然意図したものではないと訂正して作り直してもらうことになった。

私の指示が2つに分割すればよいという曖昧な助言だったのもよくないけれど、1つのアプリケーションを2つのインストーラーで操作するという発想が私の中になくて勘違いする余地があったんやと失敗体験となった。

一方でメンバーが「最初からそう言ってくれればよかったのに、、、」とか言い始めて、この姿勢はよくないなとも感じた。この問題の責任は指示が曖昧だった私にあるのは間違いないが、1つのアプリケーションを2つのインストーラーでインストールするという考え方に疑問を抱かないのは怠慢だし、実際にそのやり方で問題は解決していなかった。なんのために設計するかを当事者意識をもって開発していたら、言ってくれなかったから分からなかったという考え方にはならない。勘違いしていたとか、気付きが足りなかったとか、そういう言葉がほしかった。

定例会議で、意図しているのは、特性の違う2つのアプリケーションをそれぞれ独立させて制御すればシンプルになるよと説明して、もう一度作り直してもらって、結果として意図した通りシンプルにインストールを扱えるようになった。

リリース延期

昨日書いた通り、基準となる issue をすべて fix できないことが確認できたのでそれを説明して4月末まで延期とした。これにより、遅れていた機能開発には十分な期間を取れるし、QAテストのための準備にも余裕をもてる。インフラやドキュメントを整備する時間もあるだろう。

今月の私の稼働時間は (契約は160時間だけど) おそらく200時間を余裕で越えるだろうし、記帳していない稼働時間も含めれば230時間ほどはいくのではないかと思う。私の中では納期に間に合わせるためにがんばる意思はあったんだけど、クリティカルパスはすべて私が担当するといった調整をできなかったので仕方ないなといった落とし所で来月への延期を正当化した。