Posts for: #Information Exchange

情報共有とメンバー課金の過ち

1時に寝て4時に起きて5時に起きて7時に起きた。明け方からうまく眠れなくなった。

clang の互換性

openldap 2.5 向けに ldap の overlay モジュールのビルド環境を作っていた。これまでは 2.4 向けのモジュールのみを提供していた。2.5 もそろそろやろうということで先週末からビルド環境の構築に着手していた。rpm のパッケージングの作業をしていて、openldap 2.5 のサーバーのビルドをしていると次のエラーが発生した。

configure:21011: checking for pthread_detach with <pthread.h>
configure:21033: clang -o conftest -O2 -g3 -fstack-protector -fPIE -D_REENTRANT -D_THREAD_SAFE -DOPENLDAP_FD_SETSIZE=16384 -DLDAP_CONNECTIONLESS -DSLAPD_META_CLIENT_PR -D_GNU_SOURCE -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  conftest.c    >&5
clang-15: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' [-Wunused-command-line-argument]
clang-15: warning: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' [-Wunused-command-line-argument]
conftest.c:118:16: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'pthread_t' (aka 'unsigned long') [-Wint-conversion]
pthread_detach(NULL);
               ^~~~
/usr/lib64/clang/15.0.7/include/stddef.h:89:16: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
               ^~~~~~~~~~
/usr/include/pthread.h:269:38: note: passing argument to parameter '__th' here
extern int pthread_detach (pthread_t __th) __THROW;
                                     ^
1 error generated.

エラーメッセージを調べていると、どうやら clang 15 に pthread_detach がないといったものらしい。clang 14 のときはビルドできたという。他の oss でも clang のバージョン違いでビルドできないといったことは発生しているらしい。有識者によると、次の修正が clang15 対応らしい。

それ以外はとくに問題なく、ビルドできてモジュールそのものの動作も確認した。あとは rpm のパッケージングと gitlab ci/cd でビルドしたモジュールで動くかどうかの検証だけ。

メンバー課金による過ち

昨日 SuperGoodMeetings をさわってみた ときにチーム管理の機能があって、任意のユーザーを招待するのは無制限で課金されないと書いてあった。「なるほどね。」とピンと来てコパイロツトの中の人に次のような所感を共有してみた。

招待可能ユーザー数を無制限にしているのはよい視点だと私は思います。メンバー課金にすると、経費を削減するために共有アカウントを利用したり、あまり使わない人にはアカウントを作らないようになって情報共有の側面から望ましくない状態になる。一昔前のオンプレ時代は業務に使うシステムのアカウントは全社員がもっていて当たり前だったのが、クラウドサービスを使うようになってメンバー課金の経費削減から全社員がもたないようになりつつある (とくに中小企業) のは、情報共有の視点から過去よりも悪化しているという問題意識を私はもっています。

コパイロツトさんもまったく同じ課題意識をもっていてメンバー課金しない料金体系にしているとのこと。鶏と卵みたいな話しだけど、組織には情報共有のためにアカウントのお金をケチんなと言いたいし、クラウドサービスの会社も料金体系を1人ずつじゃなくて、30人、100人、1000人といったある程度の階段でいいんじゃない?とか思ったりする。メンバー課金じゃないクラウドサービスとして basecamp や backlog などがある。

メリハリの付け直し

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. メンバーが自由に雑談

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

合間の遊撃

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

遊撃の開発

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

sveltekit の ssr を理解した

2時に寝て7時に起きた。キングダムの新刊を読みながら寝てた。

sveltekit の初期プロジェクト

技術選定で svelte を採用した ので昨日から SvelteKit でアプリケーション開発に着手した。Project structure にもだいぶ慣れてきた。開発初期はディレクトリ構成に迷うのでドキュメントに標準的な階層構造を書いてくれているのは素晴らしい。Routing もキモいけど、ssr の場合は +page.svelte+page.server.ts を設けるのに慣れてきた。ssr で proxy 的に web api 呼び出しも簡単に実装した。知らないフレームワークで開発するのは学ぶところが多くて楽しい。区切りのよいところで初期開発の issue はクローズして明日は gitlab ci/cd でテスト環境にデプロイするのをやってみる。

課題管理の雑談

