おはよう白ばいきんまん（しろばいきんまん）
その１記事を書きました
県立図書館を遅くに訪問した理由は・・・
マイページ登録および、kintone要求定義のテンプレート化をするために、下調べで行きました。
。
という記事を書きました。
そしたら長くなったので、その２に続きます。
。
kintone実装の上での諸問題
今回のもやもやしていた私の頭の中は・・・
単に、kintoneアプリ構築だけではありませんでした。
。
書籍を読むにつれ、
今後チームを作るにあたり、
を考えるためにと書籍を読んでいたら、
単に要求定義やドキュメント化だけの話では済まなかったのは大きな収穫でした。
。
改めて作ったペルソナはこちら。
kintoneが不慣れな方でも、設計書を見て簡単にアプリが作れる！
ためにどんな設計技法がいいのか、
どう浸透させるのか、
どう進めていくのか、
チーム作りはどうしたら？
。
まさに今回手に取ったこの書籍が参考になりました。
。
中小企業にとって、売れるコンテンツは
ヒトとノウハウのマネジメント
と断言されるあたり、結構衝撃を受けました。
。
だからこそ単なるアプリ構築のためのドキュメントであっても、
スケジュールやメンバー構成、担当割なども考えての、、、内容にする必要があるということです。
。
kintone実装にあたって必要なドキュメント
通常の開発技法のみならず、
アジャイルであったとしても、UMLを使って、
ユースケース図、オブジェクト図、シーケンス図、
等を作っていくのですが、、、
。
kintoneの場合は画面ありきで、ビジネスロジックが埋もれてしまっています。
プロパティを開けばわかる
と安直に思っていた時期がありましたが、
これはいつもの逆説的なとらえ方で、
プロパティを開かないとわからない
アプリ権限まで付与すると、
万が一にアプリを削除されるリスクなどもあります。
。
今は、いかにプロパティを開かずに、
ドキュメントレベルで記載しておくか、
アプリ間の連携や、フィールドの設定、計算式、
一覧やグラフの事前作成など、設計者の頭の中を見える化する必要があります。
。
さらには導入後のオペレーションや維持メンテ、
全体スケジュールといった流れも入れて置くことで、どんなアプリ構築になったのか。
わかることになります。
。
１アプリ作る、
というよりは、複数アプリをまとめたビジネスプロセスをどう設計書にするか、
そういう目線で作っておりました。
。
結果的にこんなテンプレートに
その結果、そこそこの出来になりましたので、
一旦これで進めて、必要な細かい修正は別途、という形にしましょう。
。
全体を見せずにチラ見せするあたりがしたたかだと思われるかも知れませんが、
これはまだ下案であり、これから既存で構築したものを当てはめて項目や流れがいいのかを、これから検証します。
。
なのでWordですが、今後、Googleドキュメントに変わっていく予定もあります。
まずは運用してみて。
そんなところから始めて参ります。
。
これまでテンプレートなかったの？
これまでテンプレートなかったのか？
と聞かれると、正直な話、ありませんでした。
マインドマップがある程度でした。
とは言え、そのマインドマップも、
結構大きいものになっています。
。
他の作業で行う場合は、、、
オブジェクト図、シーケンス図を作る程度でした。
それで十分でした。
一人で行う上では
という話です。
ただ、今後はそれではいけません。
。
チームとして、組織として、
kintoneを浸透させていくために、開発を行っていくために。
進めて参ります。
今後もお付き合い下さいませ。
。
関連記事一覧
（公開されると表示されます）
コメントを残す