昨日は睡眠不足の中、同期飲みで酔っ払ってかなりひどい状態で寝ていた。朝起きて時計の見方を誤って10時過ぎだと勘違いしたぐらいには取り乱していた。今日のバドミントン練習は雨降りでおやすみ。縄跳びをもってきたのに雨降りでできなかった。

プロジェクトの進捗報告

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

今回の報告内容のメインはテスト改善の成果について共有した。カバレッジを取得できるようになったことでその成果を数値で共有した。マネジメントとしては数値で説明できると説得力があってよい。前フェーズからの要件や仕様変更により、テストが出来ていなかったところのカバレッジの改善が次のようになったと報告できた。わかりやすいし成果も確認しやすい。この数値を算出できるようになったことそのものも今回のテスト改善の成果でもある。

-/api/handler/ldap_management.go  46.8%
+/api/handler/ldap_management.go  77.1%

-/api/handler/ldap_profile.go  50.6%
+/api/handler/ldap_profile.go  79.8%

-/api/handler/ldap_util.go  61.4%
+/api/handler/ldap_util.go  80.4%

あとはバックエンドの開発を私がほとんどやるようになってしまって、その状況そのものがいずれ私がいなくなることや引き継ぎを考慮するとよくない状況になってしまったという懸念も共有した。すぐにいなくなるわけではないが、私がコアな開発をやっていてよいのかどうかの懸念を私自身が抱くようになってきた。これからメンバーへ徐々に引き継ぎしていくためにもテストコードが十分にあって、テストそのものが書きやすくなって、カバレッジでテスト漏れを確認できるようになっていて今後にもつながっていくだろうと報告できた。私自身がプロジェクトで窮屈に感じていた肩の重荷を少し下ろすことができて安心できるようになったと報告した。

今日のバドミントン練習はエアシャトルでリフティングを10分、連続最大回数は322回だった。その後にショートサーブ30回、フットワーク10分の練習をした。リフティングは連続回数よりもラケットコントロールの質を求める練習に変えていく。昨日と同様、みなとのもり公園をジョギングで4週走った。fitbit によると 1.8km 走ったそうな。

プロジェクトマネージャーが手を動かすことの功罪

朝からお手伝い先の社内インフラサーバーが落ちていて待ち時間があったのでふと思い返してつらつら考えごとをしていた。

お客さんが選ばなければ、逡巡と葛藤の結果、最終的に私は品質を優先する

開発合宿の課題管理の雑談から引用

私はもっと仕組みを作るところに注力すべきだった。私自身がコンサル嫌いの、実務をやっている姿勢をみせてメンバーが参考にしてほしいという意識が強過ぎた。また開発は楽しいことから必要以上に手を動かし過ぎてコアな開発に入り過ぎたことで、自分がやらないと他のメンバーが担当しにくい体制になってしまった。「任せる」はずが「任される」ことになってしまった。バックエンドの品質は大事だから責任感もあった。もしかしたらお客さんが求める以上の過剰品質なモノづくりをしてしまったのかもしれない。そして、仕組みづくりの後はメンバーへ委譲すべきだった。いまメンバーへマネージャーを委譲しているが、マネージャーという業務はもともと得意でもなくこだわりもなかったがためにすんなりと委譲できた。

しかし、開発の方は得意分野、且つ好きであるために品質にこだわってしまう傾向があることを認識できた。そのことが裏目に出てしまった。これが自社プロダクトの開発ならばすべて自社の資産になるためにそれでもよかったかもしれないが、他社プロダクトでやってしまうと、自分の時間を必要以上に注ぎ込むことになってしまった。その結果、お客さんの信頼を得られてはいるものの、自社プロダクトの開発に着手できず、クロージングの時期が遅れて微妙な状況になってしまった。もしかしたら、お客さんもうちの会社との契約を終了できなくなってしまって困っているという考え方もできる。

rabbitmq の autoAck (noAck) の振る舞い

