Posts for: #Project Management

イレギュラーな出張

本当は昨日の夜にもう少し開発しようと思っていたが、体力的に衰えているせいか、晩ご飯食べに帰ってそのまま家でだらだらしていた。翌1-3時前までオフィス戻って作業して、それから出張の準備をして、5時過ぎからいつも通り始発の新幹線に向かった。

定例会議

私のリファクタリング issue が1つだけ未達で残ってしまった。他の新機能開発はほぼ予定通り完了できた。メンバーががんばってお仕事してくれたことに感謝。無理なスケジュールを強いていないというのもあるが、ちゃんと見積もりと工数を管理できていることそのものはよいことだと思う。概ね予定通りであることを確認して、あと2つのマイルストーン (1ヶ月) を使って qa テストにあてる。これも web 開発からしたら驚くほどの工数を使っているようにみえると思う。しかし、品質の悪い web 開発を私はたくさんみてきたので結果的に qa をちゃんとやる方が工数削減になると私は考えている。

いま作っているプロダクトのライセンスが実は Apache License v2 になる。oss な会社だから基本的にプロダクトは oss なライセンスで提供しているらしい。とはいえ、リポジトリを一般公開しているというわけでもないため、広く oss として使ってもらいたいというほどのモチベーションでもない。お客さんが要求すればソースコードも提供するといったスタンスらしい。実際にお客さんがソースコードを要求してくることは皆無らしいが。

もうやんカレー

過去に虎ノ門で働いた頃、もうやんカレー好きな同僚がいて懐かしくて 新橋店 へ行ってみた。私がこのお店へ行っていた頃は10年以上のことなのに、昔とお店の雰囲気やメニューはあまり変わっていない気がする。スパイスが効いておいしかった。薬味?トッピング?にサービスで提供されるスモーキーなたくわんや玉ねぎのピクルスもおいしかった。

かぷせる旅籠 赤坂 SPABLIC INN

五反田から赤坂へ行くルートの1つとして、五反田 - 新橋 - 赤坂見附で行ける。乗り換えのアクセスがよかったり、新橋で晩ご飯食べるのもちょうどいい。前から知っていて1度泊まってみたいと考えていた かぷせる旅籠 赤坂 SPABLIC INN に泊まってみた。SPA:BLIC がコーポレートサイトらしい。結論から行って、私の感覚ではすごくよかった。また一泊出張のようなスポットで泊まるときがあれば予約したい。カプセルホテルだから料金は4,471円だった。いまの相場からいうとビジネスホテルでも1万2千円ぐらいするので半額以下と言える。カプセルホテルだから盗難防止を考慮して着替え以外はもっていかなかったが、ちゃんと鍵付きのロッカーもあったのでパソコン程度の荷物なら保管できる。

和風カプセルホテルで施設が新しく、ハイテクであちこちの入館やロッカー、チェックイン/アウトはすべて ic チップで行う。お風呂とサウナはこれといって特徴もなかった気はするが、大きなお風呂に入れるだけで私は満足。コワーキングスペースも併設されていた。休憩プランだと150円/時で使えるらしい。宿泊でももしかしたら使えたのかもしれない。コワーキングスペースが使えるならリモートワークをここでしてもよいのかもしれない。よいところをみつけた。

移動と会議と眠気の日

1時から3時まで仮眠して、それから準備していつも通り5時15分に家を出た。なぜかお盆前なのに新幹線はめっちゃ空いていてパーソナルスペースが広くて車内で2時間ほど寝ていた気がする。仮眠したつもりだったが、やっぱり16時前後になると眠くて眠くてお仕事にならなくなった。夕方にホテルに戻って寝てた。新幹線の移動日はたいていパフォーマンスが悪い。

プロジェクトの進捗報告

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

いつもは水曜日にやっているけれど、今回は先方の出席者の都合がよくなかったので火曜日に変更した。午前中にはチームでの定例会議をやっているので本日2つ目の会議。資料作り の中でも書いたけれど、開発がやや遅れてもう1つイテレーションをこなした上で QA を2つイテレーションするという計画を伝えた。スケジュールの前倒しするように言われる可能性もあるかなとは考えていた。しかし、とくに計画については何も言われなくて、私の想定する計画通りでよいかのように進んだ。メンバーにスキルアップしてもらう教育的な側面から時間をかけているところもあるので、そういった学習コストを容認するという判断だったのかもしれない。いずれにしても最後の締めに向けて懸念点はなく、いまはひたすらに邁進するだけ。その他、設計についての考え方やメンバーの育成について共有したりしていた。

go-ldap の syncrepl 機能のレビュー対応

