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週間遅れたことに今回は気付けた。結果論ではあるが、厳しい判断をもう少し早めに下さないといけなかった。

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

0時に寝て4時に起きて6時に起きた。本当はもっと早く起きて勉強会の資料作りやろうと思っていたけど、疲れと寒さでうまく起きれない。高速バスよりはずっと楽だけど、それでも土日に実家帰ってくると疲れが溜まる。次の週の週末になると蓄積度が違う。

隔週の雑談

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

• フロントエンドの技術選定のふりかえり
• プロジェクトマネジメントの話し
• ハドルと雑談の話し

年末にはらさん主催の忘年会に参加した。参加者は10人前後いたと思う。そのときにはらさんが「会社でオンライン飲み会やっても盛り上がらない？」といった話題があった。その意見には私も同意でおそらく参加者が5人以上いるとオンライン飲み会は盛り上がらない。オンライン飲み会の難しさは1つの部屋だとせいぜい3-4人ぐらいでないと話せない。1つの部屋に10人とかいると、実質話しているのは3人ぐらいで残りのメンバーは聞いているだけになる。それが盛り上がらない要因だと思う。オフラインの飲み会なら、例えば4人テーブルに3グループに分かれて、それぞれのグループが3つの会話が成立するから盛り上がる。そして、隣の会話が薄く聞こえたり、ちょっと休むときに隣のグループの会話に混じったりもできる。これと同じことをオンラインでもチャンネルを分けてやればよいというのは理屈の上で正しい。しかし、オンラインで能動的に別のチャンネルに入り直すのは複数の意味で障壁が高い。まずツールの操作が分かりにくいし、幹事が仕切るわけでもないので運用ルールも曖昧。仮に幹事がいても仕切れるのは1つのチャンネルだけで、他のチャンネルが意図した運用をしているかどうか、チャンネルを出たり入ったりしないと監視するのが難しい。オフラインの飲み会に近い状態にするのは、オンラインミーティングツール側で自動的にうまいこと配慮しないといけないのではないかといった話を、はらさんとしていた。

はんなりPodcast

はんなりプログラミング のコミュニティが はんなりPodcast（仮） を始めたらしい。私もちょくちょくはんなりさんのイベントに参加するので運営の方々とも懇意にさせていただいている。たまたまゲストで呼んでいただいた。感謝。内容はまた公開されてから書くので今日は収録の雰囲気だけ書いておく。かいせんさんとおがわさんとは、オンライン上でもよくやり取りしているので気軽に話すことができた。逆に私が調子に乗り過ぎて内容とは逸脱したことや自分の話したいことをわーっと話し過ぎてしまったのではないかという反省もあとになって思う。いま1人で働いているからこうやって自分の話しを聞いてくれる機会というのは貴重でそれはそれで楽しかった。ついつい自分の話しばかりし過ぎないように注意しないといけない。

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

ハドルと雑談

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

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

遊撃の開発

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

1時に寝て2時、3時、6時と起きて7時に起きた。久しぶりに胃酸が逆流して気分悪かった。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。sveltekit アプリで使う ui フレームワークの相談をして、昨日の課題管理の雑談内容 からさらに考察を深めた。私の中では知っていたことだったはずなのに、いつの間にか、そのことを軽視してしまっていることを再認識したような発見だった。

コミュ障の私にとってはペアワークという概念がすっぽり抜けていたことは昨日書いた通りだが、それでもいまマネージャーとしてそれなりにコードレビューやインフラタスクに時間を割いている。プロジェクトマネジメントだけをやっているわけではない。それは自分が遊撃として開発者のメンバーを手伝っていることに相当するなと気付いて、そう言えば、過去に五月雨式にだらだらと遅れるようなプロジェクトでは、他のメンバーのタスクが遅れることを横からみているだけしかやってなかったような気がした。もし私が自分のタスクを投げ出して遅れている課題に介入したらどうなっただろうか？と思考実験するだけの余地はあった。

