キントーンとの邂逅!
システム移行は初期設計が重要なのです

前回のあらすじ

前回の投稿では「平社員がいきなりキントーン担当を任された!?」ということで急な任命で困ったことや思ったことをまとめました。ただの平社員だった自分が会社の根幹である顧客管理ソフトの移行を任されたときのことをリアルに書いてますので、気になる方は下のリンクからどうぞ↓

この章では、その続きになります。初期構築に挑むストーリーです。

キントーンとの邂逅

まずはキントーンをお試しで導入してみた

キントーンをお試しで使ってみることになったので知識のないまま、いろいろと触ってみました。「ノーコードで使えます」という売り文句の通り、ドラッグ&ドロップで入力項目を並べて行ったりとかなり直感的に操作できるインターフェースだなと当初は感じました。

「なんでもできそう!」というのがこの時の感想です。実際、今でもそう思っています。まぁ今となってはノーコードで、という訳には行きませんが…笑

意外だったこと

キントーンはノーコードのみならずjavascriptやCSSなどのコードを外部からアップロードすることでさらなるカスタマイズが可能となる点に驚きました。この手のWEBサービスを使ったことがなかったので、ノーコードオンリーかと思ってましたが、かなり自由度が高そうだなと思いました。

ですが後々これが自分を苦しめる要素になることは、まだこの時の自分は知らない…

超大事な初期設計にトライ

初期設計とは?

キントーンの初期設計とは、今使っているサービスで何をしているかを細かく洗い出し、これらをどうやってキントーンで再現するかを考えることから始まります。キントーンの「設計図」みたいなものを地道に作っていきます。キントーンは何でもできちゃうので、最初から100%作り上げようとすると設計段階で力尽きてしまいます…

なので、ゴールを何段階かに分けて、最初は最低限のラインをクリアできるように設計していきましょう。

まずは何から設計したか

メインとなる「顧客台帳」から設計することにしました。顧客の会社名や住所、担当者などの情報が詰まった大事な会社の資産です。この顧客台帳がいわゆる「マスターデータ」になります。

マスターデータである顧客台帳アプリを構築してしまえば、あとはマスターに紐づける形で他のアプリを構築することができます。なので、1番コアとなる部分なので重要であり、構築すれば土台となる部分です。

それ以外のアプリ設計は優先順位をある程度決めて順番に設計しました。今回の場合だと以下のような順序で進めました。

  1. 顧客台帳(マスター)
  2. 対応履歴
  3. リース管理

既に使っている旧システムと同じものを設計しました。設計したら次は実際にどうやって移行して行くかの検討をしなければなりません。

初期設計までして思ったこと

ここまでの感想は「こりゃビッグプロジェクトだぞ…」ということです。旧システムには10年分のデータが蓄積されてます。しかも、最初は管理されていたものの、途中からはその場の思いつきで余計なテンプレートを量産したり、データベースを量産したりと荒れ果てた状況でした。

この旧システムでしていたことを再現するのも一苦労なわけですが、余計なものは削ぎ落としていく作業もありハードワークになりそうです。

次回からは設計の最終調整から実際に構築するまでをまとめます。

頭がおかしくなるから整理して進むにゃ