21時半から寝始めて何度か起きながら6時に起きた。昨日は雨降り、且つ移動疲れでしんどくてたくさん寝ることにした。

今日の運動はスクワット,散歩をした。統計を 運動の記録 にまとめる。

会議の準備

6時に起きてシャワーを浴びてから今日の打ち合わせの資料作り。ある程度は作ってあったものの、最終チェックしながら修正していく。9時前まで資料作りをしてオフィスへ出掛けた。

プロジェクトの進捗報告

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

今回は3次開発を無事完了させたこと、昨日の 大きなふりかえり からみえることの、経営陣向けの私なりの見解や視点を報告していた。プロジェクトの状況について報告した後は、私の気付きや視点の共有、チームの新たな取り組みとしてテックブログを読む会の狙い、今後の予定などを共有した。少し前からメンバーの指導や育成についても経営陣へ向けて私の考えを述べるようになった。その1つとして運用と開発の兼任は不可能だと明確に提案した。その結果、新規メンバーのお手伝い先の組織体制や業務の分担なども大きく変更されて、新規メンバーがフルタイムで開発に参加できるようになった。私は組織を変更したり他業務を見直すことはできないため、これには経営陣の協力が不可欠となる。プロダクト開発はチーム開発をしながら適正な実績を示しつつあるので、私の意見も説得力をもって伝わるようになっていると推測する。そして、私自身も独り善がりや見当違いの施策に陥らないよう、月例のタイミングで私の気付きや考えを経営陣と共有するようにしている。どんな状況であっても、私の目的はプロダクト開発を成功させること、そのために必要なことは何でもやる。自身の保身も見栄もなにもないから自然体で共有している。そうしているうちに、私の雑談から組織も変えていくような話題へ発展したりもしている。

開発完了後の社内向け報告とデモ

いつも開発のイテレーションを完了したタイミングでお手伝い先の全社員向けに新機能の紹介やデモをしている。他チームと連携したり営業さんに向けにプロダクトの現状がどのようなものかを知ってもらうことをこのイベントの目的としている。どんな新機能があるのか、何が出来るのかを社内に伝えないと、チーム外の社員さんがお客さんと話すときに話題にもならない。多くのケースで質問がくるのは開発者からの技術的なものではあるけれど、コンサルや営業さんからお客さんの要件にあうかといった質問も歓迎している。今回は新たに作った一般ユーザー向けの画面の UI や機能などを紹介した。

今回は寝台列車であまり寝付けなかったのか、fitbit に睡眠時間が記録されていなかった。おそらく2-3時間は寝たと思う。

今日の運動は合宿明けと移動疲れがあるのでお休みにした。統計を 運動の記録 にまとめる。

会議の準備

この3日間で私が主催の打ち合わせが5つある。主題だからそのすべてに私が資料を作らないといけない。もちろん先週から準備はしていたものの、完全ではなく、週末には城崎温泉でいっぱいいぱいになっていて余裕がない状態のまま出張になってしまった。打ち合わせの成否はそれまでにかけた準備時間に比例する。私の持論だ。最低限このぐらいの資料や段取りを組んでやらないといけないという私なりの基準がある。今回はぎりぎりまで資料を作ったり、打ち合わせ内容を練ったりして自身の基準すら満たすのにとてもしんどかった。

定例会議

いつものマイルストーン単位の定例会議。

特定の path 配下の web api にミドルウェアで認証や認可を適用している。こうしておけば認証しなければいけない web api の認証設定を実装し忘れるということが絶対に起きない。一方で未認証の web api もある。/auth/login や /status/ping といったものだ。これらは未認証で呼び出せるのでトップレベルの path をわけたい。そうすると、既存のトップレベルに設定してある /api/xxx という名前が論理的におかしい。web api は他にもあるのに認証を要するものだけ api というトップレベルの path を付けるのは奇妙に思えてくる。

/api/ping

チームで話し合ったり、私が思いついた最終結論としては1文字の path を設けることにした。ミドルウェアを適用したいという目的なので path さえあればよい。認証を要することを表す単語をつけると path が長くなってそれはそれで違和感を感じるし、開発者はタイプ量が増えることを嫌う。そこで一文字にしようと提案した。

/p/ping

permit, private, protected の意図で p という文字を使う。

3次開発の大きなふりかえり

事前に資料を作っておいた 開発の大きなふりかえり。2時間を使ってふりかえりを行う。前回の大きなふりかえり を経て、今回も若手のメンバーが大きく成長してくれて、その成長度合いが課題管理システムの統計からみてとれた。私がプロダクト開発に参加してチームを組んで1.5年経った。初期からのメンバー2人はどちらも十分に課題管理をうまくできるようになった。その結果、チームがよい開発文化を形成するようになった。

今回は新たに入りかけた若いメンバーはうまく立ち上がらなかったという反省があるだけで、その他のことについては開発全般うまくいっているし、プロダクトの品質も上がっているし、バックログの課題もたくさん自分たちで見つけられるようになってきた。私からみてもこのチームは十分によい開発チームに育ったと思う。マネージャーとしての私にとっての次の課題は途中からチームに参加するメンバーをいかに早く開発に馴染んでもらうか、よい開発文化を形成するようになってもらうかという取り組みになる。

