今日の運動は腕立て,背筋,縄跳び(両足跳),散歩,ジョギング,ハンドグリップ,ダンベルをした。統計を 運動の記録 にまとめる。

みなとのもりの運動

前回の所感 。土曜日は午前中に公園へ行って運動する。今日は朝から天気がよく、気温もカラダを動かすにはちょうどよい心地よさ・涼しさがあって快適だった。いつも通りのフルセットのメニューをこなした。土曜日は時間に余裕があるのでウォームアップやストレッチを念入りにできる。今週は月火とお休みしたものの、水曜日からは毎日継続して運動することができた。その分の疲労も溜まっていてややカラダが重かったものの、天気の爽快さの後押しもあってそれなりにこなせた。

体力がついて体重が減ったせいか、同じワークアウトをしていても回数・量を増やしたり、時間を多くとったりしないとカロリーを消費しなくなった。たとえば、縄跳びを始めたときは800回ほどしかできなかったのが、いまは1400回ほどは安定的にこなせる。2倍に近いパフォーマンスを出して、なお持久力にはお余裕がある。これ以上やるとひざや足全体に負荷をかけ過ぎないかの懸念があるから15分間という時間に制限している。一方で連続して3分間跳べるようになったり、1分休憩していたところを30秒に短縮したり、そういったところで以前よりも負荷をあげて回数が増えている。いまは2-3分ごとに休憩しながら跳んでいる。15分で4-5回ぐらい休憩をとるわけだけれども、このまま継続して体力がつけばその休憩時間を減らして回数が増えていくかもしれない。

体重の推移

前月の体重の推移 。5月はうまく体脂肪コントロールできて体重を減らすことができた。おそらく GW があって休暇が多かったために普段の月よりもたくさん運動できたからではないかと分析する。逆に6月は祝日がないので5月と比べたらパフォーマンスが落ちる可能性が高い。一方で目標体重である 70kg は6月中に達成できる見込みだと考えている。70kg という体重は私が30代前半の頃の体形といえる。お正月にみかけた筋トレ特集 に影響をうけて半年で 20kg 以上も体重を減らすことになるとは当時はまったく予測できなかった。なにがきっかけで生活のスタイルが変わるか、わからないものだ。そして、どのようなことでも継続することの偉大さも実感できた。今後も継続したいことは日記に書いて、うまくいかなかったとしても継続そのものをやめてしまわないよう、自分がやりたいことは継続して取り組みたい。

ストレッチ

夕方からストレッチへ行ってきた。筋肉痛はとくに感じないものの、疲労の蓄積は実感があるのでストレッチへの影響がある。今日つらかった部位は太ももの後ろ、ふくらはぎ全般、股関節の横の筋になる。有酸素運動のメインは縄跳びとジョギングになるため、それらの負荷や疲労がそのままストレッチのつらさに影響を与えている。運動の前後に念入りにストレッチをしていても疲労回復は完全にできていない。トレーナーさんに股関節の横の筋を鍛えるトレーニング方法なども教えてもらった。体重の目標値をクリアしたら有酸素運動から筋トレ主体に切り替えて筋肉をつけていくことについても相談した。筋肉をつけるには正しいフォームでトレーニングしないといけないそうで、ジムにある器具を使った方がフォームを矯正したり負荷を調整しやすくて効率はよいといった話しを聞いた。今日の開脚幅は開始前148cmで、ストレッチ後155cmだった。

近況報告の資料作り

月例の作業。来週の出張へ向けての進捗報告の資料作り。開発の終盤なのでとくに新しい話題はなく、現状の開発の進捗を綴るだけ。私の進捗が悪いだけで他のメンバーは十分に目標を達成できる見通しになっていて問題はない。進捗報告とは別に、今回の打ち合わせはお手伝いしている会社とうちの会社との契約を段階的に次のステージへ移行していくことについても議論しようと考えている。いつまでもフルタイムで私がお手伝いするわけでもないはず。その移行時期や過渡期における契約について検討していきましょうという提案をしてみる。

今日の運動は縄跳び(両足跳),散歩,ジョギング,ハンドグリップ,ダンベルをした。統計を 運動の記録 にまとめる。

