kintone認定エキスパート お勉強ノート
ジュリドンさんの勉強記録をマネして自分もノート残してみる
過去の自分から学ぶ
kintone SIGNPOSTについて何をつぶやいていたか ただただ纏めてみます。
https://kintone.cybozu.co.jp/kintone-signpost/pattern/0-00.html
本日のkintone SIGNPOST！
— 飯塚洋平 (@iiyohei) December 4, 2021
「0-00 kintoneはkintone」について今日は考えてみます#kiktonesignpost pic.twitter.com/NuBJDEuE4w
逆にkintoneでないkintoneを考えると、既存スクラッチシステムの置き換えとして考えて、UIも無理やり合わせようとする。1つの業務のためだけに、全社員月1500円て高いよね。と判断される。業務担当者がkintone を全く理解せずにベンダーに丸投げする。こんなのはもったいない。#kintoneSIGNPOST
— 飯塚洋平 (@iiyohei) December 4, 2021
#00
非IT部門が業務改善を推進できるというのが、hiveなどでエビデンスがたくさんあるのが強いと思う。
— 飯塚洋平 (@iiyohei) September 8, 2022
kintone以外のローコードに触れる機会も増えているが、ほんとにこれ、現場に預けられるの？ってツールも多い#kintoneSIGNPOST#kintoneはkintone
#kintoneSIGNPOST#kintoneはkintone https://t.co/YUAgjKX8m4
— 飯塚洋平 (@iiyohei) August 12, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) June 2, 2022
「0-01 現場主体の業務改善」について考えてみます。#kintoneSIGNPOST#kintone概念理解 pic.twitter.com/ISBLZDzInA
現場主体で業務改善を進められる様に、まずは１サイクル目をしっかり伴走して、業務改善の視点や、ステップを経験してもらうのが大切
— 飯塚洋平 (@iiyohei) June 2, 2022
その上で、継続的な業務改善が必要なのか？を、現場で対話してもらい、スピード感や、業務改善にかける時間など、自分たちで言語化してもらう様にしています。
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) June 20, 2022
今日は「0-01 現場主体の業務改善」
過去の反省点として、現場にまかせて、改善サイクルが回りだしたので、手放し状態にしていたら、現場の業務多忙で改善が止まっていたという事がある。
業務の外側の人が定期的にテンポを取るというのもとても大切https://t.co/35qCLuZDwQ
本日のkintoneSIGNPOST！！
— 飯塚洋平 (@iiyohei) April 3, 2022
「0-02 素早く繰り返す」について考えてみます。
繰り返すや、ユーザーからのフィードバックを貰うというところに意識をしっかり置くことが大事。#kintoneSIGNPOST#kintone概念理解https://t.co/YROENy7w0O
素早く繰り返す、現場主体の業務改善の定着のためにも「要望箱アプリ」は大事だと思います。ただ、形式はアプリに限らずに、スレッドコメントからでも良し。どうしたら、要望を書きやすいか？を意識し続けて、コメント返しや、対応スピード感を出せる運用体制をつくるのも大事です
— 飯塚洋平 (@iiyohei) December 25, 2021
「素早く」と「繰り返す」のそれぞれが大事に思います。素早く改善するためには、大きな課題を分解する必要があるし。繰り返し改善する前提であれば、最初から大きなハードルを目指す必要がなくなる。「素早く繰り返す」というSIGNPOSTは現場側にもしっかりと着信する事で、期待感づくりもできそう
— 飯塚洋平 (@iiyohei) December 1, 2021
今ある情報をオーブンにするのと、将来的にオープンにして共創するために、新しい情報を生み出すことも考える。例えば小さなアイデアだったり、ちょっとした不満だったり。
— 飯塚洋平 (@iiyohei) August 6, 2022
こういった情報はクローズドな場の方が生まれやすい。#kintoneSIGNPOST#kintone概念理解#開かれた情報
情報をオープンにしていない理由として、社員を子供扱いしているケースがよくある。子供に給与明細、通帳を見せない家庭と同じ
— 飯塚洋平 (@iiyohei) August 6, 2022
なぜ見せないのか？将来はどうなってほしいのか？を考えた上でオープンにする判断も必要
会社での社員に対しても同様#kintoneSIGNPOST#kintone概念理解#開かれた情報
なぜ開かれていない情報があるのか？の棚卸しも大事、顧客の個人情報や、リリース前の業務提携など、オープンにできない情報を明確にする事も大事#kintoneSIGNPOST#kintone概念理解#開かれた情報
— 飯塚洋平 (@iiyohei) August 6, 2022
kintoneSIGNPOSTでnote書いてみました。
— 飯塚洋平 (@iiyohei) March 20, 2022
「kintoneSIGNPOSTと情報アーキテクチャ」https://t.co/XAIK9sNAki#kintoneSIGNPOST#kintone概念理解#開かれた情報 https://t.co/Ig7k47RLwZ
本日のkintone SIGNPOST
— 飯塚洋平 (@iiyohei) November 28, 2021
今日は「0-04kintoneエコシステム」について考えてみます。#kintonesignpost pic.twitter.com/jZIgW26KyY
まずは、エコシステムって何？を調べてみました。
— 飯塚洋平 (@iiyohei) November 28, 2021
元々は食物連鎖や物質循環の生態系を意味する。
ビジネスにおいては、発展途上の分野での企業間の連携関係全体を表すのに用いられる用語
らしいです。
発展途上というのがkintoneぽくて良いです。
少ないエネルギーという部分は、心理的な部分や、モチベーションを指していて、担当者がモチベーションの維持、アップしやすい。というのもkintoneエコシステムの特徴だと思う。それはサイボウズの理念である「チームワークあふれる社会を創る」の上にkintone があるからこそ！ですね。
— 飯塚洋平 (@iiyohei) November 28, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) July 14, 2022
「1-05 業務の付加価値」について考えてみます。
とても大事で、とても難しいやつ
業務改善支援の立場で、業務部門とかかわる場合は、窓口担当者がこういう視点をもってない場合はさらにむづかしい。#目的設定#kintoneSIGNPOST pic.twitter.com/PH2rZFqWO1
正論をぶつけても視点を変えさせるのも手の一つですが、効果が薄い場合もあるので、関連部署の人も読んで認識を合わせたり、認識のズレを見えるかしたり、一層上の役職の人にも時間いただいて、俯瞰した視点での声をもらったり、コツコツ気づいてもらうのが大事かなと感じてます。
— 飯塚洋平 (@iiyohei) July 14, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) April 27, 2022
「1-05 業務の付加価値」
業務のAS-ISは描けるけど、TO-BEを描きにくいという話を聞きます。To-Beを描けないという事は、As-is整理が浅いとも言えると思う。業務の歴史背景、文化、制度なども含めて整理するとAS-ISも描きやすいかなと思ってます。#kintoneSIGNPOST#目的設定
「業務の付加価値」がどういう価値か、そこか改善されるのに自分たちでやる場合と、プロに頼った時に例えば3か月の差がでたら、業務や収益にどれだけ影響が変わるか？効果を早く出すという事は、利益の差がこれだけ変わってくる。と試算できれば、プロに支払う対価が見合ったものかの判断もしやすい。
— 飯塚洋平 (@iiyohei) January 23, 2022
本日のkintoneSIGNPOST！！
— 飯塚洋平 (@iiyohei) January 7, 2022
今日は「1-6 業務のkintone化」について考えてみます。
業務のボトルネックだけでなくて、小さな不安、不満を拾うの大事、人の感情も含めて業務はなりたっている。
— 飯塚洋平 (@iiyohei) August 12, 2022
業務に関わる人の気持ちも含めてkintone化していく
Excelでは共有できなかった顧客の生の声（写真や、音声ファイル）も共有できる様になる#kintoneSIGNPOST#目的設定#業務のkintone化
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) April 10, 2022
今日は「1-07 システム化のコンセプト」
コンセプトって何を決めれば良いのか？と悩んでいた事をnoteにしてみました。#kintoneSIGNPOST#目的設定
#note https://t.co/uuuPyEKDyS pic.twitter.com/rKkrmQJP6P
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) April 5, 2022
「1-08 現場とIT部門のチーム」
これについて考えてみます。
IT部門への期待として、kintoneだけでなく、プロジェクト管理、他部署との調整、経営層との握りなどしつかりしてくれるIT部門だと頼りがいがあるし、相談が集まりやすい。#kintoneSIGNPOST#目的設定 pic.twitter.com/n9r4gRzf17
kintoneはIT部門に頼らずに、事業部門だけでも活用できるツールだし、事業部門とIT部門が距離のあるような企業でも、、、部門単位で業務改善しやすいツールである。 ですが。。。 kintone活用の業務拡大や、部門間連携を考えると、情シスの目に止まると思うし、野良kintoneアプリが増えるのは、、、
— 飯塚洋平 (@iiyohei) January 6, 2022
放置できないので、どこかでチェックは入るかと思う。
— 飯塚洋平 (@iiyohei) January 6, 2022
であれば、早いタイミングからIT部門と一緒にチームを組んでいた方が、将来的な展望も広がるし
IT部門内の業務改善にも貢献できるのでは？と考える。
今日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) April 15, 2022
「1-09 業務の流れを掴む」について考えてみます
この山の風景が表現してる様に、業務ってデータや紙の動きだけでなくて、水や空気の流れを掴むようなことかなと思っています。
季節や天候によってどんどん流れが変わる。それをいかにつかめるか？#kintoneSIGNPOST#目的設定 pic.twitter.com/J4D7VIFp6D
個別最適ではなく、全体最適で考えるべし。という表現をよく使いますが、全体ってどこ？って結構悩みます。業務の流れを考えた時に、データがどのタイミングで生まれ、どのタイミングで止まるのかを1つの目安にする。データが生まれるのは人の動き起点か、日時起点（月末、毎朝とか）が基本かなと。
— 飯塚洋平 (@iiyohei) December 2, 2021
決まった流れの中で、イレギュラーやトラブルに対応する必要もある。
— きったん@踏み出せば、その一足が道となる (@KK80979809) April 15, 2022
流れの先にある業務の目的を見失わないことですよね。
個人的には業務改善においてこの1-09は重要視していることの一つですね…
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) May 22, 2022
「1-10 根本原因の追求」
業務のボトルネックを見つけるときに、物や情報の滞留から見つける事が多いですが、その業務を消化するために必要なスキルや、担当者さんが使える時間など、前提も言語化していく事が業務改善の近道だと思ってます。#kintoneSIGNPOST#目的設定 pic.twitter.com/ekj3zapTwK
業務改善の相談をもらう時に、”こうしたい”を伝えてもらう場合も多いです。「Excel運用をやめたい」「メールでのコミュニケーションをやめたい」「マスタを整備したい」そのまま対応すると、そもそもの課題対応にはならない。
— 飯塚洋平 (@iiyohei) December 29, 2021
Excel運用だと何が困るのですか？メールだとどんな不都合がありますか？マスタ化する目的って何ですか？
— 飯塚洋平 (@iiyohei) December 29, 2021
を言語化して、そもそも何が困っているのかを明確にしてから対策した方が、改善策の提案の幅も広がると考えてます。
今日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) March 29, 2022
「1-11 一足先に」について考えてみます。
一足先の一足のさじ加減が大切で、二足、三足はやく使ってもらってもピンときて貰えない事も多いかなと思います。
現状と未来の間にうまく、一足目を置けるかが大事かなと思ってます。#kintoneSIGNPOST#目的設定 pic.twitter.com/a60Y6guGbC
本格導入する前に、プロジェクトで使う事が多いです。
— 飯塚洋平 (@iiyohei) December 18, 2021
プロジェクトとは期間限定の活動なので、言い換えると、期間限定でkintone使ってみませんか？という事にある。合わなければ使わなくてもいいしね。と
課題管理アプリと、スレッドでのチャットだけとかで導入して少しずつアプリが増やしてく。
本日のサインポスト！
— 飯塚洋平 (@iiyohei) December 4, 2021
今日は「1-12 先駆者の話で」を考えてみます。#kintoneSIGNPOST pic.twitter.com/Oh0tbi5UzC
本日のkintoneSIGNPOST!
— 飯塚洋平 (@iiyohei) April 22, 2022
「1-12 先駆者の話」について考えてみます。
話を聞いて終わりではなく「先駆者とつながる」までいけたら更に心強い。
その時に、先駆者は何で情報発信してくれてるのだろ？を考えてみると
良い関係が築けるかなと思ってます。https://t.co/kwJAxGswIO#kintoneSIGNPOST
本日のkintoneSIGNPOST
— 飯塚洋平 (@iiyohei) March 13, 2022
「2-13 プロの伴走」について考えてみます。
プロジェクト企画の冒頭に「プロの伴走」があって違和感を感じる人もいそう。自分たちで作れるんじゃないの？やっぱり他にもお金かかる？と。#kintoneSIGNPOST#プロの伴走#プロジェクト企画#自分たちで頑張らなくてもよい。 pic.twitter.com/KR9ouscjxQ
ここで伝えたいのは、「自分たちだけでがんばらなくてもよい。」の方
— 飯塚洋平 (@iiyohei) March 13, 2022
自分だけでがんばっちゃダメ、社内に助けてもらえる人がいなかったら、外にはたくさん助けてくれる人がいるからねと
kintoneは１人で開発できるが、１人で育て続けるのは難しい。 1番難しいと思うのはkintoneは生物の様に日々成長してるので、最新の情報を集めたり、検証してりするのは１人力でやるのは非効率だと思う。情報収集や検証などはプロの発信してる情報にアンテナ貼るのが良いかなと思っております
— 飯塚洋平 (@iiyohei) January 10, 2022
「プロの伴走」という言葉には「費用」をかけてサポートして貰うとも置き換えられると思います。自分たちでも試行錯誤しながら実現できる事が多いと思いますが、スピード感は大きく変わる。特に初期のkintone開発の時は調べ方や頼り方も慣れてないので、かかる時間の差は大きいと思います。
— 飯塚洋平 (@iiyohei) January 23, 2022
安さだけでkintoneを導入する企業の場合、プロの伴走の費用に納得感をもてないケースもある。
— 飯塚洋平 (@iiyohei) August 12, 2022
その場合、システムにおける困りごとではなく、経営における困りごとに視点を変えて会話する
kintone導入におけるプロの伴走は、経営への伴走#kintoneSIGNPOST#プロジェクト企画#プロの伴走
伴走側は伴走者であるという認識を忘れない事が大事、あくまで主役は現場であり、伴走者がいなくても走り続けてもらう必要がある。マラソンのペースメーカー的な役割をイメージしている。ペースメーカーが去ってからが本番#kintoneSIGNPOST#プロジェクト企画#プロの伴走
— 飯塚洋平 (@iiyohei) August 12, 2022
プロの伴走者は何を残すのか？良いkintoneアプリではない。継続的に改善がすすむチームである。
— 飯塚洋平 (@iiyohei) August 12, 2022
人にフォーカスし続けるのが大事
詳しい人を1人生み出すのではなくノウハウの循環をつくるのが大切#kintoneSIGNPOST#プロジェクト企画#プロの伴走
どうやってプロの伴走者を選ぶのか？
— 飯塚洋平 (@iiyohei) August 12, 2022
自分の会社の未来を想像した時に、その未来で、一緒に仕事していたいと思えるかどうか？#kintoneSIGNPOST#プロジェクト企画#プロの伴走
ブラインドマラソンから学ぶ、業務改善職の心得https://t.co/Xl1QOId8Ky#kintoneSIGNPOST#プロの伴走
— 飯塚洋平 (@iiyohei) January 31, 2023
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 30, 2021
「2-14 基本機能から考える」について今日は考えてます！#kintoneSIGNPOST
kintoneの場合は、改善し続ける前提での導入が多いので、kintone開発を継続できる人材やコストを確保できるかの考慮も必要。基本機能範囲で利用していれば、スキル習得の目安が明確だし、kintone認定アソシエイト取得者を社内に育てるのも効果的
— 飯塚洋平 (@iiyohei) December 30, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) March 16, 2022
「2-15 自分たちのガバナンス設計」を考えてみます。
統制と自由度をどうやってバランスとるか？ 統制のかけ方も過去のシステム開発、運用前提で考えずに、kintoneの理解や、コンセプトの共感をした上で新しいガバナンス設計するのが大事#kintoneSIGNPOST https://t.co/49q9BH3wqq pic.twitter.com/7E5gC5iSEm
「自分たち」って誰？の明確化も大事かなと思います
— 飯塚洋平 (@iiyohei) March 16, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) January 22, 2022
今日は「2-16 オープンな閲覧権限」について考えてみます。#kintoneSIGNPOST#プロジェクト企画 https://t.co/ez46UttM43 pic.twitter.com/HKpq3ABfg1
情報をオープンにする事で、自然発生的に変革が起きる事もあるが、どんな期待をもつかは言語化しておいた方が良いと考えています。サイボウズが掲げている「風土」「制度」「ツール」の３つが大事だと思っていて
— 飯塚洋平 (@iiyohei) December 27, 2021
風土がないところに、情報共有しても見ないし、マイナスに働く可能性もある。
例えば、社内が部門ごとの個別評価制度を敷いている場合は、となりの部署に情報を開示して、自分の部門の評価が下がる。。。みたいな事も考える場合がある。
— 飯塚洋平 (@iiyohei) December 27, 2021
どういうチームを作ろうとしていて、どういう期待をもっての情報オープンなのか？は意識してからのオープンが良いと思う。
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) January 9, 2022
「2-17 未来の変化への備え」を今日は考えてみます。#kintoneSIGNPOST pic.twitter.com/8k85dlKfjb
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) May 9, 2022
「2-17未来の変化への備え」について考えてみます。
「状況の変化によっては計画や業務システムが無駄になってしまう。」
これだけで語り合えそう
組織体制が変わった、法律が変わった、経営層のツール好き嫌いとか（笑）https://t.co/SRju7T7XyT#kintoneSIGNPOST
ビジネスモデルや組織構造を変化させ続ける必要がある事を共通認識として持てるか？一度作ったシステムをそのまま使い続けるものじゃないと本当に思えるか？大きな意識変革が必要だと思います。共通認識をもった上で、変化に対応するための体制や予算を継続的に確保につなげるのが大事
— 飯塚洋平 (@iiyohei) January 9, 2022
本日のkintoneSIGNPOST
— 飯塚洋平 (@iiyohei) November 29, 2021
「2-18 守るべきデータ」
今日はこれを考えてみます！#kintonesignpost pic.twitter.com/7VOJiy6GpO
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 9, 2021
「2-19 データの断捨離」
これについて考えてみます。#kintoneSIGNPOST pic.twitter.com/w9x9WEhN1O
Excelでいうと、行単位で断捨離というより、列単位やシート単位の方がイメージしやすい。年度単位で分かれているシートや、使っているか分からない列を全てデータ移行しようとせずに、必ず使うであろうデータ中心に移行する方が良いと思う。
— 飯塚洋平 (@iiyohei) December 9, 2021
完全に断捨離するわけでないので、kintoneに移行したデータとExcelを何かしらのキー項目で紐付けておけば、移行しなかった（断捨離した）データが必要になった時に追跡する事が可能
— 飯塚洋平 (@iiyohei) December 9, 2021
データの断捨離がうまくいかないと、開発プロジェクトが頓挫する可能性もあるというのは、実際ありえる話で、データが増えるという事は、イレギュラーな業務プロセスも発生する可能性が増えたり、表記のゆれの修正に時間をかける必要が出たり、過去の消費税率や、法律まで理解する必要が出たり・・・嫌
— 飯塚洋平 (@iiyohei) January 12, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) May 6, 2022
「2-20 小さなリリース単位」について考えてみます。
小さなリリースが楽か？というと、そういうわけではなく、小さくとも、短期的に業務部門を便利にし続けないといけない。なので、リリース単位をどう定義するかがとても大事だと思う#kintoneSIGNPOST#プロジェクト企画 pic.twitter.com/WIoqEbeJRm
このパターンだけ見ると、バラバラに作るのが良いの？？
— 飯塚洋平 (@iiyohei) November 27, 2021
と疑問も出ちゃうのですが、事前に「システム化のコンセプト」や「業務の流れを読む」を実施した上でって事なんでしょうね
さらに「未来の変化への備え」や「小さなリリース」単位も考える要素になりそう
出来る事をやって、出来たら渡す。というわけではなく、リリースした時点で業務部門が少しでも便利になるのか？の視点が大事である。結果的に小さくリリースする事で、自分たちのチームの自信が少しずつついていく事になる。#kintoneSIGNPOST#プロジェクト企画#小さなリリース単位
— 飯塚洋平 (@iiyohei) August 8, 2022
システム開発には失敗は付きものである。と知っているべきである。小さな単位で業務部門にリリースするという事は、業務側の確認作業も早くなり、認識に違いがあった際にもリカバリが早くなる#kintoneSIGNPOST#プロジェクト企画#小さなリリース単位
— 飯塚洋平 (@iiyohei) August 8, 2022
数珠繋ぎのアプリをいきなり使いだすより、個々のアプリが認識できる形で使いだした方が、その後のアイデアが生まれる事もある。 長文を渡されるより、付箋のキーワードを前の方がアイデアが出やすいのと似ていると思う#kintoneSIGNPOST#プロジェクト企画#小さなリリース単位
— 飯塚洋平 (@iiyohei) August 8, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 25, 2021
今日は「3-21同一ドメインから」を考えてみます。#kintoneSIGNPOST
同一ドメインで運営することで、2重管理の負荷軽減だけでなく、ブラグインのライセンスコストの低下、将来的に、開かれた情報公開や、オープンな閲覧権限設定での、高い効果を期待できる。
— 飯塚洋平 (@iiyohei) December 25, 2021
本日のキントーンSIGNPOST
— 飯塚洋平 (@iiyohei) November 26, 2021
「3-22 3つ以上のアイデア」について考えてみます。
パターンカードは、表にも裏にもパターンが書いてるので、目をつむりながらカードをひいています（笑）
今朝はひいたカードが昨日と同じだったのでひき直しましたw
1/44の連ちゃん確率。。。#kintonesignpost pic.twitter.com/paYZpqpGUs
そもそも「批判的思考」ってイマイチ分からないので、wikipedia で調べてみました。
— 飯塚洋平 (@iiyohei) November 26, 2021
クリティカル・シンキングと同列にある言葉みたいですね。
「単に否定的になるのではなく、自身の論理構成や内容について内省することを意味する」
なるほど
1人で３つ以上必ずアイデア出そう。って事よりも、イラストにある様に、3人寄れば文殊の知恵や。批判的思考で自分から出てきたナイスアイデア！を疑ってみたり、一晩寝かしたり、そんな事も含めてなのかなと思います。
— 飯塚洋平 (@iiyohei) November 26, 2021
もっと気軽にいうと、この案どう思う？って聞ける仲間がいるのも大事
本日のキントーンサインポスト！
— 飯塚洋平 (@iiyohei) December 16, 2021
「3-23 図に描く」
今日はこれについて考えてみます。#kintoneSIGNPOST pic.twitter.com/V3jPfTJe03
関係者で共通認識をしっかり持つためにお絵描きするのは大事だと思います。その時に意識してるのは、A4一枚とか、パワポ一枚とか、一枚でまとめられる範囲や粒度から認識合わせる事。エクセル一枚だとNGで、スクロールなしで皆で認識合わせられるのが大事
— 飯塚洋平 (@iiyohei) December 18, 2021
本日のkintoneSIGNPOST！！ 「3-24 ストック情報中心設計」について考えてみます。#kintoneSIGNPOST pic.twitter.com/FtrRTMv5Ap
— 飯塚洋平 (@iiyohei) January 5, 2022
フロー情報よりストック情報の方が大事だよって事ではなくて、kintoneをデータベースとして利用して、PDCAを回すのであれば、Cで分析するためにはストック情報が大事となる。#kintoneSIGNPOST#設計と構築#ストック情報中心設計
— 飯塚洋平 (@iiyohei) August 9, 2022
本日のキントーンサインポスト
— 飯塚洋平 (@iiyohei) December 13, 2021
「3-25 プロセスのシンプル化」について今日は考えてみます！
カードめくった瞬間に松田さんの顔が浮かぶやつですなw#kintoneSIGNPOST pic.twitter.com/ammSkb7iUd
プロセス管理で実現するか以前に、業務フローをなるべくシンプルに捉える様に心がけてます。概要レベルで描く。
— 飯塚洋平 (@iiyohei) December 14, 2021
そのプロセスに何人が関わっているか、動いている書類やファイルは何か？そのレベルからの洗い出し。
業務部門では、申請書ごとに別々の業務フローを定義しているケースもありますが、大きくまとめると、１つのフローになりませんか？という事にもなる。
— 飯塚洋平 (@iiyohei) December 14, 2021
結果的にkintone化した時に今まで別々に確認していた業務進捗が、まとめて確認できるというメリットにもつながる。
おはようございます！
— 飯塚洋平 (@iiyohei) November 27, 2021
本日のkintone SIGNPOST
「3-26 担当別アプリ」
今日はこちらを考えてみます。#kintonesignpost pic.twitter.com/iPP787tMol
このパターンだけ見ると、バラバラに作るのが良いの？？
— 飯塚洋平 (@iiyohei) November 27, 2021
と疑問も出ちゃうのですが、事前に「システム化のコンセプト」や「業務の流れを読む」を実施した上でって事なんでしょうね
さらに「未来の変化への備え」や「小さなリリース」単位も考える要素になりそう
1つのアプリを多くの人が使うことももちろんあると思うのですが、kintone導入初期は、ある人の業務に絞って業務改善するのもありだと思います。その時に次のプロセス担当者の業務に影響がない事を心がける。一人が便利になるために、他の人の不便を起こさないのが大事かなと。
— 飯塚洋平 (@iiyohei) November 27, 2021
そーいう意味で、誰かからデータをうけとり、誰かにデータを渡す。
— 飯塚洋平 (@iiyohei) November 27, 2021
という業務の切れ目を注視するのって大事。
あと大事にしてるのは
— 飯塚洋平 (@iiyohei) November 27, 2021
何を便利にするか？より、誰を便利にするか？を明確にイメージできるか
担当別アプリベースで業務運用を開始しても、そのままのアプリ構成でプラグインやカスタマイズを活用してつなぐ事をいきなり考えるだけでなく、担当間の連携の要件が明確になったタイミングで、アプリを再構築する事も候補として考える#kintoneSIGNPOST#設計と構築#担当別アプリ
— 飯塚洋平 (@iiyohei) August 15, 2022
アプリ開発に慣れていない部署や、トライアル期においては特に担当別アプリから始めるのが良い。
— 飯塚洋平 (@iiyohei) August 15, 2022
複数部門の要件をまとめるのは、思っている以上に時間がかかるケースがあるからである#kintoneSIGNPOST#設計と構築#担当別アプリ
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) March 5, 2022
「3-27 親子アプリ」について考えてみます！#kintoneSIGNPOST #レゴ#倉林セット#設計と構築 pic.twitter.com/KOsGO1RPF0
親子アプリという言葉もよくて、親子アプリ化するって事は、子アプリを複数つくる事も考え出してるんですよね。
— 飯塚洋平 (@iiyohei) March 5, 2022
親になった瞬間に、「あなたの兄弟もうまれるんだよ。」って妄想しながら、このイラスト見ると、さらにほっこり
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) January 8, 2022
今日は「3-28 最軽量のアクセス権設定」について考えてみます。#kintoneSIGNPOST pic.twitter.com/H1u0R06bCO
まずはkintoneでどういうアクセス権設定ができるのか、正確に理解するのが大事。そして、一度設定したアクセス権も変更する場面が必ずある。という前提で検討するのが良い。
— 飯塚洋平 (@iiyohei) January 8, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 20, 2021
「3-29 ほどほどのUIカスタマイズ」について、今日は考えてみます！#kintoneSIGNPOST
ほどほど、、が難しいと思いますが。。
— 飯塚洋平 (@iiyohei) December 20, 2021
カスタマイズにか限った話にすると、”UIカスタマイズは止めときましょう。”ぐらいのスタンスで進めた方が割り切りが出来て良いと考える。自分がカスタマイズ苦手なのももちろんありますが(笑)。このUIじゃ業務が回らん！ぐらいまで議論してからの対応で良いかと
「このUIじゃ業務が回らん！ぐらいまで議論してから」
— 倉林一範 (@kurabayashikobo) December 21, 2021
まさに！議論しつくしたいですよね。結果的にその方が早かったりするし😊
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) May 16, 2022
「3-30共通マスタアプリ」について考えみます。
共通マスタを作るということは、自分が知らない業務に触れるチャンスだと思います。部門を超えてkintoneについて会話できるし、人のつながりも作ることができる。https://t.co/doqvhueVHy
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) March 24, 2022
「3-30 共通のマスタアプリ」について考えてみます！#kintoneSIGNPOST#設計と構築#共通のマスタアプリ pic.twitter.com/Qw0NeL26ha
共通マスタアプリづくりのワークショップとかやったら楽しそう。
— 飯塚洋平 (@iiyohei) May 16, 2022
マスタアプリはアプリを設計するだけでなくて、
— 飯塚洋平 (@iiyohei) March 25, 2022
マスタ更新の業務フローの設計も大事だと思います。
マスタアプリ更新を考慮して、krewSheet導入を決めたこともありました。
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 12, 2021
「3-31 性能への気遣い」について、今日は考えてみます！。#kintoneSIGNPOST
まずは何が性能に影響するかを知るのが大事
— 飯塚洋平 (@iiyohei) December 13, 2021
kintoneはWebシステムなので、アプリのデータをとってくる量が多ければ、通信量が増えて表示までの時間がも増えていってしまう。
プラグインやカスタマイズの処理も、対象データが多ければそれだけ時間がかかります。
ポータルにグラフを並べて、ダッシュボード的に使う場合も、対象レコードが多いと、ユーザーは毎回処理に待たされる（多少の時間でも）ので、レコードを絞り込んだり、本当に必要としているユーザーが見る時のみ処理を走らせるなど考慮が必要かなと思います。
— 飯塚洋平 (@iiyohei) December 13, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 8, 2021
「3-22 開発環境の用意」
これについて考えてみます。#kintoneSIGNPOST
使って楽しい、つくって楽しいをkintoneを知って貰うためには、自由に使える環境も用意したい。
— 飯塚洋平 (@iiyohei) December 8, 2021
実際に動いているキントーンでは、権限周りや、通知、スペース設定変更など、実務に影響がでる場合も多い。
開発環境を登録して、サポート用に僕のアカウントも作ってもらう。って事をよくやります。
本日のキントーンサインポスト！
— 飯塚洋平 (@iiyohei) December 11, 2021
「4-33現場代表」
本日はこれを考えてます。#kintoneSIGNPOST pic.twitter.com/adIhfrnaci
矢内さんが、業務改善には3人の立場の人が必要と言っていた事がある。あれは名言
— 飯塚洋平 (@iiyohei) December 13, 2021
①キントーンが詳しい人 ②業務が詳しい人 ③業務ルールを変えられる人
このサインポストだと②の方がイメージに近いですが、③の人もとても大切だと思う。
哲さん、補足よろしく@ty_mgtockintone
本日のkintoneSIGNPOST
— 飯塚洋平 (@iiyohei) December 9, 2021
「4-34 アプリ発見の工夫」
こちらを考えてみます！#kintoneSIGNPOST pic.twitter.com/ezkn8PtUiR
これはね。。。手を抜いてしまうやつです。
— 飯塚洋平 (@iiyohei) December 9, 2021
スペースにテキストリンクで業務単位のアプリリンク作る程度
途中からアイコン置くと、逆に迷わすよな。とか、作業時間帯も気にしないとな。。と手つかずに。
はい。言い訳です（笑）
こうならない様に、はじめからアプリの動線も意識するの大事です。
反省
アプリ発見という言葉から、kintone内部での工夫と受け取れるが、それだけではなく、アプリまでの導線を整えるかが大事。何をきっかけにkintoneを見ようとするのか？メールだったり、社内ポータルだったり、時にはFAXやTELもある。そこから迷わず、探さずアプリや対象レコードを発見できるか工夫する
— 飯塚洋平 (@iiyohei) January 16, 2022
「4-34 アプリ発見の工夫」も対策の１つですが、kintoneの外側でのプロモーションや意識付けがとても大事だと思います。
— 飯塚洋平 (@iiyohei) July 7, 2022
見ると得するよと思ってもらえるか？
素早く繰り返す、現場主体の業務改善の定着のためにも「要望箱アプリ」は大事だと思います。ただ、形式はアプリに限らずに、スレッドコメントからでも良し。どうしたら、要望を書きやすいか？を意識し続けて、コメント返しや、対応スピード感を出せる運用体制をつくるのも大事です
— 飯塚洋平 (@iiyohei) December 25, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 23, 2021
「4-36 利用率の把握」を今日は考えてみます。#kintoneSIGNPOST pic.twitter.com/XRyJ2cbmnY
利用率の把握としては、kintoneにどれだけの人がログインしているか？、アプリがどれだけ使われているか？
— 飯塚洋平 (@iiyohei) December 24, 2021
レコードがどれだけ追加されているか等で把握しています。kintoneへのログインが少ない場合には、定期的に社内プロモーションかけたりなど定着するまでの活動が必要になる。
kintone利用が広まった上で、部門ごとの利用方法に大きく差が出てくる場合は、利用されてないアプリの断捨離や、ライセンス費用の削減も検討にいれる。
— 飯塚洋平 (@iiyohei) December 24, 2021
例えば、10人分のkintoneライセンス費用をプラグイン費用に転換させる事で、全体の便利さが向上させる事も提案できる
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) January 26, 2022
本日は「5-37 継続的な振り返り」について考えてみます。#kintoneSIGNPOST#運営 https://t.co/LZluch9XPB pic.twitter.com/aotbtNYOgd
何事もやりっぱなしではなく、定期的に立ち止まり振返る事が大事。リリースした時点で振返りをスケジュール化しておいた方が良いと思います。導入時のコンセプトや、定量的な目標を設定しておくと、振返り時に評価や判断がしやすい。振返りの際には次の目標を明確にしておく事も大事
— 飯塚洋平 (@iiyohei) January 26, 2022
振り返りは何事にも大事！
— 飯塚洋平 (@iiyohei) December 6, 2021
走り続けるだけでなく、一度立ち止まって振り返る事で新しい気づ期が生まれると思います。新しい改善策や課題もそうですが、自分たちがやってきた業務改善の成果を客観的に評価する事も大事。
チームに自信をつけるためにもふりかえりは大事
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) January 25, 2022
「5-28 専門家への相談窓口」について考えてみます。#kintoneSIGNPOST#運営 https://t.co/Ytm5W3lpuo pic.twitter.com/3LKR93LJ3s
kintoneはアプリを改善しやすい反面、壊しやすいツールである。複数部署で利用が広がり始めると、お互いのアプリの影響範囲が見えにくくなり、意図せず他部署の業務に迷惑をかける事がある。
— 飯塚洋平 (@iiyohei) January 25, 2022
その為にも、専門家の存在をkintone開発者には明らかにした上で、担い手を増やすステップに進むのが良い。
kintoneはユーザーが自由にアプリを作成したり、変更できるのが魅力ですが、その反面、アプリを壊す事も、データを壊す事もできると言える。
— 飯塚洋平 (@iiyohei) December 7, 2021
多くの部門で使用をはじめて、お互いのキントーンの使い方が見えにくくなったタイミングで統括する部署や、情報共有する機会は必要だと思います。
特に、プラグイン、カスタマイズ、外部連携サービスを使ってる場合は、他部門のアプリに影響を与える事もあるので注意が必要。例えば、アプリID間違いで違うアプリのデータを更新してしまったり、、、などの可能性も出てきてしまう。
— 飯塚洋平 (@iiyohei) December 7, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 28, 2021
「5-39 トラブル対応フロー」について、本日は考えてみます！
#kintoneSIGNPOST#トラブル対応フロー https://t.co/X2nGZW5dZq
— 飯塚洋平 (@iiyohei) August 12, 2022
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) March 7, 2022
「6-40 担い手を増やす」について考えてみます。
これだけでも、色んな人の苦労やノウハウがありそう。#kintoneSIGNPOST #継続企画 pic.twitter.com/ojPezlweh9
担い手を増やして、社内の業務改善の拡張、継続を狙うのも、もちろんですが、自分の仲間増やしや、社内に相談相手を持つのはとても大事。孤独に頑張るよりも仲間がいた方がよい。
— 飯塚洋平 (@iiyohei) December 31, 2021
まずはkintone使っているよ。を広く発進すること、一人でも興味もつ人が現れたら勉強会を開催＆発信をこつこつ
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 15, 2021
今日は「6-41アプリ作成ルール」について考えてます。#kintoneSIGNPOST pic.twitter.com/T03gyn3ryr
kintoneを作れる人、変えられる人が増えてきた時点でルールづくりは大事になっていくと思います。
— 飯塚洋平 (@iiyohei) December 16, 2021
１つのアプリを複数部門で使っていた時に、急にフィールドが増えたり、減ったりは大事件ですが
一覧のリストの並び順が変わるだけでも、使い手としては不便を感じる事もある。
kintoneでは、kintone全体の管理、アプリ単位の管理の権限を制限する事ができるが、プラグインやアプリテンプレート追加が自由にできなくなる。kintoneを作る面白さも覚えてきたユーザーには窮屈に感じる部分も出てくるので、ある程度のゆるさをもったルールづくりが大事だと思ってます。
— 飯塚洋平 (@iiyohei) December 16, 2021
「6-41 アプリ作成ルール」にも似てると思うが、2：プロジェクト企画ステップと、6：継続企画ステップという、どのタイミングで検討するかが大きな違いに感じる。
— 飯塚洋平 (@iiyohei) December 21, 2021
プロジェクト企画時点で、ガチガチに統制をかける事を考えてしまうと、0:kintone概念理解も無視する事につながり兼ねない
まずは企画段階だし、と捉えて、致命傷にならない範囲はOKで議論をはじめる。これは絶対ダメだよね。のギリギリ部分だけは言語化しておけば良いのかなと思います
— 飯塚洋平 (@iiyohei) December 21, 2021
本日のkintoneSIGNPOST！！
— 飯塚洋平 (@iiyohei) December 26, 2021
今日は「6-42 定期的な棚卸し」について考えてみます。#kintoneSIGNPOST
アプリ数の上限を意識して、定期的にアプリを削除する。ポータルのアイコンメニューの並べ替える。アプリ名を変更するだけで使いやすさに変化が出ます。ルックアップや、関連レコード一覧の設定でのアプリ選択に少し便利
— 飯塚洋平 (@iiyohei) December 26, 2021
本日のkintoneSIGNPOST！
— 飯塚洋平 (@iiyohei) December 11, 2021
「6-43 改めて学ぶ」
これについて考えてみます。
一番好きなやつ。#kintoneSIGNPOST pic.twitter.com/lRLjhE2uhZ
kintone導入する際に一度は、仕様やカスタマイズ費用が壁になり諦めていた要件も、kintoneのアップデートや、プラグインの登場により簡単に実現可能になるケースもある。
— 飯塚洋平 (@iiyohei) December 11, 2021
一年立つと、kintoneもかなり進化していっている。hiveやdaysの様に定期的に情報収集できる場があるのは嬉しい。
ずっと学び続けるものだと思うし、SNSなどで発信している仲間に触れる事も、刺激をもらえて、学びを継続できる秘訣だとも思います。
— 飯塚洋平 (@iiyohei) December 11, 2021
よくツール導入時に目的と手段を整理しよう。と言われるが、kintoneの場合は、手段であり、kintoneコミュニティに居続けたいが目的になってたりする。