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

テックブログ公開

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

• Docker とは何か？

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

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

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

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

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

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

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

リリース前日

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

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

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

サービス精神

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

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

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

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

定例会議とふりかえり

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

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

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

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

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

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

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

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

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

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

2時に寝て7時半に起きた。昨日もWBCをみてから晩ご飯を食べて軽く作業してそのまま寝た。

伴奏

ここ2-3日若いメンバーの開発をサポートしている。

「◯◯ができません」

私が5分ほどでググってできそうなドキュメントや so をみつけてリンクを貼る。

「できました。」

みたいなやり取りを何度かした。大して難しくない処理を実装できないのは公式ドキュメントをちゃんと読んでいないのと、インターネットの検索方法を習得していないように私からはみえる。一度、定例会議のときに google の言語設定を英語にした方がよい。日本のキュレーションサイトの記事の品質は低いからと伝えたが、まだそれを実践しているようにはみえない。いまや英語は deepl で翻訳すれば大半を斜め読みできる。私も deepl で読んでいると教えたりしているのだけど、日本語の記事しか検索していないから未知のことをできないとなってしまう。

チャットで困っていることや問題点を整理したり、どういう視点で調べていくかをやり取りしながら本人が理解して作業できるようにサポートしている。私がやれば10分で終わるようなことを2時間ぐらいかけてチャットしている。それで昼間は自分のお仕事をやらずチャットの話し相手を務めている。誰もが最初は初心者なのでそういう時期はある。以前は質問すらできていなかったところを、あれができないとか、これがわからないとか質問できるようになったというのは成長したと受け取れる。わからないことを説明してもらうことで、私も相手のことを理解できて適切な指示や指導ができる。その過程でプログラミングの理解度も測れるので issue をアサインするときの参考にもなる。

曖昧なことをチャットで聞くのは効率が悪いから、口頭であれこれ質問してくれるようになるのがこの次のステップかな。以前と比べて質問してくれるようになったので信頼関係は少しずつ構築できてきつつあるのかもしれない。

昔の自分といまの自分

既存のある java のコードを読んでいて、私の中ではワーストから数えた方が早いほどのひどいコードをみている。java の言語仕様もプログラミングもどちらもよくわかっていない人がキュレーションサイトにあるような記事を読んで動くように作ったようなツールにみえる。アリエルを辞めてからいくつかの会社で働いてきて java のコードも読み書きしてきた。これまでの経験からその職場での java のコードは品質が高かったし、私もその影響で java の設計やアーキテクチャにも関心をもつようになった。私は未熟なので人並み程度のプログラミングしかできないが、そのスキルを底上げしてもらったのはその職場での3年間の java 開発といえる。私にとっての普通が当時の開発体験やチームの同僚になったことでそれ以降に出会った開発者の大半はスキルが低いようにみえてしまう。そして、その後に私がどんなプロダクトを開発しても決して当時の先輩方に敵うことはないと慢心することもない。だからプロダクトの開発を終えて、組織の方向性にあわなければすぐに辞めることもできた。

いま私がメンバーに教えていることも、メンバーからみたら少し厳しくみえるかもしれない。私にとって先人のような偉大な開発者に自分もなれるんやろか？とか思いながらマネジメントをしていたりする。今週はとくに18時にホテル戻って2-3時間寝て22時頃から2-3時間コードを書いたりしていた。当時の上長もよくそうやって開発していた。当時の私はよく働いたが、そんな私からみてもその上長もよく働いていた。そして上長の生産性は私よりも数倍高かった。お互いに課題管理システム上にいることはわかっていたし、夜中の1時頃にチケット上でやり取りすることもあった。私もいま当時の上長と同じようなことをやっているなと感慨に浸りながら夜中にコードを書いていた。うちのチームのメンバーは誰も夜中に開発していないことだけが当時とは違うことにも気付いた。

1時に寝て何度か起きて7時に起きた。寝たと思うけど、あまり記憶にない。

勉強会は初のお休み