1時に寝て何度か起きて7時に起きた。今週もよく働いたからバテバテ。

ストレッチ

これまでも慢性的に右足全般は悪かったのだけれども、今日は左足の張りがある (痛い) ところと右足の張りがある (痛い) ところが全然違うことに気付いた。トレーナーさんによるとさらに今日はいつもより上半身の腕も硬かったという話しだった。これから1ヶ月か、1ヶ月半ほどは開発の佳境で忙しくなる (座っている時間が長くなる) ので体調がよくなることはないと思う。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。普段通りなのでこの調子なら問題ない。

syncrepl のレビュー対応

先日のレビュー対応 の修正。通信プロトコルの処理を実装するには想定したパケット (byte 列) をデコードしないといけない。そのために誤っているとすぐに panic する。開発しているときは既存の処理の振る舞いと競合してあちこちで panic してデバッグが容易ではなかった。そこで既存処理とは分割して先ずは実装した。その後、プロトコルの仕様と対応するパケットを理解してしまえば、どこを直せばよいか把握できているので既存の処理と共存させることはとくに難しくなかった。私の先入観であちこち変更しないといけないのでは?と思い込んでしまっていたのをレビューアの指摘で気付くことができた。感謝。

これでレビュー対応を終えた。pr を送ってから2週間放置されていた。そこでレビューしてくれないかとお願いしたら2人のメンテナーがすぐにレビューしてくれた。これは 非同期検索 でのやり取りを経て私の信頼があがっていたためと思われる。この機能はお仕事の開発にも使う。ちょうどいま開発の佳境に際して花を添えるよいタイミングと言える。

進捗報告の資料作り

気付いたら来週は出張の週になる。月例報告のための資料を作っていないことに今日気付いて慌てて資料を作った。いまは開発の佳境の時期なので、開発方法論に新しいことを試しているわけでもないし、この1ヶ月のやったことの進捗を報告するだけ。内容は固まっていて資料を作るのはそんなに大変ではない。理想的なスケジュールだと9月上旬で開発完了を目指していたが、それは無理そうだと判断した。その次のイテレーションで完了できるように目指す。さらに追加でバッファのイテレーションももう1つある (と私が勝手に思っている) 。2つイテレーションを伸ばすと開発は1ヶ月の遅延となる。このぐらいのブレは私の中では許容範囲だけれども、一般の会社だと認められるのかどうか、開発マネジメントの機微によって分かれるのかもしれない。

他山の転がる石

23時に寝て3時に起きて5時に起きて7時に起きた。昨日は早く帰ってきてまたオフィスに戻るつもりが、そのままゆっくり過ごしていたので休憩してた。

プレスリリース前のドキュメントチェック

いよいよ来週に私が9ヶ月に渡って開発をマネジメントしてきたプロダクトのプレスリリースがあるらしい。4月末の段階でプレスリリースできる状態にはあったものの、足りない機能もあったし、展示会に出展して反応をみたり、営業さんとの調整もあったりで3ヶ月ほど時間を要した感じだ。発表されたプレスリリースを引用してうちの会社の事例紹介も書くつもり。まだまだ開発の課題はあるし、気を抜ける状況ではないが、いろんな歯車が噛み合ってきて、期待した未来になるよう、その方向にモノゴトが収束しているようにみえる。私にとっては結果はもう既定路線になっていて、あとは自分がどれだけがんばれるかでその品質が変わるだけの状況になりつつある。

開発においても「ラストワンマイル」に入りつつあるし、私の体力があと半年ぐらいもてばそれでいいんじゃないかと思う。まだまだ先は長いのだけど、終わりがみえてきて、ラストスパートをがんばっていこうといった心境になっている。

ビッグモーター問題の考察

先日 ビッグモーターの記者会見 をみた。そのときに元幹部社員で youtube に動画をあげている方が副社長である息子について言及していた。その後の報道もみていてその真偽も明らかになりつつあるので動画も貼っておく。

たまたま次の記事をみて、その副社長の line のスクリーンショットが公開されていた。

これをみていて思ったことの1つは「権力は腐敗する」の典型例なのだろうと思う。社長の息子というだけで、苦労も実績もない中で経営者になってしまって、権力を振るううちに度が過ぎてしまったのではないかと思えた。言い方を変えると、この副社長も社長の息子として生まれて不幸だった側面があるようにも思えた。普通の人は社内の人間関係を築くのに葛藤や逡巡を積み重ねて経験を増やしていくところが、社長の息子として特別扱いされるうちに分からなくなってしまったのではないかと推測する。

以前 dmm の亀山さんがこんなことを言っていた。

