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時に起きた。いつも通り夕方にホテルに戻って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時に寝て2回ほど起きて7時に起きた。土日コードを書いて疲れていたので月曜日は早めに業務を切り上げて実家のいろいろをやっていた。

開発の追い込み

サーバーサイドとフロントエンドはほぼ開発が完了し、これからテストするだけといきたいところが、想定外のことがあってまだそうはなっていない。

予想外のことは起こるものだ。ガトーは良くやっている by エギーユ・デラーズ

と言っているほどの、予想外というわけでもないが、思った通りに進捗しなくてリリースの危機を迎えている。なにが起ころうとプロジェクトの全責任はマネージャーにある。いま溜まっている issue をメンバーに再分配して乗り切ろうと定例会議で話した。私が2人分ぐらいの作業をすれば1週間もあれば取り戻せる程度の遅れではある。ただ残り時間が1ヶ月しかないだけ。また週末働いてその足で東京に行くのだろうなと直近の未来を想像していた。

上司道 野村監督から学ぶリーダーの器のつくり方

お仕事にテンパっているものの 第86回上司道 野村監督から学ぶリーダーの器のつくり方 に参加した。上司道 に参加するのは2回目。

以前 野村ノート を読んだことがある。 野村監督は言語化にこだわりのある方で選手としても監督としても一流だった氏の実践知の言語化は参考になるかもしれないと思って読んだ。本書は期待した通りでプロ野球に限らず、一般のビジネスパーソンにとっても汎用的に役に立つアイディアがいくつもあったように思う。

例えば、野村監督が捕手に求めるものとして次がある。判断というのは知識と経験を根拠になんらかの基準をもってくだすといったことが書いてあった。判断の前に分析と観察と洞察の3つの段階を語れる人がどのぐらいいるのだろうか。

1. 分析
2. 観察 (目に見えるものをみる)
3. 洞察 (目に見えないもの = 心理を読む)
4. 判断
5. 記憶

今思うのは、小さいことを重ねることが、とんでもないところに行くただ一つの道だと感じている。

これはイチローのコメントだが、この言葉は野村監督の野球観に通じていて感銘を受けたと書いてあった。そんな風に野村ノートがおもしろかったので、その延長上で野村監督に関するイベントなら参加してみようと思った次第。

実際のイベントについては、期待値も高かったのかもしれないが、私の求めていたイベントの内容ではなかった。野村監督と付き合いの長い番記者が野球人としての野村監督というよりも、一般人としての野村監督の在り方を伝えるような著書やそのイベント内容だったと思う。あと野村監督の話しを聞きに行ったのだけど、半分以上は講師が自分のことを多く話すのでその点もアンマッチだったと言える。上司道のイベントは2回目なんだけど、これまでどちらも私の求めていたものではなかった。もしかしたらマネジメントやリーダーシップのイベントで話すのはなかなか難しいのかもしれない。それはいろんな業界・業種の人たちにとって参考になるリーダーシップのようなものはないのかもしれないなと感じた。ドメイン知識も含めてのリーダーシップの話しをしないと、宗教のような徳を積んで治めなさいといったありがたい話しの一般化になってしまう気がする。

人間力は定性的なもので言語化が難しい。それよりも実践知はもう少しスキル寄りなものだと私は考えていて、習慣だったり洞察だったりなら誰でも訓練すれば身につけられるのではないかと思う。少なくとも野村ノートからはそういった片鱗が私には読み取れた。

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

仕様は誰が決めるのか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Tetsuya Morimoto (@t2y) January 6, 2022

1時に寝て6時半に起きた。久しぶりに起きずに長時間眠れた気がする。1-2ヶ月に1回あるかどうかぐらいの感覚。

リファクタリング

