この記事は「個人アプリ/サービス開発の進め方と運用、得た学び【PR】 Lenovo Advent Calendar 2020」の6日目の記事です。

先週に臨時国会が終了し、大変な部署もそうでない部署もお疲れ様でした。今年の中心的な話題は、経済にも大きな影響を与えた新型コロナウィルスへの対策についてで、公務員にもハンコ廃止とデジタル化の改革流れが来ています。

耳鳴りがするほど文書管理について様々な話があったかと思いますが、今一度、従来とは違うアプローチでこれを考えてみました。

書類はあふれるような数やり取りがなされ、文書に一つ一つつけている背表紙を内容とあっているかどうか確認するような人力管理は、限界があり全体のコラボレーションをとる必要があります。
今のトレンドに乗って、タグを使って書類の管理するそんなシステムを実現するモックモデルを作ってみました。

SingaPile

QRコードを用いて文書やフォルダなどの関係性をまとめて、管理対象がどこに含まれてるか確認します。

システムには内容を含めず、書類の関係性だけを記載して、書類の秘匿性に制限を受けず、一律に取り扱いをできるようにして包括的な文書管理システムを目指して考えました。

https://singapile.web.app

Trunkと名前の付けた入れ物に対して、
https://singapile.web.app/scan?p=A7A00F5201DE01AAFF055B5BA037E17D
入っているものを管理しています。
https://singapile.web.app/scan?p=C8AC2224BDD8619296257AFF2F74AD8B
各要素は入れ子にできるようにしています。
以降に、作るまでに考えていたことを下記にまとめていきます。

ソースコードは、GitHubに挙げています。

https://github.com/noolbar/singapile

#　要件定義
作ると決めたのなら何が必要か理解しなければいけません。
街を見渡せば、QRコードを読み取って在庫の確認をしているようなソフトはよく出回っています。みんなそんなソフトを見かけて、職場に導入できないかなと考えて文書監査の時などによく話に上がるのでしょう。ユニクロアプリではバーコードをスキャンすれば在庫やレビューがチェックできるそうです。似たようなソフトは、多く出ており制作会社を見つけるのはそれほど難しそうではなさそうですが、ほしいものは自分たちで決める必要があり、ドメイン知識も重要になります。

ユースケース

ほしいものを考えるには、まずは夢を膨らませます。実務上起こるようなケースを理想的に行うためのそんなソフトを考えます。

一般管理

e-Govポータルサイト https://www.e-gov.go.jp をみると文書管理がどのように行われているかわかります。

適当なものをいくつか見てみると、いつ取得したか、分類、文書管理者などが書かれています。
媒体の種別に紙とあるものは、背表紙をつけて紙の保存を行っていますが、保存するだけならまだしも、出したり入れたりしていたらどこから抜いたのか管理が大変になります。利用しないのなら保存する意味はないため、このようなケースは多いと思います。

そこで書類のステータスを確認するにはQRコード（ID）をスキャンし、どこで管理されて書類かわかるようにします

保存期間を過ぎているかどうか確認し、過ぎているものは一律に廃棄します。データベースと実物の情報が常に一致することで、作業の間違いがなくなります。

複製

オリジナルと複製は別な管理を行いたいです。複製は配ったものを好きに廃棄していいですが、オリジナルはずっと取っておきたいです。管理者がいくつ複製したのかを明確にして、もらった人は捨てていいのかどうかIDを確認することで処置の必要性がわかります。

統合や分割

受け取った書類にはいろいろな情報が含まれています。対外的に提出する情報と中だけで使う情報に分割して管理したい場合があります。

作った情報を2つの情報を1つの子要素として管理することで元の文書の文書管理に合わせて子要素の管理を決めることができます。

より複雑な処理

担当がわからないがEメールを受け取り、内容の修正や質問への更問など膨大な量の書類が来ている部署にあなたがいるとき、担当を明確にしたいので一斉に連絡を行い、かつ、担当割が終わったら投げた先に処理を一任したいはずです。

