ぴなさん

はじめまして。IT業とのことでやっぱり気にされるところがツボをついてますね。^^

kintoneは「100社100通り」でこれといった正解はありません。私も最初ぴなさんと同じような点でなやみましたし今でもそうです。そんな「答えのない答え」をキンコミでディスカッションできたらと思います。

せっかく箇条書きであげていただいたので、わたしなりの考えをお答えします。

・Kintoneとリレーショナルデータベースの考え方と違うところ
→同じようで違うようで^^;。最初戸惑うポイントとしては、条件式の変更などの反映が一括更新されない点(CSVファイルでの一括更新で対応可能)。これはある意味正解な仕様で、例えばExcelを基本としてみた場合ある項目の変更により他の列が一括変換されては困るということではないかと。

それと正規化にはこだわりすぎないほうがよいと思います。ある程度のマスター化は必要ですがこだわりすぎるとハマります^^;。例えばkintoneにはテーブルというフィールドがあります。そのためＲＤＢでいう第1正規形までになってしまっているともいえます。これもヘッダ部分に得意先名や注文日、ボディ(明細)部分に製品名や数量金額をいれる伝票形式を簡単につくりたいというユーザーにとっては自然な仕様ともいえます。

又、kintoneをデーターベースと捉えると一面しかみえなくなりがち。プロセス管理機能やコメント機能、通知機能も含めての製品です。データーベース機能＋ワークフロー的な機能＋コミュニケーション機能の３点セット、特にコミュニケーション機能の活用は重要だと思います。

あと細かい点ではcommitやrollbackは使えないのである意味シビれます。^^;

・UIの癖
→あります。^^;。かつ頑なに変更されません。^-^;。特にそれぞれの部品が大きく縦に長くなりがちな傾向があります。しかし頻繁に変更されないという事は良い事とも言えます。データーベースや運用の根幹にかかわるUIや仕様があまりにコロコロ変わるようでは、逆に危なっかしくて長期利用ができません。今年使える機能が来年なくなってしまうかもしれない可能性もあるからです。kintoneのアップデートは適宜ありますが、アップデートがある場合も既存機能の継承には相当配慮されている様子が伺えます。私はここにサイボウズさんの「情報インフラを守る」という姿勢が見て取れると考えています。またUIについては関連サービスの利用やカスタマイズにより、やろうと思えば色々できるようにはなっています。

・Kintoneとプログラム開発で言う、設計・開発・テスト・リリースをどう再現すればいいのか
→あまりこだわりすぎない方がよいと思います。いわゆるウォータフルな開発手法はkinoneには合いませんし合わせるメリットもそんなにありません。またそのような開発方式に合わせたツールも十分ではありません。一般的なプログラム開発手法を利用する工夫はできますが、そもそもその手法があっているかどうかは考慮されたほうがよいと思います。ちょっと極端な例えですが、Excelブックをひとつ作るのに「設計・開発・テスト・リリース」の手順は普通ふみませんよね。kintoneは、Excelブック作成と、一般的なプログラム開発の中間くらいのイメージに思ってもらえばよいのではないかと思います。

・アプリだらけになると使われないアプリのゴミだらけにならないか？
→なります。^-^;。悩みのタネというかゴミだらけアプリの中心人物が私です。^^;。言い訳っぽいですが^^;たくさんのゴミアプリがつくれる環境があってこそ良いアプリも生まれると思います。逆に自由にアプリを作れる環境をどううまく運用するかですかね。整理はkintneにかぎらず工夫が必要だと思います。キンコミでも時々話題になりますが相談・情報交換しましょう。

・アプリケーション更新の際のポリシー？
→こちらもちゃんとしようとするとたいへん。でもぜんぜんやらないわけにもいかないので悩みますよね。うちでは今のところルールベースから入らずに、アプリ開発権限を付与したユーザー専用のスペースを作成して、開発ガイドラインの共有という形で展開をしています。他回答としてはいままでの流れと同様な回答になってしまいます。^^;

。。。ちょっと長くなってしまいました。すみません。あくまで私個人の意見ですのでご参考まで。

ぴなさんのようにシステム的な知見があればkintone活用にもアドバンテージがあるのは確かです。いっしょに相談しながらやっていきましょう。^^