スライドのあちこちに次の文言を埋め込んである。

ふりかえりなくして成長 (改善) なし

初期から課題管理に取り組んでいる2人のメンバーはどちらも成長が著しいし、ふりかえりの効果を実際の業務で体感してもらえていると思う。私自身も初めてのマネージャー経験、初めての課題管理をプロジェクトマネジメントとして導入するという経験、それらの PoC としての答えは出たと思う。間違いなく、課題管理は開発プロジェクトをよりよくするものだし、適切に課題管理すればプロダクトの品質も高くなっていく。今回のふりかえりは課題管理をビジネスにすることへの確信につながった。

2時前に寝て6時半過ぎに起きた。4時間半も眠れたって感じ。今日も雨降りで外に出れなかった。

今日の運動は腕立てとスクワットをした。統計を 運動の記録 にまとめる。

3次開発の完了

3.5ヶ月を機能開発、QA テストを1ヶ月やって3次開発を完了した。新人の受け入れ失敗、2週間の開発遅れといった失敗もあったが、計画を補正して概ね予定調和で完了することができた。よかったところは最初から一緒にやっているメンバーの成長が大きく、私がプロジェクトを去っても彼らだけでプロジェクトを運営していく見通しをもてるようになってきた。お手伝い先の要望次第だが、次の開発フェーズを終えたら私がマネージャーを務めるのを終えてもよいかもしれない。

開発が無事に完了してよかったねという話しとは別に、3ヶ月前に合流した新しいメンバーへはやや厳しく指導した。QA テストをメンバーみんなで役割分担し、そのメンバーには相対的に簡単なタスクを1ヶ月という期間で与えていたにも関わらず、期日になっても4つある issue のうち、1つも完了させていないという体たらくぶりだった。先週の水曜日に 1on1 して4つのうちの2つだけは必ず完了させてほしいと依頼し、本人も了承していた。もっと言えば、1週間もあれば十分にできる程度のタスクでしかない。にも関わらず、期日に完了していないということに「なぜ出来なかったのか？どうすれば完了できたか？」という議題を提起した。

会議が始まる前にプロジェクトオーナーへも今日は厳し目に指導するからメンバーが落ち込むかもしれないので、そのときはフォローしてくださいと伝えておいた。いまの若い人はストレス耐性がないからちょっと厳しく指摘をすると落ち込むことも推測できた。実際に厳しい指摘をしてみて、私自身も相手がショックを受け過ぎないように言葉を選んだり、できるだけ仕組みをもって改善していくという姿勢で議論を進めた。そういった人間関係の配慮そのものがとても疲れることにも気付いた。昔は上司がボロクソにダメ出しできたのは楽だったんだろうなとも思えた。

リリース作業とインストールテストと手戻り

開発と QA テストを完了したのでコンテナイメージやパッケージをリリースする。実際にインストールテストをやりながらインストールドキュメントも修正していく。これがなかなか大変なことに気付いた。機能が増えたり、仕様が変わったりしたところを1つ1つチェックしていく必要があって、個々の変更は軽微でもそれがいくつも数が多くなると覚えてなくて見逃してしまったりもする。そのことに気付いたら修正は容易だが、インストールテストをやっていて気付いたらパッケージングをやり直すこともいくつか出てくる。新機能追加や仕様変更とドキュメント／パッケージングをつなげるための仕組みがいまない。それも考えていかないといけない。

0時半に寝て4時に起きて5時過ぎに起きた。起きてからなにをしていたかあまり覚えてないが、気付いたら7時になってた。

今日の運動はレッグレイズ(椅子),腕立て,スクワット,背筋,散歩をした。統計を 運動の記録 にまとめる。

QA テスト

これまでは QA 期間中はメンバーに QA テストをお願いして、私は他のことをやっていることが多かった。今回は私も QA テストをやってみて、テストケースの内容の確認やテストをやってみての自分の感覚や所感などをみてみようと、泥臭くテストをコツコツやっている。テストをしていると、いろいろ気付くことがあって、メンバーにヒアリングしたり、issue 登録したり、なかなか思うようにはテストケースを消化できない。QA テストは担当者が重複してもよい。それは人によって視点が異なるから同じテストやっても異なる気付きがあったりする。今回の私はまさにそれで、私なりの気付きを issue 登録している。

同じことをやってもどれだけ issue 登録できるか、これが課題管理において大きな違いになる。アリエル時代でもテスターは issue 登録してなんぼなので本当に細かいことでも気付いたら issue 登録してくる。いくつかは invalid や duplicate で閉じるのだけど、そういう多くの issue の中から開発者も気付きを得ることもある。

街の歩き方

昨日と同じように、今日もホテルに戻ってきて筋トレしてから散歩に出掛ける。大きな公園や神社とかだと散歩しがいがあって楽しいけれど、大崎のような街中にはなさそう。それであちこち歩いていて気付いたのだけど、不動産会社の大きなビルの周りには公園ではないけれど、遊歩道のようなコースがいくつか設けられている。その道をぐるっとひと回りするのが楽しい。今日は 住友不動産大崎ガーデンタワー の周りの遊歩道をぐるっとまわってきた。

かがみの孤城

