７月９日　kintone hive で学んでほしいこと。

７月９日ですね。

今日はkintone hive Tokyoです。
弊社の皆さんにも来てもらいます。

その狙いは、ここで何度も書いている通り、今のkintoneをはじめとしたノーコード開発や、ひいてはシステム構築のあり方が変わっていることを知ってもらうことです。

そして、そもそもなぜ世の中の会社はシステムを入れようとしているのか、kintoneを選んだのかを理解してもらうためです。

これも何度も書いていますが、従来のシステム開発者は考え方を変える必要があります。頭で理解するのではなく、実感として。

ユーザーの顔を知らないまま、システムが作れる時代は終わりつつあります。

よく顔も知らないユーザーが使うためのシステムを、ただ生活の糧を得るためにシステムを作るといった考えでは、技術者のキャリアプランとしては通用しなくなって来ます。

今までは、営業がシステム構築の仕事を受注し、それを裏方の技術者が構築すれば回っていました。

ところが、裏方に回って設計やコーディングだけをしていられる技術者は、一部の飛び抜けた技術力をもつ方にのみ許される特権になりつつあります。

私も含めた一般の技術者は、ユーザー側の意図や思いを汲み取り、それを実装するフロントの立場に回らなければなりません。

kintone hiveは、そうしたユーザー側の意見を汲み取る良い機会です。
しかもkintone hiveには大規模ユーザーが登壇する頻度が増えています。

皆さんもご存知の通り、弊社のお客様はどんどん規模が上がっています。
数千人規模のお客様、一部上場の企業様ともお付き合いができています。

つまり、全体最適と部分最適の違いを踏まえ、社風以外にも部署単位での独自の文化に応じたシステム構築が必要になってきています。

今ではお客様のご担当者と話していれば、仕様が確定できていました。
が、規模が増えるにつれ、お客様のご担当者様自身も他の部署からの連携や状況の変化に応じ、システム変更を余儀なくされます。

そしてその際、権限やフローなどもより精緻に設計しなければ、運用の時点で破綻するリスクがあります。それが小規模のお客様と違う、大規模のお客様の難しい点です。

フロントに立って、お客様と折衝する担当がどれだけ要件定義をしようとも、もはやそれだけでは回らなくなってきています。
その際、後ろにこもっているだけの技術者は、次々ともたらされる仕様変更に疲弊してしまいます。

だからこそ、要件定義を固めず、仕様変更のリスクが回避できるノーコード/ローコート開発が求められています。

そうした世の中の動きをぜひ今日のkintone hiveでは知ってほしいと思います。