0時に寝て6時に起きた。

ストレッチ

ここ1ヶ月ほどお仕事に集中しているのもあるけど、あまりストレッチに意識を割いていない。やるときは集中して注力するのだけど、飽きてくると怠ける性格的なところがある。とはいえ、やめずに続けているといいことがあると経験則からわかっているのでなるべく継続していきたい。今週も特別なことはなにもしていないのだけど、右足の股関節周りに張りがあってあまり調子がよくなかった。今日の開脚幅は開始前163cmで、ストレッチ後167cmで先週よりも数値が悪化している。良くなるときもあれば悪くなるときもある。毎週ストレッチを受けて計測しているとそういう気付きがあること自体、この機会は健康のために役立っているように考えている。

github packages で docker イメージを公開する

docker が流行りだした頃に勤めていた会社の貸与端末が docker 禁止だったので私は docker に乗り遅れて、これまでも誰かが用意してくれたコンテナを使うだけでよかったため、最低限の docker コマンドや docker-compose の使い方しか知らなかった。ちょうどインフラの運用を見直す過程で docker コンテナの作成方法から見直すお仕事ができたのでこの機にいろいろ勉強する。いまどき当たり前なんだろうけど、docker の マルチステージビルド をやってみる。

最初に go のバイナリを選択したのは間違いだったのかもしれない。go のビルド環境を作るベースイメージの選択が難しくて、ビルドはできるけど、作成したバイナリが動かないという状況にはまった。ECSのタスク起動時に「standard_init_linux.go」関連のエラーが出た場合の対処方法 であるように、いろんな不具合がある。ベースイメージの選択やビルドに必要なライブラリがないとそういうエラーになるんだと気付くまでに時間がかかった。

最終的に次のような Dockerfile でマルチステージビルドができた。builder としてのベースイメージの選択によってやり方はいろいろ変わってくるように思える。

FROM golang:alpine as builder
RUN apk add --no-cache git make gcc musl-dev
WORKDIR /work
COPY . .
RUN go mod download
RUN make build

FROM alpine:latest
WORKDIR /
COPY --from=builder /work/bin/sql-executor .
CMD [ "/sql-executor" ]

Dockerfile ができたら Publishing Docker images を読みながら github actions で自動的に docker イメージを github packages に公開する設定をやってみた。リリースを作成したときに docker イメージをビルドして公開する workflow yml を作成した。ほとんどドキュメントのまま。

github actions の実行結果。

• https://github.com/kazamori/go-sql-executor/runs/5258037718?check_suite_focus=true

github packages 上で公開された docker イメージ。

• https://github.com/kazamori/go-sql-executor/pkgs/container/go-sql-executor

リリースのタイミングじゃなくてコミットのタイミングでも docker イメージを生成できると思うけど、docker イメージのタグに相当するものをどう付けるかというところは工夫する必要がありそう。

23時に寝て1時半に起きてそのまま断続的に寝て起きての繰り返しで6時に起きた。本当は非稼働日だけど、昨日作った pr の機能を検証するための環境を用意してもらったのでそれを動かしたら要件漏れに気付いてその改修をやってた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせの日。今日の議題は2つ。

見積もりの雑談

先日、見積もりについての 私の考え を整理した。それについて第3者の意見も聞いてみたいと考えた。

いろいろ雑談したけど、結論としてはバーンダウンチャートもストーリーポイントも運用が形骸化したら役に立たないという当たり前の話しになった。従来の期限や工数を見積もる方法と比較して得られるメリットはそう多くないという私の印象である。ストーリーポイントが優れている唯一の点は、タスクの見積もりについて話し合う場ができるという、その機会そのものがあげられる。その機会を使ってメンバーとの情報共有や教育の場にもできるという点がある。それ以外のところでストーリーポイントのメリットはさしてないと私は感じた。

ストーリーポイント(以下SP)について雑談していて、あるチームでは事前に見積もったSPをタスク完了後に実績ベースで上書きする運用をしていたという。その理由は見積もったSPに対して進捗や実績が悪いと偉い人からお叱りを受けるため、SPが正しくなかったという解釈で実績から変更しているという。

— Tetsuya Morimoto (@t2y) February 18, 2022

来期の予算策定

ざっくり試算すると来期は少し赤字になる。経営者として赤字にならないようの対策を講じる。私が予め用意した施策は次の3つ。

