0時に寝て6時半に起きた。朝起きてからドラクエタクトしてた。

リリース

今日がプロダクトのリリースとなる。先週前半にはテストを完了して開発作業も終えてインフラの整備やドキュメントの作成に注力してきたのでここ数日の様子をみれば無難に順調にリリースできたようにみえる。結果からみれば「余裕でしたね」とコメントされても大きく外れてはいない。6ヶ月でやってと言われた開発を、3ヶ月目に5ヶ月でできると勝手に短縮して、4ヶ月目にやっぱ間に合わないからもう1ヶ月待ってと6ヶ月に戻した。一人時間差攻撃みたいなマネジメントをして完了した。ここ2ヶ月ほど私がいくつか開発やデバッグを肩代わりをして開発の下支えをした。別に私がやったらいけないという制約はないけれど、メンバーの教育も含まれているプロジェクトなのでなるべくメンバーが経験を積んでスキルを磨くのが望ましい。この件はちょっとズルしましたと進捗報告している。まずはうまくいって安心した。

ともあれ、私がプロジェクトマネジャーという肩書きをもって臨んだプロジェクトで概ねスケジュール通りに開発を進捗させてお客さんの要件にあったプロダクトを作り上げたことそのものが、私のキャリアにおいても重要なことであるし、うちの会社では課題管理という分野をビジネスの中核にしていく上での最初の実績として大きな意義のあるプロジェクトだった。課題管理はチーム開発において強力な武器になる。これまでの自分と、そう大きく変わらない働き方をマネージャーでやっても結果を出せたことは自信にもつながる。

この後は6ヶ月間の大きなふりかえりも控えていて、課題管理に溜まったデータを分析して、次開発への改善などにもつなげていこうと思う。過去の経験則では課題管理の価値を実感してもらうのに半年はかかるというのが私の持論。それは比較的、最初から課題管理システムを使えていたうちのチームでも同じだと思う。私がやっている課題管理とメンバーのそれとの違い、その違いによる実際の業務における成果などを分析していくと示唆を与えられるのではないかと思う。

22時頃から寝て何度か起きて7時に起きた。久しぶりに夢をみた気がする。オフィスに着いた頃にはもう覚えていないけど。

リリース前日

プロダクトの開発、テスト、パッケージングとすべて完了していてドキュメントや社外に提供するためのインフラの仕組みの作業を行っている。これはリリースまでに出来ていなくてもプロダクトが動かないわけではないのでリリース後もしばらくは継続する。今日は運用ツールのちょっとしたリファクタリングをしたり、コードレビューをしたり、windows インストーラーの調査をしたりと、なんやらかんやらで忙しかった。

示唆を与えなければならない

ここ1ヶ月ほど私がクリティカルパスの作業を担ってきたのでメンバーの作業を落ち着いてみる余裕がなかった。たまたまというか、私がクリティカルパスから脱したことでメンバーのレビューやアドバイスを行うときの余裕も戻ってきた。CSK の新人研修で習うことに社是と経営理念とサービス精神という言葉がある。

サービス精神

• お得意様にあくまでも満足していただく技術を提供しなければならない
• 技術は高度で専門的でなければならない
• 仕事は正確に、かつ迅速・効率的に行なわなければならない
• 常に、お得意様の利益を考え、示唆を与えなければならない

新人研修ではこれらを暗唱して暗記させられる。20年以上経ったいまでも覚えている。もともと私の考え方にあっていたのか、それとも新人の頃に刷り込まれたのか、その両方なのか。いま見返すと私の課題管理の考え方とこのサービス精神には共通しているところもある。その上で最後の 「示唆を与えなければならない」 という言葉を、今日メンバーとやり取りしているときにふと思い出した。