隔週の雑談

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

• 資本金と住所変更の変更登記の共有
• フルタイムではない契約提案のフィードバック

昨日の税理士さん打ち合わせ の内容も踏まえて変更登記の共有を行った。当初はまとめてやった方が登録免許税が安くなったりしないかな？と期待して、2つの変更登記を1回の申請で行うように段取りしていた。昨日、税理士さんから 登録免許税一覧 を共有してもらって、資本金の増加と代表社員の住所変更は別区分であるため、それぞれの登録免許税を支払う必要があることを教えてもらった。はらさんに説明しているうちに登録免許税が同じなら1つの変更登記の申請にこだわる必要がないことに気付いた。それぞれ別の変更登記で申請することに決めた。

今後の契約移行へ向けての提案について、いきなり契約変更を先方に伝えると、急過ぎて相手にショックを与えてしまう懸念があることを指摘してもらった。たしかにこちらの都合で契約を変更したいというところはあるので、丁寧な表現で段階を踏んで相互理解を深めていく取り組みにすることにした。こういうニュアンスのようなものは1人だと気付きにくい。相談相手がいると助かる。

資本金の増資

午後から資本金を増資しようと思って三菱 UFJ 銀行の口座からインターネットバンキングで会社の口座へ振り込みしたら強制的にエラーになってログインできない状態になった。サポートに電話したら、普段やらない手続きを検知したからセキュリティ機構により、振り込みをエラーにしましたとのこと。振り込め詐欺対策やろね。金額も大きかったし。サポートから電話が掛かってきて本人確認して90分後に復旧しますと言っていたが、実際には40分後にはログインできたので、そのまま同じ内容の振り込みを試したら2回目は成功した。手間暇かかったけど、大手銀行は振り込み手続きが正しくても強制振り込み停止のようなセキュリティ機構があるんやなというのを知ることができた。今回は正しい振り込みだったのでただひたすらに不便でストレスが溜まっただけだったけれど。

みなとのもりの運動

前回の所感 。19時前にはオフィスを出発して20時ぐらいにはいつもの運動を終えた。疲労がたまっていたのか、湿気が多くて暑かったせいか、縄跳びをしていてもいつもよりバテたり、カロリー消費もいまいちだった。終わってからそのまま家に帰って、晩ご飯を作って食べて、お風呂入って、オフィスへ戻ることもなく休むことにした。いつもより、オフィスでの作業時間が少なかった分、睡眠時間が増えて休養になったはず。

今日の運動は腕立て,スクワット,ハンドグリップをした。統計を 運動の記録 にまとめる。今日も一日雨降りなので筋トレ中心の運動にした。

サポート契約の提案資料つくり

いまお手伝いしているお客さんの開発がそろそろ落ち着きそうな雰囲気がみえている。機能開発を終えて、これからエンドユーザーへ提供して、本番運用が始まったり、エンドユーザーの要件を開発したりするフェーズへ移行していく。雇われのプロジェクトマネージャーとしての私の役割を果たしつつあると言ってもよいかもしれない。開発を完了したらいきなり契約終了とはならないと私は考えていて、今後の本番運用を通してのトラブル対応やサポートなども必要になってくると想定している。そういったサポート契約のための提案資料を作ってみた。今期からうちの会社は投資フェーズへ移行して財務が悪くなる。少しでも赤字を削減したい。お客さんが望むのであれば、週2日以内で困ったときにサポートしますよといった契約を長く続けたい。

0時に寝て何度か起きて6時に起きた。夜にストレッチを受けて寝たせいか、わりとよく眠れた。お仕事はコードレビューを中心に、既存のよくないところをリファクタリングして品質や堅牢性を高めることをしていた。

税理士さんと契約についての打ち合わせ

