今日の運動は腕立て,スクワット,縄跳び(両足跳),散歩をした。統計を 運動の記録 にまとめる。

まとめ運動

先週末から体調を崩していたり、週明けが雨降りだったり、お仕事が積み重なって余裕なかったりであまり運動できていなかった。運動できていないぐらいだからご飯も作る余裕もなくてあまり食べてもいなかった。食べてないから結果的に体重は減ったんだけど。今日は天気もよかったし、お仕事や雑多な事務手続きも一段落したので、早めにお仕事を終えて公園へ行って縄跳びしたり散歩したり日課分はこなしてきた。

トヨタイムズ

知人に教えてもらった動画をみた。有名人だからちょくちょく豊田章男会長の動画をみる機会がある。章男会長は創業者一族ながら、若いときは不遇の環境を過ごしてきたことで特異なリーダーになったようにみえる。うまくいかなかった実践の経験の中から話すから話しも説得力があっておもしろい。動画をみていていくつか気付いたことをメモに残しておく。

• 孤独感について
  • みんなモリゾウに憧れや羨ましさがある
    • 次の段階になると僻み・やっかみになる
      • その次は憎しみになる
    • 羨ましいと思っていた人を痛めつけることに自己陶酔になる
      • これが世間の冷たい風の正体ではないか
    • リーダーが説明しない世の中はどうなのか？
  • そうは言っても孤独は辛い
    • 1人になれる場所が大事
    • 会社とは関係ない友人をもつことが大事
• 日本のものづくりの強みの1つはエンジンである
• 新規事業でなにをやってよいか分からなければ、いま困っていることを解決する
  • 困っている人たちを助けていると、もっといろいろなアイディアが集まってくる
• 責任を取るということは実務でしっかり作り直すこと
  • トップが辞めるだけでは改善しない
• 最後に実際に車を乗ってみてたのがよかった
  • 車を作っているのだから自分たちで車を体験する
  • その楽しさを大事にしていく
  • この延長上にリーダーが生まれていくのかな

23時過ぎに帰ってきて歩き疲れてそのまま横になっていたら寝てしまった。2時に起きて5時に起きて6時に起きた。変な寝方をした。

今日の運動は腹筋ローラー,スクワット,縄跳び(両足跳)をした。統計を 運動の記録 にまとめる。

ブログ談義

18時から知人たちとハドルで次の記事について議論した。

• 【翻訳】テスト駆動開発の定義

私自身、自分がやっているのはテスト駆動開発の範疇だと思っているものの、昔から実装よりも先にテストコードを書けと声が大きい人たちがいたような気がする。私も多くのケースで実装と一緒にテストコードを書いているものの、別の視点から、これまた多くのケースで実装よりも先にテストコードを書くわけではない。実装がある程度、機能することを確認してからテストコードを書くことの方が多い。この記事では実装よりも先にテストコードを書く手法を「テストファーストプログラミング（Test-First Programming）」と呼び、それ自体はテスト駆動開発に含むものではないことを明言している。この事実だけでもこの記事の価値はあって教条的な人たちと一線を引くことにつながる。さすが t-wada さんで、記事についてとくに懸念もなく、素晴らしい内容だと思う。私の浅慮でツッコミできるようなところはなく、この記事の要旨に沿ってテスト駆動開発して実際の現場で困ることはないと思う。

知人の他の開発者たちと議論していると、用語の意図や解釈や開発方法論の実践について、それぞれの経験、考え方、実際の職場における開発課題があっておもしろい。私の考えが唯一の正解でもなく、他者の視点や気づきを聞いて考えること自体に価値がある。みんな大筋の概念は合意しているものの、小さいところではそれぞれに思うところはあったようにみえる。こういう、よい記事をみんなで議論してみるという、そういう場を会社イベントとして公式に作っていってもよいのかもしれない。

スマート縄跳びの試行

