2025-03-14

「東日本大震災の実体験に基づく災害初動期指揮心得」を読んだ

作者:国土交通省東北地方整備局
国土交通省東北地方整備局

東日本大震災において、その初動を担った国土交通省東北地方整備局によって執筆された本で、東日本大震災の実体験をもとに災害の初動期の対応内容や、これを実現するために必要な指揮官の心得がまとめらています。

単純に、東日本大震災の裏側を知るという意味で大変に有意義な本だと思います。特に直近でも能登半島地震など大きな被害が出ている地震が発生しているし、今後も南海トラフ地震などが起きる可能性が高い中で、その対応を担う地方整備局がどのように動いたか・動けたかを知っておくことは、万が一自分が被災者になった時にも活きる（どのように行政を頼ることができるか、どのように復旧していくかの勘所を得ることができる）と思います。

また、（大地震などの災害と比べるとはるかに小規模ですが…）日常の中で大なり小なりトラブルが発生することがありますが、そのときの初動についての知見としても活かせる内容が多いと思いました。例えば、

「平時にあって官庁の業務は主としてボトムアップを基本とする意思決定によって運営されているが、有事にあっては、その子システムを一瞬にして切り替えて、指揮官の決断によって行わなければならない。」
「状況が不確実なときは、最悪を想定し、あらゆるリスク計算をして臨むのが原則であり、あとでムダにならないようになどと考えず、大きく構えるのが定石である。」
「初動のスピードを決める要素は数々あるが、その最大のものは指揮命令系統の確立である。」
「的確な指揮のため、大概的な情報発信のため、そして災害対応の反省・教訓を引き出すために、発災直後からの記憶は重要である。専門の記録班をおくとともに、各員が活動記録を整理する習慣も必要である。」
「大規模災害への対応は長期に及ぶものであり、対応する職員の健康維持については初期の段階から厳格に指導すべきである。また、指揮官自身も自らの健康状態に留意しなければなならい。そのためには、つい全員で泊まり込みがちになりがちな日本的習慣を止めさせて、職員「ローテーション」を早い段階で決めることが肝要であり、順次、衣食住に関する情報を収集・伝達しながら、異常な生活から持続可能な定常状態への移行を図ることが必要である。」

…というのは、日々の障害（特に、対応に数日～数週間を要するような障害）が発生したときに意識せねばならない点だな、と感じます。

「おわりに」に筆者らが記載していた「備えていたことしか、役に立たなかった」もとても重要で、トラブルや障害は起こらないのが一番だけれども、とはいえ0にできないので、常に備える必要がある。そのためには、発生してしまったトラブルや障害はしっかり振り返って、次に向けた備えにつなげていく動き（振り返り、フローの改善、訓練の実施）が大変大事になる、と感じました。

2025-03-11

忘備録: タスクをうまく進めるための一工夫

先週、アサインされたタスクが結構サクッと進めることができました。この流れを再現できるように、自分なりに工夫したことを書き残しておこうと思います。

前提

前提として、今のチームでは次のようなサイクルで開発をしています:

タスクのアサイン
実装
レビュー（エンジニア）
QAエンジニアによるテスト
- もしここで不具合が見つかった場合、修正→QAエンジニアによるテスト→エンジニアによる再レビューの順で対応する
マージ

一工夫その1: 作業サイクルに基づいて開発計画を立てる

少し前に、実装に手間取ってしまった結果、レビューとQAエンジニアによるテストが後ろにズレて、リリース前に大慌てになった出来事がありました。この対応として、タスクに着手する前に、先の開発サイクルに基づいて「これくらいのスケジュールで進めよう」という開発計画を立てるようになりました。例えば…

実装開始: 3月3日
レビュー依頼: 3月5日
QAエンジニアによるテストの依頼: 3月6日
マージ: 3月7日

こういうさっくりした粒度であっても、ないよりは全然マシでした。毎日の朝会でも進捗の共有がしやすくなりましたし、「予定よりもスムーズに行っているので、次のタスクの着手が早まりそうです」とか、「少し手間取っているので、予定より遅れそうです」といったアラートも出しやすくなりました。

一工夫その2: 検証項目を丁寧に書く

タスクはIssueに書かれていて、「このような機能を実装したい」という要件や、デザインのモックなどが記載されています。これをもとに開発を進めたのに、QAエンジニアによるテストの段階で、仕様やエッジケースの考慮漏れが原因となるフィードバックを大量にいただくことがありました。

これを防ぐために、検証項目をめちゃくちゃ丁寧に書くようにしました。これによって、

仕様を「検証項目」の形で、改めて整理することができる
- 結果として、齟齬の発生を防ぐことに繋がる
レビュワーが機能のイメージを持ちやすくなる（検証項目を通して、どのような操作が可能かが伝わる）
- エッジケースの考慮漏れなどにレビューの段階で気づいてもらえる
当初のIssueから意図的に変更した点について、QAエンジニアに伝えることができる
- 実装中に得た気づきやフィードバックによって変更した点を、当初のIssueに転記しそこねる（結果としてQAエンジニアへの共有が漏れる）ことが何度か起きてしまった
  - そのときに、「Issueの仕様との差分は意図的なものですか？」と確認いただいていた…
- 「検証項目」を用意する際に、「ここは当初のIssueから差分があります」と記載することで、QAエンジニアにもれなく伝えることができた

...という効果がありました。

こういうポイントを意識するようになってから、QAエンジニアによるフィードバックの数はだいぶ減ってきた（かつ、修正内容も軽微になってきた）という実感があります。これが「サクッと進」んだと感じた理由なのかな、と思いました。

まとめ

