Confit機能拡張の仕様書作成に関係者全員が参加するメリット

はじめに

みなさま、こんにちはCTO大神です。Confitの開発では機能設計や品質管理などを担当しています。
Confitの機能拡張は、セールス・導入コンサルティング・システム開発のそれぞれの担当者が登録している開発候補リストから、重要で優先度の高いものを選定して開発項目を決めています。

今年は新型コロナウイルス(COVID-19)の影響で、オンライン開催に舵を切られた学会が相当数におよんでいるということもあり、学術大会のオンライン開催で必要な機能は開発候補リストに入るやいなや、すぐに開発に取り組んでいる開発項目もあります。
これらの機能拡張では、セールス・導入コンサルティング担当者が頂いているご要望や、打合せや導入時の新たな気付き、現状の足りない点・課題を深掘りして、機能拡張仕様を作成して開発に着手します。
また、COVID-19の影響でアトラスの働き方もテレワーク主体の働き方になっていることもあり、この開発項目決定から開発内容の詳細を決める会議もオンラインで開催しています。

今回は、機能拡張で企画された拡張項目の機能詳細を決めるオンライン会議の様子と、機能拡張仕様書の作成に関係者全員が参加するメリットを紹介します。

機能拡張で解決する課題を明確化

機能拡張項目を決定

開発候補リストからの選定は、セールス・導入コンサルティング・システム開発の各責任者での定例会議または臨時の会議で決定します。
セールス・導入コンサルティング担当者が頂いているご要望や、打合せや導入時の新たな気付き、現状の足りない点・課題に対して、各担当者の視点から緊急度や重要度を設定して、それらを総合的に優先順位を決め、順位の高いものから解決策を協議して拡張項目の選定と大まかな拡張内容を決定します。
多くの学術大会への適用度、短期的、中長期的な視点から開発候補を決定していますが、オンライン開催で必要となる機能は緊急度を上げて開発に着手します。

機能拡張仕様書の1stバージョン作成

機能拡張ごとにプロジェクトマネージャーを設定して、プロジェクトマネージャーが機能拡張仕様書を作成します。多くのメンバで機能仕様の詳細を検討する際に、この拡張で達成すべきゴールがぶれたり、曖昧になったり、時間がたったら忘れたりするので機能仕様書を必ず作成します。

機能拡張仕様書は仕様検討会議までに作成して、機能仕様を記載できない未確定事項を仕様検討会議で協議します。機能拡張仕様書には、機能仕様だけでなく以下の項目をそれぞれ記載します。

• 現状の問題・課題と解決すべきこと
• 拡張の範囲・対象機能
• 機能実現方式
• 各機能の拡張仕様
• 導入方式設計、運用設計

仕様検討会議で達成すべきゴールと機能仕様を設定

機能仕様の検討は、セールス・導入コンサルティング・システム開発担当の担当者が20人以上が集まり、機能仕様書をベースに機能仕様検討会議をオンラインで開催します。
以前は、顔を合わせた方が議論しやすいと思っていて、仕様検討の会議は必ず出社して社内の会議室に全員集まって議論してましたが、現在はGoogle Meetを使用してオンライン会議で開催してます。オンライン会議も半年以上開催し続けていますが、ツール類が充実している現在では困ったことややりづらいことはなく、今後はオンラインで開催する方針となりそうです。

アトラス内ではZoom、Google Meet、Skype、Slack コールの4種類のオンラインコミュニケーションツールを使用していますが、社内の会議ではGoogle Meetをメインに使用しています。

セールス・導入コンサルティングの各担当者が頂いているご要望や現在の課題などは、この会議で全て共有され、達成すべきゴールとどのような機能で課題を解決するかを設定します。

議論と仕様理解はオンラインのホワイトボード

参加者全員で現状の課題など議論の内容を理解することが重要です。社内の会議室ではホワイトボードに図を書いて説明することはできますが、オンラインでもGoogleのJamboardを使用すると、iPadにタッチペンで手書きで図を書いて会議の参加者と共有できるので、検討すべき事項を理解しやすくなります。仕様書内の図をJamboardにコピーすると、図に書き込みながら問題を解決するための機能仕様を議論できます。
Google G Suiteを利用していればJamboradも利用できるのでお勧めです。

全員での会議終了後に雑談タイム

全員での会議終了後に５分間の雑談タイムで、新たな気づきや質問、余談、他に進めている機能拡張の質問など、なんでも雑談できる時間を設定してあります。リアルな会議であれば会議終了後に雑談できますが、オンラインでは雑談しづらいので雑談タイムで情報交換します。

機能拡張仕様書に決定事項反映と参加者全員で確認

全体での仕様検討会議の終了後に、プロジェクトマネージャーが機能仕様書に反映します。仕様書作成後はSlackで会議参加者に仕様書の確認を依頼して、不明点や修正点はGoogleドキュメントのコメントに記入します。
プロジェクトマネージャーも仕様作成時に不明なことがあれば、コメントで記入しておくと、仕様書を確認する際にコメントで回答をもらえます。

関係者全員で機能拡張仕様書を作成する良い効果

全員で共通認識

この拡張で解決すべきことを関係者全員で共通認識できることが大きなメリットです。顧客から要望いただいたことが仕様に反映されているのか？現状の課題を解決できるか？何のために開発しているのか？最終的にどんな機能が出来上がるのか？
などの企画、仕様検討時点では理解していたことも、開発された機能がリリースされるころには、何の問題を解決しようとしていたのか、忘れることもあります。その時は仕様書を確認すると思い出せます。

コミュニケーション効果

関係者全員が機能仕様書で課題・問題、拡張範囲、出来上がる機能を確認できるので、プロジェクトマネージャーに拡張に関することを質問されることが少なくなります。
開発するための機能仕様や設計ドキュメントも１箇所に記載しているので、設計ドキュメントを探す手間も削減できます。
開発期間中やリリース間近に各担当者に機能仕様を説明する負担が軽減されます。現在はテレワークがメインなので仕様書を中心にコミュニケーションをとることで仕様を理解しやすくなります。

リリース後の導入計画・導入作業の品質向上

リリースされる新機能がどのような機能なのか、仕様検討段階から全員が参加しているのでスムーズに導入作業が進められ、機能拡張による利用期間中の学術大会に影響がないことを確認し、インシデントのない導入計画を立てることができます。

開発期間の削減・工数の削減

サービスに関わる全ての担当者が仕様書を確認するので、機能仕様の漏れ、変更による影響、導入方法の課題、変更点、考慮不足など全ての側面で洗い出しできます。
エンジニアの詳細設計も明確になり作成しやすくなります。
開発終盤に他にも機能の追加が必要であることが明らかになり、追加で機能を開発することになったり、手戻りが発生したりすることを防止できます。
特に中国のODCメンバは、機能仕様の説明後に何度も設計書を確認ながら開発します。さらに設計書を機械翻訳することで理解度が向上するので文書化することには大きなメリットがあります。

さいごに

セールス・導入コンサルティング担当者にご要望を伝えていただいている方々の声は機能拡張の仕様策定時に反映されていますので、どんなことでも遠慮なくご要望を伝えていだだくようにお願いします。