受付のためEメールにIDを付加します。IDを仕分けの仕掛かりの状態に紐づけ、そのIDの受領完了させます。（担当割がスムーズに進んだとして）担当は新たに別のQRコード（ID）を付加します。

同じIDで処理すれば一律に管理できそうで、なんだか無駄なIDのように見えます。が、もちろん意味があります。文書管理者を明確にするための作業です。

あなたは担当を決めた時点で仕事終了です。内容をもう知る必要がなく、担当につなぐだけです。しかし担当はそうではありません。もらった内容から作業を行う必要があります。間違っても消されたりしたら困ります。そのため、必要な内容は自分で管理できるようにIDを付加するようにしています。

担当者以外は、もらった情報をどのようにすればいいのでしょうか。検討の段階で複製しているかもしれません。書類のステータスを確認するにはQRコードをみて保存期間を過ぎているかどうか確認し、過ぎているものは一律に廃棄します。

連続してチェインを作ることで、カンバン管理のようなことも処理できるようにします。

その他の付帯的な処置

こんな機能とかもあるとうれしいです。

QRコードが破損した場合を考え、印刷するコードの下にはデータの内容を人間が読み取れるようにする
フローを決定して、その後の処置を表示して、現在のステータスを出せるようにする
管理対象について、CSVで出力をする
ユーザ、グループごとの管理
同じものに対して違うQRコードを与えたときの処置

#　規律と予算

業務システムで面倒な縛りとなるのが規律と予算です。絶対に破れない規律が法律です。対外的に後ろ暗いものがあるものは絶対にうまくいきません。ほかにも、ローカルルールもありますし、細かく細分化した規則やその解釈のブレがあり、すべてに適用できるものを作るのはむずかしそうですのですので、使用する部署に合わせてシステムを作りこむのがよさそうです。予算については悩みどころです。システムをどこかにホストする必要があるため、無視できない部分です。

必要なドメイン知識

システムを考えるうえで、使い方のほかにも使う側の事情を頭に入れておく必要があります。

必要なものは最初にそろっているわけではなく、文書は減ったり増えたりする
複数の文書にまたがり起案された文章は、複数に影響を受け、複数にまたがる影響を与える n-nのペアが存在する
作成、複製、経由、受領、譲渡、破棄、分割、これらが複数が同時におこる
管理していない文章を引用することがある
必要な時になくてはならないし、期間を過ぎてあってもいけない
当初の予定から、保存期間が変わることがある
文書が前後の文脈なしに、細切れに引用されることがある
無限に複製が起こる
起案と完成時で別に管理を行いたい
受付とは違う経由をしているということを残したい
管理者の移管をどのように管理するか
ネットワークが、内部と外部で分かれており、外部に接続されたネットワークでは扱えない文書がある

法律については、公文書制度の概要から、満たすべき規律の取っ掛かりとします。
https://www8.cao.go.jp/chosei/koubun/about/gaiyou/point.pdf

「公文書等の管理に関する法律」の元に内閣府が方針を決め、各省庁より細かい、もしくは、区分を決めて書類を管理しています。

セキュリティに関しては個人情報の保護に関する法律、行政機関（独立行政法人等）の保有する情報の公開に関する法律、安全保障にかかわる行政機関では、日米相互防衛援助協定等に伴う秘密保護法、特定秘密の保護に関する法律などを守る必要があります。
具体的な内容については、柔軟な運用を行うため各省庁の文書管理で細部を決めており、ここらへんはまとまったものがないので、状況に合わせる必要があります。

考えられる問題

検証中に起こりそうな問題も考えておくほうが手戻りが少なくなりそうです。

複製した文書には、どこに送付したかのかわかるようにQRコードが付されるが、そのあとにそれを再利用されると登録に重複が起こる
登録された文書かどうか、見た目だけではわからない
経由された文書など履歴を利用するが、履歴にも公開の範囲が必要
一時的に作成される文書がたくさんある場合、登録が難しく、管理外の文書が生まれる
外部ネットワークのファイル登録をいたずらに増やされることがある

