仕様書が書けないときは、アジャイル型で

解説（テキスト版）

はじめに

情シスには、こんな相談が届きます。紙とエクセルで回している業務を、何とかしたい。でも、何が必要なのか、うまく言葉にできない、と言われる。

あるいは、新しく始まる事業で、やり方がまだ固まっていないのに、来年度までにシステムを入れてほしい、と頼まれる。

どちらも、仕様書を書こうとしても、書けない状態です。第8回は、システム調達編の最終回です。そんなときに考えてほしい、アジャイル型の調達をお話しします。

一言で言うと

先に、一言でまとめます。仕様書が書けないのは、悪いことではありません。使ってみないと、分からないことがあるからです。

そんなときは、全部を先に決めて発注するのではなく、小さく作って、使ってみて、少しずつ良くしていく。これが、アジャイル型です。

流れのどこか

調達の流れの中では、情報収集やRFIをしても、仕様を決めきれない、という分かれ道の話です。

決めきれるなら、第4回でお話しした、仕様書を書いて調達する形に進みます。決めきれないときが、今日の話です。

仕様書が書けない状態

仕様書が書けない状態には、いくつかの形があります。

一つは、業務そのものが、まだ固まっていないときです。新しい制度や、新しく始める事業では、やりながら決まっていくことが、たくさんあります。

もう一つは、紙やエクセルで回している業務です。担当者は困っているけれど、何をシステムにすればいいのか、うまく言葉にできません。

こうした業務を、無理に仕様書にすると、想像で書いた要件が並びます。できあがってから、使えない、と分かることになります。

請負で発注すると

書ききれない仕様のまま、請負で発注すると、何が起きやすいのでしょうか。

請負は、完成したものを納めてもらう契約です。ですから、作り始める前に、完成の形を、仕様書で決めきる必要があります。

決めきれないまま発注すると、できあがってから、思っていたものと違う、と分かります。そこから直そうとすると、仕様の変更になって、そのたびに、追加の費用と時間がかかります。

ノーコードツールで少しずつ

そこで、一つの方法として、ノーコードツールを使うやり方があります。

ノーコードツールは、プログラムを書かずに、画面の上の操作で、入力の画面や、一覧、集計を作れる、クラウドのサービスです。

まずは、いちばん困っている部分だけを、小さく作って、担当課に使ってもらいます。使ってみると、ここが足りない、ここは要らない、という声が出てきます。

その声をもとに直して、また使ってもらう。これを繰り返すと、仕様書がなくても、本当に必要な形が、だんだん見えてきます。

作るのは、職員自身のこともあれば、事業者に手伝ってもらうこともあります。どちらにしても、使う人の近くで、すぐに直せることが強みです。

請負と準委任

事業者に手伝ってもらうときは、契約の形が大事です。

請負は、仕事の完成に責任を持つ契約です。決めたものを、決めた日までに、完成させて納めます。

準委任は、決めた作業を、きちんと行うことに責任を持つ契約です。専門家として、注意を尽くして作業します。完成そのものを、約束するものではありません。

少しずつ良くしていくやり方には、作業に責任を持つ、準委任のほうが向いています。2020年の民法の改正で、成果に対して報酬を払う形の準委任も、はっきり定められました。

アジャイル型の進め方

アジャイル型では、作りたいものを、小さな単位に分けて、優先度の高いものから並べます。

そして、2週間ほどの短い区切りで、作って、担当課に見せて、意見をもらって、直す。これを繰り返します。

サービス設計12箇条の、何度も繰り返す、という考え方そのものです。早いうちに、違う、に気づけるので、手戻りが小さくなります。

自治体でやるときの注意

ただし、自治体でこのやり方を進めるには、注意することがあります。

一つ目は、発注した側の体制です。区切りのたびに、見て、決める人が必要です。担当課から、判断できる人を出してもらいます。

二つ目は、予算と期間の上限です。準委任は、作業の時間に対して払うことが多いので、上限を決めておかないと、いつまでも続きます。何をどこまで作れたら、ひと区切りにするのかも、決めておきます。

三つ目は、ツールの選び方です。個人情報を扱うなら、セキュリティの決まりに合ったサービスかを、情シスが確かめます。データを取り出せるかも、第4回の話と同じように、確かめておきます。

そして、作った人しか分からない、という状態にしないことです。作った画面の一覧や、設定の考え方を、残しておきます。

参考になる資料

進め方の参考になる資料も、あります。

デジタル庁は、アジャイル開発の実践ガイドブックを、公開しています。国の情報システムで、アジャイル開発を進めるときの考え方が、まとめられています。

また、情報処理推進機構は、アジャイル開発向けの、契約書のひな形を、公開しています。準委任の契約を、前提にしたものです。自治体で使うときは、契約担当の課と、中身を確かめてください。

現場でよくある誤解

現場でよくある誤解を、3つ挙げます。

一つ目。準委任なら、発注した側は何もしなくていい、という誤解です。逆です。区切りのたびに、見て、決める役割が、こちらにあります。

二つ目。アジャイルは、計画を立てない、という誤解です。全体の目的、予算、期間の上限は、最初に決めます。細かい中身を、作りながら決めていきます。

三つ目。ノーコードツールなら、情シスは関わらなくていい、という誤解です。扱う情報、アカウントの管理、データの取り出しは、情シスが一緒に確かめます。

最初に確かめること

では、仕様書が書けない、と感じたら、まず何を確かめればいいでしょうか。

一つ目。本当に、全部が書けないのかです。決められるところは仕様書に書き、決めきれないところを、少しずつ作る、という組み合わせもあります。

二つ目。担当課で、使って、意見を出して、判断する人を、出せるかです。それができないなら、まず体制から考えます。

三つ目。庁内で使える、ノーコードツールがあるかです。すでに契約しているサービスがあれば、小さく始めやすくなります。

システム調達編のふり返り

これで、システム調達編は最後です。ふり返ります。

第0回は、調達の全体の流れ。第1回は、このままでいい、と言われたときの、サービス設計12箇条。第2回は、RFI。第3回は、予算と契約の、年度の壁でした。

第4回は、仕様書の作り方。第5回は、入札と、プロポーザル、そして公平性。第6回は、導入から本番まで。第7回は、運用中の課題の管理。そして今日が、仕様書が書けないときの、アジャイル型の調達でした。

最後に

システムの調達は、相談から、次の更新までの輪です。一度買って終わりではなく、使いながら記録して、次に生かします。

迷ったときは、そのシステムで、住民や職員の仕事が、良くなるのか、に戻ってください。情報システムではなく、サービスを作る、です。

この動画が参考になったら、グッドボタンとチャンネル登録をお願いします。最後までご覧いただき、ありがとうございました。