ここ最近、私がバックエンドのリファクタリングを集中的にやっている。私からみたらバックエンドの設計にはいくつか改善の余地がある。動いているという視点では及第点ではあるし、メンバーは限られた時間の中で十分にうまく開発していると考えている。それでも、遊撃として余裕があるときにリファクタリングをしている。これから運用レベルの QA テストに入っていく。その前にがーっとリファクタリングしておくとテストで振る舞いを検証できるし、テストで別の不具合をみつけたときも保守コストが下がるように設計を洗練させておくことには一考の価値がある。実際にコードを書き始めると時間をどんどん取られて、マネジメントの業務から離れていってしまう。マネージャーがコードに集中し過ぎるのも問題だというのも理解できるようになってきた。本来はあまり深入りしない程度にメンバーに要点を伝えて改善したもらうのが正しいとは思う。いろいろプロジェクトの都合があるので必ずしも思い描いたようにはいかない。バランスをとってうまくやりたい。

余暇と経営と個人

1月以降は実家の法事のために私の余暇の半分程度の時間を取られている。先週末に49日を終えたので次の法事は初盆まで余裕がある。とはいえ、弁護士さんと実家と相続のやり取りがあってまだ何割か時間を取られている。この余暇の時間に、これまでは自社の業務や事務手続きをしている。その余暇が少なくなると、最終的には他のところにも皺寄せがいく。余暇に余裕がないと自分の会社を経営するのはなかなかしんどいところもあるかもしれない。

来季は実家の一部を自社のオフィスにしようと考えている。よくよく考えれば、神戸のオフィスでフルリモートワークをするのも、淡路島のオフィスでフルリモートワークをするのも、お客さんからみたら全く違いがない。いままでそうしてこなかったのは、神戸のオフィスでは業務に集中できるよう、私にとって最適な環境を構築し続けているからと言える。最も大きな違いは椅子だと思う。よい椅子でデスクワークしていると、あまり粗末な椅子でデスクワークしたくないというネガティブなモチベーションになってしまう。

メインオフィスと同じとはいかなくても準ずる程度のオフィス環境を実家に構築できれば実家に帰って1-2週間程度のフルリモートワークをしてもよいと考えている。その延長上で実家との行き来を出張扱いにして経費を使えるようにし、経営的にはそうすることで節税にもつながる。私個人の視点からも、親の介護という、私の人生設計上避けられない問題に対する解決策となる。個人の人生の問題と会社の経営を両立させることは、自分の会社であれば、十分に両立できると自信をもって言える。この話しも田舎から上京してその後のキャリアを考える上でのモデルケースの1つとして、いつかブログの記事として書きたい。

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 におけるメンバーの教育にもうまくいっているように聞こえた。メンバー間で質問し合うのを促していて、質問者と回答者の双方の理解度をあげることを狙いとしている。質問が現状をふりかえるよいきっかけになっているとのこと。

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

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

0時に寝て6時半に起きた。2時か3時頃に急に咳込んで飛び起きてコロナ感染したんじゃないかと危惧したけど、5分ほどしたら治ってその後もなんともなくなった。よくあるたまに吐き気がして起きるときの咳き込むバージョンだったのかな。たぶん胃食道逆流症のせいだと思うけど、慢性化しつつあるので余裕のあるときに病院でみてもらった方がよいかもしれない。

rabbitmq の exchange/queue の初期化

docker compose で環境構築をするときに rabbitmq の exchange/queue の設定を初期化したい。調べてみると Schema Definition Export and Import という仕組みを使うのがよさそうにみえた。推奨方法としては rabbitmq クラスターが起動した後、管理ツールで definitions.json をインポートするのがよいとある。別のやり方として設定ファイルに definitions.json へのパスを記述しておくと、rabbitmq プロセスの起動時にインポートしてくれるという。このやり方だとプロセスの再起動時にも毎回インポート処理が実行されるので初期設定の定義が大きくなるほど起動処理のオーバーヘッドが大きくなるというデメリットがある。またクラスター環境だと、それぞれのノードでの起動時に同じインポート処理が実行されることになるのでそのオーバーヘッドの分だけ効率が悪い。いま作っている環境はオンプレ向けの1つの rabbitmq サーバーのみだし、初期設定の定義もシンプルなので起動時のオーバーヘッドはとくに気にしなくてよいだろうと考えている。

definitions.json は、あらかじめ rabbitmq の exchange/queue の設定を手動設定した後、管理 API を呼び出して取得したものをベースに不要な設定を取り除くと生成できる。

$ curl -s -u "guest:guest" -X GET http://localhost:15672/api/definitions | jq .

