ROUTE06では今年度からGitHubを活用した新しい稟議システムの運用を開始しました。ソフトウェア開発において技術やアーキテクチャ選定で活用されるArchitectural Decision Record (ADR)の思想と手法に習い、会社運営に関わる意思決定のログ(申請/承認/回覧)を記録する仕組みを構築し、Corporate Decision Record (CDR)と命名しております。少額の経費申請から大型投資や資金調達まで、管理職の権限と責任に基づくあらゆる承認がCDRを介して行われるようになりました。

この記事ではCDRは具体的にどのようなシステムであり、どのような設計思想のもとで構築されたのかについてご紹介していきます。

これまでの稟議

CDRが稼働する以前は、別の稟議システムが活用されていました。従業員数の増加に伴い、請求・支払に関する承認プロセスの整備が必要であったことから、会計SaaSとの連携性の高いツールを採用した経緯があります。一方で、理想とする稟議のあり方については、経営メンバーを中心に頻繁に議論されていたテーマでもありました。

スタートアップの成長過程において稟議システムが導入され、権限・責任・承認プロセスが明瞭になる一方で、意思決定のテンポや機動性が損なわれたり、自身及び所属部門に関わる意思決定以外の情報については見通しが悪くなった状態などを経験した方も多いのではないでしょうか。一般的な稟議システムは上場準備の過程におけるコーポレートガバナンスの強化を主目的として設計されています。

入力フォームやワークフローなどの機能面での柔軟性、通知や操作などインタフェース面での利便性、文書保管や権限管理などの安定性を重視したツールは少なくないものの、ソフトウェア開発のADRのように当事者以外の多数の関係者が過去のドキュメントを閲覧・活用する状態を必ずしもユースケースとして想定されているわけではありません。

そのような背景があるなかで、ROUTE06ではコーポレートガバナンス強化にとどまらず、従業員数や社歴に応じて「組織の形式知が飛躍的に増大するナレッジプラットフォーム」になることを新しい稟議システムのミッションと定めています。社内のInnerSourceチーム及びコーポレートチームのメンバーを中心に、後述の設計思想のもとで新たに設計・構築された稟議システムがCDRです。

CDRの設計思想

CDRは権限管理やデータ保存などの稟議としての基本要件の充足を前提としつつ、以下の点を重視して設計されています。

1.ログの透明性

CDRは一般的な稟議と比べて、承認の結果よりも、承認までの議論や稟議書の内容などの情報活用に重きを置いています。そのため、起案のプロセスおいて承認者のコメントやフィードバック・修正履歴などの議論のログをできるだけ残し、また承認されたドキュメントをできるだけ多くの人が閲覧できる状態を重視しています。

人事・経営・個人情報に関わる論点など閲覧権限の制限が合理的かつ倫理的であると判断される場合を除き、基本的な投資判断・契約締結・経費支出などは全社員が閲覧可能です。たとえ取締役であっても、どのような経費支出を行なっているかも全てオープンに公開されています。経営資源の活用や権利義務の発生・移転・更新に関する情報ができるだけ広く共有されることで、意思決定の質が健全に進化し続ける組織を目指しています。

2.承認フローの機動性

一般的な稟議ワークフローでは複数ステップが存在します。CDRでは起案者と承認者の立場と権限を明確にすることで、承認プロセスを1段階で完了できるように設計されています。前提として稟議の起案者は承認権限を持つ役職者の直下の社員が行い、かつ承認プロセスはその事象に対して権限を有する役職者のみが行うべきであると考えています。

実際は複数部長や本部長による合議が必要な場合も多いものの、部長→本部長などのエスカレーション承認のステップは仕組みとして用意されていません。また経費支出など軽微なものを除き、決裁区分の大多数の内容は部長以上が起案者となるように設計されています。稟議における起案者と承認者の立場を定めることで、プロセスの階層化を減らすことが可能になり、意思決定の機動性を高めていきたいと考えています。

3.技術と蓄積による拡張性

前述の通りCDRのドキュメントは全てGitHub上に蓄積されています。社員数が増えるほど、起案の実績が増えるほど、ナレッジプラットフォームとしての価値は高まる構造であるだけでなく、特定フォーマットで情報が集約されているため、今後様々な集計分析を行うことも可能になります。また現時点は検討段階ではありますが、プライベートLLMなどにCDRの情報を学習させることで、起案者や承認者の業務をサポートする仕組みを構築するなども考えられます。

技術成長と組織拡大に応じて社員それぞれが活用できる社内情報も進化していくように、そのような意思決定のログをデータ資産として活用することを前提としたフォーマットや環境を重視することも、CDRの設計思想の一つです。

CDRのワークフロー

CDRの基礎は前述の通り、ソフトウェア開発におけるADRの思想と手法を、組織全体の意思決定及び稟議フローに拡張適用したものです。ADRはGitのようなバージョン管理システムと相性がよく、またROUTE06は全社ワークプレイスとしてGitHubを全社員が日常的に利用していることもあり、CDRの稟議ワークフローもGitHubの特定RepositoryにおけるCommit及びPull Requestプロセスを活用して実装されています。

STEP 1. 稟議書の作成

起案のプロセスは、CDR Repositoryで特定フォルダ内に稟議書(mdファイル)を作成することから始まります。テンプレートをもとに承認内容等を記載したドキュメント(必要に応じて添付ファイルなども)をアップロードします。

STEP 2. 承認の手続き

稟議書の作成後、起案者は対象BranchのPull Requestを行います。決裁権限表を参考にしながらReviewerに承認者をアサインすることで、意思決定のプロセスが開始されます。当該Pull Request内でコメントや編集提案を行うことで、承認内容が議論されていきます。CDR Repositoryの更新はSlackにも通知されます。

STEP 3. 決定の記録

承認者全てのApproveを経て稟議書はMergeされ、その時点に解いて起案内容が決議されたものとして関連ドキュメントが記録されます。main内のmdファイルがSSOT(Single Source of Truth)となり、また過去の議論のログはCloseされたPull Requestを閲覧することで把握することできます。

ナレッジプラットフォームとして

CDRによって組織の意思決定の質と再現性が向上していくだけではなく、プロアクティブにその情報を活用する社員が増えていく状態を目指していきたいと考えています。新入社員や新たに昇進した役職者でも、過去のログやデータを利便性高く参照することで、従来よりもスムーズかつ効率的に仕事を進められるようになるでしょう。

CDRは始まったばかりの仕組みであり、改善すべき課題も沢山あります。GitHubの利用に慣れているROUTE06のメンバーであっても、CDRでの起案/活用にハードルを高く感じる人も少なくありません。CDRは情報が蓄積するほど利便性が高まるプラットフォームでもあり、これから着実な運用と蓄積を進めることで、自社独自の強みとなるプロダクトへと育てていきたいと考えています。

関連記事