11月から5ヶ月続けてきた毎週の勉強会を今日はお休みすることにした。理由は先週から私が開発にずっと張り付いていて勉強会の段取りをする余裕がないから。勉強会をやってくれと依頼されているわけではない。私が勝手に段取りを組んでずっと継続していきた。続いていると途切れさせたくないインセンティブもあって5ヶ月の間ずっと続いていた。それが一旦途切れてしまった。クロッゾも言っているように、自分勝手な論理を振り回さず、いまチームにとって大事なことをするという側面では、私が開発に張り付くのが悪いわけでもない。今週中に開発を終了させるという目標に全力を尽くすために今週の勉強会はお休みとした。

ああ。これも魔剣と同じ、意地と仲間をはかりにかけるのはやめた by ヴェルフ・クロッゾ

コードレビューしつつ開発

メンバーのコードレビューを合間にしつつ、あるモジュールの開発も進める。windows/linux の両方で動くモジュールを作らないといけないのでビルド環境の考慮や ci/cd、検証もやや工数がかかる。将来的な拡張や開発の分散も考慮にして2つのリポジトリに分割してモジュール化したものを組み合わせる。今日の時点で Active Directory における sAMAccountName と LDAP の DN との変換処理以外は一通り動くものを実装できた。エラー制御や耐障害性のための仕組みはまだこれから実装することになるが、それは後回しにしても、いまはクリティカルパスが私の開発にならないよう、テストや検証の作業をブロックしてしまわないよう、段階的に機能を作り込んでいけるように考えている。あと土日の2日間を使って Active Directory の処理を実装できればクリティカルパスからは脱することができる。

Active Directory のキーワードで検索していると go-adsi/adsi をみつけたので明日はこのライブラリと背景の調査をしていく。感覚的には2日もあれば十分だろうと楽観的にみているが、実際にはどうだろう？

1時に寝て7時に起きた。すでに疲労困憊の様相。

仕様は誰が決めるのか

たまたま定例会議である仕様について話題になった。この作業はなぜ止まっているのだっけ？と確認したら、とくに理由なく、決めの問題を誰が決めるのかでお見合いしてしまっていたような状況であることがわかった。担当の開発者は新人さんなのでスキルや経験が未熟だったりするのはよいとして、仕様を決めていくときの作業の段取りをどうやって学んでもらえばよいかについて、私が考えるよいきっかけとなった。誤解のないように書いておくと、仕様確認できずに作業が止まっていたのはマネージャーである私の責任なので担当者に非はない。

開発の仕様を決めることは難しい。要件であればお客さんに確認しなければいけないこともあるし、背景を調査したり一定の技術知識がないと決められない仕様もある。誰もが最初は上司や先輩に仕様を教えてもらいながら開発経験を積み、自分で仕様を考えたりできるようになっていく。仕様を誰かから与えられるのを待っている ==> 自分が決められる仕様は自律的に決めて作業を先に進めていくの間にある、なにか気付きを与えないといけないと実感した。

この話題でこみやさんと話してみた。

「自分が決めていいこと」の中にはこのあたりが含まれていると思う。

• ある程度正しい判断ができること
• 判断に自信がない場合に相談ができること
• 判断に自信を持てること (先に進める胆力があること)

自ら枷をはめる人は結構いるとは思っていて、明示的にやっていいことを伝えてチャレンジする雰囲気を作りたいのは同意です。ということで、判断できないというのは

• 担当範囲かどうかわからない (自分で決めてよいかわからない)
• 対応が適当であるかわからない (自信がない)

あたりに二分されるのでは、と集約されるのかも。

後者のレベルの人に対しては相談してくれ、ブロッカーを排除するのを手伝うから、とホウレンソウを覚えてもらう感じかなあ、というのが最初のコメント。仕様を決める能力がなくても、聞きに行く能力は持っていてほしい、という感じ。困ったら騒いでほしい、というのが僕が求める最初のステップですね。

スプリントを完了させるのがミッションなので、それができないとチーム全員不合格だよ。このまま待ってていいの? 仕様はどうやったら決まるの? って伝えそうだな、僕なら。

いくつかキーワードがあるように思える。

• 自信
• ホウレンソウ
• 納期の認識

「とりあえずやってみて」とか「まずは自分で考えて」が、今の若者に響かない理由。 の記事によると、いまの若い人は答えを知った後に試行錯誤したり、その後の応用で差をつける文化があるといったことが書いてある。その賛否はともかく、他のマネジメントのイベントでもいまの若い人たちは非効率なことや無駄なことをやりたがらないという話しを聞いたことがある。