アドバイスをしていると、なぜこの懸念を考えずに作業を継続してしまったのだろうか？と思う機会がちょくちょくある。そのときに質問してその背景を尋ねたり、効率や保守のための考え方を教えたりする。ふと私が指摘しなかったらそういった効率や品質の低い結果のまま進んだのだろうと推測される。当たり前の話しだが、意識的にしろ無意識にしろ、個人では気付けなかったフィードバックや示唆を与えてくれる人がいなかったら個人の能力では限界がある。気付きがないところに学びも改善もないから成長もしない。いまお手伝いしている会社はこれまで個人でやってきた働き方を、チームで協調して働くように変えていきたいという話しから始まった。私自身、どちらかと言えば個人主義の働き方をしてきた方でチームでの働き方をちゃんと教えられるか、当初はあまり自信がなかった。半年やってきて、チームで働く上で必要なことはメンバーのアウトプットに対して質問するだけでよかったんやと理解できるようになってきた。個人の視点しかない働き方と他者の視点から常にツッコミが入る働き方はまったく異なる。うちのメンバーをみていて、まだまだ道半ばではあるが、それまでの状況と私が啓蒙している課題管理は、おそらく根本的に働き方を変えてしまっていることにようやく私の理解が追いついてきた。

0時に寝て6時に起きた。午前中は掃除したり買いものへ出掛けたりムック本を買って読んだりして午後からもくもく会に参加してきた。昨日から休日って心地よくて素晴らしい時間だということに改めて気付いた。

いまがわかる地政学

やぎさんからおすすめされて オールカラー図解 いまがわかる地政学 を読んだ。ちょうど余裕もあったので読んでみることにした。私も過去に地政学の雑誌を気分で買って読んだことがあった。教えてもらってなければいまは買ってなかったと思うが、関心のある分野ではある。

見開きの2ページで左ページを地図で図解しながら右ページにその説明が書いてある。読み始めてすぐにドキュメントランドスケープを構築できるので読みやすい。地政学なので地図で説明するのがわかりやすいのと、特定の地域の限られた国で、且つ話題を限定して説明するから簡潔でわかりやすい。過去にはアメリカ／イギリス系統とドイツ系統の2つの地政学があり、地政学はナチスドイツの御用学問となり、ドイツが敗戦したことによりドイツ系統の地政学は封印指定された。日本で学ばれていた地政学もドイツ系統だったようで、戦後 GHQ により封印指定されていまに至るらしい。

地政学の解説を読んでいて、なにかを分類して、そこから得られる知見に方向性や解釈を与えて、さらに歴史が積み重なると立派な研究や学問になるという印象を受けた。観察して分類して仮説を立てて記録を取り続けるとそれはもう科学である。課題管理につながるヒントもありそうな気がしている。課題管理は事象が発生した記録を取り続けて、ある程度溜まったところで分類したり分析したりできる。

もくもく会

【三宮.dev オフライン】もくもく会 に参加した。昨日の続きでプロダクトのドキュメントを2時間ほど書いてた。集中してドキュメントと mermaid のフローチャートを書いた。初めて参加された方も何人かいたのでいろんな人の話しを聞くこともできてよい機会だった。参加者の1人から 芋屋HUG のスィートポテトをもらった。お店の存在は知っていたが、1度も買ったことがなくて初めて食べておいしかった。調べてたら神戸発祥のお店っぽいので東京出張するときのお土産に買って行ってもよさそう。よいお土産を知ることができてよかった。

昨日は夜に晩ご飯の買い出しにオフィスを出てから、また戻って作業して22時頃に帰ってきて0時に寝て7時に起きた。今日はここ1-2ヶ月では久しぶりにプロジェクトの締め切りに追われずに落ち着いてやりたいことができた。

ストレッチ

先週に比べれば負荷は減っていたので右腰の張りは少しよくなった。むしろ先週が悪過ぎた。いつも通り右足全般は張りがあるのと、お尻と太ももの境界のツボもいつもより効く感じがして辛かった。今日の開脚幅は開始前155cmで、ストレッチ後158cmだった。リリースに向けての根を詰めてやってきた作業も一段落したのでこれからは体調をよくする方向に意識を向けていけるかもしれない。

プロダクトのドキュメント

追われてないので余裕をもって昨日の続きで2時間ほど書いてた。3 (ページ) ファイルを追加した。ドキュメントは一気に書くとしんどい。少しずつ書いていけば徐々に文量が増えてさらに内容も洗練されていく。休日にドキュメントを書いていると途中で割り込みが入らないから集中できて効率がよい。ソースコードにしろ、文章にしろ、書くときに割り込みが入らない状況は重要なことに最近気付いた。この日記もまとめて数日分を (下書きから) 書くときがあるが、それは集中して書ける時間を取れそうと見計らって書いている気がする。どうやら私は割り込みの有無と書くときのモチベーションに相関関係があるように思える。

きんとん