先週の続き 。id 連携のリクエストをし続けながら compose サービスを down させたときの振る舞いを検証する。理想的にはそれぞれのモジュールのサービスが graceful に振る舞って、それぞれの永続化する場所でデータが溜まってくれることを期待している。その1つがメッセージキューでもある。Persistence Configuration によると、rabbitmq のメッセージを永続化するには queue に対して durable の設定を行い、producer が送信するメッセージに対しても persistent の属性を付与すればよい。しかし、実際に検証してみると、サービスの再起動時にメッセージキューからメッセージが消失していることがわかった。consume メソッドに渡す仮引数に autoAck というパラメーターがある。コメントにもそれっぽいことが書いてある。

When autoAck (also known as noAck) is true, the server will acknowledge deliveries to this consumer prior to writing the delivery to the network. When autoAck is true, the consumer should not call Delivery.Ack. Automatically acknowledging deliveries means that some deliveries may get lost if the consumer is unable to process them after the server delivers them. See http://www.rabbitmq.com/confirms.html for more details.

ConsumeWithContext

autoAck という名前からメッセージを取得したら自動的にそのメッセージに対して ack を返すようなイメージで私は考えていた。しかし、どうやら consumer が subscribe して接続した時点で consume 扱いとなり、consumer がメッセージを実際に取得したかどうかに関係なく consumer の終了時にそのときに溜まっているすべてのメッセージが消失しているようにみえる。余談だが、rabbitmq のドキュメントにも noAck と autoAck という2つの用語が存在する。どうやらもともと noAck という名前だったのを autoAck という用語に変更したようにみえる。メッセージを永続化するには autoAck=false にしてメッセージに対する処理を完了した後に consumer が必ず ack を返すという実装にしないといけないことがわかった。このパラメーターは2年前から同じ設定だったので私がいま検証するまで誰もこの振る舞いに気付かなかったんやと驚いた。

部屋の掃除

19時に閉まる業務スーパーへ買いものへ行くために18時過ぎにお仕事を終えて、移動して買いものをして、炊飯開始して、ジョギングして、戻って晩ごはんを食べて、バドミントン練習をして、お風呂に入って、ストレッチして、なんとなくベッドに入って休もうとした。ここで22時半ぐらい。まったく眠れなくて寝室の掃除を始めたら、これが捗ってやる気が出てきて、部屋のレイアウト変更したりして少し片付けもできた。引っ越してからまったく進めていなかった部屋づくりが突発的に急に少しできた。これまでも時間がなかったわけではないが、まったくやる気がなくて手をつけられていなかった。それがなぜできたのかはわからないが、手をつけられていなかったことに手を入れられたことで心理的に楽になった気がした。明日も帰ったら少しだけ部屋づくりの作業をしようと思う。

出張で道具がないのでバドミントン練習はおやすみ。

プロジェクトの進捗報告

出張したときの月例報告の21回目。前々回の進捗報告はこちら 。前回の9月は特別な話題がなかったのもあって書いてなかった。今回も淡々と進捗を報告してあまり話題はないものの、プログラミングを教えることの、抽象化能力と論理的思考、モジュール設計について話題にしてみた。経験のあるプログラマーやできる人は勝手にできてしまうものの、普通の人へどうやって指導していけばいいのか。どこでもよく聞く話しではあるし、プロダクト開発で課題管理をする上での延長上にある話題かもしれない。プロジェクトで解かないといけない問題の本質を認識できるかどうか、気付くかどうかという個人の素養に基づくところが大きい。経験を積んでスキルアップする過程で身につけていく特性を言語化したり明文化したりすることには意味がある。いまの私は答えをもっていないのだけど、とりとめのないの話題だけ共有した。

その後、ある案件の社内向けキックオフがあった。うちらが約2年開発してきたプロダクトがお客さん先で導入することが決まった。1月にテストして2月下旬から本番導入となる。最初のお客さんなので本番導入後のトラブルがあることも想定しておく。それが終わったらフルタイムもお仕事もようやく終えられるかもしれない。うちの会社のプロダクト開発に工数を取るようにしていきたい。

今日は1日中オフィスにこもって作業と出張準備をしていたのでバドミントン練習はお休み。夕方にお土産として モロゾフのプリンクッキー を購入するために本店へ行ってきた。これも神戸限定らしい。

パッケージ外のディレクトリにあるテストのカバレッジ計測

