みんなの投稿

アプリを作るときって、誰でもある程度の完成形や目的はイメージして作ると思うんです。
しかし、そこにたどり着くまでのアプローチやアプリ構成はいろいろあるので、
そこはやりながら調整していくことができるのがkintoneの良いところだと思っています。

最初からAとB、２つのアプリ構成があるときにガチガチにAと確定しなくてもよくて、
「いったんAで始めたけどやってみたらやっぱりBのほうがよさそう」
「実は第三のCというやり方を見つけた」というように軌道修正しやすいのがよいですね。

私の業務は変化が激しく、完成したはずのアプリでも使っているうちに修正が必要となる
ことも多いです。

そもそも「完成」という概念さえ必要ない気がします。

導入したときに、わりとすんなりこの「素早く繰り返す」の考え方が
ユーザーに受け入れられたんですが（良い記憶だけ残ってるだけかもですが）
その要因は、サイボウズの営業サポートさんのおかげだと思ってます。

導入時の最初の説明で、
・100％の完成を目指さない
・トライ＆エラーで柔軟に作っていく
というポイントを教えてもらっていたので、それをそのまま
ユーザーの皆さんに説明していました。

あとは、基幹システムの改修にすごく時間がかかるので、
プレゼン資料で、両者を並べて手順や時間がこんなに違います、
と説明したのが、実感をともなっていて良かったのかも…？

私は、IT畑を歩んできた者ではなく、
現在は、人事総務に関する部署におりますが、
かつては、暫く営業に携わっておりました。

営業のなかでもとりわけ
店舗誘致を行って、店舗を開業させる業務に就いたとき、
「修正力」の必要性を痛感しました。
というのも、相手との交渉の結果、出店がほぼ決まり、
社内意思決定等を始めとした社内調整、契約締結、店舗工事の監理等々を
進めるために工程表を作成する訳ですが、
工程表とおりに進むことはなく、けれど開店日は決まっている、
という状況に身を置いておりました。
そこで、「修正力」の必要性を感じたのです。

SIGNPOSTが謂うところと異なるかもしれませんが、
経験上、体得したと思っています。

あの頃、OODAループという概念・言葉が一般化されておりませんでしたが、
実は、経験していたということと
OODAループは、kintoneによる業務改善にも当てはまるのではと思います。

小生、前職で携帯端末などの開発をやってましたが、その経験から申し上げると、「予想して立てた計画に完璧なものなどあるはずがない！」（＝計画通り行ったら、それは超ラッキー。）と考えています。

計画立案は、
・ゴール（例　アプリの要件、リリース時期など）をスタート時に提示するのは必須。
　※これがないと、メンバーのモチベ維持や仕様変更への柔軟対応ができない。
・マイルストーンやL/Tは、実績の積み上げから一定程度の精度のものを当てはめる。
　※初めての開発で低精度は当たり前。→開発を幾つも回すことで精度を上げるしかない。
と思ってやってましたね。

想定外の手戻りに対しては、「計画がムダになるぅ～どうしてくれるの？」ではなく、「とっとと要件等を見直して、”被害を最小限に抑えるには？”を速攻で考え、手を打つ。」のがリーダーの仕事であり、資質だと考えます。

どちらの場合も、「初動を間違えると、トラブル発生時の遅れが最終的には何倍、何十倍もの遅れに膨れ上がる。」が怖いから完璧に計画したいのでしょうが、予期せぬトラブルはつきものなので、「100%は目指さず。でも慎重にかつリカバリーし易いように計画を立てる。」のが肝要かと。
（完璧を目指すと、それこそ計画立案の遅れが後々とんでもない遅れになっちゃいますね。）

これも経験からですが、リカバリーさえキチンとできれば、後はどうにかなっちゃうものです。
なので、「完璧に計画することを考える」から「想定外トラブルありきで、トラブル耐性を上げることを考える」方へのマインドチェンジが必要かと思います。

どうしても大きなプロジェクトだと関わる人数も増えるので、最初は「完璧な計画」を求められるんですよね。

とはいえ、開発側からすると欲しいのは「プロセス」ではなく「ゴールの指標」なのと、外野（使う側）からすると詳しく計画を話されても専門的なことはよく分からない、というのは割とあるあるなんですよね。

なので、最初はポイントポイントでの「ゴール」とそこに行くまでにかかる工数だけを大枠の報告として挙げて、問題があれば都度報告する、順調に進んでいれば「どこまで終わった」と報告するというスタンスを取っています。

複数の人と開発を進める場合、「プロセス」を縛ると思考が固まって（そういう進め方じゃないとダメだと言われてしまうかもしれない、と思ってしまう。）ちょっと躓いただけで止まってしまう。
初めの頃よくそうやって躓いていたので、プロセスの良し悪しは進めていく過程で決めていく形にしていますね。

kinotne導入決定後の最初の9ヶ月間はkintoneを触る事すら許されず、作りたくなかったパワポでの要望書を持っていっては「そうじゃない」と突き返されて全く計画が進まなかった思い出…。そもそも計画を立てる事すらできていなかったわけで…。
結局このままではまずいと思って自ら引き上げて残りの3ヶ月で異常に素早くアプリを作ったわけですが、この時はkintone Café大阪でのアドバイスもあり60点で稼働しました。その後運用に乗ってからは素早く繰り返しながら改善を進めています。