1時に寝て何度か起きて7時に起きた。23時に帰ってきて一昨日にお土産にもらったロールケーキだけ食べてしまった。あかんねんけど、おいしかった。

ドッグフードテストと運用談義

リリースしたばかりのプロダクトを社内に導入するべくインフラ作業をしている。社内の管理者が運用を考慮していくつか質問がくる中で、開発側としても運用の考慮の足りないところがあったりして、実運用における不測の自体に対する運用を想定しておく必要がある。こういうやり取り自体が、開発者だけでは得られない知見なので貴重と言える。追加の検証をして、場合によってはなんらかの機能を作ったりする可能性もある。

ドッグフードテストは本当によく出来た仕組みだと思っていて、仮になにか大きな障害が発生してもそれはお客さんのところで発生する前に自社でみつけられればよかったと考えられる。もちろん障害がなければそれはそれで構わない。障害が発生してもしなくてもどちらも開発にとって大きな資産となる。いわゆる win-win のような関係と言える。開発視点から言えばドッグフードテストを行うと決めた時点でうちらはすでに勝っていると言えよう。

プロダクト説明会

毎週やっているチーム勉強会の時間を使って社内向けにプロダクトの説明会を行った。リリースを終えて、その後のドキュメント作りやパッケージングの最適化なども行えた。インフラは十分に機能しているし、ドキュメントも一通り揃っていて、機能はまだまだ足りないけれど、プロダクトとしての体裁はうまくまとまっていると自画自賛している。リソースをかけた分だけスケールするといった開発体制に変化しつつある。おそらく私がマネージャーとして必要なのもあと3-6ヶ月といったところではないか？重要なことは 開発方法論/開発ガイド に書いてあるし、課題管理 + イテレーション開発は特別なことをしなくてもうまくいくことも立証された。メンバーが私と同じように振る舞えば誰でもマネジメントはできるはずである。

来週からは次開発のマイルストーンに入っていく。メンバーが成長して私のマネジメント工数が減るようになってくれば、私も開発に入って下支えすればいいと考えている。まずは3ヶ月でどのぐらいの追加の機能開発が出来ていくのかを見定めたい。

開発合宿の日程確定

そろそろ宿を予約しないといけない。冬の開発合宿 の予定を2024年3月1-3日に決めた。現時点で参加者は4名確定していて、前向きに検討してくれている人が3名いる。昨年が4名だったので倍増して今年は8名程で行ければいいなと希望をもっている。不特定多数に声をかけられるほどキャパシティはないけど、もう3人ぐらい声をかけてもよさそう。

1時に寝てやや吐き気で起きて休憩して3時ぐらいに寝たか寝てないかわからないうちに8時に起きた。ジンをたくさん飲んで帰ってきたのでうまく眠れなかった。

カスタム overlay モジュールの改修

OpenLDAP Overlays という機能がある。以前 ppolicy_hash_cleartext と カスタム overlay モジュール を組み合わせると ppolicy が平文パスワードをハッシュ化してしまって、自分たちのカスタム overlay モジュールから平文パスワードを取得できないことをデバッグで検証した。ppolicy_hash_cleartext の機能が必要なのかどうかが私はよくわかっていないけど、協調して自分たちのカスタム overlay モジュールが動くならそれに越したことはない。

gdb でデバッグして振る舞いと対応方法が分かったところで issue を作成していた。メンバーが暇だったらやってくれるかな？と思っていたら誰も手をつけないみたいなので私がやろうと決めた。最早、私は c 言語をなんも分からんのやけど、chatgpt に質問しながら教えてもらえる。例えば、c 言語についてもこんな感じにヒアリングしながら実装する。

Q. c 言語で関数の最初に変数を宣言するのと、実際に変数を割り当てるところで宣言するのでなにか振る舞いが違ったりしますか？どちらの方がよいのでしょうか？

C言語は伝統的に変数のスコープとライフタイムを管理するために、ブロック（通常は関数または制御構造内）の先頭で変数を宣言するスタイルを採用してきました。しかし、C99標準以降では、変数はその使用が初めて必要となる場所で宣言できるようになりました。 これら2つのスタイルの違いは、主にスコープ、可読性、そしてある程度はパフォーマンスに関連しています。

スコープとライフタイム