先日 深夜にバイナリのビルド・起動調査 をしたのに、最終的にはそんなことしなくてもよかった。デフォルトではパッケージ外のディレクトリにあるテストのカバレッジを計測しないことから普通にはできないと考えていた。しかし、調べたら次の SO で解決法をみつけた。結論としては -coverpkg ./... のように go test で実行している結合テストに対してオプションを指定するだけでよかった。

• How to detect code-coverage of separated folders in GO?

この調査を終えて最終的な makefile の coverage ターゲットは次のようになった。

coverage: lint
	rm -f coverage.*
	go test -tags=integration -race -cover ./... -coverpkg ./... -covermode atomic -coverprofile=coverage.out
	go tool cover -html coverage.out -o coverage.html

この make ターゲットを gitlab ci/cd から実行して coverage.out/coverage.html を自動生成する。coverage.out があるので必要に応じて好みのツールで統計情報を解析すればよい。たとえば nikolaydubina/go-cover-treemap でツリーマップを作るなら次のように実行する。

$ go-cover-treemap -coverprofile coverage.out > treemap.svg

近況報告の資料作り

普段は週末に報告資料を作っているのにもうやる気が無さ過ぎてお仕事を終えてから作っている。今回はネガティブな内容も報告に入れる。過去の経緯などを調査しながら3時間もあれば一通りのアウトラインはできた。明日がマイルストーンの最終日になるため、明日を終えてからでないと細かい数字は決定しない。マイルストーンの issue を調べたら qa テストでみつけた不具合の issue がそれなりに溜まっているようにみえる。本当は次のマイルストーンで5次開発は完了予定だが、もう1つ増やしてもよいかもしれない。いずれにしても12月／1月に本番導入のための準備もある。今の開発フェーズを完了しても次の開発フェーズには入らないのではないかという見通しもある。

朝から起きてはいたものの、午前中は漫画読んでだらだらしていて、お昼からオフィスへ行って作業していた。軽くコードを書いてリファクタリング後の機能拡張の issue を2つ fix した。先週いっぱいリファクタリングして内部設計を改善したので、その先にある機能拡張は容易ですぐに対応できた。本当は今晩から移動して前泊する予定だったが、今晩のホテルを予約してなくて新幹線も遅れたりしている状況だったので明日の早朝に変更した。スマートEX 便利。

近況報告の資料作り

昨日やろうと思っていたものの、休んでいたので今日作っていた。issue の数字だけみればまずまずの実績ではある。意図していた機能開発も動くレベルでは実装できていて完璧ではないが悪い状態ではない。先週と今週は3連休が2回続いて、9月は祝日が2日あって稼働時間が少ないことを考慮すると、十分と言える気もする。今月は若いメンバーの開発したモノをレビューしたりリファクタリングする時間を多くとった。その過程で 相手に責任を投げてしまわない働き方 の考察をする機会にもなった。若いメンバーがそうなるためには経験や時間を必要とするのはわかりつつ、自律的な働き方への取り組みとしてマネジメント側からできることはあるのか、もしくはただ待つだけなのか、そういう話題も近況報告のスライドに入れてみた。

故障した fitbit の発送

サポートとやり取りして デバイス異常になってしまった fitbit を返品することになった。メールで添付されてきた返品票を印刷して、壊れたデバイスと一緒に梱包してファミリーマートへ持っていった。発送用の QR コードもメールに添付されていた。ファミリーマートの 宅配便・配送 サービスで読み取ったレシートをレジへ持っていって、店員さんから配送用のラベルを受け取って梱包物に貼り付けて発送できた。先方で返品確認してから交換用デバイスを送ってくれる予定。

プロジェクトの進捗報告

出張したときの月例報告の19回目。前回の進捗報告はこちら 。この開発フェーズは私が経営陣へ進捗報告するものの、引き継いだマネージャーにも同席してもらって、こんな打ち合わせをしているというのを知ってもらう機会にしている。この1ヶ月間の進捗やこの開発フェーズでやろうとしていることを一通り説明して、あとはざっくばらんに経営陣と雑談するといった機会にもなった。最低限、開発のボトルネックになりそうなところは私が集中開発して解消したので見た目上はよいペースで進捗している。

