公開日：
こんにちは！アールスリー小山です。
地域の小学生サッカーチームを題材に、kintoneとカスタマインを使って“ゼロからシステムを作ってみる”連載、第2回をお届けします。
前回は、「kintoneやカスタマインを日々触っているけれど、一から設計して作る機会が少ない」という気づきから、「だったら身近なテーマで練習してみよう！」と始めたきっかけをご紹介しました。
さて今回は、いよいよ本格的に“作る前の準備”に入ります。
でもいきなりアプリを作り始めるのではなく、「どんな業務があるのか」「どんな課題を解決したいのか」をきちんと整理するところから始めました。
そこでせっかくなので、kintone SIGNPOST（サインポスト）をもとに進めていくこととしました。
kintone SIGNPOSTとは？
kintone SIGNPOSTは、Cybozuが公開している「kintone導入・改善の道しるべ」です。
ゼロからシステムを作るときに、何をどんな順番で考えていけばよいかが整理されています。
単なるフレームワークというより、「迷ったらここを見ればいい」という地図のような存在です。
SIGNPOSTは全部で7つのステップ（STEP0〜STEP6）で構成されていて、それぞれの中に具体的な観点が詰まっています。
今回はその中でも特に、
- STEP0「kintone概念理解」
- STEP1「目的設定」
- STEP2「プロジェクト企画」
をベースに、自分の頭の中を整理していきました。
STEP0：そもそもkintoneって何がいいの？
kkintoneの良さって、機能というより考え方にあると思っています。
- 現場主導で改善できる
- 失敗してもすぐ作り直せる
- 情報がオープンに見える化できる
これは、チーム運営のような“日々ちょっとずつ変わっていく業務”にはとても相性がいいです。
「まずはやってみて、あとから直す」スタイルが許されるのも、kintoneの魅力です。
また、プラグインや外部連携ツールを柔軟に追加できる“エコシステム”の存在も見逃せません。 kintoneは単体で完結するのではなく、カスタマインのような連携サービスと組み合わせることで、ノーコードでも高度な処理を実現できる点が特長です。
STEP1：業務と課題を見える化する
次にやったのが、チーム運営に関わる業務の洗い出しです。
なかでも水色に塗りつぶしているところが曲者で、１試合ごとにこんなフローになってます。
ハイシーズンでは毎週末、1日に2試合、なんてことも多く、いつも情報は錯綜していて、学年代表は本当に大変です…
コーチと学年代表のグループLINE、学年全体（コーチなし）のグループLINE、等、グループもちょこちょこと分かれていて、情報共有が出来ているようで、力業になっています。
また、出欠回答する側のメンバーとしては、ジャンジャンアンケートが流れて来るので、どれがアンケートに回答済みなのか、未回答なのか、1つ1つのアンケートを開いてみなければ分かりません。
このような現状を踏まえると、単純にアプリを作るだけではなく、「どの業務に対してどの情報が必要か」「誰が何を見るのか」という観点から整理しておく必要があると感じました。
STEP2：何から始めるかを決める
全部いっぺんにやろうとすると、設計も構築もゴチャゴチャになります。
なので今回は、下記の方針に進めることにしました。
出欠確認と名簿は連携させやすいし、 「未提出者にリマインドする」「学年ごとに出欠一覧を出す」など、 kintoneとカスタマインの両方の機能を使って実現できそうなユースケースが多く含まれています。
さらに、kintone SIGNPOSTが提唱する「小さく始める（2-20 小さなリリース単位）」という考え方にも合っています。
完璧を目指さず、まずは出欠確認だけを最小構成で作ってみて、運用しながら少しずつ機能追加していく予定です。
体験申込から入会手続きに関しては、gusuku Everysite（グスク エブリサイト）を使って作っていけたら面白いかも！と思っています。
また、試合当日の写真や動画の共有は、かなりの量になることから、現在使っているアプリのままが良さそう、と判断しました。
なんでもかんでも一つのツールにまとめるのが正義ではないですね！
次回はSTEP3「設計と構築」へ！
次回はいよいよ、どんなアプリをどう作るかを考えるフェーズです。
- 出欠はイベント（試合・練習）毎に
- 名簿はマスタデータ
といった「情報の構造」も意識しつつ、親子アプリや通知機能、アクセス権設定なども含めて設計していきたいと思っています。
SIGNPOSTで言うと、
- 3-24 ストック情報中心設計
- 3-27 親子アプリ
- 3-28 最軽量のアクセス権設定
あたりを使っていくことになりそうです。
実際の設計図（図に描く）も試してみる予定です！
設計段階でしっかりと全体像を可視化しておくことで、後の構築や運用での「迷い」や「手戻り」を減らせるはずです。特に、複数のメンバーが関わる運営体制では、「誰が・何を・どこまで」扱うのかが明確になることで、チーム全体の動きもスムーズになります。
次回はそのあたりの“設計の考え方”にも触れながら、実際に使えるアプリの形を見つけていく予定です。どうぞお楽しみに！
投稿者プロフィール
- カスタマーリレーションチームにおります