夕方にたまたま出掛けて、よく行くお店で晩ご飯食べようと思ったら開店の20分前で諦めて帰ろうとしていたときにたまたま目にとまった。以前から人気のあるお店であることは知っていたし、いつか入りたいと思っていたお店で、中途半端な時間帯だからお客さんも少なくて、いまがその「いつか」だと気付いて きんとん 神戸店 に入ってみた。後で食べログのとんかつ百名店2022の1つであることを知った。昔からあるから古いお店だと思い込んでいたけど、実際はそうでもなく、店内はオープンでモダンな佇まいで少し驚いた。特選ロースかつ定食が1900円。ちょっと高め。おいしかったので十分に満足した。タレもとんかつソース、わさび醤油、ヒマラヤ岩塩があって、それぞれに味わいがあってよかったし、キャベツにかけるドレッシングもオリジナルでおいしかった。接待にもよさそう。

第4期のふりかえり

年度が変わって1ヶ月が経とうとしている中、ようやく昨年度のふりかえりができる状況になってきた。今年は3月に余裕がなくて少し後ろにずれ込んでいる。この年度ふりかえりも毎年やっているから知見も溜まっていくし、新しい発見もある。来週の雑談に向けてまずは叩き台を作った。もう2-3日ほどかけて資料を洗練させていく。

一昨日あまり寝てなかったので昨日は早く帰ってきて20時から22時ぐらいまで寝て、その後0時ぐらいから寝て何度か起きて7時に起きた。久しぶりによく寝た。

プロダクトのドキュメント

プロダクトのインストールや設定のドキュメントを mdBook で書いている。チームのメンバーが reStructuredText を知らないというので markdown で書ける方がいいかと思って採用した。4月上旬から環境作り して時間のあるときに少しずつ書き足したり、メンバーにも書いてもらうように促したりしていた。情報としてはだいたい半分ぐらい書けたかなぁといったところ。まだまだ内容は足りていない。

内容とは別に、ある程度まとまったドキュメントとしてのわかりやすさを、例えば Sphinx のようなツールと比較してどうかというのを書き終えたら比較してみようと思う。1つ懸念点としてわかったことに SUMMARY.md からリンクされていない md ファイルはレンダリングされないという仕様になっていて、この仕様の是非や目次の作り方の構成に制約が課せられることへの懸念がある。次の issue でも議論されている。

• It is recommended that all md files in the directory be converted to html #830
• Files not in SUMMARY.md are not parsed #702

mdbook は私が想定したほど普通のドキュメントツールが備えているような機能を実装していなくて、それは markdown を独自拡張したくないという意志なのかもしれないけれど、本当に最低限の体裁だけでドキュメントのようにみえるようにするといったところしか関心がないのかもしれない。ちょっと触った雰囲気でも本格的なドキュメントを書くツールではないと感じている。私がまだわかっていないだけかもしれないのでもうちょっと触ってみてまた所感をまとめる。

チーム勉強会

2週間ぶりのチーム勉強会。メンバーが Stable Diffusion の話しをしてくれた。学生時代に関連する研究をしていたらしい。本人は研究していたから内容を理解しているのだろうけど、一般人の私には全然ついていけなくて説明そのものが難しいなと思いながら聞いていた。そして、最近の研究成果などを紹介しながら15分ぐらいで終わった。論文の内容を理解できているのなら、その内容を解説してもよかったのでは？と思ったりもした。1時間の枠があるのだからもっと話してもらってよかったのだけど、準備も大変だったのかもしれない。時間が余っていたので私がモデレーターとして質問したり、他の参加者に質問を促したりしながら残り時間の40分ほど雑談していた。そういう意味では雑談会としては多くの質問やコメントが出てよかったと思う。意図的に発表時間を短くして雑談会にもっていくというやり方もあるのかな？と勉強会の運営の学びにもなった。

2時に寝て7時に起きた。昨日も遅かったので0時ぐらいに晩ご飯を食べてうまく眠れなかった。体調が悪かったので今日は早めにお仕事を終えて帰って寝てた。

rpm パッケージングのためのアーカイブ