権力のもっとも上手い使い方は「持ってても使わない」こと。

「権力者の横暴」についてどう思いますか――DMM亀山会長に聞いてみた

私も過去にメディア力のコントロールが難しいことに気付いたことがある。会社で大きな成果をあげると、途端に周りが忖度し始めて普通の発言が周りに大きな影響力を与えたり、意図しない結果をもたらすことに気付いた。そうなったらできることは「発言しない」か「辞める」かの2択になる。亀山さんが仰っていることは前者のやり方に近いものと推測するが、権力をもってしまった時点でとても扱いが難しいことを自覚するのが大事だと思えた。

ここから1ヶ月は開発に集中

1時半に寝て3時半に起きて6時に起きて7時に起きた。昨日はビッグモーターさんの記者会見をみて、ネット上の記事を読んだりしていて夜更しした。

差分比較の処理

非機能要件である 差分比較のための機能 の開発をこのマイルストーンでやってしまう。なるべくメンバーにはアプリケーションのメイン機能を開発してもらって、非機能要件のようなサブ機能を私が作ってサポートしていく。今日は既存のコードを読んで設計したり、調査のためのコードを書いて振る舞いを確認したりしていた。いくつか詳細は残っているけれど、概ねいけそうかなというところまでやって一区切りつけて一旦手を止めて、メンバーの issue やブランチを眺めたりしていた。

法要の調整

今週末に父の初盆がある。準備の状況を母と連絡してやり取りしていた。土・日・月と帰って、月曜日は実家でリモートワークしようと思う。ジモティー検索 してオフィスに使えそうなものがあれば持って帰ろうと考えていたが、そんなうまくはいかないようだ。出品されているものの中にはもう売り切れているのか?問い合わせても返信が返ってこないものや先着で売り切れてしまったものもある。ジモティーはたまにみて気長に探すのでちょうどよいと思う。

マイルストーン終了直前の余裕

0時に寝て3時に起きて5時に起きて7時に起きた。足のしびれは治ったみたい。

マイルストーン終了直前の issue 整理

明日の火曜日がマイルストーン終了日でインフラ系や外部ライブラリの重たい issue は一通り完了したのでプロダクトの方に注力できるようになった。自分の issue よりもメンバーの issue や次マイルストーンの issue の整理などを主にしていた。自分の issue をやるよりも、メンバーやチームのサポート系の方に注力しようと思ってプロジェクトマネジメント的なところの作業をしていた。自分が開発や調査をやり始めると、どうしても注意力や認知を issue の方に取られてしまって全体を眺めたり管理したりといった側面が疎かになる気がする。会議を減らして自分の時間を増やしても、メンバーの都合でサポートする機会をみていないといけないのでこのバランスを取るのはなかなか難しいなと思う。少し時間的な余裕をもった方がよいかなといったことも思わないでもない。

会議の趨勢

前日に飲みに行ってきて1時に寝て何度か起きて7時過ぎに起きた。移動日であまり眠れていなかったのと夜遅くまで飲みに行っていたせいか、朝からどっと疲れた印象があった。

プロジェクトの進捗報告

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

今回はあまり大きな話題がなかったのと、いま機能開発の真っ只中なので報告もシンプルなもので済む。前月に導入した新しい取り組みをおさらいしつつ、それらが1ヶ月を経てどのような状況になっているかを共有することにした。前月は新しい取り組みを始めたからいろいろツッコミが出るかな?と期待したらほとんど出なくてやや消化不良だった。今回は逆に前月と大きな取り組みの違いもなく、淡々とやってますよ、進捗はまぁまぁですよみたいな共有だったのに報告後の雑談は盛り上がった。会議の趨勢は未だに読めない。

いずれにせよ、開発はこれからの1ヶ月が正念場になる。私も積極的に開発に介入するし、私がやらないといけない issue もいくつかある。人に張りついて指導していると自分の作業がまったく進められない。なので、指導していない時間に自分の作業を進める取り組みをそろそろ始めていく必要もある。心技体は悪くないのでまぁ大丈夫だろうとみている。

定例会議とそのプラクティス

22時に寝て1時半に起きて3時半に起きた。それからお風呂入って準備して始発の新幹線に乗った。いつもは夜通し起きているけど、今日は夜に雑談会があるので寝ておくことにした。

新しいやり方で1ヶ月が経過した定例会議

一ヶ月前の定例会議 は変更したばかりで手探りな状況ではあったが、今回は3つのマイルストーンをこなし、チームメンバーも新しいやり方に慣れてきたと言える。いまのところ、開発の情報共有でメンバーが困っているようにはみえない。しかし、タイムボックスの始めと終わりが生産性が上がるといったマイルストーンを短くした成果もあまりみえない。可もなく不可もなくといったところかな。悪いわけではない。