過去に働いていた会社の同僚と課題管理について雑談した。web3 系の会社で働いているのでブロックチェーンや dao 周りの話しも一緒にしたりしていた。一回りぐらい私より若いと思うけれど、私よりはるかに優秀な開発者だなぁと感じながら話しを聞いていた。いま一緒に働いても足手まといになるんじゃないかと思えて身が引き締まる。いくつか話題の中で学んだことを抜き出してみる。

  • 自分の知識やスキルを共有する手段の1つとしてペアワークをやる
    • ペアワークを通してメンバーとの信頼関係も構築していく
    • いまもっている知識やスキルには個人差はあるが、模倣の能力が低い人をみたことがない
  • 上位の意思決定者から低いレベルにあわせる (標準化など) ように指示がきたときは反発する
    • ユーザーファーストが第一ならレベルを下げるような指示はおかしい
    • 「誰を向いて仕事しているの?」と説得する
  • プロジェクトにおいて目的を明確化せずに始めてしまうのは本当によくない
    • 日本人は上意下達で行動するように教育されてきた弊害ではないか
    • 目的を明確化するのは意見を言うことと同じである
      • レイヤーが上がるほどエモい話しになって人生観や哲学の話しになっていく
      • チームのモチベーションを維持する上でも有効ではないか

私はコミュ障だから他人と一緒に作業しようという発想がそもそもなかった。こちらから一緒にやろうと声をかけて知識やスキルを共有する手段もあるのかと気付いた。これまでも何人もの人にいろんな話しを伺っている。他人のノウハウを聞くだけでもこの雑談をすることに意味はあると思えた。

出張前日の準備

1時に寝て8時に起きた。午前中は洗濯して普通にだらだらしてた。

課題管理勉強会の資料作り

12月から読み始めた Gergely Orosz 氏の記事 をベースに来週の勉強会の資料を作った。もう少し推敲はするが、スライドで全32枚になった。ブログ記事の内容を解説するスライドなので文字が多い。1時間の枠には十分に耐えそう。この資料と前回の勉強会の資料の2つを知人とオンライン飲み会するときの話しのつまみに使う。毎月、課題管理の文脈で勉強会を行う労力はそこそこあるけれど、コンテンツが溜まっていくのは未来への投資になるので困ることは何もない。課題管理の勉強会があるという機会そのものに感謝する。

フリーランス、40歳の壁

フリーランス、40歳の壁 の中盤を読んだ。

  • 「第5章 田中圭一 サラリーマンとマンガ家を両立させる男。」
  • 「第6章 『電脳マヴォ』と私の未来。」
  • 「第7章 FROGMAN アニメ界の革命児が直面した「30歳の壁」。」

平日はサラリーマンで営業として働き、休日を利用してマンガを描くという働き方を30年以上している田中圭一さんのインタビューがある。30年以上と聞くとすごいことでその実績は否定しようがないと素直に思う。一方でうちは兼業農家だったので平日はサラリーマン、休日に農業をするのは普通だった。父はその生活を42年間していた。またうつ病になった経緯のエピソードがある。ある会社に転職して最初のうちはうまくいったが、5年目ぐらいで行き詰まってしまった。技術系の会社でプログラミングを学ばないといけないという空気があったらしい。会社の仕事があわないと田中氏は思いつつも転職する自信をもてず、そのまま10年いてうつ病になってしまったとのこと。これが3ヶ月だったら大変だったんだなと思う。しかし、厳しい言い方だけど、行き詰まりは仕方ないとしても5年もなにも対策しなかったの?と私なら思ってしまう。ここだけ読むと未知のことやスキル不足を勉強しない人の典型例だと思えてしまった。本業で成果を出せていないのに転職できないから会社に残り続ける人たちを私も少なからずみてきた。助言や提案をしても、例外なく、そういう人たちはできない理由を熱心に説明し、自ら努力してスキルを習得しようとはしなかった。できる・できない以前にやろうともしなかったのをみてきた。

著者が運営している 電脳マヴォ という web マンガのサイトがある。たまたまリンクをみつけた 良い祖母と孫の話 を読んでみたら衝撃をうけた。こういう才能がたくさん埋もれているというのは理解できる。一方で漫画を描くことが以前よりも一般化したのだとも私は思う。どんな業界も人気が出たり市場規模が大きくなるにつれその創作者人口は増える。電脳マヴォを創刊したのが2012年だったらしく、奇しくもその頃が「ネットマンガ元年」と呼べるらしい。となりのヤングジャンプマンガボックス など、私が知っている web マンガのサービスも出てくる。

フリーランスの最大の営業は、仕事そのものです。 版元編集者は、そのフリーが実際に行った仕事を見て、次の仕事を発注するのです。向こうから来る仕事であれば、意に沿わない仕事は、断ることもできます。持ち込みだと、まさかこちらから断るわけにはいきません。

この考え方は私も同意する。取り引きをしている会社とのお仕事を高い品質で行うことがもっとも重要だと私も考えている。