税理士さん探し の続き。3人の税理士さんと打ち合わせをして、その中で1人の税理士さんを選定した。ようやく、うちの会社も税理士さんに税務をお願いできるようになった。最初の打ち合わせを30分ほど行った。うちは会計システムに freee を使っているので freee の操作ができることを要件に探した。freee には税理士さんをアドバイザーとして招待する仕組みがあって、それを使って登録すると税理士さんがうちの会社の会計データを読み書きできるようになるという。まずはその登録作業を行った。他にも過去の決算書と決算申告のデータを共有したり、うちの会社の特徴や課題管理のやり方なども情報共有した。課題管理にも関心をもってくれたのでうちの会社の jira にも招待して、できれば、税理士さんもうちの会社の会計作業については jira で課題管理してくれると嬉しい。それは難しいかもだけど。

税理士さんが言うには、税理士会が情報共有のツールとして dropbox を推奨しているらしい。ファイルを情報共有するために dropbox のフォルダ共有してくれると助かるという。うちは google workspace を使っているので必然的に google drive が望ましいのだけど、それは税理士さんにあわせて dropbox にした。私の感覚だと、dropbox よりは google の方がセキュリティもサービスも信頼できてよいのだけど、そこは税理士会の慣習に従うことにした。

税理士さんは社内では slack を、お客さん向けには chatwork を使っているという。私は chatwork 使ったことがなかったのでこの機会に使うことにしてみた。これは税理士さん側から私を招待してもらって使えるようにした。どうやらフリープランで使ってみるみたい。chatwork にもフリープランあったんやと知った。

• 利用プランの変更

契約についてどうしましょう？と相談したところ、どっちでもよいと言う。税理士さんの守秘義務は法律で定められていて、これに違反すると懲戒処分に加えて、刑事罰もうけるような、強力なものらしい。したがって、税理士さんが契約書を企業と交わさなくても税務には問題がないらしい。一方で顧問契約を1年は継続してほしいといったときに期間を契約書に明記して契約するといったケースもあるらしい。先方がいらないと言っていたのでひとまず契約書なしで進めることにしてみる。

• 税理士の守秘義務

3時に寝て7時に起きた。昨日は連休明け初日なのに2時まで作業していた。開発が落ち着いたので夜に自社のお仕事をする余力が戻ってきたとも言える。

Docker についてのテックブログ執筆

先日から Docker エコシステムの調査 をして、そこでわかったことをテックブログとしてまとめていた。一通り書き終えてマージリクエストを作成して社内レビューを依頼した。当初は 「ライブラリとしての Docker とは何か？」 というタイトルで書いていたものの、レビューを経て「ライブラリとしての」という修飾は必要ないことに気付いた。そのまま Docker のコンポーネントのソフトウェアスタックや過去の経緯や現状の雰囲気がわかるような記事にした。Docker を中心としたコンテナプラットフォームと標準化の概要について追っていく記事に仕上がった。インフラに関心をもつ人たちは少ないかもしれないけど、個人的にはコンテナの学びになってよい記事に仕上がったと思う。調査と執筆とレビューを含めると5人日ぐらいかけている。かけた工数を考えれば当然と言えるかもしれない。

デザイナーさんと契約締結

昨日の続き。デザイナーさんからいただいたワイヤーフレームをレビューして、契約書の叩き台も送付して、先方の所感や意見も伺いながら契約を締結した。基本的にはこちらが提示した契約書の通りに進んだのでとくに揉めることなくうまくいったと言える。顧問のはらさんからデザイナーと契約をするときの要項を事前にヒアリングしていて、その詳細を盛り込めんたこともよかったと思える。サイトデザインをお願いするものの、hugo のテンプレートは私が実装しないといけない。ある意味デザイナーと協調してサイトデザインを構築すると言えるかもしれない。私もそこから学ぶ機会があるだろうし、その過程でできた成果物は hugo のテーマとして oss で公開したい。

3時に寝て8時に起きて午前中はドラクエタクトしてた。午後からオフィスへ行って作業していたものの、今日は一日雨降りでお休みって感じ。

デザイナーさん向けの契約書の叩き台

先日ヒアリングした デザイナーさんにお仕事をお願いするときの要項 を踏まえて契約書の叩き台を作成した。これまで準委任契約の契約書しか作ったことがなかったので初めて請負契約の契約書を作ってみた。たまたま検索していて、中小機構の デザイン支援ツール にデザイナーさん向け契約書のサンプルもあったので目を通して少し参考にした。大半は準委任契約と変わらないので、請負契約に特化した条項、デザインに特化した条項などを追加・修正して作成した。