たまたまテレビをつけたら金曜ロードショーで かがみの孤城 をやっていた。みてたらおもしろかったらそのまま最後までみてしまった。鏡の世界に招かれた7人がリアルで会えないところは、なんとなくそうじゃないかと私が予想していたことがそのまま当たってた。誤った推理で並行世界じゃないかという問いかけが出てくる。その並行世界の概念図が私の解釈とは違っていて、その説明はこの物語の真相かどうかに関係なく、並行世界の概念とも違うんじゃないかと一人ツッコミしていた。d アニメストアならみていなかったかもしれないけど、テレビならストレッチしながらついついみてしまった。そういう視点ではテレビの価値は大きいのかもとも思えた。

昨日はホテルへ戻って19時に寝て21時過ぎに起きて、23時頃に晩ご飯を食べて、1時に寝て6時半に起きた。

今日の運動は腕立て,スクワット,背筋,散歩をした。統計を 運動の記録 にまとめる。

プロジェクトの進捗報告

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

開発はいま QA テスト期間であと2週間で今フェーズの開発を終える。今回は2週間遅延したけれど、あるメンバーにとってその分の成長も垣間見えたので中長期でみればこの遅延はよいものだったと思うといったことを上申した。優先度の高い要件は満たした上でメンバーの成長を実感したり、プロダクトの品質も上がってきている。私からみて十分に課題管理をうまくこなすチームになってきた。1年以上かかったけれど、よい開発文化をもつチームに成長したと思う。

今フェーズの唯一のよくなかったところとして新規メンバーの受け入れに失敗した。2週間の遅延もそこに起因するものではある。受け入れに失敗した背景や私の所感、今後の対応についていくつかお手伝い先の経営陣とも話し合いをした。開発とは結局のところ、人の問題になってしまう。それはスキルや生産性の個人差が大き過ぎるから。人に向かい合ってその人の価値観や行動を変革して、よりよい開発文化を根付かせていくことがチーム開発には重要。それは一朝一夕ではできなくて、半年とか1年とかそのぐらいの時間がかかる。

お手伝い先の経営陣も私が取り組んでいる課題管理の価値を認めてくれつつあって、開発方法論の手法を学んだことがないというのが最も大きいところだろう。よい開発文化をもつ組織で働いたことがあれば自然に身に付くが、知らない人はまったく知らなくて徒手空拳で戦車と対峙しているようなものになる。課題管理でよい開発文化をつくるという私の PoC はほぼ検証できたと言っていいかもしれない。

筋肉食堂へ行ってみた

MIYASHITA PARK に RAYARD というショッピングモールとレストランが合体したような大きな複合施設が出来てた。昔はただの公園だったと思うのだけど、いつの間にか再開発されたらしい。水曜日の夜で外も寒いせいか、施設が大きくて広い割にお客さんはまばらで閑散とした雰囲気だった。それはそれで人混みがなくて私にとっては心地よくはあるけど、施設の真新しさに比べて寂しい感じはした。

RAYARD にある 筋肉食堂 でお仕事のお願いも兼ねて知人と晩ご飯を食べてきた。たまたま渋谷でどこかお店を探していて、いま筋トレしているからちょうどよいんじゃないかと思って店名からエイヤで決めた。接待でもあるので和牛フィレ肉ステーキコースを頼んでみた。ちょっと高めの価格帯だから接待にも使えるのかな？と期待しつつ行ったのだけど、高タンパク低脂肪なメニューがいくつか提供されて、料理自体はおいしかったし、ヘルシーなら言うこともないのだけど、コンセプト的に量は提供されないし、料理の品数も少なかったのでディナーという視点からこのコースのみでは物足りなさもあった。コース料理を食べ終えてからもう1軒行きましょうとそそくさと退出した。本当の意味でトレーニングやっている人たちがご褒美のような晩ご飯を食べにいくところかもしれない。

まん丸のボールみたいなハンバーグが私は一番おいしかった。中心はレアになっていてその食感も楽しめた。これは私の好み。メインの和牛フィレ肉ももちろんおいしかったのだけど、私はもともと牛肉ステーキをそれほど好きでもないのでハンバーグで十分満足できることにも気付いた。

うしとらスタンドで飲んできた

筋肉食堂は RAYARD の SOUTH エリアにあり、同じフロアの NORTH エリアに うしとらSTAND があった。会食前に付近散策で歩いていてたまたま発見した。別店舗のうしとらに何度か行ったことあるのでこんなところにもあるんだと懐かしく思うところもあって2軒目はここに決めた。筋肉食堂でヘルシーな料理を食べて、結局ここでポテサラと餃子とナッツといった、ややジャンクな食べものとクラフトビールを飲んでヘルシーな食事をおじゃんにした。しかし、接待という意味では気張らず、こういうところで飲み食いして雑談するというのもとてもよかった。さすがうしとらさんだ。

おいしいなりんご という名前の、柑橘系ビールがあまり飲んだことのない風味で、おいしかったというよりはモノ珍しかった。なんかいつもとは違うモノを飲んで非日常感を味わうことができて満足した。

1時に寝て5時前に起きて6時半に起きた。起きてからホットクックで玄米を炊いてみた。2合で40分前後といったところ。

今日の筋トレは腕立て:20x1,スクワット:20x1,背筋:10x2をした。

