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話すべてみた。どちらかと言えばおもしろかったけど、ツィートみて期待値が高かった分、そこまで私の中に響くものはなかったかな。南極へ行く道中や南極の生活がわりと遊んでいるようにみえてあまり大変そうにみえなかった。とはいえ、実際の船上や南極でもやることなくて娯楽ないと持て余すのかなとも思えた。南極地域観測隊 って現実にあるんだなとみてた。

僕はだいたいプログラミングしてるときは既に内容を知ってるアニメを常に流してるんですが今週はまた「宇宙よりも遠い場所」を観ていました。これほどまでに13話すべて足すところも引くところもない完璧な作品は他に早々思いつかないです。

— Fumihiko Shiroyama (@fushiroyama) October 28, 2021

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

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社の仕事だけを専念しつつ、自社の仕事も少しずつ進めていきたい。

4時に寝て7時に起きた。やや寝坊したけど、夜中に作業してよく眠れたのでまぁいっかとしておく。昨日のかぼちゃの煮物が残っていたので19時に帰って晩ご飯食べて、ちょっと休んでからウォーキングに出た。ウォーキングの途中でオフィスに寄って一作業してからまたウォーキングして帰るという、運動と作業の一石二鳥になることを思いついた。ちょっと天才。ウォーキングの合計時間は1時間強ぐらい。

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

8章分散システムの問題のうち、8.1, 8.2, 8.3を読んだ。

とくに 8.3 信頼性の低いクロックは私がこれまでアプリケーションを開発していて全く意識したことがなかった問題を扱っていてすごく勉強になった。おそらくミリ秒レベルでの障害調査をほとんどやったことがなかったので気にしてなかったのかもしれない。Cassandra が採用している LWW (last write wins、最後の書き込みを勝たせる) だと、短時間に連続して行われた書き込みと、本当に並行して行われた書き込みとの区別がつかないのでクロックの同期の状況によって因果律違反が発生する懸念がある。

NTP を使っていてもクロックの同期はミリ秒から秒レベルで正確ではない可能性があり、そこにプロセスの一時停止なんかも加わると容易に数秒の時間がズレてしまい、トランザクションにおける因果律違反が発生する可能性があるという話が丁寧に説明されている。実際に同じリソースに対してミリ秒レベルでトランザクションを発行するというのはあまりない状況だろうし、状態がよければあっても正常に動作する。但し、正常にトランザクションが実行されない懸念があるという理屈を知っておくのは大事なことに思えた。Google の Spanner が原子時計を導入して精度の高い時刻同期をしているというのは記事を見聞きして知っていたが、それがないとどんな問題が発生するのかが 8.3 節を読むと理解できる。

選考面談

そろそろお仕事をしないと会社の財務がやばいので選考を受けている。今日は2社の選考を受けた。1つは Go の開発案件、もう1つは Java の開発案件。どちらも業務内容はマッチングしていて勤務形態もフルリモートなのでいまの生活のまま、お仕事ができる。1社は正式にオファーが届いて、もう1社もおそらくオファーがくる想定。どちらかを選択する。転職だと面接を何回もして選考を受ける必要があるけど、業務委託だと大半が1回で決まる。昔フリーランスやってたときもそうだったかな？調整の管理コストが下がって望ましいことではある。もう私の中では承諾する方の案件は決まっているけど、念のため、1日寝かして顧問さんとも相談した後、最終決定しようと思う。

韃靼そば茶

少し前から家では 大阿蘇万能茶 を煮出して冷やして飲んでいる。村田園のサイトにはないので商品名が変わった？のかもしれない。この万能茶は、よく言えば後味すっきり、わるく言えば刺激がないと言える。おいしくないわけではない。近所のドラッグストアでノンカフェインのお茶を求めて購入した。もう少しお茶の主張がほしいなと思って、にっこくの 韃靼そば茶 を購入した。そば茶もノンカフェイン。これは水出しもできる。試しに水筒にティーパックを入れて、オフィスのウォーターサーバーで水を入れて作ってみた。時間が経つごとにそば茶の味が濃くなっていくけど、これはこれで私は好みなので問題なさそう。なるべく1日で飲みきって水筒を洗えばよさそう。

夜にうまく眠れなくなってから、夜にカフェインの入った飲みものを避けるようになった。ノンカフェインだとわかっているお茶なら安心して飲める。しばらく試してみる。