ビッグテックのマネジメント勉強会

出張前の事前に資料作り しておいた勉強会を開催した。出席者の大半はリモートから参加しており、オフィスの会議室では私と他に1人だけだった。毎月1回、私がオフィスに出社するタイミングで質疑応答しやすいように課題管理勉強会を設けているのだけど、最早私がその場にいる必要性もなくなってきた雰囲気はある。リモートワークが定着している会社であり、私自身フルリモートで働けるよう、自分の働き方をリモートワーク向けに調整しているから当然の帰結とも言える。

勉強会の内容は基本的にブログ記事の内容を紹介するものだったので文字数が多くて口頭で説明するのが大変だった。勉強会の中でもっとも盛り上がった議論は自律性というキーワードを得るのに必要なものはなにか？といったもの。ある人はその人の性格や才能といった先天的なものではないかという。私はそう思いたくなくて、プログラミングは後天的なスキルなので開発者が自律性をもつかどうかも後天的なスキルだとみなしたい。そこに環境や組織やライフステージの変化なども関連して自律性をもつ開発者とそうじゃない開発者に分かれていく。もっと言うと自律性は優秀さとも異なる。頭がよくて理解力の高い人が自律性をもたないことも多くある。これは永遠のテーマだと思う。

もう1つ盛り上がった議論として優秀でも成果を出せない人がいるという話し。私も前職で何人もみてきた。頭もよく話すと正しいことを言っていてやることも理解しているように聞こえるのにほとんど動くモノを出せない人たちもいる。プライドが高くて途中段階の成果物を他人にみせられない結果として成果をあげられないのではないかという意見もあった。そういうのはどちらかという年配の人に多い傾向がある気がするけれど、若い人たちでもそういう病にかかってしまうこともあるのだろうか。

前日は週の中日でバテ気味だったから20時ぐらいから横になって途中起きつつ7時に起きた。体力回復した。

プロジェクトの進捗報告

月例報告の2回目。前回の進捗報告はこちら 。12月でバックエンド開発をすべて完了できたわけではないが、十分な開発の成果は出ていて、私が品質面から issue を作ってやいやい刺激を与えているのも着実に fix してくれているので及第点は余裕で超えている。遅れているのではなく、見積もりが甘くて量を増やした分すべて終えられなかっただけと捉えている。メンバーも自分から issue を作ってリファクタリングするようにもなりつつあり、先月よりも開発のワークフローに馴染んで洗練してきているようにみえる。これは時間とともに一定量はパフォーマンスが上がるので来月ももう少し上がるかもしれない。

私が日常的に行っている課題管理も好評で他部署でも参考になっているという話題もあった。私は issue のタスクをこなしながら、調べたこと・実際に動かして検証したこと・エラーになったこと・思ったこと・わからなかいことなど、何でもコメントとして書いていく。ざっと過去の私が担当した issue を眺めると1つ辺り10-50個ぐらいのコメントをしている (メンバーからのコメントも含む) 。コメントでやっていることをみえるのがよいという意見もあった。プロジェクト内の情報共有や非同期コミュニケーションを活性化する上で課題管理システムの issue にコメントを書いていくのは優れたプラクティスだと私は考えている。課題管理をやったことがない組織やチームのメンバーはだいたいコメントを書いていなくて、私が見本をみせてその価値に気付く。その価値に気付いたメンバーが模倣してやることでさらに情報共有が促進されて課題管理がよくなっていく。自律的にできるメンバーは放っておいてよいが、これから先はそれをうまくできないメンバーに対して指導していく必要がある。一方でこれは相当に難しくて、ここがうちの会社のビジネスや私のマネージャーとしてのキャリアで乗り越えないといけない壁になる。

納期までの期間のうち、いま1/3が過ぎた。私の中ではこのプロジェクトマネジメントはもう見通しが立ってしまった。バックエンドの開発がほぼ完了していることからコア機能の開発をほぼ終えた。これから開発するフロントエンドは未経験だけど、コアではないのでそれほど難易度は高くないと考えている。中核となるメンバーが開発ワークフローに習熟してきて自律的に開発してくれている。油断したりさぼったりしない限りは確実に納期までに満たすべき品質基準は達成できるだろう。納期まで残りの2/3の期間で私がやっていくことは、どれだけ品質を向上できるか、次のロードマップ開発向けに準備できるか、メンバーの成長のために知識やスキルを共有できるかといったことに注力していく。