まず私が教えないといけないことは、開発や設計において答えなんてないという真理だと思う。確かに経験のある開発者が行う設計は答えのようにみえるかもしれないが、設計は要件の変化によって大きく影響を受ける。いわば時間制限付き論理最適解のようなものだ。またドメイン知識の有無によっても変わってくる。設計とは、そのときに1回判断したら終わりではなく、ずっと考え続ける行為である。試行錯誤することは無駄なことではなく、よい設計を行うための最短の方法であることを教えないといけない。

自信をつけてもらうにはどうすればいいだろうか？これは成功体験を積み重ねるしかないと思うが、成功体験がない初期はどうすればよいのだろうか？パッと思いつくのは心理的安全なチームを作って、ここで失敗しても自分の過失やストレスにならないとメンバーが感じられて挑戦する雰囲気を作ることに思える。このこともそれを体現するのはリーダーの役割なので私がうまくその雰囲気を作れていないと言えるだろう。

ホウレンソウは課題管理を推奨する私にとっては得意分野なのでここでは割愛する。今回の一件もホウレンソウができていないわけではない。課題管理システム上に仕様を決めなければいけないことをコメントに書かれていてそのことに私も気付いてはいた。作業が止まっていることに気付いていなかっただけ。

最後の納期についてはどうだろうか。いまのところ、意図的に私は納期についてほぼチームに言及していない。それはメンバーの1人は十分に理解して自律的に動いてくれているので言う必要がないのもある。新人さんは納期に間に合わせるよりも適切な仕事のやり方や考え方を学んでほしいと私は考えている。納期を意識して不十分な品質の成果を出すよりも時間がかかっても一定の品質の成果を出せるように指導していきたいという私の考えから言及していないので、これも私の非であることは疑いようがない。

1つずつみていくと課題があるのはマネージャーのマネジメントにみえる。なかなか難しい。過去にタイムラインでつぶやいたことを思い出した。

必要な情報は他者から与えられるということを前提にしている人とそうじゃない人との働き方は「気付き」スキルが大きく異なる。後者の人は気付いたら自分から情報を集めるので「そんなこと聞いてない」ではなく「それは (自分も) 気付かなかった」と内省して自身の「気付き」スキルを鍛える。 https://t.co/7VQMzNHyTG

— Tetsuya Morimoto (@t2y) January 6, 2022

1時に寝て7時に起きた。タスクが溜まり過ぎてそろそろ辛くなってきているところ。この余裕の無さはよくないことなので、自分のダメさ加減というか、大いに反省しないといけない。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつもは打ち合わせの議題を2-3日前には共有するようにしている。だいたい水曜日前後に議題のリファレンスをはらさんに共有して金曜日の朝に話している。しかし、今週はリファクタリングに集中し過ぎていて前日の寝る前になって議題を共有していないことに気付いた。そして朝起きてから急ぎで議題を考えて共有していた。これはとてもよくない。準備ができていないので今日の議題は主に近況の話しをしていた。

• プロジェクトマネジメントの話し
• データ指向アプリケーションデザインのイベントの所感
• Gopher塾イベントの所感

ハドルの雑談

先日から 午前中はハドルに滞在 するようにしている。今週は木曜日にチーム外から勉強会についての相談が、今日はメンバーから気分転換に雑談にやってきてくれた。おそらく私がハドルにいなかったらゼロだったコミュニケーションの機会が、1週間に1-2回でもあることに私は嬉しく思ってしまう。フルリモートワークにおける、オフラインのような気軽な雑談の機会を提供する施策の1つとして意味なくハドルに入るのは悪くない気がしている。そのときにコミュニケーションを強制させるような押し付けが発生しないよう、運用ルールを徹底することが大事に思える。いまは相手がハドルに入ってくると 1on1 のような雰囲気になってしまうのでその次の挑戦としてはハドルに入っていても話さなくてよいといった運用ルールを設ければよいのではないかと思う。例えば、午前中はとりあえずハドルに入って気分が向いたときだけ話しかけるみたいな、ゆるいコミュニケーションの場になればいいなと思う。

ハドル雑談の運用ルールのアイディア