1. 既存顧客のお仕事の単価をあげる
2. 赤字分の売上を別のお仕事で稼ぐ
3. 赤字分の経費を削減する

はらさんから役員報酬を下げてはどうか？という提案もあったけど、これは却下しようと思う。もともと役員報酬は高くないし、役員報酬を下げると必然的に健康保険や社会保険の再計算やそれらに関連する事務手続きが発生する。いま私は会計士も税理士も雇わず自分ですべてやっているのだけど、専門家に依頼するにしろ、自分でやるにしろ、経費を下げるために別の経費を発生させてしまう。これは本末転倒な気がしてやりたくない。

したがって、お仕事の単価をあげる交渉からまず始めることにする。私はずっと開発者で働いてきたから交渉ごとはほとんど経験がない。交渉の経験を積むという側面でも自分のキャリアにとって新しい取り組みになってよいと考えている。次の契約更新は3月末になるのでそれまでに交渉のための準備を進めていく。

0時に寝て4時に起きて6時に起きた。6時過ぎに slack でインフラ担当者から作業の報告があってその対応してた。

Mockito のモック作成

Spring 5 WebClient のテストコードを書いてみた。Mockito というモックライブラリを使っているのをみかけたのでそれを使うことにした。当初は WebClient そのもののモックを用意して、どんなメソッドを呼び出しても Null オブジェクトのように無視すればいいんじゃないかと思ってたんだけど、Mockito はそういう用途に使うものではなく、それぞれのメソッドごとにモックを返すような設定ができる。次のような WebClient のメソッドチェーンでリクエストするようなモックを考える。

var response = this.client
        .get()
        .uri(uriBuilder -> uriBuilder
                .path(path)
                .queryParam("param", param)
                .build())
        .retrieve()
        .bodyToMono(MyResponse.class)
        .block();

他にもっとよいやり方があるかもしれないけど、私がよくわかってなくてこんなやり方しかできなかった。最終的には block() を呼び出したときに任意のレスポンスを取得できればよいのだけど、メソッド単位にモックを呼び出していかないと型チェックやら実行時エラーやらで意図したようにテストできなかった。これだけをみたらメソッドチェーンのモック作りは面倒にみえる。Mockito がどうやってこれを実現しているのかわからないけど、すごい仕組みだなとは思った。

    @MockBean
    WebClient client;
    @Mock
    WebClient.RequestHeadersUriSpec requestHeadersUriSpec;
    @Mock
    WebClient.RequestHeadersSpec requestHeadersSpec;
    @Mock
    WebClient.ResponseSpec responseSpec;
    @Mock
    Mono<MyResponse> mono;

    private void mockWebClientMethodChain(MyResponse response) {
        Mockito.when(client.get()).thenReturn(requestHeadersUriSpec);
        Mockito.when(requestHeadersUriSpec.uri((Function<UriBuilder, URI>) Mockito.any())).thenReturn(requestHeadersSpec);
        Mockito.when(requestHeadersSpec.retrieve()).thenReturn(responseSpec);
        Mockito.when(responseSpec.bodyToMono(MyResponse.class)).thenReturn(mono);
        Mockito.when(mono.block()).thenReturn(response);
    }

1時に寝て3時過ぎに起きて6時半に起きた。

ふりかえり

今日はスクラムのふりかえりとプランニングの日。1週間が終わり始まる。ふりかえりをしていて、2週連続でスプリントゴールが未達になって、原因を追求する空気になって、最終的にはリーダーを糾弾するみたいな雰囲気になった。昔の私だったら論理的に問題を掘り起こそうとがんばったかもしれないけど、いまはもう歳をとってスラムダンクの安西先生みたいになったのか、もしくは外部パートナーとしてのお手伝いだから真剣ではないのか、その両方かもしれないが、一歩引いたところからできなかったもんしゃーないんちゃう？みたいな心境で見守っていた。うまくできない人や状況に「なぜできなかった？」みたいに迫ると「努力が足りなかった」とか「もっとがんばります」みたいなやり取りしかならないので不毛にみえる。経営者のくせにこんなことを言うと怒られるかもしれないが、仕事なんてやりたい人やできる人が楽しめるように好き勝手やって、そうじゃない人は最低限やるとか、邪魔しないように配慮するとか、もうそれでいいんじゃないとか思ったりもしている。もう人類は会社の半分ぐらいの社員が遊んでても暮らしていけるぐらいの生産性を手に入れたと思うよ。半分は言い過ぎか。いずれにしても私はもう無理なく自分のペースで働きたいと思うようになった感じ。