社内版テックブログを読む会の2回目

新しい取り組みの2回目。前回の所感はここ 。淡々と始めて淡々と終えた。これはそういうイベント。一方でマネージャーの視点からメンバーの取り組みをみていて1つ気付いたことがある。読解力、文章力、言語化力に個人差がある。そんなことは当たり前だが、たまたま最近ある動画をみた。8分20秒ぐらいからみてほしい。

この先輩が後輩に指導している中で日経新聞を題材に、情報処理能力を鍛えることの重要性を説明している。言語化能力を鍛えるために新聞を読む、映画をみる、日記も書く、文章能力を上げなさいと指導している。本当にこの通り。私が働いてきた組織では開発者で半分ぐらいの人しか文章を書けず、ビジネスの人に限ってはもっと多くの割合の人たちが書けない。そして若い人よりも年配の人たちの方ができない割合が多かった。それではビジネスで勝てないよという話し。テックブログを読む会はこの視点からも言語化能力を養うよい練習になるように思えた。

野菜スープのレシピ改改

先日つくった野菜スープ のさらなる改善。前回のレシピをさらにアレンジして今日のレシピはこれ。

• にんじん x 1
• 新玉ねぎ x 1
• かぼちゃ 1/4切れ
• ミディアムトマト x 8
• セロリ x 1 の葉っぱ部分
• しめじ 1袋
• えのき 1袋
• 鶏肉
• ローリエ 1枚
• 塩コショウ 適当
• コンソメ (小さじ4杯)
• 水 600cc

調理のワークフローもだいぶわかってきて、食材を切って内鍋へ入れるのも次の順番がよいように思う。

1. 水を 600cc を入れる
2. コンソメを小さじ4杯入れる
3. ローリエを入れる
4. 塩コショウを少々入れる
5. にんじんをさいの目に切って入れる
6. 新玉ねぎを細目にくし切りして入れる
7. かぼちゃをさいの目に切って入れる
8. しめじの石づきを切り落として、個々の房を分解しながら入れる
9. えのきの石づきを切り落として、半分のところで切って、ばらかしながら入れる
10. ミディアムトマトを洗って入れる (出来たては熱過ぎて火傷するから半分に切った方がよいかも？)
11. 鶏肉の身と皮を分離して、それぞれをさいの目のサイズに小さく切って入れる
12. セロリの葉っぱ部分を切って、適当なサイズで入れる

これで内鍋の水位 MAX の線がちょっと隠れるぐらい。ちょうどいっぱいになる。あとはホットクックの調理ボタンを押すだけ。だいたい40分程度。

スクラムマスターという功罪

QAエンジニアがスクラムマスターに憧れてしくじった話 に参加した。

失敗経験の共有をするという意味で発表そのものはおもしろかった。regional scrum gathering tokyo (rsgt) 2024 の発表の再演だったみたい。開発経験の浅い人がスクラムに馴染んでいない会社に転職していきなりスクラムマスターに挑戦してみて、全然うまくいきませんでしたといった失敗談の共有。その会社では、その後、組織改編されてスクラム導入も断念して、その発表者も結果的に退職してしまったとのこと。いろいろ悲しい。スクラムマスターは組織のライン上もチームの役割としても、実務に対しての責任を負っていない (建前上はチームの成功にコミットとあるけど、スクラムの運営をうまくやるための支援をするといった活動がメインになる) ため、若い人がいきなりスクラムマスターをやるというのは難しいのではないかと感じた。スクラムマスターの役割の1つにファシリテーションをうまくやってチームを誘導するみたいな風潮がある。しかし、私の感覚的には、ファシリテーションをうまくやっただけで開発がうまくいくわけないだろと自分の経験則からの反発もある。

私からみたら、この例は経験不足／実力不足の人が開発のマネジメントに影響力を及ぼそうとして、しかも転職したばかりの組織も開発もよくわかっていないチームで、そんなことそうそうできないってだけの話しにみえた。にもかかわらず、このイベントに参加している人たちはみんな優しくて、どうすればうまくいったか？を親身に相談にのってあげたり、その組織や会社の問題点をあげてフォローしたり、それはそれでやさしい世界ではあるけれど、社会人としての責任感といったところで私は相容れないものがあった。私自身、いろんな組織やチームで課題管理の価値を共有してきたけど、それも半年〜1年、私が実際に現実の開発の中で実践して、その価値が伝わっていく。こういった開発の運用を変えるというのをファシリテーションと啓蒙の (いわば) 口先介入だけで実現するのは相当のスキルや経験がいるのではないかとも思えた。

3時過ぎに寝て1度起きて7時半に起きた。また体調を崩さないか心配になってくる。

今日の筋トレは腹筋:15x2,腕立て:10x1,スクワット20x1をした。

業務での勉強のやり方の基本

隔週で水曜日はメンバーと1on1をしている。今日は年明けで最初の1on1になる。あるメンバーと勉強のやり方について話題になった。私が普段、業務で行っている勉強のやり方を紹介してみた。