問題の解決策でざっと考えられるものを並べます。

重複したものをスキャンすることで、移動があったことを検出する
対象文書をスキャンされたとき、どこに含まれているか表示する
文書をもらうときには、コードが付されていることを確認する（運用回避）
ユーザ登録性にする。デバイスごとのID,IPなどで分けてもよい
文書間の関係性のみを扱うことで、内容に関係なく一律な運用を行うことができる

ほかの要望の追加事項がありそうなものには、ブラックライトのようなものでしか見えないインクでIDを印刷をしたいなどの要望があるかもしれません。

管理動作について

いろいろ上げてきました。やることが多すぎで、やる気がそがれます。複数の部署で利用するものだとすると方向性の合意は取れそうにありません。
一気に完成形にするのは難しく、小さな試行版を動かしながら、ブラシュアップするのがベストのように思います。

システムは、直感的にわかる使いやすいものがいいです。文書を作成するときにはコンピュータを使うので、管理するときもファイルシステムをイメージできると使いやすいと考えられます。

キーワードをつけることができればファイル検索のようにできそうですが、キーワードは中身に大きく関係するため、実装は慎重に行う必要があります。内容をシステムに含めないことであらゆる文書の関係性を一つのシステムで扱うことができるようにすることを意図しているため、ここはどこにホストする場合でも注意しなければいけません。。

これらから、必要な内容はOSファイル操作を見習って作ってく方針とします。

必要なケースをソフトウェア動作に当てはめる

必要な操作はファイル操作のコマンドと突き合わせて内容を考えます。

作成 mkdir, touch
未保存ファイルを保存する。QRコードを印刷した時点では管理対象にならずシステムへ登録して管理対象になる。登録に対しては保存先が必ず設定され、どこにも参照されない関係性の切れた書類ができないようにする。

複製 cp, dd
文書を複製したときに新規ではなく、複製文書であることを明確にする。

移動 mv
ルートディレクトリからのパスを変える。子要素もあわせて移動する。廃棄とにたような動作になりそう。

権限　chown, chmod
文書管理者の変更、経由などがこの動作になりそう。受付先と必要としている先が異なることを解決させる操作であり、いろいろ複雑にできるが、ユーザの操作が煩雑になるため実装する操作は要検討

破棄 rm, rmdir

消費 QRコードを使えないようにする。追記することを禁止し、すべての操作の起点にすること禁止する。
完全消去 QRコードを再利用できるようにする　未使用と再利用の使い分けがある　リレーションが完全に壊れるため実装はよく考える
不良 QRコードが無効であることを示す
リフレッシュ QRコードを古いものから新しいものに変える

分割 split
一つの文書を複数の文書に分割する操作

参照 ln　OSファイルシステムの実装
保管は別なところで行うが、関係があるところから参照できるようにする

merge, ls, find, history, pwd, sort このあたりも必要になりそうです。

技術選定

文書管理のために動き回るのであれば、スマートフォンで動くQRコードを利用するアプリがよさそうです。デバイスはセキュリティ上、専用のものを用意できればいいですが試行版では予算面で難しそうです。スマホは普及率が高いですし、持っている人のみで使用感を確かめていくことにします。

行政文書管理はe-Govで公開しているため、内容さえ含まれていなければいけそうな気もします（未確認）。業務に関する一切を私用デバイスで扱っていけないとなると、お手上げ状態ですが何とかなるものとして考えます。

管理対象には、内容を含まないようにしたいので起点はすべて現物についているIDになります。使い方はWebサイトにアクセスして、QRコードを撮影して、あれこれするようにします。
実装に関する方法は何でもいいので以下のようにしました。

QRコード
- 普及率の高さから採用コードは何でもいいが、運用後の変更は難しい。
React-qr-reader cozmo/jsQRのラッパー
- MediaDeviceを利用してカメラから画像を取得する
- httpsである必要がある
React
- 有名で使える人が多い
Firebase
- AWSのサービスは永久無料がないのでこれに決定