他社との契約をしているうちに契約内容にあまり関係なく締結する汎用的な条項を基本契約書とし、個別の契約に特化した内容を別紙や明細として別の契約書で取り扱っていることを学んだ。契約書の別紙とは？どういう場面で使用する？ によると、別紙の有無は契約書の効力に影響を与えないものの、契約書をわかりやすくする目的で別紙を作るという。契約書は法律上の文言であったり、冗長でかたい表現が多いため、定型的な条項は幅広い契約で再利用できると想定される。一方で個別の契約ごとに変わる内容と言えば、業務内容、報酬、期間・納期、勤務場所、請求・支払いなどの要項になる。これらだけ別紙にして契約相手と詳細に確認するといった方が、契約書の作成側は基本契約書の内容が頭に入っているから契約書の作成を効率化できる。これまで他社にお仕事をアウトソーシングする機会が少なかったので一から契約書を作っていた。いますぐはできないが、また時間ができたときに自社の基本契約書を策定しようと思う。

0時に寝て5時過ぎに起きて7時半に起きた。

契約更新

4月末が3ヶ月契約の区切りなので契約更新の打ち合わせをした。更新はするのだけど、契約条件が現状の働き方とあわなくなってきたのでその調整のための打ち合わせ。いくつか私の懸念やプロジェクト管理について話していて認知の歪みが起きている箇所を特定できた。いま開発の計画がストーリーポイントから見積もったスケジュールになっていて、これが私からみてデタラメな計画になっている。チームが習熟すれば精度が上がっていくというスクラムマスターの説だが、現時点ではデタラメな計画だから想定外のタスクや進捗遅れが起きてもそれが直接的に反映されない。タスクは増えるが、計画は何も変わらないということがすでにいくつも発生していて、それをおかしいと言っているのがメンバーの中で私だけという状況になっている。前に勤めていた会社でも全く同じことがあった。私だけが開発スケジュールの遅延を2ヶ月前に察していて、他のメンバーは締め切りの2週間前になって気付くということが過去にもあった。

いまのプロジェクトが納期に対して実際に遅れるかどうかは納期が来ないとわからないが、少なくともタスクが増えて納期が固定なら残業して終わらせるしかないと私は考えていた。しかし、開発のトップは計画を延期すべきだと考えていることがわかった。延期してよいのだ。プランニングをしていてどんなに遅延があっても計画を絶対に変えようとしないので期限が必達なのだと私が勘違いしていた。おそらく単純にストーリーポイントから見積もっているスケジュールだから、個々のタスクが増えたり遅れたりしても、それらを全体の計画にどう調整していいのかが誰もわからないのだと推測する。これもストーリーポイントの弊害の1つではあるが。

22時に寝て4時半に起きた。昨日は勉強会を連日でやって疲れ果ててからバテてすぐに寝た。久しぶりによく眠れた。起きてから1時間ほどドラクエタクトやって、ストレッチやって、7時半にはオフィスに行って8時からお仕事してた。

スクラム談義

お仕事で本格的なスクラム開発に参加することになった。スクラムマスターのかわのさんと少しスクラムで雑談した。アジャイル、スクラム、チケット駆動、課題管理などの話題であれこれ話してた。かわのさんはスクラムやアジャイルのアーリーアダプターのようで、かなり昔からやっているから経験や実績が多そうなので私の疑問や懸念に的確に返答をくれた。実際の現場でどう応用するかは別の話題としても、スクラムはそもそも「良い結果」を出すためのものではく「現状をありのままに見る」ものらしい。うまくやろうと思ったらスクラムにプラクティスや開発方法論を組み合わせないといけないし、そのための軽量フレームワークになっているのに、スクラムだけ実践すればうまくいくと誤解している人たちもいるといった話題もあった。私がスクラムうまくいってなさそうなチームをみていて微妙だと感じたのは、自分たちの課題に向き合ったプラクティスや改善に取り組んでなくて、スクラムの方法論を守ることに注力しているようにみえたからかもしれない。

