kintoneにこそ、アジャイルを。
プロ雑用です。
今日は、以前から考えていたことを軽くまとめてみたいと思います。
一つの考えの方向性として捉えてもらえれば嬉しいです。
kintoneって、カンタンで、ムズかしい。
「たしかにkintoneは1つのアプリを作るのは簡単だが、複数のアプリも含めたシスステマチックなものを作ろうとすると、とたんに難しくなるぞ…？」
「kintoneでアプリを簡単に作れるのはわかったけど、で、実際に自分たちの業務に活かすには、具体的にどうすればいいのだろうか…？」
このような声は、kintoneのコミュニティ内でも、時折聞きます。
これが原因で、残念ながらkintoneから離れてしまった方も居るでしょう。
結局、kintoneは簡単なんでしょうか？
私自身の考えを先に述べておくと、
kintoneは人によって難易度の振れ幅が非常に大きいツール
だと感じています。
その原因は「ハードルの低さ」と「自由度の高さ」。
よく比較対象とされる某青い雲などは、自由度の高さでも対極にあります。
ユーザーは彼らのメソッドに徹底的に従ったほうが習得が早く、SFA特化型ということもあり、SFAを必要としているものこそが導入すべき、というツールです。また、習得にも時間がかかります。徹底的にツールを熟知し使いこなさないといけません。全体的に使いこなすまでに時間がかかります。
一方でkintoneは、導入のハードルが低いのですが、その方法論に確固たるものがありません。使い方は完全にユーザー側に依存しています。提供する側も「機能の説明」はできますが「方法論の解説や推薦」は出来ません。よって機能技術の習得に関してもユーザー側に依存しています。
単にビジネスモデルの違いですので、どちらが良いとか悪いとかではありませんが、ことkintoneにおいては、初期離脱が高い理由でもあります。
要するに「入るのが簡単で、出ていくことも簡単」ということです。
kintoneは、ユーザー側が「機能をよく理解」した上で、「このように使いたい」というイメージの2つが揃っていないと、使いこなすが難しいのです。
アジャイルが重視する価値、大切にしていること。
さて、kintoneの話はちょっと横においておいて、アジャイルについて。
アジャイルという言葉は、どこかで耳にしたことがるかもしれません。
あるいは、スクラムやリーン、Crystalなど。
とくに”アジャイル”と”スクラム”は混同されがちですが、アジャイルは、スクラムなどの開発手法の共通性をしめした言葉で、ソフトウェア開発のワークフレームがあるわけではありません。
日本の場合、一般的にアジャイルとしてスクラムが選択されているので、両者は似た文脈で語られている場合が多い、ということです。
アジャイルは、スクラムなど、さまざまな開発手法の発案者が集まり、共通性・共通認識を言語化したものです。
その共通性を言語化したが「アジャイルマニュフェスト」です。
そこにはアジャイルとして4つの”価値”を定めています。
プロセスやツールよりも、個人との対話を
包括的ドキュメントよりも、動くソフトウェアを
契約交渉よりも、顧客との協調を
計画に従うことよりも、変化への対応を
いずれも左側の、プロセス・ツール、ドキュメント、契約、計画が不要、という意味ではありません。それらの有用性は認めつつ、その先にある「対話」「実際に動作するソフト」「協調」「変化への対応」に価値を置いています。
左側のことは、ウォーターフォール開発で重要視されることもあり、しばしばウォーターフォールの対極として、アジャイルが出る場面がありますね。
で、これがkintoneとどう関係があるのか、ということです。
kintoneは、アジャイル向きのツール、
いや、kintoneそのものがアジャイルだよね。
結論はこの見出しの通りです。
どうしてそう思うのか？
kintoneを使いこなす皆さんだったら、すでにおわかりではないでしょうか。
そう、上に記した”アジャイルの4つの価値”は、そのままkintoneの開発に生かされるのです。というか、逆にいうと、このアジャイルの価値こそが、そのままkintoneを表しているといっても過言ではないのです。
”プロセスやツールよりも、個人との対話を”
私は、kintoneのアプリは現場に寄り添う、現場が使いやすい設計にすべし、とお伝えすることがありますが、これはまさしく「対話」です。従来の開発のように「システムを作っておしまい」で、「現場が使ってくれない」と嘆くことより、なんのためにそのアプリがあるのか、kintoneを使うのか。
このコミュニケーションこそが「対話」であり、kintoneで使われるアプリを作るのに必須の条件です。
”包括的ドキュメントよりも、動くソフトウェアを”
アプリ開発に関して、完成度を高めるより早く作って現場に使ってもらうことを重視しています。完成度は高くなくて良い。使っていく内に高める、あるいは変化する余白を残しておくのが、上手なアプリの作り方だと思っています。このとき、kintoneがノーコードで簡単に作れるという「kintoneは簡単」が、とても生きてくるのです。
”契約交渉よりも、顧客との協調を”
システム開発で往々にしてあるのは、開発者と顧客の対立。開発者は「こうあるべきだ」、顧客は「こうしてほしい」が対立する図は、多くの人が体験してきたことではないでしょうか。ですが、本来システムは誰のものか？それはやはり顧客のものです。それは使う現場もそうですし、レコードのデータを活用する人かもしれませんが、とにかく開発者ではなく顧客です。
一方で、開発者にも譲れない部分、顧客が未だ見えていない課題がすでに見えている場合もあります。おのおのがProfessionalなのですから、本来は対立ではなく協調すべきこと。
kintoneはすぐに作れて、なおかつ簡単に変えられますから、いわゆる対面開発はお手の物なわけです。他のシステム開発より、ずっと顧客と協調関係を結びやすいし、そうしていくことでよりより開発がkintoneでは可能になるのです。
”計画に従うことよりも、変化への対応を”
kintoneのアプリは簡単に直せます。が、最初の計画や設計で、ガチガチに詳細な仕様を決めてしまうと、いかにkintoneといえども修正は容易ではありません。kintoneの「簡単に作れる」特徴を活かすためには、計画や設計を細かく決めずに作ってリリースすることが重要です。
完成度が低い状態で出されたアプリは、その完成度の低さが、余白になります。これが急な変化や変更に対応できる素地になるのですね。
「アプリを作ってみてわかること」「現場が使ってみてわかること」「長い間使ってみてわかること」など、設計計画では見えなかったことがわかってくるのがシステムというものです。ですからそういったものを活かしていくためには、やはり余白が必要で、kintoneはその余白を生み出しやすいということでもあります。
以上のように、kintoneで何か作るときには、アジャイルの考えを取り入れるととてもうまく生きやすいと思うのです。
うまく使えば最強、それがkintone
今年もkintone hiveが始まっています。
先日も、名古屋で行われ、また仙台、福岡と続きます。
名古屋で中部地区代表として選ばれたアミックスコム・安藤さんの事例は、まさにこの4つの価値に基づいています。
参考になるポイントが多数ありますので、ぜひ見てください。
kintoneは導入ハードルが低く、簡単という言葉に惑わされがちですが、アジャイルの考えを取り込むことで、誰しもがうまく使いこなせるようになると思います。
kintoneを使う人はアプリが欲しいわけではない、その先にある未来を見据える必要がある。このことは、下のアジャイル開発の説明で一番有名な図式にも同じことが示されています。
スモールスタートではじめ、修正は素早く！
違ってたら別のアプリつくっちゃえばいい！
これぞ、kintoneの利点を最大に生かした開発と言えます。
また、kintoneは純粋な機能開発ツールではありません。
その主体は、チームワークです。
レコードごとにコメントをつけられる、スペースを作ったスレッド作れる、メンションでやり取りができる、など基本的なコミュニケーション機能は、単にアプリ開発を主体としているツールでは必要ない機能かもしれません。
kintoneは、まさにCybozuの理念である「チームワークあふれる社会をつくる」ということを体現している機能を備えているが故に、アジャイルの価値である「対話」「実際に動作するソフト」「協調」「変化への対応」との相性が非常に良いのです。
アジャイルで使いこなせばkintoneは最強になります。
さて、長くなりましたが今日はここまで。
お付き合いありがとうございました。
「kintoneにこそ、アジャイルを」
それじゃ、また。
この記事が気に入ったらサポートをしてみませんか？