もう1つ。盛り上がった話しにおっさんはエモい話しをしにくいと私が考えていると伝えた。なぜなら、私の経験則ではエモい話しをするおっさんは総じてスキルをもっていなかった。具体的な知識やプラクティスを話すときはエモい話にならないからだ。その発言に対して、はらさんからはこんなコメントが返ってきた。おっさんもスキルはあるのだけど、そのスキルが時代にあわなくなって古くなってしまった。現場の技術とあわないスキルは、現場の人間からみるとスキルがない人と同じである。少し前に40歳の壁という本を読んだが、そのノリで言うと、40歳になるとスキルが現場に通じなくなる。

いまマネージャーをしていて気付かないうちに遊撃というポジションをこなしているのではないかと思うようになってきた。原則として実務をやらず、プロジェクトマネジメントをしている。とはいえ、コードレビューには2-3日／週ぐらいの工数を割いてきた。

— Tetsuya Morimoto (@t2y) January 21, 2023

sveltekit アプリのデプロイ

昨日の続き。Building your app によると、sveltekit のビルドは vite と adapter の2段階で行われる。gitlab ci/cd で node.js 向けにビルドして、それを docker イメージに同梱して、コンテナレジストリに登録する。あとはテスト環境で構築している docker compose に組み込むだけ。今日中にできたらいいなと思って、ぎりぎりだったけど、テスト環境で node.js 上にデプロイしたアプリと疎通できるところまでできた。ssr を介して web api サーバーと疎通できるところまで整備した。ここから先はメンバーに管理画面を作っていってもらう。メンバーの開発着手前にデプロイが一通りできているという気持ちよさ。

起業相談

過去に働いていた会社の、私と同い年の元同僚が起業するというので相談にのることに。私が会社を作ってなんとかやっているのをみて関心が出てきたという。いきなり会社を辞めると不安だから副業から始めて、本業の収入を上回るようになったから個人事業主から法人化しようと考えているらしい。実際に会社を辞めるかどうかはまだこれから検討するのかな？本業をやりながら最大4つか5つの副業をまわしてたというから驚き。そんなこと物理的に可能なの？と思ったら開発は人を雇ってマネジメントだけやったりしていたらしい。おそらく4人ぐらい開発者を雇っているという雰囲気だったけど、それでも本業をやりながら4つもマネジメントをするのは相当に大変だと思う。十分にその同僚の能力を認めているつもりだったけれど、それ以上の忍耐や集中力をもっていて、もしかしたら過小評価していたのかもしれない。1つの会社内でも3つ以上プロジェクトを兼任して成果を出しているマネージャーなんか私は見たことない。それを本業と副業と寄せ集めの開発者で実現しているのは類稀な能力だと思う。本人も睡眠時間削って働いてやり過ぎたとは言っていたが。法人登記、税金、節税、働き方とか、ざっくばらんに私が起業してやってきた3年間のお話しをした。なにかしら役に立って活躍されるといいな。

22時から寝て2時に起きて5時に起きて7時に起きた。久しぶりに吐き気もなくよく眠れた。

雑多な整理

本当はやりかけて途中の svelte 入門をしようとオフィスに来たものの、課題管理システムの整理や週明け2日間のお仕事の準備などをやっていた。あと毎年そうなんだけど、うちの会社は交際費として年間で30万円の予算を計上している。現時点で7万円しか使っていない。放っておくと私は交際費を使わない。交際費を使わないというのは情報収集を疎かにしていると同義である。これから3ヶ月かけて交際費を使いつつオンラインで雑談してくれる人を探していく。この調整作業そのものにも時間と意識をとられる。人とやり取りして予定を調整する作業だけは効率化できない。過去に話したことのある人が徐々に増えていくと、また毎年のアレやりましょうと言えるのでコミュニケーションコストは下がっていく。一方で新しい人とも話していかないと視野が狭くなっていくのでバランスをとっていく必要がある。

