たなかともゆき

自転車とkintoneのいろいろな気付きをメモしていきます。 「すごくなくてもいい」ら…

たなかともゆき

自転車とkintoneのいろいろな気付きをメモしていきます。 「すごくなくてもいい」らしい。

2023年をふりかえる

『「すごくない」kintone　その2 Advent Calendar 2023』12/3の投稿です。

たなかともゆき

    • 自分のためのkintoneSIGNPOST[6-42 定期的な棚卸し]

      パターン参考資料読んでみてイラスト kintoneアプリを表す倉庫で棚卸の際中の様です 状況 kintoneを利用しはじめて一定の月日が経った。 現場メンバー自らがkintoneで自身の業務を楽にするアプリを作りはじめている。 アプリの数も順調に増え、プラグインや連携サービスの契約数も徐々に増えてきている。 問題 アプリの増殖を放置すると、使われていない不要アプリがたまってしまい、ユーザーの利便性を損ねてしまう。 不要アプリの原因 ・作った本人も忘れて放置 ・作成

      たなかともゆき

      • 自分のためのkintoneSIGNPOST[6-41 アプリ作成ルール]

        パターン参考資料読んでみてイラスト ルールを話し合っている様です。 状況 現場メンバー自らがkintoneで、導入初期に用意した用途以外にも自身の部署やチームの業務改善を進めるようになってきた。現場リーダーとしても、現場メンバーがアプリを作って使う状態ができはじめ、嬉しい限りだ。 問題 各現場で自由にアプリ作成が行われると全体の構造が複雑化する上、重複の原因にもなってしまう。 現場メンバーが自由にアプリを作る→部署ごと・チームごとでアプリが作られる。 その場合は各

        たなかともゆき

        • 自分のためのkintoneSIGNPOST[6-40 担い手を増やす]

          パターン参考資料読んでみてイラスト 新たな担い手が生まれた様です。 状況 kintoneが利用者に認知され、当初の導入目的は達成した 今後は管理者の意図した用途以外に利用者自らがkintoneを用いた業務改善を進めてほしい。 問題 いつまでも同じメンバーでのkintoneアプリの作成や運用にとどまっていては、増えていく現場の要望への対応ができない 一方で利用者はkintoneについて何から手を付けて良いかわからない。 また、みんなが好き勝手にアプリを作ってしまうと

          たなかともゆき

        2023年をふりかえる

        たなかともゆき

          自分のためのkintoneSIGNPOST[5-38 専門家への相談窓口]

          パターン参考資料読んでみてイラスト 相談カウンターにてご相談されております。 状況 JavaScriptカスタマイズを適用したアプリを運用している。 素早い設定変更ができる様、一部メンバーもこのアプリの管理者となっている。 現場メンバーはJavaScriptなどのカスタマイズには触れられない様にアクセス権が設定されており、現時点では想定通りの利用ができていて安心している。 問題 知識・情報を持っていない現場メンバーのみの判断でアプリの設定を変更すると、実施したカスタ

          たなかともゆき

          自分のためのkintoneSIGNPOST[5-38 専門家への相談窓口]

          たなかともゆき

          自分のためのkintoneSIGNPOST[5-37 継続的な振り返り]

          パターン参考資料読んでみてイラスト ボードを前に三人が何やら話し合っています。 既存アプリの構成を振り返っているのかな？ 状況 はじめてのプロジェクトが一通り終息した。 初期導入がゴールではないのでここからさらに業務範囲を拡大したり、継続的な業務改善を実施する予定だ。 問題 初期導入時の経験や学びを今後の業務改善に活かせないかもしれない kintoneは継続的な改善を行えるものだが、初期導入時の紆余曲折をきちんと分析して原因と改善策を明確にしないと次のサイクルで同

          たなかともゆき

          自分のためのkintoneSIGNPOST[5-37 継続的な振り返り]

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-36 利用率の把握]

          パターン参考資料読んでみてイラスト 数取器片手にアプリの運用状況を把握しようとしています。 状況 現場メンバーがkintoneでの運用に慣れるまでは時間がかかる 運用定着のサポートをしたいが、運用定着の評価をどのようにすればよいかわかっていない 例えば利用開始から一か月、大きな不満や不具合なく運用できれば「定着した」と考えてよいのだろうか… 問題 運用定着の評価を怠ったり、誤ってしまうと実は使われていないシステムとなっている可能性がある どの程度利用されているのか

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-36 利用率の把握]

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-34 アプリ発見の工夫]

          パターン参考資料読んでみてイラスト アプリの案内板を見て気づいた瞬間の様です。 状況 kintone上にアプリが増え、複雑度が増してきた。 問題 必要な時に目的のアプリが見つけづらく、利便性を損ね、場合によってはアプリが使われなくなってしまう… 解決 アプリへの導線を整備し、アプリ名やアイコンを工夫することでアプリを見つけやすくする アイコンをアプリの内容のイメージを表すものにしてみたり、アイコンの中に部署名を入れてみたり 視覚的にわかりやすい表現を工夫する。

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-34 アプリ発見の工夫]

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-33 現場代表]

          パターン参考資料読んでみてイラスト 中心となる人から各々へ声をかけている様子です。 状況 kintoneを使った業務システムをリリース そのシステムの利用マニュアルを用意し、現場ユーザーへの説明会も予定しています。 問題 業務してむ側からのアプローチだけでは、現場メンバーの理解が浅くなってしまい、システムが現場に浸透しにくい 解決 現場の中から業務を深く理解している人を現場代表として選出し、その人からシステムの説明をしてもらう 現場代表からメンバーへシステムの

          たなかともゆき

          自分のためのkintoneSIGNPOST[4-33 現場代表]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-32 開発環境の用意]

          パターン参考資料読んでみてイラスト 同じ状況を二つ用意して、片一方で何やら作業をしている様です。 状況 プロジェクトはkintone上にアプリを構築する段階に差し掛かった。 設計者はアプリ構築やカスタマイズを始める為の環境を準備している。 問題 実装したアプリや加えた設定変更を試してみたいが、いきなり本番環境に反映すると、不具合があった場合にユーザの業務に影響してしまう。 運用前であればいきなりリリースでも問題ないが、運用開始後の修正を行う場合は既存のフィールドや

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-32 開発環境の用意]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-31 性能への気遣い]

          パターン参考資料読んでみてイラスト 設計を考えている人の創造の中で渋滞が起こっているようです 状況 kintoneでそれなりの規模のシステムを構築する。 一般的なシステム構築の際にはサーバーや契約プランを選択する必要があるが、kintoneは導入時点で基盤は全て整っており、スペックを選べるプランはない。 その中で、どのくらいの規模まで構築できるものなのか不安がよぎる。 問題 kintoneの特性を理解せず、性能に配慮しない構築をすると、いざリリースした後に性能低下の

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-31 性能への気遣い]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-30 共通のマスタアプリ]

          パターン参考資料読んでみてイラスト ひとつのマスタアプリをみんなで共有している構図が示されています。 状況 kintone利用開始後は、現場メンバー自らがkintoneを使って、自身の部署やチームの業務改善を進めることを想定 その際は、アプリ作成ルールを設定したり、担い手を増やすにあるように、現場メンバーにはマスタの概念や効率的なデータの持ち方もレクチャーする予定だ 問題 それぞれにアプリを作成すると、類似のマスタアプリが複数できてしまい、管理・運用が煩雑になってし

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-30 共通のマスタアプリ]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-29 ほどほどのUIカスタマイズ]

          パターンhttps://kintone.cybozu.co.jp/kintone-signpost/pattern/3-29.html 参考資料読んでみてイラスト kintoneを表した？雲にお化粧しています。 状況 プロトタイプを現場メンバーに試してもらったところ、UI/UXに関して様々な要望が 「使い慣れた既存の業務システムに比べて、kintoneはフィールドの大きさやフィールド同士の間隔が大きく、入力速度が落ちそうだ。これらを小さくしてほしい。」 「『アプリ

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-29 ほどほどのUIカスタマイズ]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-28 最軽量のアクセス権設定]

          パターン参考資料読んでみてイラスト アクセス権を表す箱でしょうか、それを以っても量りのメモリが軽いようです。 状況 kintoneのアクセス権を設定しようとしている。 “開かれた情報”“オープンな閲覧権限”を基本に考える。 しかし、アプリグループ、アプリ、レコード、フィールドとアクセス権を設定できる箇所が多く、また対象も組織、グループ、ユーザーなど複数選択肢あり、どう設定すべきか悩んでいる。 問題 行き当たりばったりにユーザー単位のアクセス権を設定すると人事異動のた

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-28 最軽量のアクセス権設定]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-27 親子アプリ]

          パターン参考資料読んでみてイラスト 棒人間の親子でケーキを分けあっている様です。 状況 アプリを作成するうえで、入力項目を追加しようとしています。 「見積書アプリ」のあて名など、同じデータを再利用するケースが多い一方、そのデータの更新頻度も比較的高い入力項目について検討している。 フィールドタイプを「文字列一行」と「ドロップダウン」のどちらを利用すべきか迷っている。 問題 毎回手入力にすると手間が多く入力ミスの原因にも ドロップダウンだけではすべてのケースに対処でき

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-27 親子アプリ]

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-25 プロセスのシンプル化]

          パターン参考資料読んでみてイラスト 複雑にからまった矢印がほどかれてシンプルになっています。 状況 申請業務をkintoneで構築 その一部が基本機能のプロセス管理では実現できないとわかった。 そこで従来の運用に合わせるために連携サービスやカスタマイズの検討をはじめた。 例）現在の紙運用 　➡申請済みの紙の「取り戻し」（取り下げ？） 　➡承認者不在の場合の代理承認 問題 現在のプロセスや運用方法をそのまま再現するだけでは業務改善効果は少ない 業務の変化に伴って申

          たなかともゆき

          自分のためのkintoneSIGNPOST[3-25 プロセスのシンプル化]

          たなかともゆき