一方で6月末に私が休暇をとったり社員旅行があったりしてその分の業務時間が3日ほど少なかったことが最も大きく影響したと言うべきかもしれない。私は終わってみれば2週間で1つの issue しか fix していなくて、これまでは10以上 fix しているので、今回のマイルストーンの成果がいまいちにみえるのは私が最も働いていないといった方が正しい。いろいろ手掛けてはいるのだけど、調整のタイミングが悪くて fix しなかったという状況がある。それも含めて次の1ヶ月をピークにもっていく開発のメリハリではある。これまでの1ヶ月の進捗をみてメンバーにも3ヶ月でいま想定している機能開発を終わらせるよと共有した。

私が作業するなら余裕でこなせる作業量だけど、実際に作業するのは私じゃなくてメンバーが担当する。今後もメンバーの進捗を注視しながらサポートしていくことになる。他人の進捗をコミットするのはなかなか難しいという思いを抱きながらサポートしていく。

コパイロツトさんと雑談

準備を経て 19時半から南青山のオフィスで雑談してきた。いろいろ準備していったが、モニターが大き過ぎて画面共有しても文字がよくみえなかったり macbook の操作がやりにくかったりして資料はほとんど使わずに雑談してきた。コパイロツトさんはプロジェクトマネジメントそのものをやっているわけではなく、プロジェクトリーダーの意思決定を支援するための取り組みをしているというユニークな業務を提供している。スクラムで例えると、スクラムマスターよりも代理プロダクトオーナー (Proxy Product Owner) に近いという。

定例会議をうまくやればプロジェクトがうまくいくという信念のもと SuperGoodMeetings を提供している。ツールを正しく使ってもらえると意図した通りにうまくいくのだが、問題はツールをそもそも使ってくれないユーザーやチームをどう導くかというところで苦労されているように思えた。これは課題管理システムを使ってくれないという私の問題意識とも通じる。ツールを使いこなすには文章を書くことが重要で、文章を書けない人たちが一定数いるという事実を受け入れて、どのような取り組みをしていくか?これも課題管理と共通の問題であるように思える。課題管理の話しをして背景や意図が通じる人は少ないだけに、その価値観を共有できるというのは稀な機会であった。また 日本ナレッジ・マネジメント学会 という学会があることを教えていただいた。後日加入してみようと思う。

19時半から21時ぐらいまでオフィスで雑談して、その後23時半ぐらいまで飲みに行ってきた。楽しかった。

メリハリの付け直し

23時ぐらいまで作業して、1時から2時ぐらいまで仮眠した。いつも通り普通に寝ないで始発の新幹線に乗って寝てた。寝ていて体があちこち痛くて、月に1回ではあるけどこの生活を続けるのもよくないかもなと思い始めた。

新しい定例会議の初日

6月から新しい開発がスタートして 新しい定例会議の進め方 に変更した。ふりかえりと情報共有の定例を1時間に詰め込むので時間が足りないかも?と時間を意識しながら進めた。その甲斐もあってか、ちょうどぴったり1時間におさまった。これも一種のパーキンソンの法則のようなものが働いているのかもしれない。

仕事は、完成までに利用可能な時間を使い果たすように拡大していく

パーキンソンの法則

メンバーが2人なので機能開発が2つずつ並行に進む。1つは開発が完了し、もう1つも大半は完了している。完了できなかったことは残念だが、私からみても着実にステップアップしているのでそれほど問題視していない。ドッグフードテスト の導入も完了こそしなかったが、これも社内インフラの都合や管理者の工数を調整してもらったりするので着実に進捗しているのであれば、それほど厳密にスケジュール管理しなくてよいのかもしれない。

イテレーション開発のルール的には優先度を付けた issue はそのイテレーション内でやり切るという目標をもつように促している。但し、まだ開発の序盤であるので現時点ではそれほど重要ではない。これも1つのメリハリだとみなすこともできる。また様々な状況の変化や調整をしながら期限を意識して働くのは一定のスキルと自律的な行動を取れる開発者に限られる。

なんのために働くかの答えを見い出せていない若い人にそれを求めるのもまた違うなと思えて、この状況を作り出しているのは、働く目的そのものを導くようなリーダーシップを取れていない私自身の責任だと実感した。つまり私が自身の規律を緩めているのがメンバーに伝わって、結果的にスケジュールを守ろうとする最後の底力を支えられていないと思えた。開発の仕切り直しに私自身も切り替えていかないといけない。