先日 LED の長さ調節できなかったことから SmartRope PURE を購入 した。PURE は普通に縄を切って長さ調節できる。雨だったり予定があったりでなかなか試す機会がなかったのだけど、昨日ようやく公園へ行って試すことができた。いま最も近い公園が芝生の養生中で土の上が全面使えない。なので少し離れた公園まで歩いて行って縄跳びする必要がある。アプリでカウントできるかのテストしながら、タイマーを置いて1分間跳ぶというのを4回やってみた。いまの私のペースだと1分で110回前後ぐらいの回数になる。同時にカロリー消費もみえる。本当は夜遅いから300回やったら帰ろうと思っていたものお、45kcal ぐらいだったので 50kcal を越したいなと思って追加でもう1分ほどやってみた。やっぱり数値がみえると切りのよいところまでやろうというモチベーションになる。PURE は長さとアプリの連動は問題なさそう。あとはどのぐらい使えるかの耐久性かな。amazon のレビューだとハードに使う人は数ヶ月で壊れたというコメントもあった。私は1回に数百回跳ぶ程度だろうから1-2年ぐらいもってくれればいいなと思うんだけど。

縄跳びした場所を写真に撮って SmartRope のアプリで合成してシェアできる。よい機能だと思う。

3時に寝て6時半に起きた。なんかいろいろ忙し過ぎる。

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

マイクロ法人の仲間

先日たまたま facebook で白ヤギ時代の、ある顧客の会社に勤めていたわかばやしさんが起業していたことを知った。創業して1年経ったという。わかばやしさんとは同い年なので応援の意図も含めてコメントしたら久しぶりなので近況報告会しましょうとなって、さらに honeycome さんという会社がうちの近所ということもあって、そこも含めて雑談会やりましょうとなった。4人で雑談会が始まったわけだけど、誰がホストで何を話すのかも段取りがなかったので最初はぐだぐだだった。私は呼ばれて行っただけなので、これは私のせいじゃないから。とはいえ、徐々に打ち解けていって、お互いのビジネスでやっていることや関心事などを共有したりした。昨年末に作った 2023年ふりかえりのスライド は私の関心事を紹介する、よいスライドに仕上がっていて、これを共有すれば自己紹介を省けて楽なことにも気付いた。昨日書いた テックブログを読む会 についても共有した。

4人の雑談会が終わってから、延長線でわかばやしさんとも軽く話して、近況やマイクロ法人のあれこれを共有した。マイクロ法人の相談相手がいないという弱点はコワーキングが補ってくれるという、私のプラクティスも共有した。わかばやしさんとは白ヤギ時代にお仕事してから8年経つかな。またいつかどこかで縁があるかもしれない。私は facebook を年賀状みたいなものに思っている。そこに発信しておけば、あるとき戻ってきた誰かがみつけて連絡をくれたりする。お仕事の依頼も年に数回は来る、大半はお断りするのだけれども。先のことは本当にわからないからつながった縁は大事にしていきたいと思う。

Coworking Day 2024

OFFICE CAMPUS という古民家を改造したコワーキングスペースへ行って次のイベントに参加してきた。

• コワーキングデイ「オフィキャンで仕事してそのあとみんなで飲もうさ」

このイベントは毎月どこかのコワーキングスペースでやっているらしい。イベント自体も1日やっていて、朝やお昼にコワーキングに関する発表があって、夜は飲み会になっていた。私は昼間、普通のお仕事があるので夜の飲み会だけ参加してきた。カフーツさん経由で知っている人が2人いるから大丈夫かな？と行ったら、やまさきさんは帰った後でむかいさんは居られていろいろ案内してもらった。むかいさんとは zoom 会議で毎月みかけてはいるけれど、初めてお会いしてご挨拶できてよかった。

着いて早々に伊丹市でシェアオフィスを運営されているふくださんに酒粕チーズスプレッドという食べものをごちそうになった。酒粕とチーズの組み合わせ、酒粕の香りがする斬新なスィーツに仕上がっていて、これも外国人がびっくりするような天才の所業にみえた。

• 白雪 酒粕チーズスプレッド