プロダクトは docker compose を使ってデプロイするので docker-compose.yml と関連する設定などのサンプルファイルをパッケージングして rpm として提供する。ビルドは必要なく、初期は数ファイルだったので rpm の SOURCES ディレクトリに直接配置して個別に SourceXx と指定してパッケージングしていた。設定のサンプルファイルが増えてくると1つずつ指定するのが面倒になってきてアーカイブすることにした。rpm を作るための Makefile で次のように git コマンドからアーカイブを作ることができる。このやり方のメリットの1つは git でアーカイブすることでリポジトリにコミットされているものだけが使われるため、対象ディレクトリに中間ファイルなどが散らかっていても無視してくれて都合がよい。

VERSION          = 1.0.0
SRC_PREFIX       = my-product-$(VERSION)
SRC_ARCHIVE      = $(SRC_PREFIX).tar.bz2

SOURCES/$(SRC_ARCHIVE):
	git -C ../my-src archive HEAD --prefix $(SRC_PREFIX)/ -o $(SRC_ARCHIVE)
	mv ../my-src/$(SRC_ARCHIVE) $@

make したときに my-product-1.0.0.tar.bz のようなアーカイブが rpm パッケージングするときの SOURCES 配下に置かれる。そして rpm の spec ファイルでこのアーカイブを Source0 として指定して %prep で %setup マクロを呼び出すと展開される。

Source0: my-product-%{version}.tar.bz2
...
%prep
%setup

たったこれだけで spec ファイルの Source 管理をシンプルにできて保守コストが下がるのでうまいやり方だなと学びになった。

0時に寝て6時に起きた。昨日は晩ご飯の買いものに行こうと早めに帰ろうとしたら雨降りでそのまま帰って家でだらだらしてた。

リリース前テスト

来週の火曜日がリリース日になる。4月から3週間ほどかけて行ってきたテストケースを完了した。致命的な不具合もなく、テストの過程でみつかった不具合も修正済みで予定していたテストが完了となった。ここ2週間ほど、テストして issue が登録されると、私が細心の注意を払って内容を精査して、即日で fix して検証したりしていた。それもあってテストでみつけた不具合はほとんど fix した。あとはリリースのためのパッケージングやドキュメント作成、インフラ作業などへ移っていく。アプリケーションの振る舞いに影響を与えるものではないので私の中では肩の荷がおりてプレッシャーも軽減されて少し安心できた。よかった。よかった。

docker hub のプライベートリポジトリ

先日 docker hub の rate limit に引っかかったこともあり、docker hub の有償アカウントを使うことになった。team プランは5人以上必要らしいので pro アカウントで契約してもらった。有償アカウントなら無制限のプライベートリポジトリを提供できる。docker hub でリポジトリを作成していて、いまさらながらにリポジトリ名にスラッシュを含められないことに気付いた。基本的にはハイフン区切りでスラッシュの代替する名前になっていた。これまで自分で docker image を扱ってこなかったので今更ながらに気付いた。

社内のコンテナレジストリから docker hub のプライベートリポジトリへの promotion のスクリプトを書いていた。bash の連想配列を使ってコンテナレジストリのマッピングを定義してあとは pull/push するコードを書くだけ。

declare -A repos
repos["internal-my-repo1"]="external/my-repo1"
repos["internal-my-repo2"]="external/my-repo2"
for internal in "${!repos[@]}"; do
  external="${repos[$key]}"
  echo "pull from: $internal"
  echo "push to  : $external"
done

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

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。promotion のスクリプトを書いていたら20分ほど遅れてから参加。今日の話題は chatgpt だった。少し前に 雑談会 したので歴史や原理的な仕組みなど、調べたことを参加者と共有しながら今後の社会の変化などを議論していた。私も関心のある内容なのでおもしろかった。いまや私は日々の開発業務にも chatgpt を使って調べものをしたりサンプルコードを書いてもらうのが普通になりつつある。そのうち ide と連携してテストコードの叩き台なども書かせるようにしてみたい。

いとうさんは chatgpt をみて、人間は働く意欲がなくなるのではないかといった懸念を表明されていた。いまのところ、ドメイン知識をもっている人がより効率よく働けるようになるツールでしかないという私の認識だが、あと3年ぐらいしたら人間を遥かに超えていって、chatgpt の出力をそのまま業務に応用する日も来るかもしれない。llm というのは次にくるもっともらしい単語を膨大な学習データから統計的に選択しているだけで、実際には内容を理解していないし、人間のように創造的な行為もできない。大雑把に言えば、インターネットの空気を読んで発言すれば人間っぽいというのはすごいことだし、便利で役に立つし、働き方も変わっていくだろうけれど、その延長上で変わる世の中が、私の人生における行動に影響を与えるほどではないと考えている。そういった話をする過程であんちぽさんの言う「価値観を育てる」という文脈が頭の中に残っていて、llm ぐらいでは揺らぎそうにはない気がしている。