忘年会のお酒選び

カフーツさんの忘年会 へ参加するときにもっていく飲みものを探してきた。ビールは用意してあるということなので灘五郷の日本酒をもっていくことにした。以前 灘五郷酒所 へ行ったときに飲んだ琥泉というお酒がおいしかったからそれを購入しようと調べていたら、同じ 泉酒造 では仙介という有名なお酒もある。実は2019年に近所の公園で灘の酒フェスティバルをやっていてそのときに仙介を飲んでおいしかったと記憶に残っていた。仙介は山田錦を100%使っていて琥泉が国産米となっていてこの素材の差が主な価格差 (720mlで2,050円と1,500円) になっていると推測される。イベントにもっていくならブランディング的に上等な方がよいかなと考えて仙介を忘年会に、琥泉を実家へもって帰ることにした。それぞれ次のお酒を購入した。どちらも生酒を選んだ。

• 琥泉 純米吟醸おりがらみ無濾過生酒原酒
• 仙介 純米大吟醸無濾過生酒原酒

おりがらみ とは、にごり酒の一種とみなすこともできるそうで「おり」と呼ばれる、米のかけらや酵母などの細かな固形物を少し残した日本酒を言うらしい。それによる風味の違いを楽しむといったものにみえる。たまたま灘五郷酒所で飲んだのがおりがらみだったので同じものを選択してみた。

初夏に 開発合宿 (ワーケーション) へ行く前のレンタカー運転リハーサル で 白鶴酒造資料館 へ行ったときにお土産に Hakutsuru Blanc を購入した。そのときにいくらか飲んでその後ずっと冷蔵庫に残っていたお酒を飲み終えた。灘五郷を学ぶよい機会だと思うのでこれから飲んだ灘五郷の酒造のお酒を課題管理してそれぞれの特徴や所感を溜めていこうと思う。

エピック名は BE KOBE にした。なんかうまくはまった。

0時に寝て何度か起きて7時に起きた。だいぶ眠れるようになってきた。

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。来年やりたいことというテーマだった。来年の抱負というほど堅苦しいわけではないが、それぞれの参加者別にやりたいことをわーっと話すようなイベントだった。私は課題管理について軽く話し始めたらいとうさんが深堀りしてくれて、参加者からも共感を得られてそれなりに盛り上がった。自分が参加したイベントの録画を見返すことを私は滅多にしないのだけど、今回は話した内容を整理するために見返した。

課題管理という分野の体系化、ならびにプラクティスの整備をしたい

ざっくり話した内容はこんな感じ。

• 課題管理を追求していくにはメンバーに強制・指示できるだけの権限が必要となる

  • ボトムアップで課題管理を実践するのは難しい
  • 課題管理の実践のために人の運用を変えないといけない場面が出てくる

• 私は it 業界のプロダクト開発における課題管理のノウハウしかない

  • 複数の組織・チームで働く過程で課題管理ができていない、または課題管理システムを使いこなせていない開発者やチームがたくさんあることを知ったのが背景になる

• 本質的には、課題管理自体は業界・業種を問わない分野だと思うので広く応用できるプラクティスとして体系化したい

• 課題管理とは、ハウツー本を読んだり、ツールを導入すれば解決する類のものではない

  • それぞれの目的のためにメンバーが日々の業務において運用していく必要がある
  • メンバー全員が運用しなかったら効果もその度合いに応じて減っていく
    • 権限が必要というのは、やらない人に対してある程度はやってもらう必要があるから

• 課題管理をうまくやろうとすると、組織論や組織の文化、マネジメントの分野とも密接に紐づく

• 課題管理と密接な分野の1つに情報共有がある

  • 情報の一元管理は組織において重要なのに疎かになっている組織やチームは多い
    • 一元管理できると情報共有のためのコミュニケーションコストを削減できる
    • このためには組織レベルで使うツールや情報共有のやり方を統一しないといけない
      • 自分の好きなツールを使って自由に情報共有するといったものをいくらか制限する必要がある