関数の先頭で変数を宣言すると、その変数は関数全体で使用できます。これは必要に応じて変数を再利用できるという利点がありますが、一方でスコープが広くなりすぎて変数の使用を追跡しにくくなるという欠点もあります。 一方、変数を使用が必要となる場所で宣言すると、その変数のスコープとライフタイムはその場所からブロックの終わりまでに制限されます。これは、変数の使用をより明確にし、未使用の変数を避けるという利点があります。

可読性

変数を使用が必要となる場所で宣言すると、その変数の目的と使用方法がより明確になるため、コードの可読性が向上することが多いです。一方で、関数の先頭で変数を一括して宣言すると、変数の目的が明確でない場合や、それらがどのように使用されるのかを追跡するのが難しくなることがあります。

パフォーマンス

パフォーマンスについては、現代のコンパイラは非常に高度に最適化されているため、変数の宣言場所がパフォーマンスに直接的な影響を及ぼすことはほとんどありません。

結論

どちらのスタイルを選ぶかは、主にプログラミングスタイルやチームのコーディング規約、または特定のタスクに対する特定の要件に依存します。しかし、変数を使用が初めて必要となる場所で宣言するスタイルは、コードの可読性を向上させ、変数のスコープとライフタイムを制限するという利点から、一般的には推奨されています。これにより、コードの可読性が向上し、変数の使用範囲が明確になるため、コードの理解と保守が容易になります。

そっか。C99 で変数宣言の制約が撤廃されたんだということを学んだ。そんな感じで openldap についても chatgpt にヒアリングしながら開発したら意外とすんなり実装できてローカルでは動いた。レビューまでできた。

遅く帰ってきたわけではないが、うまく眠れなくて3時に寝て7時に起きた。

開発方法論／開発ガイドの更新

今週が開発の谷間の最後の週。毎週いろいろ資料を作ったり、あちこちのドキュメントを更新したりしていた。最後に残ったものの1つ (を2つに分割した) として、うちのプロダクト開発における開発方法論と開発ガイドを仕上げた。開発方法論は開発のマネジメント手法やプロセスの概念などを抽象的な表現で説明したもの。簡単に言えば、アジャイル開発とかスクラムとか、そういった概念の説明やなぜそれが大事なのかの意図や背景を説明したドキュメントになる。当初はこの1つしかなかったのだけど、実際に課題管理システムを使ってイテレーション開発をする具体的な話しと抽象的な話しを一緒に書くのはまとまりが悪いように思えてきた。抽象的な内容と実務に近い内容は分けて書くことにした。

• 開発方法論: プロダクトで採用している開発方法論の概念をまとめる
• 開発ガイド: 開発方法論を具体的に実践する方法についてまとめる

例えば、開発ガイドにはマージリクエストの運用について書いてある。どこの会社へ行っても私は次のような「マージリクエストを作成しなくてよいもの」という文章を書いている。

すべての修正にマージリクエストを要求すると開発がとても遅くなる。それは人間が介在するトコロがもっともコストを要求するからである。とくにコミュニケーションコストは開発の中でも最も大きいコストの1つである。レビューしなくてもコミット履歴は誰でも把握できる。修正内容が気になる開発者は自分でコミット履歴を確認すればよい。

従ってレビューの必要がないと想定される修正は直接 main ブランチに push してよい。例えば、軽微な修正は CI/CD の自動化により品質を担保できるように努める。テストを失敗させる修正を push してしまったとしてもデプロイできないために障害を発生させることはない。

この運用は軽微な修正だと思って push したものが不具合を発生させてしまうリスクを許容している。そのときは気付きの学びとして「ごめんなさい」で終わらせる。稀に不具合を発生させることよりも、開発の速度を上げる方を優先する。

カフーツさんイベント

カフーツ13周年Jelly〜カクサク（やりたいこと宣言）第1弾〜 に参加した。私がカフーツさんへ遊びに行ったときに人がたくさんいたことはない。記念イベントだったので参加者多いかな？と思って行ってみた。10人ぐらいいた。参加者の大半は私と同じぐらいか、それ以上の年配の方にみえた。やや年齢層が高め。13年やっているコミュニティなので同じぐらい歳をとったんだと思う。みんなでわいわい話しながら0時前まで飲んでた。ここ行くと基本飲み会w