1. 業務の中で未知の内容やわからないことに遭遇する
2. ツールやフレームワークを学ぶなら公式ドキュメントを一通り読む
3. チュートリアルやサンプルコードを書くためにサンプルリポジトリを作る
4. 実際にコードを書いて、動かしてみて、ドキュメントの内容を理解する
5. 自分が理解した内容をテックブログに書く
6. 対象への理解の解像度が上がってから業務に応用する

業務をしながらこれを繰り返してプロダクト開発をしている。

私からみると、経験の浅い開発者は勉強せずに、インターネットでググった内容をそのまま業務に応用しようとする。そして、理解の解像度が低いために誤った設計や実装をしてしまう。それで手戻りが発生したり、品質が悪かったりする。何度も公式ドキュメントを読んだ方がよいと提唱しているものの、これがなかなか勉強しないといけない人には通じない。私も過去にそういう時期があったので意図が理解できないというのも理解できる。だからこそ、この話しは何度でもするし、いつかそのことを理解できるときがきたら役に立つことだと考えている。

メンバーから「公式ドキュメントを読んでも書いてあることが理解できない」というコメントをもらう。そう。理解できないから自分でコードを書いて、動かしてみて、その勉強をするんだよと教える。本当にそれだけのことなんだけど、それだけのことも理解できずに他人が書いた信頼できるかどうかわからない記事のコードを使う人が多い。本質的には技術の勉強を過小評価している。経験の浅い人は1-2時間読み書きしただけでモダンなフレームワークの抽象化や振る舞いを理解できるはずがない。私でもバックエンドならたいていのことは理解できるが、経験の浅いフロントエンドは怪しい。だから、分かるまでもっともっと勉強しないといけないという認識が必要だ。1-2時間で終えようではなく、勉強も含めて2-3日かけようと思うぐらいでちょうどよい。

さらに私はメンバーに「時間がかかってもよいからちゃんと理解して開発しなさい」と、これも何度も何度もメンバーに伝えている。それによってタスクが遅れても構わないとすら言っている。他社のプロダクト開発でそこまで言うと経営者からクレームがくる可能性はあるが、おそらくお手伝い先の経営者もいっときの開発の速度よりも、地に足の着いた開発者として成長してもらう方がずっと価値があると理解してもらっていると、私は考えている。だからこそ、メンバーにそう言って、みせかけだけで開発しないように伝えている。

今日話していて、ようやく自覚できるようになってきたんじゃないかと手応えを感じた。1年かかったけれど。私自身マネージャーとして未熟でもあるし、マネジメントがよくなかったところもあるし、伝え方もよくなかったのかもしれない。それでも繰り返し繰り返し、開発において大事な価値観はメンバーに伝えていこうと気持ちを新たにした。

災害義援金の推移

先日 石川県の災害義援金に寄付した ときにサイトにその日の残高を掲載していることに気付いた。関心をもったのでその記録を付けている。チェックを忘れたときは internet archive から分かる範囲で調べた。次のような感じに推移していて、そろそろ落ち着くのかもしれない。約60億円といったところ。他の団体や期間からの寄付もあるだろうけど、被害総額は約8,000億円らしいのでまだまだ全然足らない。

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

月例のカフーツさんのオンラインイベントに参加した。前回の所感はここ 。今回のテーマは「自治体とコワーキング」だった。私は行政を好ましく思っていない。行政と関わるお仕事もいくつかやってきた中で行政側の態度がよくなかったり、担当者も上から指示されたからやってますといったやっつけだったり、若い担当者は理解があっても決済権をもってなくて上司に没にされたり、一緒に働いていて楽しいようなお仕事に巡りあわなかったからだ。そして、目的意識からの違いから行政とのお仕事やプロジェクトが失敗とまで言わなくても、うまくいかないケースをいくつも見聞きしてきた。うまくいかないのに対して、うまくいったというのはほとんど聞いたことがないからまずうまくいかない。

それはともかく、行政と一緒になってコワーキングの事業をやろうとしている人たちもいるのでそれはそれでどんなことをやっているのかを聞いていた。今回は新しい参加者がいてその人の経歴ややっているコワーキングの行動なども聞けておもしろかった。街の人たちとどうやって仲良くなるかという話しで単純接触効果がもっとも効果が大きいのではないかと話されていた。なにもしなくてもそこにいて、徐々に人がくるようになって、人と会っているうちに仲良くなるといった話し。営業さんが取引先をまわるのもその戦略。

空き家バンク は住居向けしか対象としていなくて事業用にはなっていない。事業に使える空き家を探すのが難しい。空き家のマッチングシステムはあるようでないらしい。空き家がいっぱいあるのはわかっているので空き家をコワーキングスペースに改装して、町興しの拠点に使えばいいのではないかといった話しがあった。それはそうかもしれないが、私の感覚では、田舎にスペースは山ほどあるが人がいない。コワーキング的な新しい価値観で個々が自律して課題解決するような人を田舎でみつけるのはなかなか難しいと考えている。どちらかというと、一定の人口がいる地方都市や大きめの市が落とし所なのではないかと思う。

2時に寝て何度か起きて7時過ぎに起きてゲームして10時ぐらいからオフィスに出掛けた。

年末の事務手続き