40代で大した強みもなくて不安みたいなのは共感はするけど、一方で、何歳であっても、他人との比較で生きている限り、一生不安は消えない。どんな年代であっても、自分の正しいと信じることをすればいい。もしそれがないのなら、問題の本質は年齢ではなく、価値観を育てやれてないことの方である。

— あんちぽ 🎨💙 (@kentaro) April 17, 2023

ただ it 業界以外にもこんなに話題が拡散しているプロダクトはそうそうないので世の中をどんどん変革していくのだろうというのは、異業種の人たちと話していても実感できた。

0時に寝て2回ほど起きて7時に起きた。わりと気分がよい方。

unix の crypt(3) というライブラリ実装

google の Admin console の api の REST Resource: users で hashFunction として crypt を選択してハッシュ化したパスワードを連携できる。

crypt - C crypt ライブラリに準拠しています。DES、MD5（ハッシュ プレフィックス $1$）、SHA-256（ハッシュ プレフィックス $5$）、SHA-512（ハッシュ プレフィックス $6$）ハッシュ アルゴリズムをサポートします。

この crypt というのは単純に sha256 や sha512 でハッシュ化すればよいわけではなく、歴史的経緯でそれぞれの os ごとにある crypt ライブラリの実装に依存しているらしい。

$ man 3 crypt

おそらく google のドキュメントがいう C crypt ライブラリというのは glibc のことを指していると考えてよいと思うが、go の準標準パッケージである golang.org/x/crypto を探してもその実装は存在しない。これも推測だが、仕様が曖昧なものを go の開発者は実装しようとしないのだと思う。とはいえ、c の crypt ライブラリをラップして go から使うのも面倒と言えば面倒なので誰かが crypt ライブラリを真似て野良実装して、それが一部で使われていたりするようにみえる。しかし、なぜかそのオリジナルを作った開発者はそのコードのリポジトリを削除していて、ソースコードのコピーがまわりまわって、いま github.com/GehirnInc/crypt で保守されているらしい。このライブラリを使ってエンコードすると c の crypt ライブラリの出力と一致することは確認できた。この実装をみれば、単純にエンコードすればよいといったものではないことが伺えるので pure go のライブラリとして共有されているのは有り難い。

このライブラリを使ってハッシュ化した文字列と c 言語のコードも chatgpt に書いてもらっていくつか一致することは検証できた。デバッグしていて、もう1つ salt を生成も特定の文字しか使えないのでうっかり乱数を使って文字列生成していると間違ってしまう。

var saltChars = []byte("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789./")

func GenerateSalt(method Method) []byte {
	var b = make([]byte, 16)
	charsLength := len(saltChars)
	for i := range b {
		b[i] = saltChars[rand.Intn(charsLength)]
	}
	var salt []byte
	switch method {
	case SHA256:
		salt = append([]byte("$5$"), b...)
	case SHA512:
		salt = append([]byte("$6$"), b...)
	default:
		panic(fmt.Sprintf("unsupported salt method: %s", method))
	}
	return salt
}

ここで生成した salt を使って github.com/GehirnInc/crypt を使うとこんな感じで crypt を使って google のユーザーアカウント連携ができる。

func Crypt(password, salt []byte) (string, error) {                              
    if len(salt) < 3 {                                                           
        return "", fmt.Errorf("invalid salt: %s", string(salt))                  
    }                                                                            
                                                                                 
    var crypter crypt.Crypter                                                    
    switch string(salt[0:3]) {                                                   
    case "$5$":                                                                  
        crypter = crypt.SHA256.New()                                             
    case "$6$":                                                                  
        crypter = crypt.SHA512.New()                                             
    default:                                                                     
        return "", fmt.Errorf("unsupported salt prefix: %s", string(salt[0:3]))  
    }                                                                            
    hashed, _ := crypter.Generate(password, salt)                                
    err := crypter.Verify(hashed, password)                                      
    return hashed, err                                                           
}

ハッシュ化した文字列が正しいかどうかは実際に google にログインしてみないと判別できないのでわりとデバッグや検証に時間がかかった。