進捗報告して雑談しているうちに、もうこれ以上は私がお手伝い先へ提供できる新たな価値はなさそうに思えてきた。ここからは課題管理できている issue を優先度順にひたすら fix していく、よくないところはリファクタリングする、開発の負債やボトルネックを解消していくといった、より実践的な実務が求められる。課題管理を含むプロジェクトマネジメントやチームの情報共有を改善することで開発をうまくまわしていくフェーズは十分にメンバーが実践できるようになったと思える。自身の引き出しの中身を払い出してしまって、なにも残っていないような寂しさを感じるようになった。

いまマルチブラウザ／デバイスのテストの自動化のために BrowserStack というプラットフォームを評価している。まだ評価中なので採用の可否はこれから判断するところだが、採用したらコストがかかるのでその話題も経営陣に伝えてその場で議論したりしていた。おそらくこのサービスは Selenium Grid を使っているのではないか？と推測される。うちのプロジェクトだけでなく、社内インフラとして全社共通のテスト基盤を作るという施策もあるかもしれないと話しが発散したりもした。開発においてプラットフォーム的な投資も大事だと考えられている。うちのプロダクトで作る課題管理のメトリクスに、プラットフォーム投資のための見える化ができる機能もあるとよいのかもしれないと思ったりしていた。

今日は開発の設計に関する打ち合わせが2つ入っていて、どちらも私はメインではないものの、メンバーが要件ヒアリングしやすいよう、ハドルで話しを聞きながらチャットにコメントしたり質問したりしてサポートしていた。その合間に ldap サーバーのグループメンバー管理のための api を実装していた。いま ldap client はライブラリとして作っている。docker-openldap というコンテナを使って dockertest で単体テストを実装している。openldap サーバーに対する ldap プロトコルの操作を容易にテストできるので開発がやりやすい。新規にグループメンバーを操作するための api をライブラリとしての ldap client に実装し、その後に web api としての機能を提供した。だいたい1日で完了した。この2週間ほど取り組んでいた、開発フェーズにおける私のボトルネックをこれで解消できた。ここからは私がやりたい開発ができるボーナスステージへと移行していく。これで少しストレスやプレッシャーが減っていくはず。

今日も出張戻りで運動はおやすみ。帰ってから運動をする余裕もあったけれど、日銀の追加利上げ決定から為替が円高に動いて、日経平均先物が急落しているのをみかけて、帰りの新幹線内から経済系の関連記事を読んだりしていた。景気が悪化すると経営に影響するから、こういった転換点に敏感になった。

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

前回の所感 。これまでは2時間をとって要件の発散会議をしてきた。今回は残課題の issue が溜まっていて、まずはそれらを fix してから最低限の機能開発をするといった段取りで進めることを出席者に共有した。そのため、要件を発散させるような話しはほとんどしなかった。主には残課題の共有をしながら、11月頃から最初のお客さん導入を想定して、それまでにやらないといけない要件の機能の再確認を行った。ちょうど2時間ぐらいでおさまった。優先順位なども改めて確認する必要もなさそうに考えている。お手伝い先のプロダクト開発において課題管理が普通になってきたので、特別な確認や打ち合わせをしなくてもどの課題をやらないといけないかは明示されるようになった。これはこれで課題管理の方法論の成果でもある。一方でメンバーからはどの issue を担当すればよいか、開発始めの段階は担当者を割り当ててほしいという意見もあったので、私がいくつか残課題をそれぞれのメンバーに割り振っていった。これも開発が進むうちに、自分が関心のある issue を取ったり、やらないといけないものを自分で割り当てるようになっていけば自律的な開発へ向けてさらに進展していく。

これまでは機能開発を3ヶ月、QA を1ヶ月としてきた。今回は機能開発を2ヶ月、テスト／QA 期間を2ヶ月とる。自動テストや QA 工数の削減のための取り組みに時間を割いて、人間が QA 検証する工数を削減していく。私自身やらないといけない残課題がいくつかあるので早め早めに fix していって集中力をもって取り組む必要がある。今回はマネージャー業をメンバーに移行した分、久しぶりに開発に専念してコードを書ければいいなとも思う。どうなるかな。

今日は出張中で夕方から突発的な嵐がきてホテルに籠もっていた。21時半には過ぎ去ってそれから運動することもできたけど、なんとなく気がのらなくて晩ごはんがてら飲み歩いてた。