名刺交換しただけでも5名の方とお話して、交換していない方も3人ほどお話できて、コワーキングやコミュニティのこと、うちの会社のビジネスや課題管理の話題などをざっくばらんに話した。コワーキングへ行くとだいたい話しを聞いてくれる。みんな親切で丁寧な方々ばかりだった。ここにいる人たちは大半がコワーキングスペースの運営に関わっている人たちだから当然と言えば当然なんだけど、これは it 業界のコミュニティとも少し違う特殊な空間だなと思えた。

そんなことを考えながら帰ってきて、たまたまいとうさんの記事をみかけたら アジール というキーワードをあげていて、これもおもしろい表現だなと納得した。

「日本って通常、縦社会。企業も、部活動も。コワーキングで一番いいなと思ったのは、コワーキングって横の関係なこと。年齢が離れてても本当のコワーキングに来る人ってそんなの関係ないですよね」

今日のアウトテイク#99（日曜無料版）「ぼくの中ではコワーキングってアジールなんですよ ほか」【メンバーシップ特典】（2024-02-25）

私が今日行ったコワーキングの空間はまさに初対面なのに歓迎してくれて、いろんな人たちの話しを聞けて、まさにこんな感じやったなぁと読んでいた。

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

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

3次開発の完了

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

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

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

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

開発と QA テストを完了したのでコンテナイメージやパッケージをリリースする。実際にインストールテストをやりながらインストールドキュメントも修正していく。これがなかなか大変なことに気付いた。機能が増えたり、仕様が変わったりしたところを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億円らしいのでまだまだ全然足らない。

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

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

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

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

0時に寝て何度か起きて気分が悪くて吐きそうになりながら7時過ぎに起きた。昨日は飲み過ぎた。やはり年末でだらけているのでオフィスへ出勤したのが9時44分だった。

slack コネクト

昨日の 税理士さんとの打ち合わせ内容 の1つに chatwork のフリープランの メッセージの閲覧制限 への対応がある。以前は制限がなかったらしいが、どこかのタイミングで40日制限に変更されたという。slack もフリープランは3ヶ月に制限しているので世の中の流れとしては仕方ないのかもしれない。それはともかく、chatwork に (先方の負担で) 課金するか、slack コネクト へ移行するかの相談をしたら slack でも構わないという。先方も slack を有料プランで事務所内では使っているという話しだった。問題提起してヒアリングしてみたらなんのコストもなく移行できることがわかった。

早速、今日、調べて税理士さんを招待した。その際に社外の個人アカウントを使って slack コネクトの振る舞いも検証した。slack コネクトのよいところは次になる。

• 通常のメンバー同様、slack コネクトで招待したメンバーはチャンネル、プライベートチャンネル、ダイレクトメッセージを使える
• 自分のワークスペースに他組織のワークスペースのチャンネルを追加できる (参加するワークスペースが増えない)
• チャンネル名、トピック、説明はそれぞれのワークスペース管理となる
  • とくにチャンネル名を自組織のワークスペースの都合で名前を付けられるのがよいと思う

無料ワークスペースに設定されている使用制限 によると、フリープランは slack コネクトを利用できない。invitation を送るとフリープランでも接続できるが、それは pro のトライアルになるため、3ヶ月だけ使えるみたい。

開発合宿の打ち合わせ

先日 作成した旅のしおり を使って開発合宿の打ち合わせをした。打ち合わせをする前に見直していると、いくつも不備や誤りに気付いて1時間前ぐらいから修正したりしていた。私の作る資料は手直ししないと小さい誤りがいくつもある。参加者は現時点で7名で、いまのところ、これ以上増える見込みはない。昨年は4名だったのでおよそ2倍に増える。きのいえは9名まで宿泊できるようにみえる。神戸組4人に対して関東組は3人参加してもらえる。関東からわざわざ来てもらえるのは本当にありがたい。このぐらいの規模で数年継続できるような仕組みや体制を作るのが当初の目標でよい気がする。昨年は初めてだったので手探りだったが、今年は2回目なのでもう少し段取りやノウハウを使ってうまく運営できればと思う。

