kintoneエンジニアの2タイプと成功への条件~現場ユーザータイプと情シスタイプ、いいとこ取りできなきゃ失敗する~

公開日:

システム開発グループの井上(たーぼー)です。

kintone開発に携わってきて痛感することがあります。
エンジニアには大きく2つのタイプがいて、どちらかに偏るとプロジェクトはうまくいかないということです。

1つは「現場ユーザータイプ」。
もう1つは「情シスタイプ」。

どちらも強みがあるのに、弱点をそのままにして突っ走ると必ず破綻します。
今回はその実態をあえて強めに言葉にしてみます。


1. 現場ユーザータイプ:スピードはあるが甘い

現場ユーザータイプは、元々エンジニアではなく現場業務の人からkintoneに入ったケースに多い。
「自分で業務を楽にしたい!」という動機から始めているので、現場の痛みを誰よりも理解しています。

強み

  • スピード感:欲しいと思ったらすぐアプリ化できる
  • 共感力:利用者と同じ言葉で会話できる
  • 改善意欲:業務改善の視点を常に持っている

弱み

  • データ設計を軽視しがち(Excelの延長でフィールドを作ってしまう)
  • アクセス権限やガバナンスを考えない
  • 「動けばOK」でリリースしてしまう

結果どうなるか。
最初は現場にウケるけど、数か月後には「修正ができない」「他部署に展開できない」と壁にぶつかる。
短距離走は速いけど、マラソンに耐えられないタイプです。


2. 情シスタイプ:安心感はあるが重すぎる

一方の情シスタイプは、情報システム部門やSIer出身のエンジニアに多い。
設計や運用の基礎を叩き込まれているので、技術的には信頼できます。

強み

  • データベース設計やセキュリティに強い
  • 長期運用を見越した設計ができる
  • システム全体の整合性を気にかけられる

弱み

  • 仕様書を作らないと進められない
  • 小さな改善にも稟議や承認を求めてしまう
  • 「kintoneの柔軟さ」を殺してしまう

結果どうなるか。
立派な設計書と強固なルールはできるけど、肝心の現場は「これじゃ動けない」と距離を置く。
フル装備で甲冑を着たまま短距離走に挑むタイプです。


3. いいとこ取りをしなければ失敗する

ここまで読んで分かる通り、どちらのタイプも“片翼飛行”です。
現場ユーザータイプだけだと拡張できずに息切れする。
情シスタイプだけだと柔軟性を失って現場に拒否される。

どちらか一方だけでは、kintone開発は必ず行き詰まる。

求められるのは両方のいいとこ取りです。

  • 現場ユーザータイプの「スピード感」「寄り添い」
  • 情シスタイプの「設計力」「安心感」

この両方を持ち合わせたとき、kintoneは「現場に刺さるスピード」と「組織で安心して使える土台」を両立できるのです。


4. 実践のポイント

では実際にどうやって“いいとこ取り”をするのか?
私が現場で意識しているのは次の4点です。

  1. 70点でまず出す(現場ユーザー的)
    完璧を目指す前に触れるものを出し、現場の声を早く拾う。
  2. 最低限の設計ルールは守る(情シス的)
    アクセス権限、命名規則、データ正規化は最初に仕込む。
  3. 雑談から課題を拾う(現場ユーザー的)
    ヒアリングではなく、日常会話で本音を探る。
  4. 改善サイクルを仕組みにする(情シス的)
    場当たり的な修正ではなく、定期的に改善を回すルールを作る。

まとめ

どっちかに甘えるな、両方やれ。

kintoneエンジニアにとって一番ラクなのは、自分の得意な側に寄ることです。
現場ユーザータイプなら「動けばいいでしょ」。
情シスタイプなら「設計ちゃんとしないとダメだ」。

でも、それではプロジェクトは半分しか成功しません。
両方をやれる人だけが、本当に現場に評価されるエンジニアになれる。

kintoneの魅力は「現場で育てられる柔軟性」と「組織全体で支えられる拡張性」の両立にあります。
それを引き出せるのは、現場ユーザータイプの“共感力”と、情シスタイプの“設計力”を兼ね備えたエンジニアだけです。

「俺は現場タイプだから…」「私は情シスだから…」とラベルを貼るのは今日で終わりにしましょう。
現場に寄り添い、技術で支える。両方できてこそ、kintoneエンジニアの本当の価値がある。

弊社のエンジニアは、全員両方の視点を持って、「キミノマホロ for kintone」を提供しています。

キミノマホロ for kintone

アールスリーでは業務改善・システム開発を行うサービスを「キミノマホロ for kintone」として提供しています。

キミノマホロ for kintone」は業務改善のプロセスをイロハで3つのフェーズに分け、フェーズごとに作業をメニュー化しています。

  【イ】業務改善の始まり:業務改善の方向性を決める

  【ロ】業務改善に必要なkintoneアプリ作成:業務改善を実現するための仕組み(kintoneアプリ)を作る

  【ハ】業務改善の実行サポート:業務改善を進める

今回の記事のようなお話は、イロハのどのステップでも弊社が気にしている内容になります。

また、システム開発グループではkintoneに関するお悩み相談をお受けする「kintone駆け込み相談室」を随時開催しています。kintoneのシステム開発でお悩みの方がいらっしゃいましたらぜひお申し込みください!

投稿者プロフィール

いのうえ
いのうえ
さすらいの、kintoneエンジニア