要件定義をすることで、言葉が整理され、実現したいことをより明確化できます

皆さんこんにちは

働き方改革で話題の「統合型校務支援システムの導入のための手引き」についてご説明をさせていただきます。
http://www.mext.go.jp/a_menu/shotou/zyouhou/detail/1408684.htm

今回は第5章3.3.3　要件定義　についてご説明させていただきます。

ここは、事務作業が非常に必要になる部分であり、やりたいことを明確に定義しておかないと後で大変なことになりますから、手引きとしてもボリュームがあります。
要するに、「どんな仕様書を書くか」ということですね。他自治体の仕様書を参考にするのも一つですし、手引きには「別紙５　調達仕様書ひな形http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/08/30/1408684-010.pdf」がありますので、こちらを参考にするのも一つです。
行政職の皆様にはお分かりの通り、「仕様書を作ろう」から仕事を始めていては細部に矛盾の出る仕様書になってしまいがちです。本当はここはこれがいい、それならここに関係するあそこも…と修正を重ねるのは得策ではありません。
ですから、まず要件を定義せよ、と手引きは述べています。その要件もいろいろありますので、手引きに沿って細かく見ていきましょう。
まず、調達仕様書の構成例が示されています。これを網羅しておけば導入後困らない、という必要最低限のひな型ですね。

統合型校務支援システムの導入・利用に関する手引き　第5章P98から引用
http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/08/30/1408684-003.pdf

これだけでも、たくさん作らないといけないなあという印象ですが、更に調達仕様書については以下の内容を盛り込んだほうがあとあとスムーズだということです。

統合型校務支援システムの導入・利用に関する手引き　第5章P98から引用
http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/08/30/1408684-003.pdf

そして、それぞれの記載内容の意図が解説されています。
①調達の背景と目的
では、どのような課題を解決するために導入するのか、共同調達、共同利用の目的はどこにあるのか等を記載する、とあります。話し合ってきた担当者間では共有されている合意事項も、業者にはわかりません。ですから、「何をどうしたいから導入するんだ」ということを書いておくと、意図が伝わりやすく、落札後「そんなこととは思わなかった」を減らすことにつながります。

②調達に置ける方針
なぜ「共同調達・共同利用の実現」をしたいのか、と言えば低コストでの導入を目指す、が大きなメリットとして考えられるからですよね。
そのために、前提条件として「クラウド型のシステム導入を前提とする」「Web方式にて動作するシステム」「パッケージシステムとしての導入を前提とし原則としてカスタマイズは行わない」等があるなら、それを明確に記載しておく必要があります。
また、「教育情報アプリケーションユニット標準仕様」に完全準拠したパッケージ製品は、将来的なシステム更改時に別の統合型校務支援システムパッケージ製品への移行がスムーズになる等のメリットが考えられます。
苦労して導入した校務支援システムを変更することがあるのか、という印象をお持ちかもしれませんが、製品によってメリット・デメリットがありますから、時代が変わればメリットも変わり、校務支援システムの製品を変更したほうがより学校のためになる、という状況が発生することも考えられます。
将来、今授業支援システムが担っている児童生徒のポートフォリオをセキュリティ上安全に校務支援システムのデータとあわせて、簡単に一元管理できるシステムが出てくるかもしれません。その場合はそちらを導入したほうがより子どもたちのため、学校のためになりますね。

③調達対象範囲
については、調達機器の明細を見ればわかるだろう、とも思いがちですが、できるだけ「読む側に負荷を与えない」仕様書を作成することによって、「こんなはずじゃなかった」の発生を抑えられるため、明確に定義しておくことはお勧めです。

④契約期間・想定スケジュール
こちらも、話し合ってきた人の間では合意事項で当然のことなのですが、「契約期間＝導入期間」ではありませんから、いつまでに全校一斉導入するということを明確に打ち出しておくと行き違いがありません。

⑤業務の要件
「対象業務の範囲」「ユーザーの規模及び場所」「管理すべき指標」の記載を行っておくとスムーズです。例えば、全県導入なら「県立高校全何校、市町村立高校全何校……」というように、明確に記載しておくと困りません。なぜなら、自治体のサイトを見て「よし、公立高校は○校だな」と思っても「県立の○○校が市内にあり、特別に参加する」や、「○○分校は今は休校状態だけれどサイトには掲載されていて、でもそこはいつか復活する予定があるからライセンスの範囲に含めておかなければならない」というような自治体の事情は、業者にとって短い期間で調べきれない場合があるからです。
それくらい調べろ、と思われるかもしれませんが、そこに労力を割いてもらうより、もっと調達コストを安くする提案を考えてもらうほうが得策ではないかと思います。

⑥システムの要件
「機能」「帳票」「情報・データ」「外部インターフェイス」から構成される「機能要件」と、「非機能要件」を記載します。詳細は手引きのこの続きにありますので、またそこでお話しします。

⑦役務の要件
研修や運用、保守業務だけではなく、　プロジェクトマネジメントに求める要件等を明確に記載しておくことを、私も強くお勧めします。記載していなければ、忙しさのあまり「教育委員会担当者と合意をする」ということすら怠って物事が進んでいく場合があります。
また、共同調達だと大きなプロジェクトですので、今までやったことがありません、サポートもいません、という人がプロジェクトマネジメントを行うと困りますよね。業者としてはそのほうが安く入札できるわけですから、入札を有利にするために削れるところは削ってくるので、後から「こんなはずじゃなかった」が発生する可能性が高まってしまうわけです。
作業実施体制に求める要件、定例報告会議の頻度や実施方法等に関する要件を記載しておくと安心ですね。具体的な記載例は「別紙５　調達仕様書ひな形http://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2018/08/30/1408684-010.pdf」にありますので、参考にしていただければと思います。

⑧納品成果物及び納入場所
こちらも明確に記載をしておくと「いつまでたっても完成図書が送られてこない」という状況を防ぐことが出来ます。「研修に使用したマニュアルのデータは会社の資産なので編集できる形式では渡せません」だと困る場合は、それも記載しておく必要がありますね。
こちらの思うことを相手は実現してくれる、といういい関係の業者は総じてコストがかかるため、入札では不利になりがちです。やってほしいことは明確に記載しておく必要があります。

⑨事業者に求める要件
事業者に望む経験や能力等について記載します。「文教全く初めてですが頑張ります！」ではたぶんうまくいかない可能性が高いわけです。ですから、「どのような経験を必要としているか」「どのような資格を必要としているか」を明記しておく必要があります。また、大規模な案件は何社もの企業体で事業を行うことも多いですが、プロジェクトマネージャーはいったいどこの会社が行うか、というのも設定しておくとよいでしょう。元請け・下請けの力関係は行政職から見て想像以上です。下請けのプロジェクトマネージャーにいくら注文しても、元請けが動かなければ調達のスピードが遅い、などという事態を避ける必要がありますね。
また、「文教初めてです」は本当にこまるわけです。期間の区切られた中で、「会社同士の話と学校相手の話は同じ単語を使っていても全然違うことがある」「お金に対する概念が全く違う」の理解から始めなければならないというのはお互いに不幸です。強力にサポートしてくれる文教で仕事をしてきた会社や人がいない限り、難しいので、それも明確に定義しておく必要がありますね。

次回は第2部第５章の続き、調達対象範囲についてご説明させていただければと思います。

何かご質問、ご意見等ございましたら是非お聞かせください。
よろしくお願い申し上げます。