プロジェクトの進捗報告

出張したときの月例報告の18回目。前回の進捗報告はこちら 。今回は4次開発のふりかえりを淡々として、うまくいかなかったところなどもそのまま報告した。あまり経営陣からはこれといって責任を追及する指摘などはなかった。まだお客さん先へ提供していないからそれほど深刻な状況でもないのだと推測する。あとはずっと開発をやってきたから私に対する信頼度も上がっているのかもしれない。今回の開発期間において計画通りに進まなかったという失敗をしたが、この失敗を引きずるつもりもない。次の開発へ向けて名誉挽回の取り組みはしていく。

それと同時に次の開発は、うちのチームのメンバーにプロジェクトマネージャーを移行することを提案して了承してもらった。私はまた開発者の立場でチームに貢献する。これもいずれはお手伝い先の社員さんがプロダクト開発をリードしていく必要があるし、チームにおいて機動的にマネージャーという役割を変えることもよいことだと私は考えている。私が関わっている状態で徐々に移行していくのが、チームの混乱もなくてよいと思う。もしかしたらフルタイムで私がこのプロダクト開発に取り組むのは次の4ヶ月が最後になるかもしれない。開発がマンネリ化してきた雰囲気もあったので、新しいマネージャーで少し新鮮な気持ちが出てくればいいなとも思う。

プロジェクトマネージャーを移行して、今後は進捗報告も新しいマネージャーから行うのであれば、私が東京出張しなくてもよい (お手伝い先からみたら経費削減) のではないか？と考えて、その是非も聞いてみた。予想に反して、もうしばらくは私に進捗報告してほしいとのこと。新しいマネージャーにも一緒に参加してもらうのもいいかもしれないとのこと。他のプロジェクトは進捗報告をしていない？らしく、月に1回ぐらいプロジェクトの状況を知れるのは先方の役に立っているといった話しもあって、それはそれで私も嬉しかった。最低もう4ヶ月は毎月の東京出張が続く。

今日は出張中で飲み会があったので運動はおやすみした。

4次開発の大きなふりかえり

前回の大きなふりかえり 。約4ヶ月の開発フェーズが終わってからの大きなふりかえり。もう4回目なのでメンバーも慣れてきたし、過去の知見もたまってきた。そして、私がいまあまり調子がよくないのもあってなにか目新しさがなくなってきたところでもある。今回の開発は2つの大きな失敗があった。

• 想定していた開発機能を1つ落とした
• QA 検証を網羅的に進めることができなかった

これらは私のマネジメントの失敗になる。これまでうまく進み過ぎていたと言えるのかもしれない。プロジェクトマネジメントは毎回うまくいくとは限らない。スクラムガイドにもある見積もりより経験主義の重要性を認識する開発期間でもあった。これまでの順調な進捗に、私自身マネジメントの驕りがあったのだとも思う。次の開発フェーズでまた気を引き締めてプロダクトの品質を担保していく。

いつも通り gitlab の統計情報を眺めながら定例イベントのふりかえりなどもやっていった。UI 周りのふりかえりを口頭での報告や文章で表現するのが難しくなってきたという意見があった。UI は画面の操作をみないと本当の意味で理解するのは難しい。テックブログを読む会も、自分が読みたい記事をすぐにみつけるのが難しいから事前に読みたい記事を探しておくといった「準備」をするメンバーもいる。実は私もたまにその準備をしているのでその気持ちはわかる。記事を探すという作業には一定の時間を取られるという事実がわかってきた。

記事を読んだ後に軽く雑談する時間があってもよいのではないかという意見もあった。これはこれであってもよいとは思う。ふりかえりは隔週でもよいが、メンバー間での確認事項は毎週やった方がよいのではないか？という意見も出た。これは話す必要があるときにハドルすればいいでしょうというところで一旦は見送った。みんなで集まる会議時間はコストが大きいので慎重に判断する。1on1 の隔週30分もそろそろ調整や見直しがあるかな？とも考えていたけど、逆にメンバーからはなんやかんやで30分話すことはあるからこのまま継続した方がよいといった意見も出ていた。

開発のやり方がだいぶ定着してきて、大きなふりかえりも1つの型ができて落ち着いてきた感じはある。よくもわるくも。

