こんにちは！kintone新機能開発チームでWebエンジニアをやっている立山です。 今回は、エンジニアの私がkintoneの新機能を提案し、それを実際にプロダクトに組み込むまでの経験についてお話しします。
この記事を通じて、新しいアイデアを提案し、実現に近づけるためのステップを共有したいと思います。 特に、新しいものを作りたいと考えているエンジニアの方々に向けて、私の経験が役立てば嬉しいです。
新機能提案の経緯
まず、今回提案した「関数」や「フィールドコード」の入力を補助する機能 について簡単に説明したいと思います。 kintoneには、フィールドの値や関数を組み合わせることで別の値を算出することができる、計算式という機能があります。 この計算式によって、勤怠時間の管理や、消費税額の計算などが行えます。
しかし、従来の計算式の設定では、手入力によって、関数名や文法に誤りが生じないように気を付ける必要がありました。 ユーザーによっては複雑な計算式を組む場合もあり、人的ミスが起こりやすい機能の一つでした。
今回提案した「関数」や「フィールドコード」の入力を補助する機能は、入力した文字に応じてフィールドや関数を推測し、補完する機能です。 これによって、kintoneの計算式に慣れていない人でも簡単に計算式を設定することができるようになりました。
リリースまでの全体のスケジュール感は下のような図になります。 期間は結構かかってしまっていますが、隙間時間で行なっていたのが大半で、日常のタスクと並行して進めることができました。 以下ではその詳細を説明します。
きっかけ
この機能を作ろうと思ったきっかけは、ユーザーからのフィードバックを開発チームで共有する会でした。 この時、計算式に関するフィードバック（e.g. 使える関数がわかりづらい、フィールドを参照するための情報を逐一確認する必要があり手間を感じるなど）が多くある印象を受けました。
同時に、エクセルのように関数が補完される機能があればこれらの計算式が難しいという問題は解決するかもしれないと思いました。
プロト実装
割と簡単に作れるんじゃないかと思い、早速プロト作りに着手しました。 この時は「入力中の文字列を含む関数、フィールドを候補表示・補完する機能によって入力が楽になる」というざっくりした仮説で作成し始めました。
ただ、やってみると意外と難しかったです。 そもそもジョインしたばかりなので開発言語に慣れてなかったのはかなり大きなハードルでした。 また、入力中のさまざまな操作（入力、項目の選択、カーソル移動など）をモデル化し、適切に候補表示するための実装は結構複雑になりました。
出来上がったものは、まず、プロダクトマネージャー（PM）に見せました。 実用面でのフィードバックも受けることができ、それを通じて機能の解像度が向上しました。
この段階で、候補の表示だけでなく、入力状況（関数内の引数の位置、使えるフィールドのデータ型など）に応じて候補を絞り込む機能が必要であることに気付くことができました。 しかし、この時点ではその実装案が思いつかなかったため、プロトの作成を一時中断しました。
2ヶ月くらい経って、入力状況に応じて候補を絞り込む実装案が思いつき、開発を再開しました。 すぐにプロトを作り、この時はチームにフランクに共有し、PMに見せる運びとなりました。 再度PMのフィードバックを受け、正式にバックログアイテム（＝開発チームとして取り組む可能性があるタスク）として登録することになりました。
バックログアイテム化
この段階では、機能概要を説明し、タスクの工数を見積もり、チームとして着手するかどうかの判断材料を集めることが目的となります。 しかし、エンジニアがプロト提案をしてバックログアイテム化するという前例の少ないケースだったため、このプロセスは難しかったです。
見積もりの難しさ
プログラムとしてどのような実装が残っているかを自分では把握できていた一方で、この機能がユーザーにどのように利用されるのかや、詳細な仕様の部分がまだ明確に定まっていない状況でした。 そのため、他の開発メンバーにとっては、残り何をやるべきか、工数の予測がしにくくなってしまっていたと思います。 さらに、機能のコードを自分だけが把握していた状況も、予測のしづらさを高めてしまったと思います。
受け入れ条件の定義の難しさ
受け入れ条件とは、バックログアイテムの達成条件とも言い換えられます。 通常受け入れ条件は、「ユーザーの特定の操作に対して期待するシステムの挙動」を示すもので、具体的な操作に関する期待値を明示的に記述します。 簡単な例で言えば、「◯◯ボタンを押したら、××と表示される」といった形式です。
しかし今回の機能のように、様々な操作状況に関連する場合、それらすべてに対する受け入れ条件を簡潔にまとめることは難しいものでした。
最終的には、受け入れ条件という形で進めるのではなく、プロトを触りながら増やしたい機能・減らしたい機能を考えていき、徐々に作り上げていきましょうという進め方になりました。
デザインブラッシュアップ・ユーザーテスト
このプロセスはPM主導で行なっていただきました。 まず、デザインチームと連携し、ユーザーインターフェースの配置や文言のブラッシュアップを行い、見た目や使い勝手を向上させるための改良が行われました。
その後、ブラッシュアップされたデザインを元に、ユーザーテストを実施しました。 このテストでは、実際にカスタマーサポートのチームのメンバーに新機能を試してもらい、現場目線での使い勝手や問題点の把握を行いました。
上記のブラッシュアップを経て、新機能に組み込むべき機能や改良点が確定していきました。 このプロセスがなければ、ユーザーにとって価値のある機能として進化させることはできなかったと思います。
開発チームで着手・リリース
前述のプロセスを経て、ようやく開発チームでの着手となりました。 この段階では、実装の細かい部分を詰めたり、製品コードとしての品質向上が主要な目標でした。
特に時間を費やしたのは、仕様書の作成でした。 各操作に対する期待結果を仕様書に落とし込む作業をチームで行なったことで、この機能の属人化を防ぐことができました。
最終的に、開発チームで完成させ、製品としてリリースすることができました。
プロト開発の魅力
以上が今回の提案の流れでしたが、ここでは、今回新機能を提案できた経験を振り返り、プロト開発の魅力と、その際の注意点について考えたことをお伝えしたいと思います。
好奇心とモチベーション駆動の開発
今回のプロト開発に着手した際、好奇心とモチベーションが私の最大の推進力でした。 思いついたアイデアをもとに「これを作りたい！」という強い意志を持って取り組むことで、開発スピードが向上し、難しい技術的課題に挑戦する意欲も高まりました。 ものづくりが好きな私にとって、プロト開発は新たな刺激となり、日々の業務に活気を与えてくれました。
また、出来上がったものを共有して、ポジティブなフィードバックを受けられると、モチベーションが一層高まりました。 このようなフィードバックループは、アイデアが実用化される過程で不可欠なもので、開発を持続させる重要な要素でした。
実物をもとに検討を進められる
プロトがあると、その実用性や効果を直接感じることができるため、説得力が増すと思います。 また、実際に動くものがあることで、リアルな状況を想定して機能の検討を進めることができます。 その結果、着想時には思いもよらなかった良いものが生まれる可能性もあります。
特に今回の提案では、バックログアイテム化された時点で多くの不明瞭なポイントが存在しましたが、プロトがあったおかげで、機能が「なんとなく良さそう」と感じ取ってもらうことができました。 その直感が強かったからこそ、デザインブラッシュアップやユーザーテストを経ることで製品の目指す姿を定義するというプロセスで進められたのだと思います。
プロト開発時の注意点
エンジニアとして、ものづくりは楽しいですが、注意すべき点もあります。 それは、時間をかけず、過度に作り込まないことです。 これによって、アイデアを高める作業をより効率的に行えます。 また、仮にアイデアがイイ線行っていないとわかったとしても撤退時の時間的・精神的なダメージを小さく抑えられます。
そのためには、検証すべき仮説を持つことが不可欠です。 例えば今回のプロジェクトでは以下のような基本的な仮説を立てました。
コンボボックスを実現すれば計算式入力が楽になる
入力位置に基づくフィールド・関数の絞り込みが行えると計算式入力がもっと楽になる
これらの仮説はとてもざっくりしたものですが、達成すべきことを意識するのに重要なものでした。 これを意識するのを忘れるとすぐに作り込みに走ってしまうので注意が必要です。
そして、ある程度できた時点でフィードバックをもらうのも重要です。 仮説検証ができるだけでなく、作っているものの方向性を早期に修正できるからです。 一人で考えているだけでは、アイデアが限定的になりがちで、自分でも気づかぬうちに作り込みの方に進んでいる可能性があります。 人に話すことによって思わぬアイデアが生まれ、不要な作り込みに時間をかけることを避けられます。
活動を行えた背景
今回のような活動ができたのには外部的な要因もいくつかあります。
まず、kintone開発チームには、日常のタスクの時間以外に、個々で勉強会をしたり、コードの改善活動などに自由に使える探求時間があることです。 このような時間があることで、新しいアイデアやプロジェクトに集中できる環境が整っていました。
また、今回提案した機能がフロントエンドに閉じていたこともうまくいった要因だと思います。 万が一不具合が起きたとしても影響が小さく抑えられることがわかっていたため、PM的にもGoを出しやすい機能だったのだと思います。
まとめ
今回、エンジニアからの新機能の提案という通常の開発プロセスとは異なる進め方をしたことはとても良い経験となりました。 この経験を通して、改めてサイボウズがさまざまな技術的な挑戦をしやすい環境であることを実感しました。 今回の私の経験がアイデアの実現に向けて、少しでも役立つことを願っています。