厄介なインフラの問題 x 2

ちょうどインフラに関する、特定の状況においてパフォーマンスが劇的に劣化したり、意図しない振る舞いをしたりする事象を2つ確認している。これこそ私が面倒をみる issue だなと思って着手した。m2 macbook はこういったインフラの再現環境を作るのに向いていない。2022年に virtualbox 7.0 で m1/m2 に対応したという changelog があるけど、少し前にインストールしようとするとエラーになって動かなくて諦めた。

macOS host: Providing a Developer Preview package for systems with an Apple silicon CPU. This is unsupported work in progress, and is known to have very modest performance.

Changelog for VirtualBox 7.0

アプリケーションのコンテナイメージも、現時点では amd64 向けにしか提供していないため、どのみちコンテナでの検証が必要になったら m2 macbook では動作させられない。そういう厄介な issue を抱えた。帰ったらオフィスのデスクトップマシンで再現環境を作るところから始める。

ぼくのかんがえたさいきょうの定例会議

1時に寝て何度か起きて8時に起きた。昨日ブログを書き終えてほっとしたのか、珍しく寝坊した。

課題管理の定例会議の進め方

5月31日から 新しい開発がスタート していてイテレーションを2週間に、そして定例会議も同様に隔週とした。その狙いは先日の日記に書いてあるが、これまで毎週やっていた定例会議の進め方はあわないので新規に会議の進め方を刷新した。これまでふりかえりと定例会議を別にやっていたのを1つにした。またふりかえりの会議のときに、ふりかえり作業そのものもやっていたのを、定例までに事前にメンバーがそれぞれやってきて、結果を定例のときに共有しようというやり方に改めた。ネガティブなふりかえりは発生時点で課題管理システムに登録してフィルター可能というのがアピールポイント。いまチームのメンバーが3人なのでこれでも会議は1時間でおさまる見積もり。メンバーが増えたらふりかえりと定例は別の時間にわけてやるかな?会議時間が長くなるとダレるので1つの会議は1時間以内で締めるというのは徹底したい。

  1. 現マイルストーンのふりかえり (目安時間: 25分)
    1. fun/done/learn を使ったポジティブなふりかえり で共有
    2. ネガティブなふりかえりは課題管理システムに Postmortem ラベルを付与して issue 登録したものを共有
  2. 次マイルストーンでやることの確認 (目安時間: 25分)
    1. 課題管理システムにある次マイルストーンでフィルターした issue を共有
  3. issue になっていないもので聞きたいことや分からないことを聞く (目安時間: 10分)
    1. メンバーが自由に意見を表明
  4. 雑談 (余り時間)
    1. メンバーが自由に雑談

事前準備を済ましてから、スクラムでいうところの、レトロスペクティブとプランニングを同時にやるといったもの。実践としてうまくいくかどうか、今回の開発で試してみる。

落ち穂を拾い集めて課題管理を促す

2時に寝て何度か起きて7時に起きた。能の本を読みながら寝落ちした。

落ち穂拾いの終了

4月末にリリースしてその後 GW に入って、5月は「落ち穂拾い」として 開発全体のふりかえり をやったり、次の開発の要件を整理 したりしていた。ドッグフードテスト の導入もまだ作業中ではあるが、社内のシステム管理者にも協力していただいて進めている。私の作業でも十分な余裕をもって次の準備につなげることができたので開発の区切りで1ヶ月ぐらい準備期間があることはよいように思える。経営者はもっと働かせたがるかもしれないが。

これまでの開発は定例会議も 1on1 も毎週行ってきたが、次の開発ではこれらの会議を隔週にしてみる。口頭による同期コミュニケーションのコストを減らし、より開発そのものに時間を割いて注力できるようにする。もしかしたら、これによって私も開発に参加する時間を作りやすくなるかもしれない。もう1つ 必要なときに必要な人とすぐに話す (会議の日まで待たない) という狙いがある。毎週会議があると、すぐ聞けばよいことを次の会議まで待ってしまうということがある。私もある。私ですら待つときがあるのだからおそらくメンバーにもそうしてしまうことがあると推測する。会議の頻度を下げることでこの待ち時間を削減して即時問い合わせ、即時解決するといったコミュニケーションに移行していきたいという狙いがある。開発者の自律性を高めるためにはこういった取り組みも必要だと思える。もっと言えば、毎週会議しないと情報共有できないというのは開発者を子ども扱いして堕落させるのではないかと考える。実際に意図したようにうまくいくかどうかはやってみてから考える。

うちの開発メンバーは半年前より見違えて課題管理に習熟したので次の開発がどうなるかが本当に楽しみだ。