• ハドルに入らなくても業務上の支障は一切おきない
• ハドルにいる人には、用事があってもなくても、話しかけてよい
• ハドルに入っていても話さず聞いているだけでもよい
• 業務に集中していて忙しいときは話しかけられても後回しにしてもよい (ハドルから退出した方がわかりやすいかもしれない)

go の generics 勉強会

ちょうど先週からあちこち直したり、mongodb のクライアント周りをリファクタリングしたりしている。その過程で generics を使ってコードの共通化もしたりしている。私自身 generics で意図した通りにコンパイルできなくてはまってしまった事例もあるのでそういった失敗コードも共有した。go の generics はコードに対して静的な領域しか適用されず、コード中における動的な値の型は generics とは直行した概念だというところに初学者ははまるのではないかと思う。私がはまった。参加者におそらく1度はまるからはまったときに私が話していたことを思い出してとコードの解説をしていた。

今日は type constraint でできることと動的な値との関係を混同して generics でできないことを一生懸命やろうとしてた。interface に変換して型パラメーターに type assertion すればコンパイルは通る。2時間ほどはまってた。。。https://t.co/vmk6CfVTl8

— Tetsuya Morimoto (@t2y) February 16, 2023

余裕があったらスライドにまとめて後で資料として再利用できるようにしたかったものの、私の作業に余裕がなさ過ぎて次のリファレンスから引用しながら解説するといった勉強会になった。ただ私が読んでよいと思った他者のスライドやブログの記事のみを紹介している。それはそれで参考にはなるので勉強会の意図としては問題なかったんじゃないかとは思う。

• The Generic Dilemma
• Tutorial: Getting started with generics
• Go 1.18集中連載 ジェネリクス
• Go1.18最新情報
• Understanding generics in Go 1.18
• golang 1.18+ generics: The Good, The Bad, The Ugly.

23時に寝て何度か起きて5時半に起きた。

プロジェクトの進捗報告

出張したときの月例報告の3回目。前回の進捗報告はこちら 。1月はバックエンド開発を完了させてフロントエンド開発に着手した。当初は6ヶ月の開発期間を設けていたものの、1ヶ月前倒しの5ヶ月でフェーズ1の開発を完了させる見通しを報告した。管理画面も機能的にはすでに一通り実装できている。これから2月は使いやすさの ui を改善していくところや品質をあげるためのリファクタリングを行い、3月は運用レベルのテストをしてバグ修正を行う。ソースコードの品質も私がチェックしているので、どういう修正が必要かも予測できていて、十分に余裕のあるスケジュールだと私は考えている。油断も慢心もなく、いまできるだけの知識とスキルをつぎ込んで品質の高いプロダクトに仕上げるのに努める。

先月に宣言した通り、フェーズ1の開発はもう私の中では終わっていて次のフェーズ2への準備や計画をこれから考えていく。業務的に区切りがよいのでフェーズ1で契約終了する可能性もあったけれど、4月以降も開発のマネジメントをしてほしいとのこと。フェーズ1の開発と並行して、余裕をみてフェーズ2以降の計画も立てていく。フェーズ2以降に予定している、少なくともあと2つの機能開発に私は責任をもとうと契約の有無に関係なくもともと考えていた。それらを実装すれば大半のお客さんのニーズにあうプロダクトになるはずなのでそれ以降の開発は引き継いでいいかなと思う。言うても野心的に言えば3ヶ月強といったところか。チームも成長しているので3ヶ月前よりは開発速度が上がっている。

さらにいま私が担当しているプロジェクトとは別に、他にもやってほしいお仕事があるらしい。もしかしたらそれも含めて来季の半期以上のお手伝いになるのかもしれない。しばらく次のお仕事探しはしなくてよい状況にある。3月のリリースを終えたら会社の事例紹介を書きたい。今回は会社として初めてのプロジェクトマネジメントの実績になる。周りにも喧伝していきたい。

出張晩ご飯

たまたま1月末に課題管理についてチャットで議論していたら盛り上がったのでこみやさんと晩ご飯に行ってきた。ざっくばらんに近況やチームのマネジメントについて話してきて楽しかった。19時半過ぎから始めて23時過ぎまで飲んでた。帰路の途中で新宿駅構内で人身事故が発生して、電車が止まってしまい、復旧に1時間ぐらいかかるというのでタクシーで帰った。タクシー料金も region pay で「ただいま東京プラス」のクーポンが使えたので金銭的に損はしなかった。

