「未承認」と表示されて気づいたこと ― 決裁の可視化がもたらした訂正

表示方式を変えたら、隠れていたことが見えた

本日、SKY SOCIAL LABのサイトの見た目を作り直した。トップページは構築記録を主役に置き、収集と考察は日付順にまとめて畳む形に変更した。あわせて、記事ページにある決裁欄の仕組みも変えた。これまでは承認の結果をHTMLに直接書き込んでいたが、これを台帳を読んで表示する方式に切り替えた。承認が台帳に記録されていなければ、自動的に「未承認」と表示される仕組みである。

この変更を反映した直後、8月19日と20日に公開した記事が「未承認」と表示されることが判明した。過去に承認したはずの記事である。何かがおかしいと考え、原因を確認した。

原因は仕組みではなく、手順だった

調べると、該当の記事はApproveを押さずに、Bypass rules and mergeでマージしていたことが分かった。承認を記録する仕組みは、レビューの承認操作が行われたときにのみ動くように作ってある。マージという操作そのものは、承認の有無にかかわらず可能であり、承認操作を経ずにマージすれば、台帳には何も記録されない。

つまりこれは、承認を記録する仕組みが壊れていたわけではない。仕組みは設計どおりに動いていた。運用する側が、承認という手順を飛ばしていたというのが実際のところである。表示方式を変えたことで、これまで見えなかった手順の抜けが表に出てきた形になる。

直せないものは、直したふりをしない

次に検討したのは、この状態をどう扱うかだった。マージ済みのプルリクエストは、後から承認操作を行うことができないことを確認した。つまり、今から「正しく承認し直す」ことはできない。

ここで選べる道は二つあった。一つは、台帳を直接書き換えて承認済みに見せること。もう一つは、未承認のまま確定させ、その事実を記録に残すことである。

該当する稟議R-0008とR-0009については、後者を選んだ。台帳を書き換えて承認済みに見せることはしないと判断し、稟議一覧に訂正文を追加した。承認済みとして扱い直すことはしない、という一文である。記録の見栄えを整えるより、記録が記録として機能することを優先した。

この件が示すこと

承認の仕組みそのものは、以前から存在していた。しかし、承認結果をHTMLに直接書き込む方式だったため、手順を飛ばしても外からは分からない状態が続いていた。表示方式を変え、台帳を読んで表示するようにしたことで、初めて手順の抜けが見えるようになった。これは仕組みの改善が意図せず過去のミスを掘り起こした例である。

中小企業でも、承認や決裁の記録が「書類上は整っているが、実際の手順は省略されていた」という状態は起こりうる。承認欄に印だけがあり、承認者が実際に内容を確認していないケースなどはその一例である。今回のように、記録の見せ方を変えるだけで、こうした手順の抜けが可視化されることがある。

大切なのは、見えてしまったものをなかったことにしないことだと考える。都合の悪い記録を書き換えて整えるのではなく、そのまま残し、訂正として明記する。手間はかかるが、その積み重ねが記録全体の信頼につながる。