kintoneカスタマイズに関する書類

皆様はkintoneカスタマイズor開発を行うにあたり、書類を作成しておりますでしょうか?
弊社は小規模な事もあり、現在は私のみの開発・運用で事足りているため何の書類も作成していません。
(期間が開いての再開発の場合、javascriptを読んで当時を思い出しています)
しかし永遠に私が開発できるわけでもないため、何らかの書類を残さねばと考えている次第です。

例えば標準機能のプロセス管理であれば、画面を頑張って読み込めば流れを理解できない事もないですが、
自前のjavascriptを、後任者に引き継ぎたい・代理人に開発をしてもらう等で『私が介入できないシチュエーション』でも
過不足なく伝えられるものがあればと考えています。

賛否あるExcel書類で作成し始めてはいますが、よりよくなるアイデアや、インスピレーションに繋がるアドバイス等いただけましたら幸いです。

2 Likes

@t.nori さん

こんにちは、私も同じような悩みが現在もあって興味があったので、ご回答させていただきました。
私が勤めている所も小規模で一応お客様向けにも提案等など行っているのですが、Kintoneでの開発が絡む業務はほぼ私でして日々「自分がいなくなったらどうするんだろう」って漠然に考えていましたが、ひと月ほど前に転機があって @t.nori さんと同じように残す事を始めてきました。

私が参考にしている記事として↓
https://blog.ddm.tri-stage.jp/2021/07/02/キントーンのgit管理について/
でして、アプリの情報をJSONで保存しておいて、構成管理を行っているようです。

あとは、Kintoneにですがアプリの目的と作ったJSファイルをアップロードして何をしているのかをテーブルでまとめたり、CDNのURLを付属したりなどしておりますね…

過不足なく伝えることができれば幸いなんですが、恐らくなかなか厳しいと思うので、
なるべくプログラムにもコメントを入れるようにしています。
例えば、この変数はどういう目的で定義しているとか、この関数はなにしてるとかまとめてます。

回答になっているかわかりませんが、私がしていることは以上です…

1 Like

コメントありがとうございます。

ご参考URLですが、gitでの管理も若干の知識・IT方面の教養が要るものの、なかなか良さそうですね。
バージョン管理を主軸に私もこちらを導入しようかと思います。

JSファイル内コメントにつきましても、私も同感です。
JSDOCを参照しながら、それらしいコメントを多めに記入しています。

@y_minamitani9534 さんは、例えばひと目見て理解しやすいような図表などの運用はされているのでしょうか??

@t.nori さん

ご返信ありがとうございます。
意図している図表かどうかわかりませんが、アプリによっては複雑なものもありますので、簡単ですが状態遷移図とかも作成しておりますね…
全部作れるといいとは思いますが、なかなか体力いりますので…簡易的なものはスキップしてますね(汗)

私も基本githubで管理していますね。ソースコードやフォーム情報も管理できますが、Readmeに残したり、wiki機能とかもあるので、仕様の背景などそれ以外も残せるかなと思います。
また、図に関してはMermaidでフロー図やシーケンス残したりもいいかなとおもいます。

@y_minamitani9534 さん

なるほど状態遷移図ですか、、現在私が作成している分は(kintone触って一年というのもありますが…)簡単なものが多く状態遷移図までは作成しておりませんでした。
今のうちに既存アプリをもとに作成して慣れておこうと思います!

状況お察しします。
私も自分用備忘録と、将来の引継ぎ用途と半々くらいの意識で作成していますが、
利用者からの要望→開発の方が多く、書類作成にはなかなか手が回っていない状況です。。。

@mura さん

やはりgithub管理されている方が多いんでしょうか。ソース本体に加えてreadmeやwikiを使って文書情報も一緒に残せるのがメリットなのかもしれませんね。
@mura さんはgithubに保管するにあたり(おそらくprivateで運用されているかと思いますが…)、RESTAPI用のトークンもスクリプト内に記載されているのでしょうか?

Mermaidというサービスは初めて聞きました。これもjavascriptで作られているんですね!
SE時代に運用していた昔ながらのExcel方眼紙はちょっと…と思案していたところですので、こちらのサービスも使ってみたいと思います!

1 Like

やはりgithub管理されている方が多いんでしょうか。ソース本体に加えてreadmeやwikiを使って文書情報も一緒に残せるのがメリットなのかもしれませんね。

あんまり多くないと思いますね。僕はもともとエンジニアですので水が合うのですが、kintoneからカスタマイズ入ってきた場合にはある程度ハードルは高いのかもしれないなとおもいます。ソース管理自体、慣れてないとウッとなるといいますか。
あとはプロジェクト管理ツールつくってそこで課題を管理してればあとから見返した時、わかる、とか、最近であればNotionなども有力候補かなと思います。

トークンなどの機密情報は.envファイルや別ファイルなどで管理して、そこだけソース管理に含めないほうが定石だとは思いますね。Privateリポジトリなら大丈夫、ではあるんですが、間違った操作などもありえますし、より確実にするには、という感じで…

1 Like

@mura さん

私もエンジニアでしたので、ソース管理は何とかなりそうです。
現在はwinmergeというアプリで地道に確認していましたので、これを機にgithubに慣れようかなと思います。
実はNotionについても興味があって先日ウェビナーを受講していました。

.envファイルを.gitignoreに入れて管理という手法もあったんですね、ありがとうございます。
仰る通り管理をしっかりできていても、人為ミスまで100%防げない(または内外部からの悪意等…)となると、万が一の対策で必須と感じます。github管理する方針で取り入れさせていただきます!
また最後の参考リンクですが、非常に勉強になりました。

1 Like

このトピックはベストアンサーに選ばれた返信から 3 日が経過したので自動的にクローズされました。新たに返信することはできません。