みんな時間通りに打ち合わせに集まってくれて、自己紹介して、主旨を説明して、大雑把なタイムスケジュールを紹介して、質疑応答をした。私の知人に声をかけているので神戸組と新規参加の関東組とはまったく面識がない。そういった人たちを少しでも話しやすいよう話題を設けたり、きっかけを作ったりすることがコミュニティマネージャーとしては求められる。別に私がコミュニティマネージャーを目指しているわけでもないが、コワーキングやコミュニティの価値の実践的なものを理解していく上で避けられないと考えている。私自身コミュ障で他人と話したくない人間なので、役割としてやらないといけないというポジションに追い込むことでその機会を得ていると言える。あと2ヶ月、詳細の詰めをしていく段階に入ってきた。

マネーの虎たちのその後

たまたまみたらおもしろかった。昔リアルタイムでみていた。いまの感覚でみればハラスメントやら人格否定しまくりの時代背景の史料の1つも思える。そのときボロクソに言っていた社長たちもその後破産している社長は多いみたい。そして、すごいのが数十億といった負債を抱えて破産してもまたやり直して復活している社長もいるということ。その再起のきっかけにセミナーや講演をしてマネーの虎を宣伝文句として使っているところが本当にダサいとは思うけど、そういったなりふり構わず売上を上げるためなら何でもやるといった姿勢が復活するためのバイタリティになっているのかもしれない。昭和世代のハングリー精神のようなものを感じる。

その中でも南原竜樹さんがすごい。年商100億の会社が取引会社の突然の倒産から資金繰りが悪化して破産して、2年かけてすべての負債 (20億円) を返済して、ホームレスになってからまた再起してまた年商100億まで復活したらしい。経営能力がある人はゼロから成功できるというのがよく分かるモデルケースにみえる。失敗して門前払いする人がいる一方、助けてくれる人もいたみたい。

• 元『￥マネーの虎』南原竜樹さん 年商100億円社長が45歳でホームレスに転落、どん底からの復活劇

一方で、手を差し伸べてくれる人もいた。中でもありがたかったのは、旧知の社長が会社の空きスペースの提供を申し出てくれたことだ。すべてを失った南原さんは、間借りしたオフィスで「過去の成功にとらわれず、心を入れ替えて再出発する」ことを心に誓った。

「僕は、“老害化”した経営者をたくさん見てきました。高齢になった経営者がいきなり頓珍漢なことを言い出して、周囲を困惑させるケースも少なくない。だからちょっと早めに準備して、いろんな方に事業を引き継いでもらいました。(…中略…) 頭も体もしっかりしているうちに、自ら退くのが一番なんです」

手持ちの資金はゼロだったので昼夜を問わず働いた。
「資金を得るためにオートバックスで8時間、吉野家で8時間、モービル石油で8時間バイトして、吉野家ではお客さんがいない時に立ったまま寝ていました（笑）。

2時に寝てあまり眠れなくて6時半に起きた。スマホで ゴブリンスレイヤーⅡをみてから寝た。

プロジェクトの進捗報告

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

開発の中盤を過ぎて、これから追い込みへ入っていく。予定していたバックエンドの機能開発は完了した。私の頭の中ではもう完了までの見通しができていて、あとはフロントエンドの新規画面を構築したり、品質や堅牢性のための小さい改善をしていくといったことを残りの1ヶ月で行う。若いメンバーに経験を積んでもらうことも考慮しているため、サポートを最小限にしながらメンバーの成長を期待したいところ。見た目上の開発スケジュールは順調なのでマネージャーとしスケジュールの懸念はほとんどない。kit/vite アプリケーションの調査 を私が自らやっていて、これを一区切りつけないと次の作業に進めないところが、私の課題でもある。インターネットを検索してもみつからないことを、どのように考え、仮説を立て、調査して、意思決定していくかをメンバーに示したい。マネージャーが一連のワークフローについて業務の参考になるようものをみせることができればいいなと考えている。