FROGMAN さんという方を私はまったく知らなかったけれど、インターネットの黎明期 (2000年頃) に動画配信サービスをやろうとして FLASH アニメで一山当てた実業家らしい。その経歴も破天荒にみえる。もともと映画業界で働いていて、映画業界の没落とともに半ば強制的にフリーランス (リストラ) となり、業界としての先行きは不透明だった。島根の山奥に移住し、インターネットに動画を配信する仕事なら島根でもできるだろうと考えたとのこと。これを2000年頃に実施しているのだから素晴らしい先見性と言える。その延長でアニメ制作をするにいたったのも、奥さんが妊娠して出産費用が必要となり、1人で仕事を完遂できればコスト削減できるというアイディアでアニメ制作を始めたとのこと。実写は最低でも数人のスタッフを必要とするが、アニメなら1人でできるのではないか。実際に初期のインターネットの FLASH アニメを1人で作って人気を博して事業が軌道になったらしい。スポンサーを募らず、徹底したコスト意識から権利をスポンサーに渡さないことを意識していた。2006年頃に youtube が台頭したときも、他のアニメ会社が映像を勝手にあげられるのを嫌ったのに対して、FROGMAN さんの会社は自分たちが権利をもっているので自分たちの作品を率先して配信し、時流にも乗ったようにみえる。FROGMAN さんは絵もろくに描いたことがなく、アニメマニアでもないにも関わらず、まさにビジネスモデルの勝利と言える。また実写業界での経験があったから普通のアニメ会社が作るようなアニメとは異なる作品を作り、アニメ落語・アニメ漫才というジャンルそのものを作ってしまったという。きっかけは家賃を半年間滞納して出産費用を捻出するためという、ピンチをチャンスに変えた事例の1つとして、また製作委員会方式というアニメ業界のモデルとは異なるビジネスモデルを考案して実現してしまったところもサクセスストーリーとして痛快に読めた。

課題管理の話題で発散

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

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

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

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

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

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

    • ボトムアップで課題管理を実践するのは難しい
    • 課題管理の実践のために人の運用を変えないといけない場面が出てくる
  • 私は it 業界のプロダクト開発における課題管理のノウハウしかない

    • 複数の組織・チームで働く過程で課題管理ができていない、または課題管理システムを使いこなせていない開発者やチームがたくさんあることを知ったのが背景になる
  • 本質的には、課題管理自体は業界・業種を問わない分野だと思うので広く応用できるプラクティスとして体系化したい

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

    • それぞれの目的のためにメンバーが日々の業務において運用していく必要がある
    • メンバー全員が運用しなかったら効果もその度合いに応じて減っていく
      • 権限が必要というのは、やらない人に対してある程度はやってもらう必要があるから
  • 課題管理をうまくやろうとすると、組織論や組織の文化、マネジメントの分野とも密接に紐づく

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

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

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

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

    • この文脈で心理的安全性が重要になる
    • 「わからない」と声をあげてくれることで文章や伝え方を改善していける可能性がある
  • 実は一昔前と比べて、いまの方がメンバー間の情報共有を疎遠にしている背景がある

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

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

    • 今後もこの分野を盛り上げていくのは女性ではないか?
      • 男性は変なプライドが邪魔して行動力を抑制してしまうところがあるのではないか
      • 女性は損得勘定から行動力を発揮しているのではないか
        • 男性の方が感情的な動機でコワーキングをしているようにみえる?
  • コワーキングに課題管理の理論やシステム化はあってよいのではないかと、いとうさんはみている

仲の良いチーム

1時に寝て何度か起きて7時に起きた。起きてからも昨日の夜にやってた勉強会の資料作りをずっとやってた。

1on1 で設計談義

あるマージリクエストで私が nil ガードを実装した方がよいとコメントした。その意図がわからないという話になって nil ガードを実装する背景について、実際のコードをみながらメンバーに説明した。プログラミングの文脈では全然難しくないことではあるけど、あまり経験がない人にとってはその意図や考え方を学ぶのは難しいかもしれない。こういった、詳しい人に聞けばすぐ解決するけど、ググって調べるのは難しいこともある。1on1 のような身近に話す機会があると、定例会議でみんなの時間に話すほどの重要度ではない話題を聞くことができる。そこで聞いた意見をベースに私が issue 化したり、ある話題をチームで話し合う打ち合わせの機会を設けたりしている。

メンバーの送別会