こみやさんのチームの話しからは、対話重視のスクラムのイベントが si におけるメンバーの教育にもうまくいっているように聞こえた。メンバー間で質問し合うのを促していて、質問者と回答者の双方の理解度をあげることを狙いとしている。質問が現状をふりかえるよいきっかけになっているとのこと。

あとメンバーに自律的に勉強会をしてもらうにはどうしたらいいかという話題も盛り上がった。私もいま毎週勉強会をやっていて、これはよい開発文化を作る上で大事だと思っているものの、いずれメンバーが自律的にやるようになってほしい。いまは私がお手本をみせるという意図もあって勉強会の運営をやっているのだけど、それをどうやってメンバーもできるように巻き込んでいくかを考えている。こみやさんや私が勉強会をやると、一定の水準で運営してしまうから、それがメンバーにとって逆に気後れさせてしまわないかという視点も話したりしていた。勉強会は準備に工数がかかると発表者が大変になって続かなくなるので、毎週やろうと思ったら準備に工数をかけないという仕掛けは重要になる。もしくは情報共有やコミュニケーションの場としての勉強会を考えるならもっと身近な内容を話す場になってもよいのでは？という考え方もある。例えば、最近の時事ネタで関心をもったニュースや技術などを取り上げて雑談するのでもかまわない。

いずれにしても、うちらがやれと指示してしまうと、業務命令として業務だからやっているだけになってしまい、よい開発文化を作るという、結果的に業務に大きな価値をもたらすなにかとは違うものになってしまうのがこの問題の難しいところ。開発をよりよくしたい。技術を深めたい。品質をあげたい。なにかしら開発そのものに対して関心をもって自律的にそういう活動をする開発者を増やしていく。言葉にすればたったこれだけのこと。しかし、このことを教えるのは相当に難しい。まだ私がマネージャーとして働く時間はあるのでこれからも挑戦していきたい。

1時に寝て5時に起きた。ホテルのテレビを付けっぱなしで寝たら朝のニュースで起きた。なんとなくニュースをみながら7時ぐらいまでのんびりしてた。

1週間のイテレーションはナンセンス？

毎月行っているマイルストーンのふりかえり。今回で3回目なのでメンバーもだいぶ慣れてきた。11, 12, 1月と3ヶ月に渡って課題管理をメンバーに実践してもらいながら開発してきた。当初、開発のイテレーションを1週間で行うか、2週間で行うかの話し合いで短い方がいいんじゃないかとなり、あまり深く考えずに1週間のイテレーションで開発をまわしてきた。しかし、いまとなってはこれは開発のイテレーションとは違うものになっている。

最初の1ヶ月はメンバーにとって慣れないワークフローだから、1週間のイテレーションでこの issue をやる・やらないといった厳密な取り決めはしなかった。その後、徐々に慣れてきたのを見越して、定例会議のときに issue 一覧をみながら、メンバーに2-3個ぐらいの issue をアサインしたり、issue の優先順位付けを明確にしたりしてきた。必ず issue を完了させるという強い制約を課していないものの、だいたい毎週アサインしたものをメンバーは対応してくれていたので、マネージャーとしての私の視点からもとくに問題はないようにみえた。要はうまくまわっているのでそれ以上の管理をしなくてもいい状態だったと言える。

一方で、本来の課題管理のイテレーションとは異なる開発のワークフローになっていて、それがよいことなのかどうか、私自身にも明確な答えがなかった。それでメンバーに尋ねてみた。いまの1週間単位のイテレーション (開発のワークフロー) をどう思いますか？

メンバーからは、1週間の作業内容を厳密に決めなくてもいいんじゃないかという意見が出た。それは私の考えとも一致していたものの、開発のイテレーションを2週間に伸ばすことについて話しているときに、そうしたとしても、定例会議は毎週やりたいという意見が出た。要件確認や仕様共有のために重要だという。通常、イテレーションの成果共有のために定例会議とイテレーションの長さは一致している。仮にイテレーションを2週間にしたら定例会議は2週間に1回となる。しかし、メンバーの視点からはイテレーションを1週間にするか2週間にするかについて関心はないものの、毎週の定例会議で行っている情報共有は重要だという認識があった。