YOHAKHU というクラフトジンがあってロックと炭酸割りで4-5杯ほど飲んでいた。これまでジンをあまり飲んだことがないので、普通のジンとの比較はできないが、強烈なインパクトのある風味で圧倒されてしまった。おいしいかどうかというよりもこれは強烈やなぁという所感が先にくる。さらに「余白」という名前がよい。いとうさんに影響を受けて私が「ゆとり」と呼んでいた概念にいくつか補強がされて、最近は私も余白という言葉を気に入って使っている。人生に必要な余白を忘れない飲みものがこれだと言えるかもしれない。なんだか酔っ払ったようなコメントになってしまった。

0時に寝て何度か起きて6時に起きて7時半に起きた。最近疲れからか6時ぐらいに2度寝してしまうことが多い。

定例会議

先週の東京出張で次開発の打ち合わせをしてきたので、今日はそこでいくつか絞り込んだものから決議を行った。すんなりと次の開発課題が決まって時間に余裕があったので、別の曖昧な要件の認識合わせもしていた。半年やって私自身のシステムへの理解やドメイン知識も付いてきたところではあるが、この要件の認識合わせが現状の範囲で私の理解が追いついていないところの最後のピースにもみえる。この要件の背景と解決方法の設計を論理的にやってしまえば、あとは課題管理に馴染んできたうちのメンバーがうまく開発してくれるのではないかと思う。

半年間の開発、課題管理とイテレーション開発のプラクティス、リリースできたという結果、そして主体変容を示唆して過去の自分と比べてどう変わったかをふりかえりで確認した。なんとなくメンバーの働き方が変わってきた感じがして頼もしくなってきた。少なくとも半年前より私が言っていることの意味や価値を理解して開発に取り組んでくれているのではないかと思う。次の開発がどのように展開していくのか、楽しみになってきた。今週はドッグフードテストのインフラ作業をメインにして来週の水曜日から次開発に入ることにした。

車でお買いもの

少し早めに帰ったので車で近所のスーパーへ買いものに行ってきた。過去の記録をみると1月29日に満タンで給油した。そのガソリンがまだ半分ぐらいある。うちの車は燃費のよいハイブリッドカーだ。いくつかの記事をみるとガソリンの消費期限は3-6ヶ月程度だと書いてある。目安としては3ヶ月程度で消費するのが望ましい。長くて6ヶ月程度にしないとエンジンや燃料系の故障の原因となりえるらしい。気温の変化が大きいとさらに劣化が早まるとかあるそうだ。平時はガソリン満タンじゃなくて少しずつ給油した方がよいことに気付いた。

4時過ぎに寝て7時に起きた。3時前まで相続手続きの書類作業して帰ってきてから本を読んでたら寝るのが遅くなった。

メンバーの oss へのコントリビュート

チームのメンバーがプロダクトで使っているライブラリにコントリビュートした。土日にライブラリのメンテナーからコメントがあって、その指摘にもすぐに対応して日曜日にマージされていた。ライブラリ側のレビューもすぐに終わってすごくうまくいったと言える。

• feat: enable DirSync control in search operation #436

もともとうちらが欲しい機能を作りかけた pr があったものの、作業途中でマージされずにクローズされていた。その残骸を参考にうちらの要件を満たせるかどうかの調査から始めた。調査を進めているうちにうちらの要件には足りない機能があってそれを拡張するようにも指示していた。すぐに出来たというのでライブラリにコントリビュートするように私が指示していた。

その後メンバーに聞いてみると、oss のライブラリにコントリビュートしたのは今回が初めてだという。開発者なら初めて oss にコントリビュートしたときのことを覚えているだろうか？私は、、、何だったか覚えてないが、おそらく linux distributor で働いているときに簡単なパッチを送った気がする。昔はメールや課題管理システムにパッチを投稿していたのが、いまは pr で気軽にパッチを送れる。若いメンバーがうまくコントリビュート経験を積めたことの背景に github がもたらしたパッチを送る簡単さがあるようにも思えた。oss にコントリビュートする機会は普通に oss を使って開発していればいくらでもある。マネージャーがその機会を見逃さず、ちゃんとメンバーにアサインしてあげることの大事さもあると思う。メンバーにはこの成功体験を活かして今後とも活躍してほしい。

サイトデザイン打ち合わせ