backlog の管理者権限

お手伝い先で backlog を課題管理システムに使っている。私は課題管理システムのスペシャリストとして、ああしたい、こうしたいといくつも注文を付けて、チームの開発やワークフローを改善している。これまでは管理者権限がなかったのでもっている人に依頼するしかなかったけど、そろそろ私の相手をするのが面倒くさくなってきたのか、私にも backlog の設定を変更する管理者権限をもらえた。さっそくカスタム属性をいくつか作って実験的な検証をしていた。カスタム属性は backlog のフリープランでは使えない機能なので、お手伝い先の実地で用途や振る舞いを検証するしかない。同じプロジェクトでも種別ごとにカスタム属性の設定有無を切り分けられる機能があって、この機能は他の課題管理システムでみたことがない実用的で珍しい機能だと思った。チケットに PR とコミットのカスタム属性を追加して、github actions でコミットや PR のタイミングでそれらの属性に URL を追加すれば github 連携もできそうな気がしてきたところ。週末に時間があったら作ってみる。

0時に寝て4時に起きて6時半に起きた。今回のスプリントは1つの機能拡張のチケットに専念していてとても疲れた。

担々麺

オフィスの近くに 珠しっぴん という坦々麺専門店ができているのに気付いた。半年ぐらい前にオープンしたらしい。あまり通らない場所だったせいか、全然気付いてなくて試しに入ってみたら私の好みの味でとてもおいしかった。食わず嫌いだったのか何なのか、昨年ぐらいまで担々麺はほとんど食べたことなかったんだけど、近所においしい担々麺のお店がいくつかできて、担々麺そのものも好きになってきた。新しい担々麺のお店をみかけるととりあえず入ってみるようになった。

珠辛担々麺

汁なし担々麺

1時半に寝て5時半に起きた。いよいよ眠れなくなった感じだな。

取材商法の営業

会社の問い合わせのメールアドレスに取材させてほしいといった問い合わせが届いた。うちみたいな無名の零細会社になんの前触れもなく届く問い合わせの大半は営業に関するもの。

※撮影・インタビュー記事の掲載にあたりまして、費用等は一切発生しませんので、ご安心くださいませ。

WEBにて、お写真と記事でご紹介させていただきたいと考えております。

こんな感じで取材の費用はいりませんと言っている。記事広告と取材商法(タレントインタビュー)で雑誌掲載の効果は？ によると、取材は無料かもしれないが、メディアや雑誌といった媒体に掲載するのに料金を請求するらしい。まさにこの記事で書かれている会社からのメールだ。取材して記事ができてしまうとサンクコストが気になって掲載料を支払ってしまうような心理を利用しているのだと推測する。

いろんなビジネスがあるなぁと世の中の勉強になった。

22時に寝て0時に起きて5時に起きて7時に起きた。なんか体調が微妙。

リファクタリングのチケット作成

これまでは業務に関係しないところの機能拡張をしていたので新規にコードを書くことが多かった。いま業務の開発にも着手し始め、その過程で既存のコードを読むことも多くなった。私からみたらコードの品質が著しく低くて、ただ動いているだけで堅牢でもないし、設計の意図も伝わらないコードが多い。そういうのを自分が変更するときに少しずつ出来る範囲でリファクタリングしたりしている。今日もコードを読んでいて enum の扱いについてチケットを作成した。

前に手伝っていた会社の契約を終了するときに java のコードレビューだけなんらかの契約で依頼できないかという話しはあった。そのときは別件のお仕事が火の車だったので断ってしまった。いまお手伝いしている java のコードをみても、java に慣れていない開発者の書く java のコードはたいていひどい。なぜひどくなるかというと、java は言語仕様が複雑で難しいからだと思う。java の経験が少ないと Effective Java を読んでも理解できないぐらいには java の設計は難しい。その結果として java で開発しているのに設計を練っておらず「動けばいい」コードが散見される。java で開発するなら「これ以外に動かない」コードを書いた方がよいと私は考えている。その意図が伝わるからドキュメントなんか読まなくても「動かすにはこう書けばいい」とわかる。さらにインターフェースが明確であれば、責務や拡張方法も明示的になる。