リファレンス

• 色々な Unix 系 OS の crypt(3) について調べたら面白かった話
• /etc/shadow などで使われるハッシュ関数、 crypt(3) を Go 言語で実装しました

0時に寝て何度か起きて7時に起きた。変な夢をみた気がするが、どんな夢だったかは思い出せない。

openldap のカスタム overlay モジュールのデバッグ

先週末から openldap のカスタム overlay モジュール の開発やデバッグをしている。openldap のソースコードや gdb のデバッグのやり方にも慣れてきて私の中でも理解度が増してきた。

openldap サーバーのデバッグログは次のコードが設定されている。

#define LDAP_DEBUG_TRACE  0x0001

このコードを slapd.conf の loglevel に設定するとデバッグログを出力できるようになる。

loglevel stats 0x0001 ...

このときに ppolicy の overlay モジュールがどのタイミングで呼ばれるかをデバッグログを確認しながら検証した。

overlay ppolicy
ppolicy_hash_cleartext on

結論から言うと次の2点になる。

• overlay は slapd.conf の後ろに書いた方のカスタムモジュールが先に実行される
• ppolicy_hash_cleartext は ppolicy_add のタイミングで平文パスワードをハッシュ化している
  • gdb でデバッグすると op->o_request->oq_add->rs_modlist も op->o_request->oq_add->rs_e->e_attrs も同じアドレスを指す
  • overlay の処理は db に書き込む前と後の2つのタイミングがある

slap_passwd_hash( &(pa->a_vals[0]), &hpw, &txt );
...
pa->a_vals[0].bv_val = hpw.bv_val;
pa->a_vals[0].bv_len = hpw.bv_len;

カスタム overlay モジュールを使って openldap からパスワードを取得するには次の順番で処理が行われることを理解しておく必要がある。

1. mycustom_add <= このタイミングで平文パスワードを取得しないといけない
2. ppolicy_add <= このタイミングで平文のパスワードをハッシュ化する
3. mycustom_add_response <= このタイミングではすでにパスワードがハッシュ化されている

openldap のことを何も知らない素人が chatgpt と一緒にデバッグしてこのことを2日で理解できた。開発のやり方が変わっていく予兆を感じた。

0時に寝て7時に起きた。午前中は洗濯して、昨日届いたお肉を焼いて朝ご飯にしながらドラクエタクトやってた。

yubikey bio の購入

デスクトップマシンが不調だった1-2ヶ月ほど m2 macbook air でお仕事をしていた。デスクトップマシンと比べて明らかに便利だったことがある。1password にログインするときに os のシステムアカウントも利用できて、具体的には指紋認証によりパスワード入力を必要としなかった。デフォルトでは2週間ごとにパスワード入力を必要とする設定になっているが、これも無効にすることもできる。パスワードを忘れないように1ヶ月に1回ぐらいは手入力してもよいかもしれない。生体認証はその精度にまだ懸念はあるそうだけど、こういった日常的な認証における用途ならそれほど高い精度を要求しないことに気付いた。私は個人でお仕事しているから日常でオフィスに保管している物理的なデバイスを盗むのは難しい。他にも linux で使える指紋認証のデバイスを探してみた。しかし、現時点では usb の指紋認証デバイスは windows 一択になっていて linux はサポートされていない。YubiKey ぐらいしか、私はみつけることができなかった。

YubiKey Bio - FIDO Edition をオンラインストアで購入した。船便で購入したので届くまで1ヶ月ほどかかる。急ぐものではないので気長に待つ。

YubiKey Bio - FIDO Edition
$90

Shipping & handling
Economy - 10-20 Working Days - No tracking available
$5

Duties, taxes and/or carrier subcharges
$14.68 USD

日本にお店がないので輸入扱いで関税がかかるのかな？また会計システムに登録するときに税金の計上方法を調べる必要がありそう。

自分たちでやろうとしないことを他人は助けられない

他社のプロジェクト開発のお手伝いでプロジェクトマネージャーとしてこの半年をマネジメントしてきて分かるようになったことが1つある。米軍がアフガニスタンから撤退するときの方便のようにみかけ、ロシアのウクライナ侵攻のときにウクライナ軍が善戦して西側諸国の支持を得たことでその正しさを再確認できた言葉がある。