Reactを使うにあたって、以下のライブラリも利用させていただきました👌

react-hook-form
react-router

QRコードの内容

Googleレンズなどは、URLを読み込むことでアクセスすることができるため、URL+クエリをQRコードに書き入れます。これによってソフトを立ち上げなくても、URLの読み込み動作から、ソフトがクエリ部分のIDを読み込み、管理の動作につなげられるようにします。
生成したQRコードはシールに印刷して、管理したい文書にぺたぺた張り付けていくことにします。

IDに含める情報は、つける対象ではなく印刷時や固有の情報を与える必要があります。いろいろ考えましたが、時間のSHA1ハッシュをつけて試作しました。衝突しなければなんでも良しにしています。
これは、印刷、保管、貼り付けまでの間に時間があり、複雑なことをしようとするといろいろな種類のコードを管理する必要があるためです。以下のような情報を考えましたが、今回は保留です。

ソートできる情報
- 一か所で一連の番号を作ったとしても実際に使用されるまでに時間差があり、連番に使われると限らないのであまり意味ないかも
所属
- ほかで使われると管理対象と所属がぐちゃぐちゃになるため、あまりあてにしてシステムを作ることができない。また、可変の内容がQRコードに含まれるのがよろしくない
- キーワードなどもここに含める
時間
- 時刻は登録時に使用することが確定されるため、IDにはないほうがいい。使用時の印刷するようなシステムでもあれば有効
大区分、中区分、小区分などの分類
- 変更されるうえ、シールの種類が多くなりすぎるためこれはおそらく管理できない
作成者のID
- 一括で検察できるが、移動などによって管理者が変わる場合に対応できない。
電子上のファイルパス
- 長くなりすぎるうえ、内容がQRコードに含まれるのがよろしくない。
初期動作フロー
- そのあとの動作を行うにあたってずっと残ってしまい、一意なIDを割り当てるのがむずかしい。
- 同じ動作をさせるのであれば、ソフトウェアの動作の一つとしていれるのが好ましい。

マイルストン

とりあえず重要そうなところからとりかかりました。

一元管理システムからデータを引っ張ってきて、ユーザの使用感を試す
- とりあえず登録できる機能をつくりました。Trunkと呼び大区分、中区分、小区分を書き入れられる
QRコードをかざし、URLを読み取り、どこに保存されているか表示する。作成、移動ボタンを表示
- 保存されていない場合には、作成ボタンを表示
- すでに保管されているものについては、移動を表示
- QRコードのドメインは運用後変更できず、その後ずっと保管する必要があるため慎重に決定したほうがいい。
10～1000程度のスケールで動作できるもの
機能を限定
- 作成と移動だけあればいい
画面には、カメラ画像、読み取り内容、作成OR移動ボタンを表示
- 使っていくうちに不便だったので、リセットとカメラ切り替えを付けました。

政府共通プラットフォーム

実装するにあたって、ホストするためのプラットフォームを決める必要があります。

現存する情報システムがどこで動いているかを真似すれば、実現できそうです。
各省庁、各独立行政法人、各部署で独自にインフラを整えていますが、トレンドは集約化に向いておりそこに逆らわないほうが話が進みやすいかと思います。
ここで、そんなインフラの集約を目的とした政府共通プラットフォームの利用を考えてみます。
政府共通プラットフォームとは、2009年に掲げた霞が関クラウドの基盤システムで、いろいろあって管理業務の事業者にNEC、日立システムズが入り、Amazon Web Services（AWS）上で運用することになりました。以前よりこういったシステムは、富士通とMicrosoftをよく見かけていたので結果には驚きです。
https://www.soumu.go.jp/main_sosiki/gyoukan/kanri/a_01-03.html

政府共通プラットフォームの整備は、第１期と第2期と段階を踏んで計画されており、2020年10月から第2期の運用が開始しました。共通のプラットフォームで運用することで全体のコスト低減など様々な問題を解決することを目的にしています。