23時に寝て何度か起きて7時に起きた。朝から近況報告のための資料を作ってた。

プロジェクトの進捗報告

お手伝い先の経営者の方々と、この1ヶ月で私がやったこと、開発の進捗、今後の展望などを打ち合わせした。組織のことも業務のこともわかっていないマネージャーがやってきて開発プロジェクトを仕切ることになったのが1ヶ月前。そんな簡単に成果を出せるわけがないがないと考えているため、私の所感としてはぎりぎりの及第点といったところかな。開発体制を構築し、4つのイテレーションから成る1ヶ月というマイルストーンを設け、その最初のサイクルがまわって、メンバーもどういった働き方を私が求めているか理解できたと思う。毎週の勉強会を設けて知識やスキルをチームで共有することの大切さも啓蒙している。嬉しいことにチーム外からも参加者がいる。ここからはこのワークフローを最適化していくだけ。その下地を作った1ヶ月だった。先方からも開発のプロがやるマネジメントから学ぶことも多いといったコメントをもらえた。1on1 も節目のタイミングでしかやっていなかったらしく毎週1on1をやっているのはよさそうといった話題も出た。一方で目標としている時期にこのプロダクトは何ができるのかわからないから次回はそれを明確にしてほしいといった要望もいただいた。この1ヶ月の私の課題として対応していきたい。

2時に寝て5時に起きて7時に起きた。いろいろ余裕ない。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

• フロントエンド勉強会のアウトラインの摺り合わせ
• ふりかえりワークショップの記事の共有

フロントエンドの開発は monorepo が主流といった話題になって本来の monorepo はビッグテックが全社レベルで展開している巨大リポジトリのことを指していたんじゃないかという話しになった。どちらが正しいという話しでもない気はするけど、プロダクトやサービスレベルの monorepo と開発者が数万人いるような会社で開発しているものを1つのリポジトリにすべて管理する monorepo では、議論していて噛み合わないと確認した。どちらも monorepo と呼ぶからどちらかの名前を変えるべきなのかもしれない。そう言えば facebook が自社のソースコード管理システムを oss で公開していたニュースを最近みかけていた。

• Sapling: Source control that’s user-friendly and scalable

11月のマイルストーンをほぼ終えた

開発スケジュールの期間を表す単位を次の3つの用語で管理する。

• 1週間を1つのイテレーション
• 4イテレーションを1つのマイルストーン
• マイルストーンを複数集めたものを1つのロードマップ

11月のマイルストーンの締め切り日を11月29日としている。あと月曜日だけなので11月のマイルストーンをほぼ終えたと言える。このマイルストーンの目的は要件定義を確定させることに置いていた。というのは、開発体制が大きく変わり、新規参加者が私も含めて3人いる。前任者からの引き継ぎ、開発対象の再定義など、曖昧な要件の部分を私がすべて洗い出して初期の開発目標の言語化を狙いとしていた。概ね狙い通りには進捗して可もなく不可もなくという認識。プロジェクトのキックオフの初月としては十分とみなすこともできる。

開発メンバーが課題管理システム (gitlab) に慣れていて、私の指示や意図をすぐに把握して行動してくれているので課題管理はとてもやりやすい。前月に手伝っていた sier の開発者とは格段にレベルが違う。大雑把に言えば、開発メンバーが優秀だからちゃんとマネジメントすれば成果を出せる見通しが立っている。

Go Test Comments の学び直し

Go Code Review Comments の勉強会 を前半・後半の2週にわけて読み終えたのでその次に Go Test Comments を読んだ。ちょうど Gopher塾のテスト会 に参加した後だったのもあり、書いてある内容のいくつかは重複していて、記憶に新しかった。開発メンバーがいま書いている単体テストに有効なアドバイスもいくつかあって参考にになったように思う。wiki に書いてあることにすべて従う必要はないものの、簡単にできて役に立ちそうなものはどんどん導入すればよいと私は考えている。