先日の ワイヤーフレームのレビュー の続き。顧問のはらさんとデザイナーさんと私の3人でデザイン案をみながらレビュー会をした。素人の私からみたら十分によいものが出来つつあるように思えるのでデザイナーさんのモチベーションを削がないようにサポートできればと思う。はらさんはデザインの専門家なので細かいところの確認や気付きをあげていてさすがという印象。きっとデザイナーさんのモチベーションも上がるのではないかと推測する。私はこれまでデザインの打ち合わせに出たことがなかったので参考になることが多々ある。サイトのトップは普通は会社の紹介があるものらしいけど、私がそれはいらないとデザイナーさんに伝えたのでトップで会社紹介を一切しない稀な構成のサイトのデザインが出来上がった。その後、社名ぐらいあった方がよいのではないかという話しもあってこれから変えるかもしれない。私の会社情報を書かない理由は次になる。

• 一見さんの訪問客がみるようなサイト (会社) ではない
• 知人やうちの会社の関係者がみて近況を手早く分かるようにしたい
• デザインはシンプルな構成にしたい

2時に寝て遅くまで飲んでいたせいか、やや吐き気もしながら朝起きてだらだらして11時ぐらいに起きた。

1password のロック解除を yubikey で行う

先日購入して触っていた yubikey bio の設定 の続き。1password のロック解除を指紋認証で行いたかったが、1password の 8.10.4 のアプリではロック解除をシステム認証で行おうとするとエラーが発生していた (バグってた) 。5月の頭に 8.10.6 がリリースされていてシステム認証のバグが直っていることに気付いた。1password のアプリケーションがどうやって linux のシステム認証を使っているかは次の1文に書いてある。

システム認証は、Linux のユーザーアカウントに組み込まれたアクセス制御機構を使用します。これは polkit と PAM (Pluggable Authentication Modules) という2つの Linux 標準に依存しています。この2つを組み合わせることで、安全な認証サービスを提供します

https://support.1password.com/system-authentication-linux/#about-system-authentication-security

私は polkit を使ったことがなくて初見でよく分かっていないが、どうやら polkit から pam を介して認証しているようにみえる。pam.d 配下の設定を調べてみると /etc/pam.d/polkit-1 がある。前回の設定で pam.d の設定とテストの方法を理解していた。ここまでくれば Module Arguments のドキュメントをみながらオプションを設定するだけ。1Password のロック解除をYubiKeyでやる の記事で origin/appid にホスト名を指定しているが、最新のモジュールだと指定しないときはデフォルトでホスト名が使われるようにみえる。

