アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ！
本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。
STEP.2 2-20「小さなリリース単位」
0-02 素早く繰り返すと似てるのですが、状況が許すのであれば価値を提供できる最小の単位でリリースするのがオススメです。
計画上の都合や外注する場合は発注単位の都合などで必ずしも価値を提供できる最小の単位でリリースすることはできないケースもあるのですが、それでもできるだけ小さくリリースすることには意味があります。
従来のシステム開発に慣れている方だと「そんな中途半端なもの入れても意味がない」など言われるかもしれませんが、逆に「大きな単位で作って入れて、まったく不満も問題なく入ったことありますか？」と問うてみてください。「あった」と言われるかもしれませんが、多くの場合、不満が認識されていないかもみ消されていると思います。
完成したシステムがどのようなものになるか、どのような使い勝手になるかを動くものを見る前に予測しきることは非常に困難です。アールスリーは長くシステム開発をやっているのでかなり見通して考えていますが、それでも現場で使われる方のITリテラシーや業務の複雑さなどによってブレがあるため、どうしても動くものをみてからこうしたいというのがでてきます。
「修正はあるものである」ということを前提に計画をたて、できるだけ小さい単位でリリースして現場で使ってみてもらいフィードバックしてもらう。
フィードバックされた内容を0-02 素早く繰り返すにしたがって次にサイクルで修正することが大切です。
とはいえ、どういう単位で考えればいいんだ？？？と思われる方もいらっしゃると思います。
簡単でオススメの方法は、基本機能でできることだけをやってリリースしてみるというやり方です。
プラグインやカスタマイズを入れる前に、基本機能でできる範囲で作って実際に使ってみる。当然、ここが使いにくいとか、ここは手間が多いなどがでてくるので、それをプラグインやカスタマイズで解消していく。
このやり方がいいのは、小さくリリースできるということと、基本機能だけなので修正しやすいという点です。
さらに、その後プラグインやカスタマイズで手間を省いていくと、前より便利になっていく様を現場にみてもらえるので「意見すれば改善されていく」ことが理解され導入をスムーズに進めることができます。
kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。
