Chapter 10

おまけ-2)提案書について

nobuhito
nobuhito
2022.03.06に更新

プログラムの話からは少し外れますが、仕様書と似たようなものに提案書というものがあります。
新しいシステムやプログラムを導入する際には提案書的なものが必要となる場合が多くありますので、最後に提案書についても考え方を書いておきます。

はじめに書いたとおり、情報システム部は直接お金を産むところではありません。各部署の業務改善をすすめることで間接的に利益を出していくところになります。
ですので、情報システム部という部署は、必然的に提案という機会が多くなり、それが業務的に必要なスキルとなります。

提案については出来合いのプログラムを購入しても良いでしょうし、自分で作成しても良いでしょう。
ですが、どちらにしても相手から承認をもらわないといけません。その相手は上長かも知れませんし、他部署のリーダーかも知れません。また、もしかしたら会社の経営陣の可能性もあります。
システムやプログラムの大小問わず提案する際の自分なりの型を持っておくと、プログラム作成だけにとどまらず業務をスムーズに進めることが出来るようになります。

このページでは、そんなときに社内で必要になる稟議書を例にとり、提案書を承認してもらう際の考え方をまとめておきます。
(稟議書の作りについては各社様々でしょうから参考程度です)

稟議書を決裁まで持っていくまでのプロセス

提案型の稟議書を最終決裁まで持っていくためには、通常以下のプロセスが必要となります。

  1. ベンダーと仕様や範囲を詰めて内容をまとめる
  2. 部内で提案しその内容を説明する
  3. 部内から質問や意見および指摘事項があればまたベンダーと調整する
  4. 部内で再提案して承認を得る
  5. 稟議書をまとめて関係者に回付する
  6. 稟議書が決裁される

運用や維持のためにルーチンワークとして発生する費用に対しての稟議書であれば、決裁されたという証拠としての稟議書であれば良いだけです。
しかし提案型の稟議書については、どのような内容についてどのようなプロセスでその稟議が決裁されたかという情報も残しておく必要があります。

そのため、提案型の稟議書には補足資料というものが必ず必要となります。また、その補足資料により、部内で実行に対しての承認がなされ、会社として実行に対しての決裁がなされます。実際はここまで厳密で難しい話ではない場合が多いのですが、どの責任者は何の権限があるかというところです。

大事なのは稟議書の決裁というのは「事業部門で検討された内容について会社が可否を判断する」ということで、その内容については「妥当な内容になるように部内で適切に検討されてある」というところです。
稟議書には部内で検討された内容が記載されていなければ決裁できませんし、そもそも部内で承認されてない内容は稟議書として決裁できないということになります。

必要となる書類とその内容

上記のプロセスから、稟議書の決裁というのは「部内の承認」と「会社の決裁」という 2 つの了承が必要ということになります。
その 2 つに必要となるのが内容説明用の資料で、稟議書の場合は「補足資料」で部内承認用としては「説明資料」となります。これは別々に作ると労力だけがかかるので一緒にしてしまいます。

そして、この資料を元に重要部分だけを抜粋したのが稟議書の表紙となります。表紙の位置付けはサマリーなので、これは説明資料と一部の内容が重複しても構いません。逆にあとから抜粋版をつくるので説明資料については、出来るだけ詳しく書いて長くなっても構わないということです。

ですが、技術的な細かい内容まで書く必要はありません。それは運用側の話になりますので、導入を決めた部内で解決するだけで良いです。
と考えると、次は運用も含めた部内向けの資料が必要になります。専門家として集められてる部のメンバーが、詳細資料では読めないリスクなども含めて評価するものです。また、実際の実行には作業工数や納期が必要なりますので、他業務との関係を見ながら調整が必要です。
以上から提案に際しては 3 つの書類があり、それぞれが以下の関係を持ってます。

  • 稟議書表紙
    ↑ 抜粋
  • 説明資料(稟議書の添付資料もしくは部内説明資料)
    ↓ 噛み砕き ↑ スケジュールの確認や懸案事項などの洗い出し
  • 詳細説明資料

具体的な進め方

  1. まずは「説明資料」を作成
    • 稟議書に添付する形なのでワープロ文章が好ましい
  2. 部内で確認してもらう(紙の回覧でも電子データの共有でも)
  3. 部員のフィードバックに応じて「詳細説明資料」を作成
    • 部内説明用なのでプレゼン資料が好ましい
  4. 説明資料および詳細説明資料で部内承認が終わったら「稟議書」をまとめ
    • 稟議書は所定の書式を利用
    • 必要に応じて詳細説明資料から説明資料へ必要事項を転記

もし「説明資料」で全体概要を部員が理解出来るようであれば、「詳細説明資料」は不要です。

説明資料の構造

説明資料は殆どの場合、以下の項目だけで十分です。

  1. 背景と目的
  2. 提案概要(目指すゴール)
  3. 詳細内容(ゴールに向けて実施する内容)
  4. これまでとの違い
  5. 考えられる懸案事項
  6. 導入スケジュール

また、説明資料と詳細説明資料の関係ですが、1:N の関係になることもあります。ほとんどは説明資料の一部を噛み砕いた内部仕様や構造の説明の場合が多く、自分で作らなくてはいけない場面も多いですが、多くの場合はベンダーやメーカーの提供資料でも十分な場合が多いです。

これらの項目や関係性に拘る必要はありませんが、「項目や資料間で粒度が揃っているか」ということは意識すると良いでしょう。

また、説明資料を作成する段階で稟議書への抜粋も意識しておくと、後からの作業が楽になります。稟議書の抜粋内容として必要になるのは、2 の提案概要と 3 の詳細の一部および 6 のスケジュール、それに支払いに関することです。提案概要と詳細の銭湯をそのまま転機する感じでも構いません。

新しいことを始める場合は、これまでとの違いというものがない場合もあります。ですが、これまでやってないときのデメリットと新しいことを始めた後のメリットを考えると、違いというところが見えてきます。

テクニック

粒度を意識する際に便利な機能が、ワープロに備わっている「スタイル」です。例えば GoogleDocument では項目タイトルに適切にスタイルを当てると、自動的に目次として拾ってくれます。
そうすると、項目が並ぶので粒度が揃ってない場合に気づきやすいです。

例えばこの文章の場合は↓のような構造になってますが、もしこの項目の並びに「ワープロとパワーポイントの違い」みたいな項目があったら違和感を感じるはずです。
そのような場合は、ワープロとパワーポイントの違いの説明が必要な段落に適切に移動させましょう。

image

書きたい内容を思いついた順に並べて、その内容について適当にタイトルを付けるということではなく、どういう構造で文章を作るかというグループを意識します。
そして、その大きな概念から細かい概念と流れを意識し、構造的な面から考えると分かりやすい文章になるはずです。