紙の契約書に挑戦

新しいお仕事の契約は紙の契約で結ぶ。実はこれまで クラウドサイン で電子契約しかしたことなくて、紙の契約書は初めてでどきどきした。言うても印鑑を押すだけなんやけどな。でも、印鑑押すのってきれいに押したいという気持ちが出てちょっと緊張するからあまり好きではない。

PMBOK セミナー

PMBOK®ガイド第7版 Quick Review に参加した。

参加者は60人で、すでに PMBOK ガイド第7版を購入またはダウンロードした人が十数人だったらしい。 PMBOK ガイドは4-5年ごとに更新されるものらしい。 本セミナーでは第6版と第7版の違いがどういったものかの概要を説明していた。第7版は第6版の拡張であり、実務で PMBOK ガイドが必要な人は依然として第6版も購入した方がよいと話されていた。

というのは、第7版は過去のガイドを更新したものではなく、PMP 試験は第6版の時点でアジャイルな要素も取り入れているため、第7版のために変更を加えるといった予定は現時点ではない。 つまり、少なくとも PMP 試験やプロジェクトマネジメントの国際規格である ISO 21500 は第6版をベースにした内容があるため、それらが急になくなったりすることはないらしい。第6版と第7版の違いとして次のような話しをされていた。

• プロジェクトマネジメントの節目の切り口が変わった？
  • 第6版: プロセスベース
  • 第7版: 原理原則
• 第7版でガイドに チーム が登場するようになった
  • 主語がチームとなり、チームが○○するための原理原則はこうであるといった内容に変わった
    • 主役はプロセスではなくチーム
  • プロジェクトにチームが寄り添うようになった

これらの違いは、第6版と第7版をテキストマイニングして、共起ネットワークを構築して比較してみるとよくわかると分析されていた。あとおもしろかったのが、第6版と第7版ではページ数は半減したものの、文字数は3割減程度となっており、箇条書きが多かった内容が説明ベースの文章に変わったためだろうといった話しもあった。

0時に寝て6時半に起きた。朝活の日以外に6時に起きるのは難しいけど、だいたい6-7時の間には起きているような気がする。とはいえ、休日は8時に起きたりもしてたけど。10月25日 から生活リズムの移行を促してちょっとずつ近づいている気はする。

働き始め

今日から新しい職場で働き始め。3ヶ月ほど自社のお仕事をしていたが、ずっとやっていると会社が倒産するので出稼ぎに行くことに決めた。まずは開発の定例会議に出てみた。最初なんで話していることがなんもわからん。3ヶ月ぐらいは業務のキャッチアップに集中する。intellij idea のコードフォーマッターで開発しているそうなので intellij idea を使うことにした。eclipse をやめて vscode に移行したいとは思っていたが、コードフォーマッターの問題は厄介なので仕方ない。コミュニティエディションを使う。

RabbitMQ のチュートリアル を1から5までやった。チュートリアルのサンプルコードはそのままだけど maven でビルドできるようにして https://github.com/t2y/rabbitmq-sample に置いた。今日のところはチュートリアルに書いてあることの振る舞いなどを確認していた。なんか調査や検証するときにまた使うと思う。

3時に寝て7時に起きた。ウォーキングから帰ってきて0時にベッドに入ったものの、選挙結果の総括記事を読んだり、宇宙よりも遠い場所 をみたりしていたら3時になってしまった。全13話すべてみた。どちらかと言えばおもしろかったけど、ツィートみて期待値が高かった分、そこまで私の中に響くものはなかったかな。南極へ行く道中や南極の生活がわりと遊んでいるようにみえてあまり大変そうにみえなかった。とはいえ、実際の船上や南極でもやることなくて娯楽ないと持て余すのかなとも思えた。南極地域観測隊 って現実にあるんだなとみてた。

データ指向アプリケーションデザイン

9.3 順序の保証を読んだ。

データベースや分散システムにおいて順序付けは重要な基本的概念である。順序と線形化可能性、合意との間には深い関係がある。順序付けが重要なのは 因果関係 を保つのに役立つことがあげられる。

