kintone 新機能開発チームでエンジニアをしているぶっちーと宇都宮です。
６月の中旬から約３ヶ月間、アプリストアという「kintoneアプリ」を作成するための機能を実現している複数のページのフロントエンド刷新に取り組みました。この取り組みは、以前から kintone 開発チーム全体で取り組んでいるフロントエンド刷新の一環であるため、このプロジェクトの概要について説明されている以下の記事をあわせてご覧ください。
基本的にフロントエンド刷新は開発チームの開発容易性を向上するものであり、新機能開発とは違ってそれ自体が顧客価値を生むものではありません。そのため、出来るだけ迅速に完了し、新機能開発などの顧客価値を提供する活動に繋げていく必要があります。そこで本記事ではフロントエンド刷新をより迅速に完了するために意識した「作るものを減らす」と「開発＋テストの速度を上げる」という２つの軸について紹介します。
作るものを減らす
１つ目の軸は「作るものを減らす」ことです。実装すべき機能群の中でも優先順位の低いものを実装せずにファーストリリースをしたり、機能の完全再現を目指すのではなく、ユーザーストーリーの実現にインパクトが小さいものは簡易実装にとどめたりすることで、全体的に実装量を減らす工夫をしました。
機能に優先順位をつけて実装する
アプリストアは「kintoneアプリ」を作成するための複数の機能で構成されていて、それぞれに独自のユーザーストーリーを持ちます。例えば、ユーザーはサイボウズが提供しているアプリテンプレートの中から目的に沿ったものを検索したり、各テンプレートの詳細を確認したり、テンプレートからアプリを作成したり出来ます。このようにアプリテンプレートに関係するユーザーストーリーはいくつかありますが、その中でも「テンプレートを利用してアプリを作成できること」が最も重要なユーザーストーリーだと判断しました。テンプレートの詳細が確認できなくても、テンプレートの名前から作成できるアプリはある程度推測出来ますし、検索ができなくてもテンプレートのカテゴリーを推測することで目的のテンプレートに辿り着くことが出来ます。しかし、テンプレートからアプリを作成できないとなると、ユーザーは１からアプリの構築をしなければならず、kintone が提供する「素早く・簡単に」という重要なユーザー価値の実現から遠のいてしまいます。
優先順位をつけるプロセスは kintone という製品の理解や顧客理解が深く必要になる部分ということもあり、 kintone 開発チーム横断で行われるミーティングで様々な方からフィードバックをいただいたり、プロダクトマネージャーと話し合いをして柔軟に意思決定をしました。
このように、ユーザーストーリーの重要度を考えることで、各機能には実装の優先順位をつけることが出来ます。優先順位の高いものから順番に実装し、極力無駄なものは作らないことを意識することで必要最低限の実装量でリリースが出来ました。
機能を必要以上に作り込まない
「作り込まない」とは、ユーザーストーリーにインパクトが小さい部分は簡易実装にとどめることを指します。
例えば、今回刷新する機能としてアプリテンプレートの詳細を確認する機能がありました。テンプレートごとに詳細な内容が説明されるページがあり、そのテンプレートの名前、説明、イメージ画像などが表示されています。刷新前のページでは、この画像のプレビュー表示がリッチに実装されていました。この仕様を完全再現するのはかなり工数がかかることが見積もり時点でわかっていたため、ファーストリリースでは仕様を変更しようと考えていました。しかし問題は、仕様をどのように変更したらユーザーストーリーを満たしたまま実装量を削減できるかということでした。私たちは画像プレビュー機能のメインのユーザーストーリーは、「ユーザーがテンプレートから作成できるアプリがどのようなことができるアプリかを視覚的にイメージ出来る」だと考え、それを満たすためには画像の内容が確認できる実装であれば良いと判断しました。最終的に、既存の実装より画像サイズを拡大し配置するだけの、非常に簡素な実装をしてリリースしました。
上記で紹介した２つの方法に共通することは、開発をする上でユーザーストーリーへの深い理解が必要だということです。ユーザーストーリーをしっかり理解できていないと、機能の優先順位をつけ間違ったり、機能を作り込みすぎるもしくは作り込みが足りない、といったことが起き得ます。ユーザーストーリーへの理解はまだまだ深める余地はありますが、今回は作るものを減らすための良い意思決定ができたと感じています。
開発＋テストの速度を上げる
２つ目の軸は「開発＋テストの速度を上げる」ことです。これは刷新に限らず全ての開発業務に共通することだと思いますが、今回の技術刷新において大きな効果があった３つのアプローチを紹介します。
Design System をフル利用する
１つ目のアプローチは、kintone Design System（kDS）をフル活用したことです。kDSとは社内で開発をしている kintone のためのデザインシステムです。詳しくは下記のブログをご参照ください。
今回の刷新では、アプリテンプレートの一覧を表示するテーブルや、アプリ作成時の確認ダイアログなどに kDS のコンポーネントを使用しました。今回 kDS を利用することの最大のメリットは、エンジニア側でコンポーネントの実装とテストをする必要がなくなり、一定のクオリティを担保しつつも開発を大幅にスピードアップできる点にありました。実際にコンポーネント単位でのテストをエンジニアがほとんど書く必要がないままリリースをすることができました。それに加え、kDS はガイドラインやカラーテーマなども提供しており、デザイン調整に取り組む際に発生するエンジニアとデザイナー間のコミュニケーションコストを最小化してくれました。
また、デザインシステム側でアクセシビリティの品質を担保してくれているのも大きなメリットです。提供されているコンポーネントを使用することで Web ブラウザのアップデートの早い CSS やアクセシビリティの知識の獲得に時間をかける必要がなくなります。このおかげでアクセシビリティの向上にかけるコストを削減しつつも一定以上の品質を保つことができました。
実装の前に試験設計をする
２つ目のアプローチは、実装に取り掛かる前もしくは取り掛かると同時にQAエンジニアに試験設計をしてもらい、そのテスト設計の項目を満たすように実装を進めたことです。
kintone の新機能開発では通常、機能を実装したあとに試験設計をしてもらい、それをエンジニアがレビューしたのちに試験を実施するというプロセスを取ります。しかし新機能開発とは違い、フロントエンド刷新では基本的に既存の仕様を参考に試験設計ができるため、機能の実装を待たなくても良い状況にありました。既存の仕様から大きく変える機能はほとんどなかったため、実装に先んじて試験設計とレビューを行いました。試験設計において、特定のユーザーアクションに対する挙動や期待結果、想定されるエラーケースなどが網羅されていて、一つ一つの項目を満たすように実装すれば期待した機能が出来上がります。
前述した通り、いくつかの機能は簡略化したり、ファーストリリースでは実装しないといった差分は存在したので、その都度QAエンジニアとコミュニケーションをとりながら差分を埋めていきました。満たすべき仕様が予め頭にある中での実装は非常にスムーズで、仕様に関して悩むことがなく開発を進められました。
実装と試験のサイクルを小さく速く回す
３つ目のアプローチは、刷新の単位を小さく分割することです。これまでの私たちのチームでの刷新活動では、先に刷新対象の画面の実装を終えてその後にテストをするプロセスで進めていました。しかしこのプロセスでは、実装した機能に不具合等があった場合の修正コストが高くなってしまう可能性がありました。
そこで、今回のアプリストアの刷新では、刷新の単位を画面や機能単位で分割し、その都度テストを行う方針で進めました。このように進めることで、影響範囲が小さいうちに、低い修正コストで不具合を修正することができ、大きなコストをかける必要がある修正を発生させずに済みました。
最後に
アプリストアという機能は「アプリを作成する」という明確な役割があり、機能自体も非常に複雑なものというわけでもなかったため上記のようなアプローチでスムーズに刷新することが出来ました。より複雑な機能や画面の刷新では、必ずしも上記のアプローチや考え方が適用できる訳ではないと思いますが、参考にできるものがあれば嬉しいです！