同期との飲み会

たまたま新卒で入った会社の同期から連絡がきて、関西で働いている同期が2年ほど単身赴任で東京出張になるらしく、久しぶりなので飲みにいこうという話しになった。本当は4人で飲む予定だったのが、1人がお仕事でドタキャンになって3人で飲んできた。10年以上会っていなかった同期だから近況を話すだけでもおもしろかった。今日会った3人に見た目は昔とあまり変わってなかった。私は体脂肪コントロールした後でよかった。ある同期は課長になっていて、単身赴任である省庁へ出向になった。外からみたら国家公務員やね。本当は話したらダメなんだろうけど、同期というよしみもあって飲みながらいろいろと話しを聞いてた。ここには書けないが、おもしろかった。飲み過ぎた。

私は最初の会社を3年でやめたものの、飲んだ同期たちはもう20年以上、1つの会社で働いているわけで価値観もだいぶ違うだろうと思う。同期って本当によいもので、価値観が違っても会社が違っても未だに仲良く気軽に話しができる。私はたまたま新卒で入った会社が大企業のグループ企業だったから100人ほど同期がいて、5つのクラスに分かれて30人ぐらいのクラスで4ヶ月ほど研修を受けた。いまとなってはその頃の同期とはほとんど会わないし、みんながいま何をしているのかも知らない。おそらく半分以上はその会社をやめてしまっていると推測する。やめた同期とも会う機会があれば楽しく話せるとは思う。

今日の運動はジム筋トレ,縄跳び(両足跳),ジョギング,ハンドグリップ,ダンベルをした。統計を 運動の記録 と 筋トレの記録 にまとめる。ジョギングと縄跳びの後に 右股関節の改善体操 をした。

近況報告の資料作り

来週の出張へ向けての進捗報告の資料作り。一通りは作った。あとは時間があるときに洗練させていくだけ。今回の4次開発はプロジェクトマネジメントの視点からはうまくいかなかった。想定した機能開発は完了しなかったし、品質を担保する取り組みも不十分となった。それは私のマネジメントのスキル不足もあるし、プロダクトが成長してきてこれまでの延長のやり方ではうまくマネジメントできないということも痛感する開発となった。それだけメンバーの自己管理に任せてまとめられる規模からプロダクトが成長したとも言える。いずれにしても、今回の開発フェーズはロードマップ上のマイルストーンとしてはそれほど重要ではない。反省すべきところはふりかえりで気を引き締めて、お客さん先で本番運用が始まる直前となる、より重要な次の開発フェーズの取り組みに活かすための情報共有の機会としていく。

あと私が日々の運動や筋トレに時間を使ってきたから何割か業務の時間を削っている。大きいふりかえりの課題管理の統計からみると、それほど issue の数値の変化はみえないものの、私がもう少し集中力をもって取り組んでいれば20%ほどはパフォーマンスがよかったかもしれない。次開発はプロの開発者がどのぐらいのパフォーマンスを出すのかをメンバーにも示していきたい。

いそがみの筋トレ

前回の所感 。20時前後に体育館へ着いて軽くジョギングしてから筋トレをしてきた。最初に取り組む筋トレの方が疲労がない分、多めに回数をこなせたり、重りを増やしたりできる器機もある。私は10回 x 3セットを基本としてやっている。1つの器機に2-3分あれば終わる。周りの人のやり方をみていると、もっとゆっくりやっているようにみえるので回数や重りを増やしてゆっくりやった方がよいのかもしれない。これまで筋トレをちゃんとやったことがないから適切なやり方がわからない。やっているうちに前回の重りだと軽く感じて1ランク重りをあげたりする機器も出てきた。無理せずやっていく。

筋トレを終えてから磯上体育館の外の公園の空いているスペースで縄跳びもした。ベンチにタイマーを置いて時間を確認しながら跳んでみた。筋トレ直後で疲れているから10分だけやってやめようと始めたものの、10分も跳ぶとマラソンで言うところのランナーズハイになって、しんどくなくなってきて、そのまま15分跳んでしまった。数回縄に引っ掛かってミスしているが、1回休みで7分と7分の2セットを跳び続けた。縄跳びは3ヶ月ほど続けているが、持久力ついたなぁと思う。