バイデン大統領は演説で「当事国の軍隊が戦う意思がないのにアメリカが戦うわけにはいかない」という趣旨を繰り返した。

アフガニスタン崩壊と日本への教訓

2月からプロジェクトの開発遅れがみえていてスケジュール調整している。プロジェクトの開発がうまくいかないことの全責任は私にあることは間違いない。その点には一切の懸念も疑問もない。昨今の働き方改革で有休取得が大事なことも理解していて、平均して取得するなら毎月1-2日休むことになる。それは理解できるが、開発が遅延していても有休で休み、その遅延をマネージャである私が休出して開発を肩代わりするという調整を1ヶ月以上続けてきて、この歪みは開発やプロジェクトにとってよくないということもわかってきた。

私個人のモチベーション管理にも多少の影響はあるが、私は指示されて休出しているわけではなく、自分の目的のためにやっているのでこの影響はそれほど重要ではない。

なにが問題かというとプロダクトオーナーシップを開発者がもたないという点にある。私はお手伝いであるから、いずれいなくなる。周りからどうみえようと最終的にプロダクトオーナーシップは契約形態としてもてない。そして、お手伝い先の開発メンバーがもつようになるのが望ましい。しかし、そういう雰囲気はみえない。これまで他社の人間がマネージャーをやっているようなプロジェクトに私が参加したことがなかったためにそういった視点がなかった。そして、私は自分がイニシアティブをもって開発するプロダクトはすべてプロダクトオーナーシップをもって臨んできた。そのため、開発者に裁量を与えることで必然的にプロダクトオーナーシップをもつようになると信じてきたが、いまのやり方だとそうならない気がしている。なぜならば、放っておいても問題になる前に私が勝手に対応してしまうために開発者のインセンティブやモチベーションを阻害してしまうからだ。

プロジェクトにおけるスケジュールや品質を担保するためにはマネージャーである私が一定の尽力をするのは合理的ではある。一方でそれをやり過ぎることで開発メンバーのプロダクトオーナーシップを遠ざけてしまう。プロダクトオーナーシップをもっていない開発者が休出してまで開発に尽力する意味など普通にはない。仮に私が開発メンバーでもそう思うだろう。昔の上長 がやっていたことをみて私が学んだことを、外部の人間として開発メンバーに教えることはとても難しいことを理解できた。

昨日は久しぶりに飲みに行っきて1時に寝て8時に起きた。

ストレッチ

外がだいぶ暖かくなってきて散歩に行く機会も増えてきた気がする。今日の開脚幅は開始前157cmで、ストレッチ後159cmだった。先週と違って今週は忙しくて座っている時間が大幅に増えた。そして、その分の右腰の張りは強かった。腰の張り具合はその週の忙しさや労働時間で推測できるぐらいにはわかってきた。それ以外はだいたい可もなく不可もなくな感じだったと思う。

淡路牛の受け取り

姉からお肉が届くという連絡があったので日時を調整して受け取った。島サラダフェア2022 という懸賞に応募していたのが当たったらしい。5000円相当の淡路牛らしい。お正月に食べるようなお肉だと言えば伝わるかな。A賞の5名のうちの1人がここにいるので総応募数は推して知るべし。姉が言うには全然応募ないらしい。こういうの調べて真面目に応募してメルカリで売るみたいなことやったらそれなりに儲かるのかもしれない。運営はマーケティングのやり方を変えた方がいいんじゃないかとか心配になって話していた。

openldap の overlay のデバッグ

午後から昨日の続き。chatgpt と一緒に openldap サーバーのカスタム overlay モジュールのデバッグをしていた。昨日の時点では2つの問題があることを確認できていた。今日は個々の問題の詳細をデバッグしながらワークアラウンドとして動かすためのコードを書いた。1つはビルドの問題じゃないかと思える不可思議な現象が起きていて、もう1つは openldap の ppolicy の仕様とカスタム overlay モジュールの仕様のどちらが正しいのかを設計者に確認する必要がある。15年ぶりぐらいに c 言語のコードを書いている。かなり怪しいけど、gdb をインタラクティブな repl のようにして振る舞いを確認しながら書いている。カスタム overlay モジュールでエラーが発生すると openldap はその処理をスキップするようにみえて、なんのログも出ない。細かくログ出力してどこまで動いたのかを確認しながら開発するとよさそうな雰囲気がわかった。