年末調整と給与支払報告書の作成を行った。年末は平時の月末と異なるからわちゃわちゃしてたら25日の給与の支払いも忘れていた。いや、忘れていたというよりは年末調整を12月分の給与で調整したいから年末調整を完了しないと給与確定できないと放置していた。今日は金曜日で平日だからシステムは稼働しているだろうと安易に考えていたら eltax も e-tax も稼働日を次のように書いてあった。

土・日・祝日、年末年始12/29～1/3は除く

eltax のアプリケーションで書類データは作成できたけれど、作成したデータを送信することはできなかった。年明けの4日まで持ち越し。こういう失敗が最近増えてきた。がっかりして嫌になる。あと eltax や e-tax の運用停止時間に遭遇することが私はとても多い。月に1回も使わないようなシステムなのに年間で2-3回ほどは使えない時間に遭遇する。それは当たり前で、私が余裕のある時間は早朝・深夜と休日になるため、メンテナンスの日程と重なることが多い。システムは基本的に24時間365日動いていないとダメだということがわかる。なにかトラブルがあったときの運用対応は年明けでも構わないが、定型的なデータ処理は24時間365日できるはずだと思う。

その後に自社の請求書を作成したり、他社の請求書の対応や会計の明細登録などをしていた。キャッシュフローも眺めていて 今季はもともと赤字想定で予算策定 していたが、受託開発のお仕事が長引いて黒字決算で着地する予定。あと3ヶ月しかないのでブレることもないだろうと思う。本当は今季に事業の体制変更もやらないといけなかったことが来季へずれ込む。計画通りに進捗していないという面からは、いろいろあって事業も経営もあまりうまくいっていない。

カフーツさんの忘年会

初めての参加。昨年も参加する予定が 父の訃報 があってドタキャンしたのでリトライ。手土産に 一心堂 のフルーツ大福をもっていくことにした。神戸の阪急百貨店にお店があったのでてっきり神戸発祥のお店かと思ったら大阪発祥だった。種別によって値段は異なるが、だいたい1個410-640円 (税抜き) ぐらい。9個入の詰め合わせにしてもらった。

他に持ち寄りであった食べものに 三宮一貫樓 のちび豚まんと焼売を撮った。神戸に住み始めて商店街の一角にあるのは知っていたのだけど、神戸の名物の1つだと知ったのは住み始めて2-3年経ってからだった。勉強会の食べものの定番はピザだけど、神戸なら一貫楼の 中華パーティーセット (送料/消費税込みで10,750円) などを頼むのもよいのかもしれない。

コミュニティとコワーキングの違い

いとうさんと話していて、以前よりコミュニティとコワーキングの違いが明確になった。私の中では似て非なるものという考えはあったものの、あまり違いを明文化できていなかった。

コミュニティマネージャーと コワーキングマネージャー では求められるスキルセットが大きく異なる。キャリアとしてもコワーキングマネージャーの方がずっと難易度の高いものであるように話されていた。集合で言えば、コワーキングマネージャーはコミュニティマネージャーのスキルセットを含む。コミュニティマネージャーは私も身近なものだし、コミュニティマネージャー (会社によっては DevRel と呼ばれたりもする) を社員として雇用する会社も増えてきた。会社に雇われるコミュニティマネージャーというキャリアは、その会社のサービスやプロダクトのコミュニティを盛り上げたり宣伝したりといったマーケティング活動の一環とみなされることが多い。一方でコワーキングマネージャーというのは、会社に雇われるというよりもコワーキングスペースや地域のようなコミュニティに根付くものかもしれない。

コミュニティというのは、それ自体を1つの意思をもった人のように扱い、そこに集まる人たちがコミュニティの思想にあうよう1つにまとまって活動する、協調するといった趣きが強い。そのため、コミュニティマネージャーはコミュニティの理念にあうようメンバーをまとめたり、逆にあわない人たちを排除することもある。一方、コワーキングというのは、個々がそれぞれの背景をもち、得意・不得意があり、性格や思想も様々で多様な価値観をもつ人たちが集まり、それぞれの特性を活かした上で協調するといった趣きがある。そして、コワーキングマネージャーは個々人にあわせたホスピタリティを提供するという。これは主従において大きな違いの1つでもあると理解できた。コミュニティはそれ自体が主でその理念にメンバーが従う。コワーキングは個々が主でその人たちが協調するかどうかはそれぞれのコワーカーの判断に委ねられる。そして、コワーカー同士が協調しやすいように縁の下で支えるのがコワーキングマネージャーだという。コワーキングマネージャーは、訪れたコワーカーとコミュニケーションを取る中で、一緒に考え、相談にのり、そして答えや結論を出さなくてもよいという。コワーカーと一緒に考えてあげるだけでよいというのだ。どこかに落とし所に着地させたり、全体をまとめたりしないという点がコミュニティマネージャーと大きく異なる。

そこで素朴な疑問。コワーキングマネージャーが個々人に向き合うとしたら、そこには ダンバー数 (100-150人？) のように人間の認知能力の限界が出てくる。数千人や数万人が所属するコミュニティも存在するが、コミュニティといった枠組みで集団を抽象化して管理できなければ認知能力に限界がある。次の問いを投げかけてみた。

コワーキングマネージャーが個々人にホスピタリティを提供するとしたら、小さい規模や小集団でしか機能しないのではないか？スケールしないのではないか？