• 課題管理において重要なことの1つに文章を書けない人たちが一定数いることを受け入れないといけない

  • 情報共有の文脈で言えば、テキスト化は検索できるという大きなメリットをもたらす
  • 一定数の文章を書けない人たちをどう対応するかは難しい課題の1つ
    • 文章を書くための練習をすればよいのではないか
      • 新人やキャリアの浅いメンバーには有効となる
    • 文章を書かなくても情報共有できる手段と組み合わせるとよいのではないか
      • it 業界ではスクラム開発という開発方法論が流行っている
        • 大雑把に言えば、対話を重視して会議をたくさん設けることで情報共有を密にする開発方法論と言える
          • 文章を書けない人であっても話せない人はほぼいない
          • 対話を促されれば話すことで情報共有できる
        • デメリットとしてはコミュニケーションコストがとても高い
          • このコミュニケーションコストは開発における生産性とトレードオフになる

• 課題管理において重要なことのもう1つに文章を読めない人たちも一定数いる

  • 日本人の1/3は日本語が読めない？PIAAC (国際成人力調査) の調査結果
  • 文章を書いてメンバーに読んでおいてと伝えても1/3は理解できていない可能性を示唆している
    • 情報共有において文章を書いても伝わっていない可能性を考慮して対策する必要がある

• 仮に情報共有できていない状態でメンバー「わからない」と言えることはすごく重要になる

  • この文脈で心理的安全性が重要になる
  • 「わからない」と声をあげてくれることで文章や伝え方を改善していける可能性がある

• 実は一昔前と比べて、いまの方がメンバー間の情報共有を疎遠にしている背景がある

  • いまは情報共有にクラウドサービスを使う組織が増えている
    • 基本的にクラウドサービスはユーザー単位/従量制で課金される
      • あまりサービスを使わないユーザーアカウントを減らすことでコストダウンできるインセンティブが働く
        • 情報共有という視点からコストダウンしてはいけないコストを削ってしまっている
          • 例) 課題管理システムのアカウントは開発者しかもっていないとか
    • 中小規模の会社ほどクラウドサービスを多用するのでこの傾向がある
  • 昔はオンプレで社内システムを管理していたため、システムのユーザーを減らすインセンティブはなかった
    • 要否に関わらず、社員は全員アカウントをもっていることが当たり前だった
  • 念のため、クラウドサービスのアカウントをメンバー全員がもつことは目的ではない
    • アカウントをもった上でそのメンバーがそのサービスを使うように運用を変えていく必要がある
    • システム投資とメンバーの運用を変える取り組みがセットでないとうまくいかない

• コワーキングスペースは課題が持ち込まれるところではある

  • 課題管理のプラクティスが応用できるなら使いたい
  • 課題をどう整理して、優先順位を付け、情報共有していくかは難しい
  • 様々なメンバー、様々なツール、様々な課題を同じツールで一元管理することは非常に難しい
    • どうやって情報の一元管理をするかはコワーキングスペースの運営において難しい課題でもある
      • 複数のサービスを連携するサービスなどを使って一元管理する方法もある
    • 海外ではコワーキングスペース向けの sns も含めたプラットフォームサービスなども出始めている
      • 日本ではまだまだあまりシステム化されておらず、導入もされていないのではないか

• コワーキングの分野では女性がとても活躍しているように、いとうさんから見えている

  • 今後もこの分野を盛り上げていくのは女性ではないか？
    • 男性は変なプライドが邪魔して行動力を抑制してしまうところがあるのではないか
    • 女性は損得勘定から行動力を発揮しているのではないか
      • 男性の方が感情的な動機でコワーキングをしているようにみえる？

• コワーキングに課題管理の理論やシステム化はあってよいのではないかと、いとうさんはみている