以前 コミュニケーションのレベルについて考えたこと をベースにした方法論を社内の wiki にも書いてある。5段階のコミュニケーションのレベルがあり、多くの人たちはレベル4までしか到達しないのだけど、課題管理のスキルを身につけるとレベル5の「聞かなくてもわかる」というエスパーのような状態に達する。メンバーのうちの1人はこのレベルに片足を踏み入れていて、十分にうまく課題管理できているという話題も共有した。一方でレベル5に至るためのプラクティスや施策を、課題管理という文脈でもっとうまくできないか？というのはうちの会社のビジネスの中核でもある。とても難しい。いわば「気付き」を習得するための短期修行コースのようなものを作りたい、業務の中で。この話題を話し始めると、気付きの有無はその人の性格や動機づけにも関連するせいか、賛否両論の多様な議論に発散しやすい。私の立場としては、一定レベルまでは誰でも身につけられるスキルとして扱いたいが「気付き」が本当にスキルなのかどうか、実は確信がない。しかし、諦めることなく継続的に考えていきたい。

23時に寝て1時に起きて4時過ぎに起きた。昨日、打ち合わせに来た親がうちに泊まっている。親がいると4時起きになる。

しくじり先生

たまたま元プロ野球選手の 森本稀哲 選手のしくじり先生をみた。日ハムで新庄選手が活躍していたときにブレークした選手としてしか私は知らなくて、その後、どうなったのかも知らなかったが、キャリアハイを迎えた後は期待された成績を残せず、苦労しながらも野球を続けて引退試合をしてもらえるぐらいには活躍された選手だったようだ。無名のまま引退するプロ野球選手もたくさんいる中で、本人も話していた通り、一時期レギュラーとして活躍して、16年3球団もプロ野球選手で入れたことは間違いなく幸せな選手の側だと思う。

病気のため、小さい頃からコンプレックスを抱えてきた人生の中、それが改善したり悪化したりもしながら、いまふりかえっているのは、人は共通してそういうところに陥ると思えて親近感もわく。いろいろなしくじりもあった中での私にとって気になったのは次の言葉だった。

うまくいっていないときに頑固で他人の言うことを聞かないから自分で悪い状態に気付けなかった。

マイクロ法人やフリーランスの一番の難しさはここにあると私も思う。1人だとキャリアに与える影響に自身の状態がかなり大きい。「無知の無知」への 3ステップ を常に私は意識していて、自分の誤りに自分で気付けていない状態が一番怖い。私にもいくつか成功体験があるから、自信過剰になるとこのやり方ならうまくいくはずと誤った方向に進んでしまう懸念は避けられない。周りにいる人たちに「それ、おかしいよ」とか「何をやっているのか理解できない」とか言ってもらう機会や制度設計に気を配っている。私も他人の言うことをあまり聞かない傾向があるので稀哲さんの頑固で失敗したという体験談は親身に思えた。

スタンディングデスク受け取り

ジモティーで引っ越しで処分していた「DEVAISE スタンディングデスク」を2000円で購入した。メーカーのサイトがどこかわからにので amazon のリンクを張っておく。これは実家の離れではなく、うちのマンションでホットクックを置く台として使う。お昼に東灘区まで引き取りに行ってきた。メッセージを送ると相手のレスポンスの早い方で20分以内には返信が届いていた。メッセージのやり取りだけでシステムに慣れた相手だというのがわかる。本当は引き取りも13時の予定だったのだけど、こっちの都合が変わったので11時頃に早くできない？と訪ねたら20分後には11時45分にいけるよと返ってきて早く引き取りした。

実家との往復

親を送るのと、実家コワーキングスペース化のための椅子を運ぶのと、親戚と打ち合わせの3つを兼ねて実家へ車で帰る。道中、姉の職場へ立ち寄り相続関連の書類を渡して、親戚の家にお邪魔して少し打ち合わせして、16時過ぎには実家へ着いた。カフーツのいとうさんから引き取った椅子4脚 をようやく実家の離れまで運んだ。2脚ずつで2回かかった。あとは机を1-2つ探してくればコワーキングスペースとして形は成り立ちそう。

それからまた神戸へ戻る。1日で神戸と実家を往復したのは初めてかもしれない。帰りは途中で眠くなって淡路 SA で休憩した。

昨日は夜にいろいろ作業して、1時に寝て4時に起きて7時に起きた。

テックブログ執筆