• origin: FIDO 認証手順の party ID を設定する、値が指定されない場合は識別子 pam://$HOSTNAME が使用される
• appid: FIDO 認証手順の application ID を設定する、値を指定しない場合は origin で使用されたものと同じ値が使用される (origin も指定しない場合は pam://$HOSTNAME)
• nouserok: 認証しようとするユーザーが authfile 内に存在しない場合や authfile が欠落/不正確な場合でも、認証の試行を成功させるように設定する
• cue: タッチすることを促すメッセージを表示するように設定する

これらを踏まえて u2f で認証が成功したらそれ以降の処理をスキップするように次の設定を先頭に追加する。

$ sudo vi /etc/pam.d/polkit-1
auth   sufficient   pam_u2f.so nouserok cue
...

cue を指定したことでパスワードプロンプトを表示せず、デバイスをタッチするように促される。よい感じ。

$ pamtester polkit-1 t2y authenticate
Please touch the device.
pamtester: successfully authenticated

これで pam の polkit の設定が正しいことを検証できる。この後に 1password のアプリケーションでロック解除するときに u2f を使って指紋認証できた。めっちゃ便利。

3時に寝て7時に起きた。昨日は深夜まで yubikey bio で 1password のロック解除の設定を調べていて遅くなった。また後日まとめる。

ストレッチ

今週は出張があったり、飲み会があったり、前日に深夜まで作業して疲弊していたりとあまり調子はよくなかった。いつも通りの右股関節の関節痛はあるし、腰の張りも少しあったし、右の太もも後ろの筋に違和感があるように感じた。太ももの後ろの筋を伸ばすストレッチが快適でお気に入りの1つなんだが、そこの部位でいつもとはやや違う別の張りを感じた。筋の張りの違和感をトレーナーさんにどう伝えてよいか、表現方法がわからなくて困ることが多い。今日の開脚幅は開始前156cmで、ストレッチ後158cmだった。疲労した体調を立て直すきっかけになってよかったと思う。

カフーツさん訪問

カフーツさんへ 昨年の6月以来 となる訪問をしてきた。毎月オンラインでいとうさんと話しているので身近ではあるけれど、リアルで会うのは約1年振りになる、本当に月日の流れる早さを実感する。ブログJelly Vol.132 に参加してきた。参加者は3人で18時から始まって1時半ぐらいまでお酒を飲みながらうだつの上がらない話しをしていたw ここにいる人たちと私は価値観があうのでだらだら話しているのが楽しい。

神戸と実家で2拠点生活しようと考えているという話しをしたら、実家のはなれを改修したスペースに宿泊できるなら airbnb で貸し出したらいいんじゃない？という話題が出て、たしかにそういう取り組みもできるなと感心した。そして、そのスペースにもう少し手を入れて小さいコワーキングスペースにしてもよいのかもしれない。すぐ側に田んぼもあるので農業体験なども簡単にできる。淡路島は気候もよくそこそこよい環境でコワーキングの拠点になるかはともかく、海が好きな人向けにはよいところかもしれない。実家のコワーキングスペース化という視点を今後も考えていきたい。

お酒飲んで新幹線乗ったせいか、新幹線の中であまり寝られなくて暑くていつもより移動に疲れた。その後1時に寝て何度か起きて7時に起きた。2日酔いではないが、寝起きの気分はよくなかった。

issue を作ることによるストレス軽減

昨日の打ち合わせのメモから議事録を作ったり、そこから新しい issue を作ったりしながら来週の打ち合わせの資料作りをしていた。資料を作っている途中、割り込みでメンバーのコードレビューが入ったりして、あまり資料作りは進捗しなかった。

打ち合わせした内容から issue を作る作業を、私は好きだったりする。何をやってよいかわからない状況というのは苦しい。issue を作ること、要件を言語化したり、背景を調べたり、他の issue との関連付けしたり、そういった手を動かすことがきっかけになって、その issue を明確化していく作業を積み重ねれば時間の経過とともに課題が解決するということを経験的に理解しているからだ。

大雑把に言えば、私にとって、issue さえ作れればその課題解決は優先順位付けと (解決までの) 時間の問題に置き換えられる。あれやらなきゃ、これもやらなきゃ、なにか抜け・漏れがあるんじゃないかと頭の中でもやもやしているものを issue という概念に変換することで考えなくて済むようになっていく過程がストレスを軽減している気もする。

コンテナ勉強会

先日公開したテックブログ とプラスアルファで勉強会をした。コンテナという汎用的な話題だったので CTO から社内向けにアナウンスされて (半業務命令っぽい雰囲気で) いつもより参加者は多かったように思える。10人前後は参加されていた。40分ぐらいで話し終えて20分ほど雑談の時間をとって盛り上がりは微妙だったけど、いくつか意見や質問が出たのでよかったのではないかと思う。

チームのメンバーが発表するときは私がモデレーターの役割をしている。私が発表するときはモデレーター兼発表者になってしまう。モデレーターと発表者を兼任するのはとても難しい。おそらく脳の集中力を向ける先が異なるからではないかと思う。モデレーターは質問者の質問を広げたり、コミュニケーションがうまくいくように手伝ったりする。回答から次の質問を考えたりもする。一方で発表者は自分の調べたことや伝えたいことを聴衆にわかりやすく伝えることのみに注力する。

モデレーターと発表者が同じになってしまうと、自分の説明のどこが伝わっていないのか、質問者の意図を組むにはどうすればいいかといったモデレーターの視点がなくなってしまう。以前 tenntenn さんの個人カンファレンス に参加したときに1人2役でパネルディスカッションをされていて、そのときに同僚からあまりやり過ぎると人格崩壊するから気をつけた方よいといった忠告を受けたと冗談で話されていた意味が理解できた。役者が他人になりきるように、これは兼任じゃなくて1人で2つの人格を演じないといけない。そんな器用なことはそうそうできない。

能のサイトを眺めつつ 世界を変えた“愚か者”フラーとジョブズ をみているうちに寝落ちした。0時過ぎに寝て何度か起きて8時過ぎに起きた。休日以外に8時まわるまで寝ていたという記憶が直近数ヶ月にはないので久しぶりに寝坊した。起きたら8時10数分でそんなことあるはずないとか思ってしまって脳が現実を受け入れられなくて起きた時間を認識できなかった。明らかに8時10数分なんだけど、時計が壊れているなとか思ってしまった。

開発課題の打ち合わせ

大きく時間を使って次開発の打ち合わせ。事前にいくつか開発課題を洗い出せているが、その優先順位付けをしていかないといけない。開発メンバー + 別チームのコンサルタントにも入ってもらって各々の意見を出し合うといった会議をした。私が議題の資料を予め作っておいた。その進行に応じて議論や意見が盛り上がったのでうまくいってよかったと思う。 大項目でまとまった機能をやるよりも、個々の機能単位に優先順位付けした方がよいだろうという話しになって小さい単位で担当者を割り当てて開発を進めていくことになる。いずれはすべてやるが、開発の順番を決めていくのは意外と難しい。

話し終えてからメモをまとめ直しているうちに私自身が要件を詳細に把握できていない要件があることもわかってきた。空中戦だとわからないままふわっと進んでしまうので、文字に落とし込んで整理した上で、本当に必要なものをさらに深堀りして議論しないといけないことに気付いた。

少ない人数で会議をやる利点の1つとして、みんなの意見を順番に聞いていく余裕をもてることがあげられる。「誰一人取り残されない」とどこかの省庁がミッションにあげているように、うちのチームも課題管理を駆使して、それぞれのメンバーができることややりたいことでチームに貢献するような開発にしていきたい。もう半年やって課題管理に慣れてきているので、次開発は前回のようなやり方を教えるところからスタートにはならないはずだと思う。

打ち上げ

4月末にリリースを終えたので区切りとして打ち上げしてきた。うちのチームメンバーと偉い人の5人で行くのだと思っていたら直前に社内のメンバーにたくさん声を掛けたそうで10数人での飲み会になって送別会や部署のキックオフみたいな飲み会になった。賑やかでよかった。個人だとあまり行かないようなちょっとお値段のするコースでよいものを食べられておいしかった。日本酒もいろいろ飲んだ。神戸の酒どころに住んでいるので日本酒に関心をもつようになってきた。

• 山形 上喜元
• 愛知 醸し人九平次

18-20時と打ち上げやって、21時に新幹線を予約していたのでそのまま帰ってきた。このスケジュールの段取りもちょうどよかった。お酒を飲んで新幹線に乗ると思いの外眠れなくてそこだけ疲れた。

0時に寝て何度か起きて5時半に起きてテレビで朝のニュースを聞き流しながら7時に起きた。

資料作成

今日はメンバーの1人が休暇だったため、打ち合わせはなしで資料ばかり作っていた。今週のチーム勉強会の発表は私が担当するのでその資料を作ったり、リリースを終えて社内向けにプロダクトの説明のための資料を準備したりしていた。これまでたくさんの資料を作ってきてるので改めて作るというよりは、過去に作ったものを洗練させたり、集めてきて補足する程度の作業になりそうな雰囲気だけわかってきた。

aws app runner の情報収集

App Runner Night !! にオンラインで参加した。AWS Startup Community というコミュニティがあることも知らなかった。顧問のはらさんが LT 発表すると聞いていたのでそれをみようと思ってながらで聞いていたので他の発表はあまりちゃんとみていてない。特別に目新しいことはなかったし、発表の中でもいくつかちょっとそこ怪しいんじゃない？とか思いながら他の作業をしていた。

私も余裕があれば app runner でサービスを動かしてみてその勘所を把握しておきたい。ecs がやりたいことに比べて使いにくいという印象は私もずっと思っていた。実質 k8s 以外のコンテナプラットフォームは aws しかないので app runner がよいものかどうかに関心をもっている。

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日は「移動」というテーマでいつも通りいとうさんがわーっと話をしていた。この2ヶ月に新しい官民の取り組みが始まったらしい。なんか空気だけでダメそうにみえる。

• 「テレワーク・ワーケーション官民推進協議会」を設立しました！

このサイトでは次の2つの用語を定義している。ブレジャーを初めて知ったけど、発音しにくくて語呂が悪いだろとか思えた。

• ワーケーション (Work + Vacation)
• ブレジャー (Business + Leisure)

このサイトにあるワーケーションの実施形態には共感するところもあって次の4つに分類している。IT 業界で多いのは合宿型とサテライトオフィス型かな。

• 福利厚生型
• 地域課題解決型
• 合宿型
• サテライトオフィス型

あとどういう文脈だったか忘れてしまったが、身体感覚で「芭蕉」を読みなおす。 『おくのほそ道』謎解きの旅 という本を紹介された。能の探求者が書いた独特の視点から松尾芭蕉を取り上げた本らしくて、なんかおもしろそうにみえたのですぐに購入してみた。紙の文庫本しかなかった。読んでみる。

少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

• Docker とは何か？

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか？と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない？

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。