前から考えてはいたけど、sier や内製始めたばかりの事業会社向けに java のコードレビューのサービスを提供することも考えている。私1人だとたくさん受けられないし、コードレビューサービスのようなものは会社の信頼関係の方が重要なのでビジネスにするのはちょっと難しいかもなぁ。

見積もりのまとめ

先日 見積もりについて考察した 。もともとは社内向けに書こうと書き始めたが、内容の大半は社内に閉じたものではなかったので一般論の記事として書き直した。最終的には1万文字ぐらい書いた。

• 見積もりをがんばらない

23時に寝て2時前に起きて5時に起きて8時に起きた。あんまり眠れなくなってきた。

もくもく会

【三宮.dev】もくもく会 に参加した。もともとオフラインの予定だったけど、オミクロン株の流行でオンラインに変更された。

お仕事である開発環境の構築をしていて docker-compose を使って mysql の環境構築や共有の開発環境にある db2 に接続するために clpplus のインストール方法などを wiki にまとめてた。コンテナにある mysqldump や mysql コマンドを使ってこんな風にデータ移行もできた。

共有の開発環境からデータをエクスポート。

$ docker-compose exec -T mydb mysqldump -h $DB_HOST -C --set-gtid-purged=OFF --skip-triggers $DB > dump.sql

ローカルの mysql にデータをインポート。

$ docker-compose exec -T mydb mysql -h localhost -u root -proot $DB < dump.sql

コンテナにある mysqldump と mysql コマンドを使ってデータのインポートするには -T を指定すればいいみたい。そうしないと WARNING とかの文字列が sql ファイルに含まれてしまってインポートできない。https://t.co/JGeDNsWjhx

— Tetsuya Morimoto (@t2y) February 12, 2022

ストレッチ

いつもは11時からなんやけど、今日は17時40分からだった。カレンダーの予定を変更し忘れてて11時に行って間違えた。今週は2日間ぐらいストレッチしたかな。今日の開脚幅は開始前164cmで、ストレッチ後168cmだった。いつも時間帯が違うので数値も変わる。今日は右太ももの内転筋や内側やらがすごく張ってた。あまり調子はよくない。

0時に寝て2時過ぎに起きて5時に起きて6時に起きた。珍しく3回ぐらい起きた。

docker のマルチステージビルド

これまで docker を使った開発を主導してこなかったので私はあまり docker についての知識をもっていない。いま k8s クラスターで java アプリケーションの運用をしていて、リリース作業の改善には docker イメージのビルドも改善する必要性が迫られてきた。いくつかプラクティスの記事を読んでいると マルチステージビルドの利用 を推奨している記事が多い。マルチステージビルドをうまく活用することで、docker イメージサイズの削減と日々の ci やビルド時間の短縮の2つを図れるようにみえる。docker の仕組みを学ぶちょうどよい機会なので主導的な立場でこの改善に着手しようと考えている。

オフィス内覧

オフィスの引っ越し調査のために エリンサーブ に行ってきた。駅近でもなく市街でもなくちょっと辺鄙な海外沿いにあるせいか、他のレンタルオフィスと比べて全体的に広さに対する家賃は安く設定されている。案内をしてくれた代表の方が「狭い部屋で働かせたくない」といった想いを話されていたので、意図的に窮屈なスペースにならないように広めに設計されているらしい。

オープンスペースでそれぞれの席が別会社という作りは斬新な考えとも言えるし、お互いの信頼関係で成り立っているとも言える。例えば、パソコンのモニターや資料とか、近くを通ったらみえてしまうわけだし。そういったセキュリティも考慮して、一見さんのドロップインには対応していないという。利用者はお互いに面識のある一定の信頼関係を築ける人たちで構成されているらしい。なにか審査があるのかどうかわからないが、人間関係が苦手な人には向かないスペースにもみえる。私は1日のうちにテレビ会議を何度もやるのでオープンスペースだと顧客の情報を守る義務があるのと、そうじゃなくても周りにも迷惑がかかるので、1日のうちの何度も場所を変えてテレビ会議できる部屋に移動しないといけない。それがボトルネックだなと思えた。個室もいくつかみせてもらって、2人向けの窓のある個室があってよさそうにみえた。そこはテレビ会議しても問題ないとのこと。家賃も予算にあうものだった。