先週から調査している内容 についてテックブログを書き始めた。マネジメントや実装をしていると筆が進まなくて書き始めるのが随分と遅くなってしまった。学校の試験前に、試験勉強やらずに部屋の掃除をやってしまったりするような感覚。午前中は昨日 go-ldap に送った pr がまとめてマージされた。その修正を取り込んだライブラリのバージョンで関連するところのコードをリファクタリングしていた。それでもようやく書き始めた。書き始めたら一気に 2/3 は書けた。本当は晩ご飯を食べた後にレビューできるところまで書いてしまおうと思っていたが、そこまで体力 (集中力) が続かなかった。なんとなく張り合いがなくて適当なところで妥協してしまう。

試行錯誤から学ぶ開発スタイル

たまたまみかけた記事でひどい内容の記事をみた。一読しただけでもやもやしていたのを知人と議論していて言語化できるようになったので書いてみる。

• エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう

もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。

こういうこと言い出すマネージャー (PO) 多いし、意見そのものは一理あるんだけど、これをエンジニアがイニシアティブとってやっていたらマネージャーいらないでしょ？ということを自覚していない。もっと言うと、PO という責任のある立場の人が大変という理由で責任放棄しているようにみえてしまう。(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 という記事では実際にテックリードまたはエンジニアがプロジェクトのイニシアティブを取っていると書かれている。もしそうするなら、まず自身のスキル不足や未熟さを受け入れないといけない。

マネージャー (PO) にとって大きな役割は意思決定であって、仕様案や計画において技術的なところがわからないのであれば、エンジニアに委譲したり相談して事前にいくらでも調整できるはずだし、その調整作業そのものはマネージャーの仕事の1つと言える。そういった調整をマネージャーがやるからエンジニアは実開発の設計や実装に集中できる。結果的に生産性も上がる。この文章から伺えることはリファインメントや計画に臨んだときにダメ出しされてやり直すことを手戻り、大変、効率が悪いとネガティブに捉えている。逆に言えば、最初から完璧に仕様案を作れるはずだと思い込んでいるふしがある。

そして、誰もが知っていることだが、最初から完璧な仕様案や計画など作れるはずがなく、不確実性を許容しながらスクラムやアジャイル開発といった開発方法論の取り組みで調整していくというのが、モダンな開発のやり方である。その試行錯誤や手戻りは無駄なことではなく、チームやプロジェクトが学ぶべきことの1つだという考えがこの文章からは読み取れない。そして、自分が仕様案を適切に作れなかったのを自分のスキル不足だと認めず、チームのエンジニアが議論に参加していないからだと責任転嫁している。それはマネージャーが技術的に大事なことを理解できていなかったとふりかえり、計画を修正したり、次に計画するときは同じようなことが起こらないよう、努めていくというのがスクラム的なプロジェクトの進め方になるはずだ。手戻りはアンチパターンではなく、学びの過程や必要な試行錯誤であると認めて受け入れるところから始めるべき。

2時に寝て7時半に起きた。昨日からよく寝た。また心機一転。

ldap エントリーの crud api

先週から ldap クライアントや そのプール を実装して結合テストも一通り書いていた。今日はそれらを使った crud な web api を一通り実装した。クライアント実装もテストもしっかり出来ているので後は時間の問題で1つずつ確認しながらコードを書いていくだけだった。こういう作業になると、まとまった時間があればすぐに終わる。他のメンバーのコードレビューをみたり、設計の話しをしたり、他に意識を取られてあまり自分の作業に集中できなかった。

言葉が通じないもどかしさ

先週「参考にして」と指示したものが「全コピー」で驚いてしまった。私がいくつか指摘したらすぐに削除し始めてさらに落胆した。自分の頭で考えて作業していないようにみえる。

開発というお仕事は自分で考えて、コードの1つ1つに明確な意図や根拠をもって書くものだ。もちろん、情報不足や設計に自信がもてなくて一時的に曖昧な実装にするときもあるけれど、それは懸念事項として把握しておくことで将来対応すればよい。基本的に追加するコードにはすべて意味がある。

他人が分からなくても自分が理解できているのなら、自分の考えを説明し、それが論理的であったり筋が通っていれば、私は自分の考えと違っていても構わない。説明できないコードを追加して、ツッコミを受けてなにも説明できない状況をみているのは本当に悲しい。

山田ズーニーさんの著書に書いてあった「考えないという傷」を思い出した。

• 「働きたくない」というあなたへ ７

23時に寝て何度か起きて8時に起きた。ホテルの部屋が暗いと朝になった気がしなくて2度寝したら寝坊した。

組織の対応と sns の議論

先日の sns 騒ぎ の続き。公式からの声明も出たので軽くまとめておく。

• PyCon APAC 2023におけるNOCコンテンツに関するご指摘について

簡潔な文章に事実の記述、責任の所在、関係者への配慮が含まれていて十分な内容にみえる。法律なども関係するため、弁護士チェックが必要なことを考慮すると、こんな短期間で組織の見解を出せたことは運営側の体制を鑑みることができる。それが適正かどうかは人によって判断は異なるかもしれないが、私はコミュニティ運営というボランティア主体の組織であれば十分なものだと思えた。その後のネット上の議論も、ちゃんと終えてはいないが、様々な見解で議論は進んでいるようにみえる。

今回みていて感じたことの1つに、コミュニケーションが成り立たない人が世の中にはたくさんいるということ。議論の前提や論理の出発点が異なる人たちは、一定の論理を含む全体や大局を理解できず、細部や詳細のところだけを拠り所に自身の論理を組み立てる。意見の差異があることはなんら問題はないが、論理が通じないのは議論の余地すらないようにみえた。そういう人たちを会話するときは前提条件を同じにしたり、思想の背景を共有したり、もっと時間をかけて丁寧にすり合わせていく作業が必要になる。そして sns のような、流れが速い不特定多数の議論はそういった丁寧な作業にまったく向いていない。だから sns で議論することは時間の無駄である。

コネクションを共有しないプール

go の非同期処理であまり使われることはないが、semaphore が準公式ライブラリとして提供されている。私はセマフォを気に入っていてたまに使う。

ldap プロトコルではコネクションの確立とログインに相当する bind の操作が分かれている。コネクションを確立したまま、ログアウトに相当する処理ができればプールを設けることでコネクションの再利用ができる。

• The LDAP Unbind Operation

しかし、このドキュメントの説明によると、unbind という操作は用意されているものの、ログアウトに相当する機能ではなく、クローズする前に通知するといった用途だと書いてある。unbind のリクエストをした後にはクローズするしかないといったものになる。それを踏まえて、プールはセマフォで同時接続数のみを制御するのでよいのではないかと思う。そんなワーカープールを実装してみた。

type ClientPool struct {
	config *config.LDAP
	sem    *semaphore.Weighted
}

func (p *ClientPool) Get(
	ctx context.Context,
) (*LDAPClient, error) {
	if !p.sem.TryAcquire(1) {
		return nil, fmt.Errorf("failed to acquire, wait and get later")
	}
	client := NewLDAPClient(p.config)
	if err := client.Connect(ctx); err != nil {
		p.sem.Release(1)
		return nil, fmt.Errorf("failed to connect: %w", err)
	}
	return client, nil
}

func (p *ClientPool) GetAuthenticated(
	ctx context.Context,
) (*LDAPClient, error) {
	client, err := p.Get(ctx)
	if err != nil {
		return nil, fmt.Errorf("failed to get: %w", err)
	}
	dn := p.config.BindDN
	passwd := p.config.BindPasswd.String()
	if err := client.Bind(ctx, dn, passwd); err != nil {
		p.sem.Release(1)
		return nil, fmt.Errorf("failed to bind: %w", err)
	}
	return client, nil
}

func (p *ClientPool) Close(client *LDAPClient) error {
	err := client.Close()
	p.sem.Release(1)
	return err
}

func NewClientPool(cfg *config.LDAP) *ClientPool {
	return &ClientPool{
		config: cfg,
		sem:    semaphore.NewWeighted(cfg.ClientPoolSize),
	}
}