…なんというか、こうやってブログに書いてみると全然大したことないというか、「それはそう」みたいな感じはしますネ。一方で、プロダクト開発において銀の弾丸はなくて、根本から丁寧にやるのが案外一番の近道なのかもしれないな、と感じました。

2025-01-15

VSCodeでCodespacesを動かしているとき、「code」コマンドが突然使えなくなった場合の対症療法

前回のブログにも書きましたが、最近はCodespacesをVSCodeで開いて開発をしています。

papix.hatenablog.com

想像していた以上に違和感なく使えていて、例えばVSCodeのターミナル（Codespaces上）でcode /path/to/file を実行すると、普通にCodespaces上にあるファイル/path/to/fileがそのままVSCodeで開けたりして、大変便利です。

…ただ、時折こういうエラーが出ることがありました:

Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /tmp/vscode-ipc-XXXX.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/tmp/vscode-ipc-XXXX.sock'
}

少なくともCodespacesのコンテナをrebuildすれば回復することを確認したのですが、たまに（週1くらい？）発生しており、都度rebuildするのは大変面倒でした。

あれこれ調べていた結果、$VSCODE_IPC_HOOK_CLI 環境変数で指定されたsockファイルが、/tmp にある vscode-ipc- がprefixなsockファイルのうち最新のものより古い場合、前述のエラーが発生している… ということに気づきました（いつもはCodespaces上でtmux＋zshの環境を構築して使っていて、問題が発生したときにたまたまbashで実行してみたら前述のエラーが発生せず、違いを調べていたときに、$VSCODE_IPC_HOOK_CLIが異なることに気づきました）。

ひとまず対症療法として、以下のコマンドで/tmp以下にある最新のvscode-ipc-がprefixなsockファイルを引いてきて、それを$VSCODE_IPC_HOOK_CLIに設定することで問題を解決することができました。

export VSCODE_IPC_HOOK_CLI="/tmp/$(ls /tmp -t | grep 'vscode-ipc' | head -n 1)"

おそらく、$VSCODE_IPC_HOOK_CLIを更新するような仕組みがあるはずなのですが、自分があれこれCodespacesをいじくりまわした結果、うまく動いていないのかもしれません。そのあたりの調査は時間があったときに委ねようと思います…。取り急ぎ、対症療法だけ忘備録がてら書き残しておきます。

2025-01-10

OSC 52でリモートにあるファイルの中身をクリップボードに書き込めるようにする

GitHubのCodespacesで開発する日々を過ごしています。シュッと立ち上げてVSCodeで開けばすぐに作業が開始できて便利ですし、CLIの操作もVSCodeのshellが使えるので、最近は「すべてをVSCodeに任せる」ようになっています。

あれこれ環境を整備していて、ほぼほぼ満足のいく開発体験を得られるようになったのですが、最後に困ったのがクリップボードの扱いでした。例えば「あるファイルの中身をコピーするために一旦クリップボードに入れたい」というとき、Macならcat /path/to/file | pbcopy で済みますが、Codespaces上のファイルだと（リモートにあるファイルなので）そうもいきません。

…で、あれこれ調べていると、「OSC 52」なるものがあり、これを使えば解決できそう、ということがわかりました。

※「OSC 52」については、以下のページの記載が参考になりました：

zenn.dev

自分の場合、Codespaces上でtmux + zshという開発環境を構築しているので、zshでこんな関数を用意しました。

※ このスクリプトは、以下の記事の「clipboardの同期」で紹介されていたスクリプトを参考にしました。

qiita.com

function copy-to-clipboard() {
    if ( test "$#" = 0 ); then
        payload=$(cat -)
    else
        payload=$(echo -n "$1")
    fi

    b64_payload=$(printf "%s" "$payload" | base64 -w0)

    # OSC52
    printf "\e]52;c;%s\a" "$b64_payload"
}

あとは、Codespaces上でcat /path/to/file | copy-to-cliboard するだけで、クリップボードに/path/to/fileの中身が格納されるようになります。

※ 但し、自分のようにCodespaces上でtmuxを動かしている場合は、set -g set-clipboard on しなければ正常に動作しません。

諦めずにいろいろ調べてみた結果、無事に課題が解決できてよかったです。忘れそうなので、忘備録として参考にしたウェブサイトなどをまとめて、ブログ記事にしておこうと思います。

2025-01-01

トグルホールディングス株式会社に入社します

あけましておめでとうございます、2025年もよろしくお願いいたします。

さて、タイトルにあります通り、本日2025年1月1日よりトグルホールディングス株式会社に入社します（初出社は1月6日の予定です）。

toggle.co.jp

ただ、12月より既に業務委託の形で関わらせていただいております。業務委託を受け入れてくださったトグルホールディングス株式会社と、許可して頂いた前職の株式会社はてなには大変感謝しております。

やること

「デベNAVI」という不動産に関するサービスの開発に従事する予定です。

tsukuru.ai

フロントエンドもバックエンドもTypeScriptで開発しているので、現在必死にTypeScriptのキャッチアップをしています（なので、JPAやYAPC::Japanの活動はもちろん続けますが、TypeScriptのコミュニティにも徐々に顔を出すようになるかもしれません）。

業務委託で携わった感想としては、開発環境の整備がとにかく整っているので、環境構築を開始してからだいたい8時間くらいでプロダクトを動かして最初のPull Requestを提出できました。自分のポカで詰まった部分もあったので、そういった点を潰していけば（作業内容にもよりますが）4～6時間くらいで初Pull Requestを出すことができるんじゃないか、と思います。とにかく立ち上がりの体験が良かったのが印象的です。