いとうさんが言うには、この弱点を補うのがツールの力だという。コワーキングマネージャーのチームを作り、コワーカーそれぞれと話した内容やその人の背景や特性、いまやっていることなどを記録し、その記録をチーム内で共有する。これなら個人の認知能力を拡張できるし、コンテキストを引き継いだ上で初めて会うコワーキングマネージャーとコワーカー間におけるホスピタリティも担保できるかもしれない。

ここまで聞いて、これはまさに私が開発の現場でやっている課題管理そのものだということに気付いた。日々の開発のアクティビティを課題管理システムにコメントとして記録し、そのタイムラインをメンバー全員で共有しながら、リアルタイムに必要なコミュニケーションをもって相互に情報共有または協調するといったことを、まさに私のチームでは実践している。これをコワーキングスペースにいるコワーキングマネージャー間で行う、もっと言えば、複数のコワーキングスペース間で共有できれば、それはさらに大きなホスピタリティになるのかもしれない。別のコワーキングスペースへ行っても、自分の背景が共有されていて、よりよいホスピタリティを受けることができるのかもしれない。

初めてカフーツさんに訪問したのが2022年6月 だった。当時いとうさんと話してみて、課題管理に通じるところがあると直感的に感じて、その後、やり取りを継続してきて、1年半経った。ようやくコワーキングと課題管理がつながった。いとうさんからみれば、課題管理とはコワーキングマネージャーが備えるべきホスピタリティの延長上にあるチームで協調するための概念なのだと思う。そして、私からみれば、コワーキングとは課題管理そのものなんだと理解できた。

課題管理システムの利用状況を表すメトリクスの1つに カレンダーチャート がある。これがいま課題管理を知らないチームでその実践を指導する上で想定外に役に立つことがわかった。この他にも課題管理特有のメトリクスを増やしていきたいと私は考えていた。そのアイディアの1つに「コワーキングチャート」というものを作ろうと思う。おそらく世の中にはないし、課題管理とコワーキングの両方を研究している人にしか、この発想は出てこないと思う。来年、他社のお手伝いを終えた後のアイディアの1つに寝かしておこうと思う。

1時に寝て何度か起きて7時過ぎに起きた。寒くてなにもできない。

定例会議

年末という追い込みもあってか、このマイルストーンで対応した issue 数も多くて、ふりかえりの内容や議論する内容がいつもの定例よりも多かった。1時間の会議時間を20分ほどオーバーしながら定例会議を終えた。

テックブログを読む会 の調査報告をして年明けぐらいから社内でもやってみようかという話しをしていて、メンバーから開発が忙しいから勉強時間が取れないといった意見が出た。これは課題管理の文脈で取り組むよい問いに思えた。一番勉強しないといけないメンバーから出た意見でもあった。私の過去の経験則でもこの類の発言はスキルの高い開発者からは出ない。それは勉強することの価値を理解しているからだと推測する。

いまテスト駆動開発はどちらかと言うと文化に近いと言われる。その所以はテストを書かないから開発が遅くなるということをヒューリスティックもしくは経験則として理解している開発者が多いからだと私は考えている。現実のシステム開発でテストを書かないと開発と、テストを書く開発を定量的に評価したり比較することは相当に難しい。事実上そんなことはできない。なぜならば、業務はそのどちらか一方しか選択できないからだ。だから、これは開発者の感覚としてテストを書いて当たり前だという文化をもって、その実益もあると信じて業務に組み込むしかない。だから文化と言われる。それと同じで開発や技術の勉強をせずに、目の前の開発だけやっていてもスキルアップできないのは経験を積んだ開発者からみたら自明だが、それをどう伝えていくか、もしくはその気付きを課題管理の文脈で与える仕組みはないかな？と考えていたりした。

納会

今日はお手伝い先の仕事納めになる。私もそれにあわせて15時半にはお仕事を終えて退勤した。1人だけ働いていてもテンションが上がらないかなと思ってそうした。その後、お手伝い先の納会途中の写真がアップされていてスマブラやりながらのほほんしていたみたい。

納会：何かの出来事や物事が終わった時に締めくくりとして催す会

昔から会社の納会ってなんの意味があるのだろう？と思っている。だいたいお疲れ様でしたって感じで軽食とお酒があって、それを飲み食いしたらすぐ帰る人もいれば、そのまま残って雑談してから帰る人もいる。いつ帰ってもよい流れ解散となる。会社によってもやり方は異なるのだと思うけど、どうせイベントをやるならもうちょっとちゃんとやったらいいんじゃないかと思わないでもない。だらだらしたイベントが納会ってイメージすらある。

本当は夕方から明日の打ち合わせの議題を整理しようと思っていたものの、夕方から急にお腹が痛くなって、帰ってお腹を下して寝ていた。お昼に食べたもののせいかもしれない。寝ていたら直ったのでそんな大したことはないみたい。うちの会社の業務としてはいつも通りで29日までは働く予定。ちょうどカフーツさんの忘年会が29日17時からあるのでそれを２回目の仕事納めにするのがよさそう。

晩ご飯食べて21時頃から横になっていた。なんか寒くてなにもやる気がしない。1時に寝て何度か起きて7時に起きた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日は議題を準備するのを忘れていて、ふりかえりをしながらフリートークのような雑談をした。