私があるチームのマネージャーをして1ヶ月が経つ。メンバーの1人が退職することになった。実はマネージャーになって1週間後に転職が決まったという話しだった。いきなり開発体制がバタバタしたけれども、私からみたらやることは変わらないのでその影響は最小限に留められたのではないかと思う。いまのところ、当初の開発の計画にも変更をきたしていない。出張でオフィスに来ている機会なので私もそのメンバーの送別会に参加した。他の社員さんも20人ぐらい参加されていた。飲み会の雰囲気をみていて若い人が自由に発言して楽しんでいるのを傍から眺めてた。飲み会の雰囲気ってその組織の性格が出ておもしろいと思う。イヤな人がいないのは組織において重要になる。後日、経営者の方々とそういう会話をしていたら小さい会社はみんな仲良くできるといった話しをされていた。たしかにそれぞれのメンバーの顔とやっていることを見渡せる規模だから親近感を抱きやすいと言えるかもしれない。ここ数年どこへ手伝いに行ってもよい雰囲気をもつ会社は多い。変な言い方だけど、よい世の中になったと思えて嬉しい。

出張の最終日

出張の最終日

0時に寝て7時に起きた。疲れているせいか、よく眠れたと思う。わりと出張でよく眠れているので普段眠れていなかったのは体力が余っているからではないかという気もしてきた。

課題の洗い出し

一昨日の続きでわかっていることや進捗のあったものを確認しながら、追加で課題を作って整理していく。まだまだ課題が足りないのでどんどん作っていかないといけない。それと同時に go のソースコードを読みながら設計や改善の要点を私の中で把握していく。java に慣れたプログラマーが書いた go のコードなので java の考え方の影響が強いようにみえた。私がいくつかアドバイスする余地はあるようにみえた。google でコードレビュー時によくある指摘事項をまとめた有名な wiki がある。メンバーに聞いたらちゃんと読んだことがないということだったので2-3回かけてみんなで読んで学ぶ機会にする。私自身、数年前に読んで忘れていていることも多いだろうから学び直し。テストのページは2019年9月に追加されている。たぶん読んだことない。

課題管理勉強会

1時間分ぐらいの資料を用意したつもりが35分で終わってしまった。勉強会の雰囲気が固かったのか、慣れない場所での説明だったのか、マスクした状態で長々と話すことも過去に一度もやったことなくて話しにくかった。初めての試みであまりうまくいかなかったが、初めてやることでうまくいかないのは私にとって当たり前のことなので次の勉強会に向けて改善していきたい。どのぐらい伝わったのかわからないけれど、もっと参加者を巻き込んだ活気のある勉強会になるように努めていきたい。

リアル飲み会

19時から3年ぶりに友だちとリアル飲み会。せっかく東京に行く機会だからと5日のうち3日飲んでいたので後半になるほどバテていった。これは加齢による体力低下もあるのだろう。娯楽はどういうものか?という定義や在り方の議論が盛り上がって、私は暇つぶしの時間であって何もしないのでぼーっとしているのも退屈だからその時間を埋めるもの、楽しければいいけど楽しくなくても、どうせ何もしない時間なのであまり気にしないといった考え方をしている。私の友だちは楽しむために娯楽に集中するとか、その時間を無駄にしないようになるべく楽しめる娯楽を選択するとか、24時間のうち、1時間足りとも無駄な時間にはしないぞという姿勢がみえて、私からみたらそんな生活はしんどくないですか?みたいな気持ちになった。おそらく時間を無駄にしたことがストレスになるからそういう姿勢になるのだろうと推測する。娯楽をしながらだらだら時間を過ごすということはないらしい。オンライン飲み会はちょくちょくしていたものの、3年ぶりにオフ会をしたので飲食代をご馳走になった。感謝。前も会社を作った後の飲み会でご馳走になっていて、なかなか私からお返しできていない。それを覚えておくためにもここに書いておく。

本棚に埋もれて眠る

この日は 新宿 BOOK AND BED TOKYO に泊まった。前に浅草の同施設に泊まったことはあったけれど新宿は初めて。大雑把に言えば本屋とカプセルホテルが合体したような施設になる。この非日常の雰囲気が好きなので機会があれば泊まるようにしている。宿泊費は6,000円とカプセルホテルより高くビジネスホテルより安いという価格帯。ここに来て本を読んだり泊まったりしている人はコワーキングスペースもしくはコミュニティ的なスペースが好きで本も好きな人たちだと思う。勉強会に行く感覚と似ている。そういう自分と似た人たちが集まる空間そのものが価値観の共有だったり安心感につながっていて私はそういう空気も楽しんでいたりする。とはいえ、バテバテで疲れていたので少しだけ本を読んでわりとすぐに寝た。