ここで開発のイテレーションと定例会議の頻度は別にあわせなくてもいいんじゃないかと考えるきっかけを私は得られた。スクラムもスプリントと会議体の頻度はセットになっているのでこの発想はなかった。ちなみにアリエル時代は1つのイテレーションが3ヶ月で定例会議もなかった。そして、うちのチームは1ヶ月のマイルストーンに対してふりかえりをセットにしている。これはもはやイテレーション開発の文脈でいえば、実質うちのチームはマイルストーンと呼んでいる1ヶ月が1つのイテレーションになっていて、1つのイテレーション内に4回の定例会議があるというイテレーション開発のワークフローになっていることに気付いた。課題管理の考え方やワークフローがもっと洗練されていくと、毎週の定例会議をやらなくてもよいようになっていくのが私の経験から自明である。しかし、うちの開発は私も含めて8割以上がフルリモートワークなので、メンバー全員の顔を合わせる機会を作るという観点から毎週の定例会議は大事な場にもなっている。

実際の開発のマネジメントをしてみると、私自身、分かっていなかったことや新たな発見があって、まだまだ自分自身も修行の身であることを実感する。ここでの結論としてわかったことは次の通りで、ロードマップにおける最初のフェーズが完了する3月末までは現状のワークフローを継続してみることに決めた。

• 開発のイテレーションとして1週間は短過ぎて管理対象としてあわない
• 開発のイテレーションと定例会議の頻度をあわせなくてもよい
• フルリモートワークの場合、メンバー全員を集める目的は情報共有だけではない

2時に寝て7時に起きた。お仕事は時間かけた割に成果でなくて、遅くに帰ってきて晩ご飯食べてダンまちみたら寝るのも遅くなった。

ハドルと雑談

今日から午前中はハドルミーティングに滞在するようにして、メンバーが気軽に雑談しやすい雰囲気を作ってみる。大学で言うところのオフィスアワー。初日だったせいか、どんなものかとお試しでチーム外の開発者が来てくれたりもした。メンバーの1人もお昼前にとくに用ないけど試しに来てみましたと軽く雑談した。ハドル中じゃなかったけど、別のメンバーも午後にコードレビューの詳細について聞きたいといったメッセージが届いてハドルをした。リモートワークしていても気軽に話しかけていいんやでと表明することで、いくらか話しかけるのをためらう心理的障壁が下がったことは確認できた。普通に誰でも考えて起きること。あとはこれを一定期間、1ヶ月とか2ヶ月とか続けてみてどのぐらいの雑談ができるかを記録して、効果がありそうなら次のアクションを考える。とくに用事もないけど、暇だから気分転換に雑談に来ましたというのが高頻度で起これば心理的安全性にとってもよいことじゃないかな。私が逆の立場なら、用事もないのに会社の人に話しかけるのは仲のよい同僚しかいなかったと思う。他のメンバーも気軽にハドルに滞在するようになれば、物理的にオフィスに出社しなくても雑談しやすい雰囲気は作れるかもしれない。

0時に寝て4時に起きて7時に起きた。晩ご飯に餃子の中身とニラと卵を炒めたものを食べてわりとよく眠れた。

遊撃の開発

ちょっと前に自分が 遊撃としての役割 を担っているのではないかと書いた。ある機能開発で javascript を用いてカスタムスクリプト を実行できるようにしたい。スポット的に私の手が空いていて手伝ってと言われたので実装している。開発していると集中しているから時間が経つのが早い。あとコードレビューのときよりもしっかりコードを読み込んだり、振る舞いをシミュレーションしたりするから、コードレビューのときに気付かなかったことや見逃したことにもい気付く。そして、それもついでにリファクタリングしていく。チームのメンバーに、過去に書いたコードをどんどん書き直すのはよいことだというのを、遊撃しながら教えていければいいなとも思う。課題管理システムの issue に調べたことや設計の素案のようなコメントをしていると、メンバーもコメントしてくれたりして、考え方や検証したことをどんどんテキストにして書いていく、言語化していくことの良さも、遊撃の中から学んでくれたりすると嬉しい。開発しながら、メンバーの教育や指導をどう進めるのがいいかな？とかも考えながら働いているのがマネージャーにやっているなという自己満足にもなっていたりする。だいぶマネージャーとしても自分自身にも慣れてきたんじゃないかと思う。