全順序 があれば任意の2つの数を比較して大小関係を必ず判断できる。たとえば自然数には全順序があると言える。線形化可能なシステムは操作に全順序がある。一方で因果律には並行という概念があり、どちらが先に行われたかが重要ではない場合に操作が並行に行われたとみなせる。したがって、因果律は全順序ではなく、 半順序 を定義すると言える。半順序とは、大小関係を比較できる場合もあるしできない場合もあることを指す。

因果律に基づく順序と線形化可能性との関係は、線形化可能性は因果関係を 暗に含む といえる。線形化可能性を持つシステムは、因果律を正しく保持する。しかし、システムを線形化可能にすればパフォーマンスや可用性が損なわれる可能性がある。特にネットワークの遅延が大きい（たとえば地理的に分散している）システムで問題になる。そのため、分散データシステムの中には線形化可能性をあきらめることでパフォーマンスを向上させたものの、扱いが難しいものもある。因果律を保持する方法は、線形化可能性が唯一というわけではなく他の方法もある。多くの場合、システムに本当に必要なのは線形化可能性ではなく因果律における一貫性だけであり、これは線形化可能性よりも効率の良い実装が可能となる。

因果律における一貫性を保持する方法として次のものがあげられている。

• シーケンス番号またはタイムスタンプ
• ランポートタイムスタンプ（Lamport timestamp）

しかし、分散システムではネットワークを介して他のノードの状態を確認しないと因果律の一貫性を確定できない。たとえシングルリーダーアプリケーションであっても、リーダーに障害が発生したときにリーダーのフェイルオーバーが必要となる。この問題は 全順序のブロードキャスト と呼ばれる。ZooKeeper や etcd のような合意サービスが全順序ブロードキャストを実装している。

詳細は省くが、ネットワークを介した分散システムで線形化可能な compare-and-set （あるいは increment-and-get ）を実装しようとすると、必然的に合意アルゴリズムに行き着く。これらと全順序ブロードキャストは等価であることが証明できる。したがって、これらの問題のいずれかを解決できれば、他方の問題の解決策に変換できるという点は重大な知見である。

REALFORCE のワイヤレスモデル

ユーザーから待望されていた REALFORCE のワイヤレスモデルがとうとう発売された。

• 高級キーボードREALFORCEから待望のワイヤレス機「R3」が登場、見どころは？

先週から amazon で予約販売を受け付けていたので REALFORCE 東プレ R3 キーボード 静音 ハイブリッドモデル 日本語配列 91キー ブラック R3HC12 を予約して、本日届いた。私はとくに必要ないけど、bluetooth のマルチペアリングに対応していて最大4つまで接続できる。オフィスの机はそこそこ広いけれど、本とラップトップとモニター2台置いたらスペースが埋まってしまっている。ご飯を食べるときや書類を作成するときにキーボードを立てかけたりしてスペースを確保していて不便に感じていた。

ubuntu 環境での bluetooth の設定に少し手こずった。GUI の設定マネージャー (blueman) でペアリングしようとしても失敗する。キーボードの情報は取得できるけど、ペアリングは失敗する。試しに macos でペアリングしてみたらパスキーの入力画面が表示されて、6桁の数字を入力して ENTER した後に接続するとペアリングできた。blueman だとパスキーが表示されないなと気付いてググってたら [SOLVED] Bluetooth keyboard: Unable to pair (authentication timeout) を見かけて、bluetoothctl でも設定できそうなのでやってみた。

キーボードの情報を表示
[REALFORCE_3]# info F6:9D:A5:80:B7:1F
Device F6:9D:A5:80:B7:1F (random)
	Name: REALFORCE_3
	Alias: REALFORCE_3
	Appearance: 0x03c1
	Icon: input-keyboard
	Paired: no
	Trusted: yes
	Blocked: no
	Connected: yes
	LegacyPairing: no
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
	UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
	RSSI: -45