課題に対する意思決定

1時に寝て7時に起きた。ホテルのビッフェ形式の朝ご飯は2回目のなのでうまくプレートに盛り付けて段取りよく配膳できた。昨日より改善できた。

課題の意思決定と割り当て

プロジェクトの初期なのでとにかく段取りを早め早めに決めてタスクを洗い出し、メンバーが目標に向かって作業しやすい状況をマネージャーとして作り出さないといけない。昨日からプロジェクトのリポジトリ構成を変更しようというイシューを作ってメンバーと議論していた。当初は私がちゃちゃっと作業して移行しようと考えていたが、私の移行イメージを書き出していたらメンバーからいくつか背景や要望が出てきて、メンバー集めて打ち合わせして合意をとって決断することにした。私が入ってからプロジェクトでの初の意思決定かもしれない。

既存のソースを読んだらリポジトリ統合は少し工数がかかるとわかって、私がやるよりもメンバーの方がいいだろうと意思決定だけ私が判断して、実作業はメンバーに割り当てた。初めてのマネージャーっぽいお仕事をできたとちょっと自己満足。その議論の過程で monorepo vs polyrepo という比較記事を読んでみた。monorepo から polyrepo に切り出すのは容易だが、polyrepo から monorepo に統合するのは大変ということが書いてあって、まさにプロジェクトの状況と合致してメンバー間で認識合わせした。いま (過剰な) polyrepo で管理されているのを monorepo に統合しようという決断をした。これをやるのにコミット履歴を維持するのはコストがかかるのでソースファイルをコピーして新規ソースとして移行してよいという判断も下した。こういう意思決定は即断即決でやりたい。

1on1

マネージャーとして1on1を行う。プロジェクト初期は毎週やって、その後はメンバーの要望を聞きながら隔週でもよいと考えている。1on1 の目的ややり方は様々だが、私が提供できるのは次の3つに含まれることかなと思う。

  • モチベーションアップ
  • 業務・組織課題の改善
  • 能力開発/キャリア支援

初日から長時間の会議と懇親会などでチームのメンバーと話す機会が多かったので 1on1 もみんな気さくに話してくれてよかった。私はなるべく話さずに聞くことに専念しないといけない。私は圧倒的に自分の思ったことをがんがん話してしまう方なので他人の話を聞く姿勢を身につけるよい機会になると思う。今回は準備不足で雑談がメインではあったものの、1on1 の本なども読みながら勉強していこうと思う。

課題管理の取っ掛かり

0時に寝て6時過ぎに起きた。朝からシャワー浴びてホテルのビッフェ形式の朝ご飯食べてた。初めてのオペレーションだと段取りわからなくて朝ご飯さえうまく配膳できなかった。経験のないことは全然できない。

課題の洗い出し

お手伝い先のワークフローや段取りを学ぶ。毎週火曜日がプロジェクトの定例会議。火曜日の終わりに週報を書く。メールで週報を提出するという、いまどきの会社からみると古い会社の慣習にみえる。郷に入れば郷に従えということで私も同様に行う。課題管理で日々の活動をひたすら書いているので週報はいつでもすぐ書けるので私は全く苦にならない。

プロジェクトのリポジトリ構成の変更や課題の洗い出しなどをやっていた。イテレーションは週1でマイルストーンを4週間(月1)で設定して、その区切りでふりかえりなども実施していきたいと思う。コミュニケーションコストが高いことから、私は開発方法論としてスクラムを採用するつもりはない。あくまで自分がやってきた経験による課題管理 + イテレーション開発で製品開発のワークフローを構築したい。お手伝い先ではチームで課題を共有して開発に取り組むといったことはこれまでやってきていないものの、課題管理システムを使って開発者間でやり取りするのは普通にやっていたそうなのでイシューのコメントへの返信がめちゃくちゃ速い。イシュー上で議論していて私がこうしましょうとコメントを書いたら最も速いメンバーは5秒後にリアクションがつくぐらいの速さ。他のメンバーも数十分以内には返信がつくので課題管理システムを使うところのなにかを教える必要はない。課題管理が身に着くのに半年から1年間かかるというのは、他人のアクティビティを監視するという日々の運用 (行動) の変化に半年ぐらいかかると私は想定しているが、このチームはもっと早く課題管理の考え方に適応しそうな気がする。イシューの他人のコメントに5秒でリアクションできる開発者はそうそういない。

私がまだまだプロジェクトの理解が浅いので1-2週間はそのキャッチアップをして、メンバーが遊ばないように課題をどんどん作って優先度付けしてメンバーが担当できるようにしていきたい。