今、蕨市議会3月定例会が開かれています。
市議会の定例会は、全国どこでもおそらく同じで、3,6,9,12月の3ヶ月毎、年に4回、それぞれ一ヶ月間に渡って開かれます。
3月議会では、予算審議を行うので、話し合う量が最も多くなります。
（決算審議を行うのは9月議会です）
議会開会中といえども、朝から晩まで毎日やっているわけではありません。
当たり前の話ですが、会議には、その事前の準備のために何十倍もの時間が必要なので、3日やって3日休憩くらいのペースで進んでいきます。
また、よく国会なんかだと紛糾して会議が深夜に及んだりするようなことが時々ありますし、他の地方議会ではそういうこともあるようですが、蕨市議会では、慣習的に必ず17～18時くらいには終えることになっています。
市議会の定例会における一般質問
「一般質問」というものがあります。
そもそも、ちょっと分かりにくいのですが、「質疑」と「一般質問」とは、議会では区別して用いられています。
一種の専門用語です。
質疑：
議案、請願に対して、尋ねること。
市長（市執行部）が提出した議案なり、誰か議員が紹介して提出きた請願なり、対象があり、これを提出した人に対して、聞くことです。
一般質問：
テーマは自由で、何を訪ねてもOK。
相手は、市長（市執行部）となります。
具体的に目の前で問題が起こっているテーマについて、市長側の考えなり対応策なりを具体的に尋ねる形でもいいし、自分の意見を一本的に開陳した上で「～～と私は考えるが、市長はどう考えるか？」みたいな主張を述べることを主眼とした話し方もOKです。
今回の2014年3月定例会における、私 ほやたけし（保谷武）の一般質問の発言通告内容
以下の内容で2題、出しました。
細かい文言は微修正が入ります。
待機児童対策について
1. 保育サービスの4年前、2年前、本年の需要人数合計の推移は。
保育サービスの2年後、4年後の需要人数合計の見込みは。
2. 認可保育園、家庭保育室それぞれにおける、年齢別定員数、待ち人数は。
3. 平成27年4月に塚越に新規に開設される認可保育園の年齢別定員数は。
4. 認可保育園、家庭保育室それぞれにおける、保育士一人当たり担当する子どもの人数は。
5. 家庭保育室における、有資格者割合は。
6. 市内の認可外保育園のうち、家庭保育室として本市と委託契約を結んでいない保育園の件数と定員数合計は。
それらが家庭保育室として契約しない理由は。
7.認可保育園に申し込んだ場合の、待ち順番を決める方法は何か。
夫婦と1歳0ヶ月の子どもが一人で、世帯年収438万の家族において、
認可保育園に預ける場合の、月額保育料は。
家庭保育室に預ける場合の、月額保育料の最大値、平均値、最小値は。
8. 私立の2認可保育園それぞれの事業計画における、初期投資総額は。
内、行政から補助した割合は。
想定初期投資回収期間は。
9. 市立認可保育園、私立認可保育園、家庭保育室それぞれの、運営費に対する行政からの子ども一人当たり年間所与額は。
10. 少なからぬ待機児童がいる現状をどのように考えているか。
11. 今後、どのような方針で対処していくのか。
12. 次なる認可保育園の新設予定はあるか。
13. 待機児童問題は、いつ解消するのか。
14. 初期投資額を抑えつつ保育サービスの供給量を抜本的に増やし、今後の需要人数に対応できるようにするために、家庭保育室制度の拡充に力を入れてはどうか。
いろいろ細かいことは正直どうでもよくて、主眼は以下です。
・市内の待機児童は、まだまだゼロになる見込みはない。
今は、「質より量」を確保するフェーズだと考える。
（最低限の質を確保することを前提として）
・現状の蕨市の待機児童対策は、認可保育園の整備中心である。
まだ不足しているので、今の方針で行くならば、さらに増設が必要となる。
・認可保育園は、イニシャル投資額は大きく、新設期間も2年くらいかかるし、長期間経営しないとペイしない。
・さらに、今後「存在感大きな街 ビッグシティ蕨」構想を推し進めていくと、劇的に市内に子育て世帯が増えていく可能性がある。
首都圏ベッドタウン各自治体どこも待機児童問題を抱えている中で、蕨市が待機児童問題をクリアすることができたら、「供給が需要を創造していく」という動きも出てくると思う。
保育サービスへの需要の増減に迅速に対応できる仕組みが必要。
・限りある資源を認可保育園新設に使うのではなく、蕨市独自基準の家庭保育室 （認可保育園よりも質は落ちるものの、必要レベルの品質は蕨市が保証している）の拡充に注力すべき。
・現状で、待機児童が多数いるにもかかわらず、家庭保育室は定員割れしている。つまり、需要と供給がうまくマッチングできていない。
・この原因は、家庭保育室の保育料が高いことと、家庭保育室のイメージが悪いこと（2流で、幼児虐待が心配、狭くて汚いところにつめ込まれているのではないか不安、といったイメージがあるらしい）。
・対策として、次なる認可保育園の整備に使うお金を、家庭保育室の支援に回すといいし、家庭保育室のイメージアップ施策を打つといい（元々、質は市によって保証されている）。
ちょっとまだうまくまとまってないけど、だいたいこんな感じで。
行政サービスの保証品質について
本市の行政サービスの品質レベルは、過剰性能なのではないかという観点から、
26年度新規開発予定の公共スポーツ予約システムにおいて、
- 想定される登録施設数とその内訳は。
- システム上保証される、最大ユニーク登録ユーザ数、最大月間申込み延べ件数、最大同時接続ビジター数、アクセス集中時の申込みフローにおける最大待ち時間、登録可能な施設上限数、月間累計ダウンタイムは。
- 現行の窓口カウンターでの公共スポーツ予約における、月間ユニーク利用者数、月間申込み延べ件数、窓口カウンターへの最大同時訪問者数、窓口カウンター混雑時の利用者の最大待ち時間は。
臨時福祉給付金給付事業において、
- 想定される詳しい作業手順は。
- 想定される工数合計は。
- 給付対象者一人当たりの工数、人件費・オフィス家賃を含む全ての費用とその内訳は。
- 過去の同種の給付金支給事業における、給付対象者一人当たりの工数、人件費・オフィス家賃を含む全ての費用とその内訳は。
必要最低にして十分な行政サービスの品質レベルをサービスレベルステートメントとして定め、行政サービスの提供内容が過剰性能になることを排除し、余った資源を必要にして不足している他の行政サービスに回すべきではないか。
行政の各サービス（事業とも呼ぶ）は、なんか運営費が高いなー、高コストだなーと思っていた。
必要以上に、手間、ヒマ（時間）、お金をかけ過ぎていると思う。
他方で、必要なのに手が付けられていない、不足していることも、たくさんあるのに。
根本的な原因は、
・市民は、行政サービスは「完璧で当たり前」と思い、減点法で評価している。つまり、失敗したら「ふざけるな！市役所は何をやっているんだ！」と口を極めて非難する。
・そうなると、市役所内の人事評価の仕組みは、どうしても減点法になってしまう。
・そうなると、市役所スタッフのメンタリティは、あらかじめ必要以上に多めの予算を確保しておいて、必要以上にハイスペックなサービスを提供して、絶対に漏れやミスがなく、非難されないような内容にしよう！と、必要以上の完璧主義になってしまう。
ということではないかと思う。
この流れを変えるのは難しい。
行政サービスの種類によっては、当然ながら、漏れやミスが絶対にあってはならないものも、多々ある。
つまり、「ベストエフォート型」でやるわけにも行かない。
それでは、どうすればいいか？
ということを考えたのだが、
必要最低にして十分な行政サービスの品質レベルを定めて、サービスレベルステートメントとして対外的、対内的に明示してはどうだろうか。
たとえば、私の業界だと、データセンタを借りるときに、契約書の中に、サービスレベルアグリーメントを盛り込む。
ネットワークや電源のダウンは絶対に起こるものだし、絶対に防ぐことは出来ないという前提で、「サービス停止は、一回当たり○×分まで、月間累計で△★分まで」と、保証する品質を定めるのだ。
同じように、コンタクトセンタを立ち上げるときは、「混雑時に電話をかけてきた人の最大待ち時間は120秒」といったように品質を定める。
もちろん、データセンタにおいて、ネットワーク経路や電源を二重、三重どころではなく、十重にしたり百重にしたりすれば、事故の発生は、確率的に限りなくゼロに近づく。
コンタクトセンタの場合であれば、受話スタッフを千人あるいは一万人用意すれば、待ち時間はゼロになるかもしれない。
しかし、そのためには膨大な費用がかかってしまうわけで、「必要最低にして十分な品質レベル」をあらかじめ決めておこう、というものだ。
上記の例だと、双方向の契約なので「アグリーメント」となるけど、行政の場合は、市民に対して一方的に示すものなので、「ステートメント」となる。
文章として定めておくことで、サービスの品質が必要以上に過剰になることを防げるのではないか。
このサービスレベルステートメント、行政が作る場合は、具体的にどんな内容、文言になるのか？
今、他市に事例がないか調べているところ。
誰か知ってたら教えてください。
スポーツ施設予約システム事業と、臨時福祉給付金給付事業は、26年度予算で初めて乗ってきた新規事業なので、取り上げやすいから例として取り上げただけです。
既存事業であれば、過去の予算書、決算書やら議事録やら掘らないとならないけど、新規事業であれば、遡って調べる必要がないゆえ楽なので。
具体的にどの辺が過剰なのか？
→ちょっと長くなったので、別エントリに分けて書きます。