ペアリングを実行
* エージェントからパスキーが表示されて、キーボードで入力して ENTER したらペアリングに成功した
[bluetooth]# pair F6:9D:A5:80:B7:1F
Attempting to pair with F6:9D:A5:80:B7:1F
[CHG] Device F6:9D:A5:80:B7:1F Connected: yes
[agent] Passkey: 323759
[CHG] Device F6:9D:A5:80:B7:1F Paired: yes
Pairing successful
[CHG] Device F6:9D:A5:80:B7:1F Modalias: usb:v08ACp0302d0001
[CHG] Device F6:9D:A5:80:B7:1F ServicesResolved: yes

キーボードを信頼する
[REALFORCE_3]# trust F6:9D:A5:80:B7:1F
Changing F6:9D:A5:80:B7:1F trust succeeded

契約書の確認

先日 の業務委託案件の契約書が届いたので内容を確認した。

これまで クラウドサイン でしか契約したことがなくて、紙の契約書で契約を締結するのは初めての挑戦でもある。レターパック を使って郵送するのがお作法？といったところから調べてた。明後日から働き始める。フルリモートなので物理的な職場は変わらないけど、新しい職場は緊張するな。うまく入っていけるやろか。フルリモートの経験もだいぶたまってきたし、体調も万全だし、憂うことは何もないはず。いまの状況は純粋に私ががんばるだけだ。

0時に寝て6時半に起きた。久しぶりに勉強会でたくさん話したせいか、疲れて抜け殻になってた。昨日もよく眠れた。今日は調整作業が多かったので集中力を欠いてチケットの業務は進められなかった。

データ指向アプリケーションデザイン

第Ⅱ部の最後の章である9章の一貫性と合意を読み始めた。この章も内容は難しそう。9.1 まで読み終えた。時間をかけて1節ずつ読んでいく。

間違っているかもしれなくても動き続ける方が良いのか、それとも正しくあるべく停止してしまう方が良いのか？

―― Jay Kreps, “A Few Notes on Kafka and Jepsen” （ 2013 ）

冒頭の格言で kafka というキーワードが気になったので原文を探して (deepl で翻訳して) 読んでみた。一般論で考えたらこの問いの答えは停止してしまう方を選択するように私は考えてしまったが、原文の記事によると、この答えはアプリケーションに依るという。ダウンタイム=データの損失という特性のアプリケーションであれば、間違っている可能性があってもすぐに復旧して動かした方がよいという場合もあると言っている。kafka はどちらかと言えば、間違っていても動き続ける方のシステムに分類されると思う。メッセージの到達保証も At Least Once だし。

もう1点、意識しておかないといけないのはレプリケーションを行うデータベースの大半は 結果整合性（eventual consistency） であること。私は本書を読むまで、結果整合性をスケーラビリティやスループットの高い分散システムのキーバリューストアの特性だと考えていたが、RDB であってもレプリケーションはリアルタイムに行われるわけではなく、ネットワークという遅延の上限が保証されないインフラの上に構築されたものである以上、結果整合性で同期される。レプリケーションをしないデータベースシステム以外はすべて結果整合性の特性があると考えて設計や開発をする必要がある。

PMBOK ガイド第7版

プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準 を購入して届いた。たぶんいつか電子版も出ると思うけど、現時点では紙の本しかなさそう。ぱらぱらとめくりながら中身を眺めているとそんなに文字がびっしり書いてあるような本ではないので読むのはそんなに大変ではなさそうな印象を受けた。索引で知りたいキーワードを探しながらその箇所を拾い読みしたりしてた。またがっつり読み込んでまとめていきたい。

選考面談の最終決定

先日受けた 選考面談 で2社ともオファーをいただいた。感謝。自分の中では決まっていたが、顧問さんにも双方の案件の概要を話してアドバイスをもらった。その結果、私の意思と顧問さんのアドバイスも一致した。何の憂いもなく Java の開発案件の方を選択した。11月上旬から働き始める予定。3ヶ月ほど課題管理の調査・研究みたいなことをやっていたけど、いつまでもやれるほど財務に余裕がないので普通に働きながら自社のプロダクト開発も並行してやっていく。以前は2社のお仕事を引き受けて他のことをやる余裕がなくなってしまっていただけど、その失敗を教訓に今回は1社の仕事だけを専念しつつ、自社の仕事も少しずつ進めていきたい。