はじめに
セールスプラットフォーム本部の開発チームで、ダッシュボードの改善を行なっている牛丸です。
この記事では、先日行った項目数無限対応の中で、今後の開発で意識したいと感じた視点・考え方を紹介します。
項目数無限対応とは
私が開発を行っているサービスの中に、以下の画像のようなグラフ作成用データを選択する画面があります。
画像を見ながらイメージしていただけると分かりやすいかと思いますが、列や行グループに設定することが出来る項目(画像のリードソースや部署など)があります。
この項目は常に同じものではなく、別画面から追加する事ができます。
今回の件では、追加された項目数が多かったことで、API Gatewayの6MB制限によってエラーになり、対応を行う必要がありました。
この対応で得た3つの学びを紹介します。
学び1 ビジネス価値を意識する
今回の件を把握し開発チーム内で少し共有を行った時点で考えていた目標と方針は以下のようなものでした。
- 目標: エラーが出ないようにし、設定を正常に行えるようにする
- 方針: 項目数上限を設定しエラーを回避する or スキーマを修正する事でデータ量を減らしエラーを回避する
しかし、「他社が設けている項目数への制限がネガティブになっており、制限が無い事がGENIEEの優位性となっている」という情報が事業部長から齎された事で目標と方針が変化しました。
- 目標: 項目数無限に対応出来るようにする
- 方針: 項目を取得するAPIを作成し、Offset Paginationの形で取得出来るようにする
今回の件で、ビジネス価値によって目標と方針が変化する経験をしました。
エラー対応の時には、原因は？どうすれば素早く直せる？どう進める？という内容の思考になっている事が多いですが、エラー対応でもどのような価値がある機能なのかを意識する必要があると学びました。
学び2 印象を大切にする
対応の中で上長が大切にしていたポイントが、無限という事でした。
最初聞いた時には、無限に対応出来る筈がないのに何故こだわるんだろう？実装するエンジニア的には確実にテストして保証出来る制限を設けて欲しいなと思っていました。
思いながらも無限対応というのを意識して対応した結果、開発者、社内、ユーザーそれぞれに効果があると感じました。
開発者
無限を意識する事でそこに近づける為のアイディアが出てきていました。
今回の対応に限れば方針は変わらなかったかも知れませんが、今回の対応でも足りない項目数になった場合はどうするかというアイディアや話し合いは無限を意識した事によるものでした。
社内
凄いことを行ったんだという印象に繋がったと思います。
この記事を会社のブログとして出す影響が出た理由の一部は無限対応にあると思います。
ユーザー
制限がかけられていないというのは、使いやすさに繋がります。
食べ飲み放題を元が取れなくとも使う人がいるのと同様に、制限を意識せず使えるというのは使いやすさに繋がるものだと思います。
数値化出来ず、曖昧な表現が多くなりましたが、無限に拘ったことで、印象を大切にすることを学びました。
学び3 明確な目標設定を行う
エラー対応という事で、出来るだけ早い対応が求められていました。
そこで、チーム内で「1週間で対応する」という目標を立てて動き、結果目標通り1週間でリリースまで行う事ができました。
ポイントは1週間と明確であった事と、チーム全員の合意を得ていた事でした。
それによって、全員で通話を繋いだ状態でスキーマ決めしたり、得意部分をそれぞれが担当するように分担したり、レビューも含めて他のタスクより優先して動いたりと、ほぼロス無くリリースまで行えました。
全員で合意を取り、一つの目標に向かって動く事で、スムーズに進む事を経験しました。その為に明確な目標設定が必要だと学びました。
Discussion