Dタイプ(3F)

• 月額利用料: 66,000円

Eタイプ(3F)

• デスクは2つ
• 月額利用料: 76,000円

いまは他の会社が借りている状態だけど、空きが出たら教えてもらえるようにお願いして帰ってきた。

0時に寝て5時に起きてちょっとだらだらして7時ぐらいにはオフィスにいた。

スプリントの期間とプランニング

いまスクラムのスプリントを1週間で運用している。スクラムのスプリントレビューをやっていて、今回のスプリントはスプリントゴールが未達となったという事実がありつつも、ある開発者が本来のスプリント計画にはなかった課題を少し工数を使ってやってしまってたという話題が出た。それはある機能開発の調査の過程でこういうツールがあると業務メンバーの作業効率が上がりそうだとわかって、それをヒアリングしていた開発者が PoC も兼ねてプロトタイプを作っているうちにすぐ運用で使えそうなベータレベルまで作ってしまったという話し。言うても2日ぐらいで作ったと思うのだけど、5日しかないスプリントで2日は40%という大きな工数を占める。スクラムマスターも否定はしなかったけど「スプリントの計画にないタスクに工数を割くのはよくないと、スクラムマスターの立場からはお小言を言わざるを得ない」と言及した。

先日、私も直接はスプリントの計画達成に直接寄与しない リファクタリングに半日を費やした ので、ツールを作ってしまった開発者の気持ちはわかるなと無言で聞いていた。それと同時にスクラムのスプリントは、運用によっては開発者のモチベーションを削ぐことも実感した。やる気の有無で仕事をするのはよくないと一般論では言うけど、実際のところ、人間のモチベーションは制御が難しいのと、知識労働はモチベーションが生産性に大きな影響を与える。開発者のモチベーションが高いときにそのタスクをやるのは理に叶うという側面もある。非開発者は次のプランニングで承認を得て来週のスプリントでやればいいじゃないかと思うかもしれない。でも、違うのだ。いまやってみたいという気持ちが大きいときにいまやるのと来週やるのではモチベーションが異なる可能性がある。この気持ちは開発者にしかわからないと思う。

その開発者がデイリースクラムでツール開発をやることを相談しなかったかの理由も理解できて、合理的に考えたら相談しても承認を得るのは難しいので、黙ってやってしまったのだろうと思う。そして、今回のスプリントのスプリントゴールが未達になったとしても、なにか業務に影響が出るというわけでもないことをメンバーが知っているというのもある。スプリントは全力でやるものだけど、全力でやらなくてゴールが未達になっても、なんら業務に支障がでない事実がスプリントの目的を減衰させている。

そういう業務と実情があっていない現実、ルールに則るとお小言を言わざるを得ない牽制機構、たった2日すら自由に時間を使えない開発者、なんかスクラムって窮屈だなと直観的に感じた。

1時に寝て6時前には起きてた。昨日がんばったから今日は早めにお仕事を切り上げた。

リリース作業を柔軟に、効率的に

以前から認識していた開発の課題にリリース作業のコストが大きいことがあった。具体的には人間が手動で進捗をみながら処理を実行していて、さらに1つずつの処理に数分かかるので順番に実行していくだけでも確認を含めて30分から1時間ぐらいかかる。リリース後に変更したところの動作確認とかを開発者が集まってやってたらだいたい2-3時間はかかる。だらだら？やっているとリリース作業に開発者全員がハドルに入って半日ぐらいやってたりする。最初のうちは雑談しながらリリース作業のやり方がわかってよかったんだけど、何度か繰り返したらこれを毎週やるのは非効率だわと思うようにはなっていた。

そんな開発側の事情もあったんだけど、スクラムマスターからもいまのリリース作業は柔軟性がないみたいな指摘が入って、その改善のチケットが切られた。開発者も全員それは認識していた。改善するならスプリントを1つ使うぐらいの工数がかかるという背景を説明するために、私が「ぼくのかんがえたさいきょうのりりーすさぎょう」を考えていくつかのタスクをチケットに作った。いま GitHub Actions の無料枠におさまるようにリソース制限を運用で調整しているのもあって予算確保できるなら戦略も変わってくる。それらも含めて然るべき改善の道筋を示したい。