こんにちは！プロダクト開発部のせきねこです。ICTコドモンの請求関連機能を開発するチームに所属しています。先日久しぶりに風邪を引いてしまい、処方された点鼻薬が「シュッ！」と鼻に新鮮な感覚を届けてくれるのを面白く感じている今日この頃です🌷
カジュアル面談やインタビュー（面接）でお会いしたエンジニア職の希望者とお話させていただく中で「コドモンではどんな風に仕様を決めて開発しているんですか？」 という質問が何度かあり、今回はその問いにお応えする形で、最近チームで担当した給付費申請画面の刷新プロジェクトから仕様決めの実践例を紹介していきたいと思います！
前提
当プロジェクトでは、ICTコドモンで一部自治体に属する施設向けに提供している「給付費申請用データ作成機能」について、連携先システムの更改に合わせてコドモン側の画面も刷新する開発を行いました。
給付費申請とは
保育施設が毎月の保育内容や利用園児数等を自治体に報告して、運営費の給付を受けるための手続きです。コドモンでは延長保育等の利用実績を集計して、申請用データの一部を生成する機能を提供しています。
仕様確認／開発ストーリー検討にあたり、はじめにプロジェクトメンバーで連携先システムの資料に目を通すことから始めました。
その中で「連携先システムのUIだけでなく、給付費申請の業務フロー自体も新しくなるようだ」ということは何となく理解できたのですが、開発途中と思われる画面のスクリーンショットや申請用データのサンプルだけからは「コドモン側に何をどうする機能があれば良いのか」をほとんどイメージすることが出来ず、出口が見えない状況からスタートしました。
実践したこと
1. 申請業務を行うユーザーへのヒアリング
資料や既存機能とにらめっこしながら「従来の設定を引き継ぐ必要がある項目はどれか」「利用実績はDBのどのデータを使用すべきか」など不明点を洗い出し、その答えを探るべくメンバー同士で会話をしたり、自治体の担当者に問い合わせることで徐々に仕様を固めていきました。
それでも「申請用データの提出はいつ誰が行うのか」「このデータに変更が生じる条件は」といった、給付費申請の業務フローを分かっていないと解消できない疑問が残っていることで、仕様を決めきれない部分があることに気づきました。
そこで、既存の給付費申請用データ作成機能を利用中の施設に相談し、給付費申請等の事務作業を担当している先生にヒアリングの時間をいただくことになりました。ユーザーのペインやこだわり、開発上の制約など多角的に情報収集できるように、プロダクトマネージャーやデザイナー、エンジニアが職能問わず複数名で参加し、ヒアリングを実施しました。
ヒアリングでは、給付費申請にまつわる業務を以下のように時期・頻度別で教えていただきました。
- 毎日行っていること
- 申請締日に行っていること
- 園児や職員の入れ替わりのときに行っていること
このおかげで、給付費申請に関わるデータを施設の先生が参照・更新するタイミングや利用実績にどう影響するかを深く理解することができました！
また、一部の申請項目については対象園児数や請求発生頻度が少なかったり、別の先生が紙ベースで実績を記録していたりと、コドモン上で利用実績を管理していないことも分かりました。この気づきは、後の機能開発の優先度判断において非常に参考になりました。
（「提供機能が利用されていない」ことは一見残念に思えるかもしれませんが、先生方が業務負担を感じる箇所は施設によって異なりますし、コドモン導入前のやり方で困っていない業務を無理やりICT化した結果、かえって業務負担が増えてしまうのは本望ではないと私たちは考えています。）
ヒアリング結果はデザイナーがエクスペリエンスマップにまとめてくれて、ヒアリングに参加できなかったメンバーにもしっかり情報共有することができました✨️
2. UI検討フェーズから開発リスクを考慮した意思決定
UIを検討・設計するタイミングでも、開発リスクを考慮した案出しと意思決定を積極的に行いました。
一例として、施設の事業所番号や保育時間など一度設定したらほぼ変更が生じない項目をどう扱うか？では、こんな議論が生まれました。
- 編集頻度が少ないのに専用の編集画面を作成するのはオーバースペックでは？
- 申請業務上、変更データの履歴管理は必要か？
- 時刻変更のUI、既存実装は使いづらさがある…かといって新規で独自コンポーネントを作る工数は割けない
UIが決まって開発に入ってから気づくと涙目になるトピックばかりですね…😭
想定コストや必要性の認識を合わせ、それぞれ次のような意思決定を行った結果大きな手戻りなく開発を進めることができました。
- 編集操作はダイアログ表示でシンプルに
- 履歴管理は不要だが、申請業務を行う月ごとに設定内容を保持する必要あり
- 時刻変更のコンポーネントにはブラウザ標準のタイムピッカーを活用し開発工数を削減
3. 「やらないこと」も含めた意思決定の記録
設計・実装方針に関する重要な意思決定を行った際は、その内容をドキュメントに記録するようにしました。
以下のような課題感がきっかけで始まった取り組みで、ADRベースのフォーマットを用いて記録していきました。
- 議論の場にいなかったメンバーとの情報共有コストを軽減したい
- 決定事項だけが文字や図で残されていると決定までの経緯を思い返せず、後になって同じような議論を繰り返してしまうのを防ぎたい
この意思決定記録を続けてみて良かったと感じているのが、フォーマットに代替案 (Alternatives Considered)の項目があることで、候補となった各案のメリット・デメリットを洗い出し、相互比較する意識が高まったことです。
例えば「日付データを扱う処理で祝日考慮は必要か？」という議題について、最初は「大多数の保育施設は祝日閉所しているから、考慮しないとどこかしらで不都合が生じそう…これは対応すべきだろう」と漠然と考えていました。
しかし、代替案となる「対応しない」場合のデメリット（ここでは「施設の業務に支障をきたす問題が発生し得るか」に焦点を当てて）検討した結果、現段階では支障をきたす問題は発生し得ず、また今後問題が発生したとしても回避策があることが分かったため、「対応しない」案を採用することになりました！
このように 「やることによる効果」と「やらないことによるリスク」を正しく把握し両者を天秤にかけて意思決定することで、限られた時間の中で本当に必要なものだけを作ることに集中できたと感じています。
さいごに
「コドモンではどんな風に仕様を決めて開発しているんですか？」への回答として、給付費申請用データ作成機能の刷新プロジェクトを通して「正解の仕様が分からない状況」から試行錯誤と取捨選択を繰り返しながら仕様を明らかにしていくプロセスをご紹介しました！
- ユーザーヒアリングを通して業務フローを理解する
- 開発前段階でも開発リスクを考慮して意思決定する
- 意思決定の記録をドキュメントに残す
これらの取り組みは特定の誰か一人が推進したわけではなく「ユーザーにより多くの価値を届けるために出来ることは、自分たちで何でもやる」という熱意を持ったプロジェクトメンバー全員の力を合わせて実現したものです。この記事を通して、仕様決めのプロセスに加えてチーム開発を大切にしているコドモンのカルチャーについても、少しでも伝わっていたら嬉しいです。
そして、文中でも触れましたがコドモンを利用いただいている施設の先生方が本当に協力的だということも、感謝してもしきれません…！
業務ヒアリングの相談も即座に快諾してくださったり、別の利用施設からもリリース後に見つかった不具合の事象を丁寧に報告いただいたおかげで即日修正対応を行うことができたり…。「お客様」というより、子どもの成長を一緒に支える「仲間」のような心強い存在だと感じています🤝
子どもを取り巻く環境で活躍する人々に価値を届ける開発を、これからも続けていきたいと思います！