• 2023年ふりかえり

昨日の 組織論の動画 なども共有しながら課題管理の文脈でマネジメントやリーダーシップの原則として思うことを言語化していた。次のような価値観をメンバーにもってほしい。

• 常に人間は学ぶ
  • どのポジションの人も、どんな役割でも、人それぞれのペースで学ぶのは当たり前である
  • 組織に学ばない人がいると足を引っ張るようになってしまう
• 人間は時間とともに成長して変わっていく
  • 同じことを何年もずっとやり続ければよいという時代ではない
  • 成長することでやり方もやることも責任も変わっていく
• プロジェクトは一期一会
  • 人は学び成長することから同じプロジェクトを再現することは本当の意味でできない
  • そのときそのメンバーで、その知識や習熟度で取り組むプロジェクトはその人の人生において1度しかない
  • 本当の意味でプロジェクトマネジメントに再現性などないし、そのときの状況で最適解を考えて実践しないといけない

知の創造研究部会第63回

知の創造研究部会第63回 に参加した。内容は悪くなかったが、私が関心のあるテーマではなかった。

最初の30分ほど、会そのものの紹介やイベントの宣伝、登壇者の自己紹介が延々と続いて、ちょっと長過ぎてうんざりした。自分たちのことをちゃんと知ってもらった方が内容がわかりやすくなるというのはやや前時代的な考えだと私からは思えた。私がイベントに登壇するとき、ほとんど自己紹介を省いて本題へ入るようにしている。それはおっさんの経歴を多くの聴衆は関心がないというのもあるが、本題を聞きたいのに関係ない話しをされるのを私自身もしんどく思うようになったのがある。映画館で映画をみるとき開始前に他の映画の宣伝が10分ぐらいあるのをうんざりする気持ちと同じ。

知の創造部会 というクローズドな facebook グループがあると聞いたので参加申請した。翌日には承認されていた。今後はイベント情報などをここでチェックすればよいのかもしれない。

2時に寝て4時半に起きて7時半に起きた。昨日のオンラインイベントの後に課題管理についての質問を受けたらいろいろ調べ始めてしまって帰るのが遅くなった。

組織論のあれこれと元凶

たまたま教えてもらってみたらおもしろかった。私もこの歳までに10社以上の組織をみてきたことから、組織の問題、あるいは組織であるがゆえに避けられない問題があることは理解できるし、自分の経験則でもダメな組織の特徴などいくつも思いつく。だいたい知っている内容ではあったけれども、若いのに書籍や論文を研究して、そういう現象にこういった名前がついているというのを言語化してくれていることは知識を共有する上で大事なことでもある。そこまでは知らなかったのでとても参考になる。

私が思う解決策の1つに役職や地位が固定化されないような組織設計というのがある。「権力は腐敗する」 という言葉がある。権力を維持したまま、いまの人間社会でこれを避ける方法はないと私は考えている。どんな優秀な人であっても。上司も役員も社長でさえも、定期的に入れ替わる。どんなに成果をあげても優秀であっても一定期間以上とどまれない。そういう新陳代謝がいいんじゃないかと思う。実際にティール組織やホラクラシーといった組織形態はこの解決策を実現している。

動画の中で、心理的安全性の誤った解釈の文脈で組織がなぁなぁになっている世の中の流れがあって、私もずっと思っていたことの1つに自己肯定感を高めるのがよいというのは本当か？という問い。たしかに過去の行き過ぎたハラスメントは意味がないものではあったのは理解するが、できない人を然るべき内容で叱らないのもどうかという思いは私の中にもあった。坂井さんによると、自己肯定感が本当によいのかどうかという成果も怪しいという。

成果が出ていない人に対して自尊心を高めると、逆に成果が悪くなったり、他者へ横柄になったりする。

直感的に当たり前の話しだと思う。できない人を特別扱いする必要はない。そして、坂井さんは流行りのキーワードにとらわれず、自分たちの組織では本当にそうなのか？具体的で地に足の着いた制度や施策を見極めるべきだ、ちゃんと自分たちで考えましょうといったメッセージを発信していた。これは課題管理の文脈でも私もメンバーに常々言っている。自分たちのやり方にあうかどうかを考えるのが大事だ。

一方でうまくいっていない組織を立て直すのはとても難しい。それは組織のマネジメントというのは、上位の意思決定者、役員であったり部課長であったり、幹部社員の影響力がとても大きいため、うまくいっていないことを認めることそのものが役員や幹部社員へのダメ出しとなる。私もお手伝いをしていて、本質を追究すると経営陣への批判になってしまうため、お茶を濁すときもある。もちろん重要なことで言うべきところは言うが、それほど重要ではないところはお茶を濁してしまう。それは人間関係もあるし、取引関係もあるし、誰だって嫌な人になりたくないし、厳しいことも言いたくない。外部の人間ですら怯むところがあるのに、同じ会社の上下関係や人間関係ではもっと言いにくいことはあるだろうというのは容易に察することができる。優秀な若手が会社を去るのは至って自然だし、もっと言うと年配の人たちも若い人にポジションを譲って会社を去らないといけない。1つの会社で5-10年働くのはとても難しい時代にきているのだと私は思う。