【ローコード開発】kintoneで工数を削減すれば見積もりの難易度が上がる話
みなさん開発規模見積もってますか？
めんどくさいですよね😅
今日は取り扱いにくい話題に踏み込んでみようと思います。
曰く、「kintoneで工数を削減すれば見積の難易度が上がる」という話題です。
ローコード・ノーコードツールとは
僕はふだん、kintoneというツールを利用した、業務システムの開発・提案を仕事にしています。
ローコードツールはGUIによってソフトウエアを構築できる仕組みです。たとえばkintoneでは、ユーザーインタフェースをブロックを組み立てるように作成することができます。
すごいですよね！ 僕はすごいと思います。
これにより、開発工数を抑えて素早くソフトウエアを組み立てることができます。また、設定が少ないので比較的経験が少ない人でも不具合に遭遇しにくく、行き詰りにくい特長があります。
システム開発初学者向けと思われがちですが、実は中級～上級でも知識と特性を生かして勝負できるので、あまり熟練度に左右されないシステム開発ツールだと思います。
システム開発者の使命は、システムを構築することで広く社会に貢献することと、対価をもらってその個人の生活を維持・向上させることです。
みんなに喜んでもらって、お金ももらえるいい仕事！
システムを価格を抑えて開発できるローコードの開発はその使命に合致しているといえますね。
さて、システムの見積とは
ここで言う「見積」はライセンス費用外の役務（開発の行為）自体を指します。kintoneは月額1500円とか、そういう話ではないです。
kintoneを利用してあなたの課題を解決するにはいくらかかります、という見積ですね。
さて。
まず、見積とは何かということなんですが、それは天気予報です。
「統計データに基づいて」、「未来を予測する行為」ですね。
システム開発では、まだできていいないものの完成をお客様と約束します。
コンビニでジュースを買うときには、あなたはジュースの缶を見て触れることができ、何度もそれを買ったことがあるし、中身もいつも同じでしょう。たぶん。
しかし、システム開発では違います。なぜでしょう？
それは、なぜなら、パッケージングされた標準的な方法では対応できない部分を取り扱うためです。
標準の方法の隙間が、対象企業にはあって、それをどう埋めるかを求められるわけです。（パッケージ製品：kintoneでいればテンプレート、で事足りるなら、そもそも開発の見積をする必要はない）
＊ここでは、パッケージライセンスいくら、テンプレート利用料いくら、という話とはまた別の話をしています。
システムの見積手法
さて、システム見積は未来を予測する行為です。
ではどのように実施するかというと、いくつか方法はあります。
下記４つは原始的な方法ですが、わかりやすいので挙げたいと思います。
１つは勘です。要するに、経験値ですね。
１つは投票です。これはデルファイ法とかです。「専門家の意見を聞く」というやつです。
１つは分割積算です。機能ごと（発注書の発行機能とか、棚卸リストの作成機能とか）に分けると、小さくなって見通しがよくなります。ボトムアップ式とか積み上げ式の方法ですね。
１つはデータです。データの構造とフローを追いかけて、いくつがどのくらい変化するか考えます。ファンクションポイント法はこの方法の一つかなと思います。
…
さて、これらはすべて「経験」に裏付けされているのがわかるでしょうか？
勘はいくつか案件をこなさないと身につかないし、機能やデータを作るのにいくら時間がかかるかは、完了済みのプロジェクトを集めて分析しないとわからない。
最初は肌感覚で見積り、だんだん細かくデータに基づくようになる。
これがシステムの見積の世界です。一番難しい業務なんじゃないかな。
ローコードツールを導入するとどうなるか
さて、見積は経験に基づくという話をしました。
またローコードツールはソフトウエア開発の工数を抑えるという話をしました。
ではこの2つが重なるとどうなるのでしょうか？
実際に開発工数を削減してみましょう！
はい。工数を赤ちゃん一人分ローコードツールで削減しました。
図を見てどうですか？
ローコードツールが削減できるのは開発工数のみ
それはソフトウエアの開発ツールであって、企画・設計やテストのツールではありません。要求定義・要件定義や運用テストでは効果を発揮しません。
ローコードツールを扱う人は「要件定義段階でお客様の目の前で開発できる」とか言いますが、別に紙に図でイメージを書いても相手に伝われば一緒です。
イテレーション（開発と運用テストの1組）を繰り返すような開発手法であっても、計画と運用テストには効果を発揮しません。
ローコードツールを使って削減できる工数は、開発フェーズ（詳細設計～単体テスト）の工数のみです。
もちろん逆のことも言えることに注意してください。
ローコードツールは開発工数を削減することができます！
開発工数を削減するとどうなるか
さて、スケジュール図のなかで、開発会社がプロジェクトを主導できる場所を図示したのが下記です。緑色の箇所。
いかがでしょうか？
プロジェクト全体を俯瞰したとき、開発会社が確実に責任を負うことができる箇所が減っていることがわかると思います。そして、相対的に増えているのはお客様の影響が高い箇所であることがわかるでしょうか？
プロジェクト全体の責任を開発会社が負える箇所が減る。
例えば、納期に間に合わない状況で、
開発フェーズが間に合っていない場合は開発会社が単独で人員を投入して開発速度を上げることができます。
要件定義フェーズが間に合ってない場合、お客様と一緒に急がないといけません。
急いでいるのに「お客様の打ち合わせの日程が調整できない」とかは、開発会社はどうしようもないわけです。
そういった時間帯が増えます。
ローコードのプロジェクトの見積
さあ、ローコードの見積の話に戻りましょう。
見積には経験値が必要なので、集めたプロジェクトの概要を確認します。
するとどうでしょうか。同じことを実施しているのに、各社ごとに工数にばらつきが出てきます。また、担当者によってもばらつきが出ます。
お客様の事情や、担当者の傾聴・提案力が成否にかかわってくるわけです。
ローコードのプロジェクトの見積の正確さは、お客様の事情でずれやすい。
またそのずれを修正するための手を（開発会社単独で）打ちにくい。
逆のことも言えます。
ローコードのプロジェクトはお客様が無意識で成否を握っている領域がある。
またそのずれを修正するための手はお客様のほうが多く握っている。
開発担当者にはこれらをコントロールする多大なコミュニケーション能力が求められる。
では開発会社はどうするか
さて、これらは「見積」を実施するから発生します。では見積はなぜ発生するかというと「納品」するからです。つまりまだ見ぬ「システム」なるものを対象にとって、値段をつけるからです。
よく考えたら変な話です。
定額開発とか伴走支援という言葉を耳にしたことはないでしょうか？
定額開発では、「開発行為の品質はばっちり保証しますが、システムの完成はお客様しだいです。できるところまでやります」と言っています。
伴走支援では、「開発行為はお客様がやってください。支援はばっちりいたします」と言っています。
これらは見積を避けている一面がある。しかしながら、お客様にとっても、ほしいのは現実の問題の解決であって、見積書じゃないですよね。といったところで、商材として成立しています。
とはいうものの、予算確保には見積が必要なんですよね。・・・むーん。
本来であれば「見積書を作る」すなわち「要件定義」の対価をいただければよいのですが。
まあ、開発会社は、これからも一緒にがんばりましょう！
では、お客様（発注側）はどうするべきなのか
お客様としてはプロジェクトに参加している部分が広く、ハンドリングが容易であることを表しているので、いいことです！
ただ、成否について思っている以上に責任があるということは言えると思います。
開発会社からのQAを放置したり、ソフトウエアがあがってくるまで業務の整理を待っていたりすると、取り返すのは難しくなるかもしれません。
僕はどうしているか
僕はあんまり定額開発・伴走支援はしません。見積求められます。
ただこれらのメニューはおすすめです。
見積ははっきり言って無駄な時間ですからね。何も作ってないし。
比較的正確な見積書が必要なとき（予算取り段階ではなく、契約の直前）は、交渉の発生頻度を予測に盛り込めるような手順で実施しています。（分割法で作った見積もりを、交渉の頻度予測で評価するような方法でやってます）
みなさんの見積手法をぜひ教えてくださいね。
この記事は以上となります。お読みいただきありがとうございました。