公開している資料からは、どのようなものを運用できるのか規定は見つかりませんでした。中で務めている人であれば、問い合わせるのが近道でしょう。

ここでは利用できそうかどうかを公開資料から見てみます。
https://www.soumu.go.jp/main_content/000709984.pdf
移⾏対象システム

政府が直接保有・管理する必要があると考えられる情報システムを移行（パブリック・クラウドとの棲み分け）
移行に当たっては、投資対効果の検証を徹底

国費投入の必要性については、総務省管轄の文書管理システムがまさに政府共通プラットフォームで動作しているため、改善として利用するということで説明が立ちそうです。費用効果については、独自調達と政府共通プラットフォームにした時の差額を示せそうです。

考慮しなければいけない事項としては、以下のようなものを考えられます。

業務内容に文書管理を総括する部署でない場合、所掌範囲外の業務を提案として上げなければいけない
似たようなシステムが乱立するような状況は避けれるなら避けたい
試行版を作ってから内容を詰めるような使い方ができるのか

ほかにもいろいろと出てくると思いますが、一番の問題は利用にあたっては費用負担が必要になることです。つまり予算です。

システムに必要な予算をちゃんととってくるのであれば2年前の概算要求から始まります。政府共通プラットフォームの負担分の予算取りを考えるのであれば、3年前から構想が必要になります。
https://cio.go.jp/guide/manual_t/manual_1/index.html#s1_2
ここをみれば、プロジェクトの標準的な活動スケジュールで運用開始の4年前から線表が引いてあります。

大企業に勤めている人であればわかると思いますが、総合職、一般職を問わず、頻繁に配置換えがあり、４年後に同じ仕事をしている可能性は低いです。必要な時に簡単にホストすることができるような環境にならない限り、立ち上げにかかわったシステムを拝むことはできないでしょう。

現時点で公開されている解決策はなさそうです😢
せっかく基盤システムを持たずに資産を必要な時に利用できるような仕組みにしているのですから、予算面で柔軟になれば恩恵を受ける人はかなり多いはずです。

さいごに

この記事では技術的な話より、何を作るかわからない状態でどうやって作るものをまとめるかに重きを置いて記載してきました。ドメインに関する内容は、各官庁でバラバラなこともあり、抽象的な部分も多くなってしまいました。

いろいろな意見を聞いていると訳の分からない方向に進むプロジェクトをよく見かけます。
コンピュータを使った一律な仕組みを作ってしまえば、教育のコストは低く運用できます。検証環境としてパパっと作ってしまい、筋が悪ければ別な方法にピポットしてしまえばいいと思います。

政府共通プラットフォームは、ミスが許されないようなシステムは慎重に作り、もがきながら作っていくような試行版のシステムは軽く運用できる構想が当初より計画されています。厳しくするところは明確にして、利用できそうなころから広げていく、そんな業務の進め方ができればよいと思いこの記事を書きました。

文書の管理に関して思うところとして、行政文書の管理の在り方等に関する閣僚会議発の「公文書管理の適正の確保のための取組について平成30年７月20日」では財務省、防衛省が名指しで再発防止の重視が示されており、他の官庁は巻き添えを食ったかのように思っているのかもしれません。

しかし、実際動いている担当にしてみれば、対岸の火事でなくどこにでも起こる問題と思っているはずです。今の仕組みは人間の運用能力を超えるものになっていると言い切っていいです。管理の仕組みの中に人間が入り込んでおり、運用で問題を回避するような建付けが、この構造をつくりだしていると考えています。

退職まで逃げ切り決め込んでいる職員には、積極的な改善は期待できないでしょう。入ったばかりの新人にとって今までの負の遺産は、上の世代から降ってきたのもので、この問題を背負わせるのは酷かと思います。

どこかで断ち切るのだとすれば、今問題を抱えている職員です。システムは後発有利に開発できるため、今から取り掛かる場合でも後れを取ることはありません。
この記事が改革のトレンドの後押しになればと思います。

面白いと思ったらLGTMボタンを押して、シェアしてね👍