- ホーム
- kintone
タグ「kintone」
「ある条件下で入力が不要なフィールドは非表示」、「記録は残したいけど変えてほしくないフィールドは編集ロック」というのが基本の使い分けだね。
なるほど！判定結果は次工程の担当者も確認したいから、ロックが合ってるんですね。
非表示にしてしまうと、内容が確認できなくなってしまいますもんね。
参照はOK・書き換えはNGという状態を作りたいならロック、不要な情報をすっきり隠したいなら非表示を使うといいよ。
状況に合わせて使い分けられるのが便利ですね！
あらゆる業種で活躍！条件分岐フィールド非表示プラグインのユースケース
これって、製造業の品質検査だけじゃなくて、ほかの業種でも使えますよね？
もちろん。ステータスが変わったらフィールドをロックしたい場面なら、どの業種でも使えるよ。
いくつか例を挙げるね。
不動産業
・「契約済み」になった物件の価格・条件フィールドをロック ・契約後に担当者が誤って売値や賃料を書き換えてしまうリスクを防げる
契約確定後に金額が変わると大問題になるから、ロックで守れるのは重要だよ。
医療・介護
・「記録確定」後の診療記録・介護記録の誤書き換えを防止 ・確定後の記録は参照できるが、内容の変更はできない状態にする
医療・介護の記録は正確さが命だから、確定後はロックして記録の完全性を保つことが大切だよ。
建設業
・「発注確定」後の発注金額・工期フィールドをロック ・確定した発注内容が事後に書き換えられることを防げる
発注金額や工期は後からもめやすい項目だから、確定と同時にロックしておくと安心だね。
士業・コンサル
・「提出済み」になった報告書の内容フィールドをロック ・提出後の内容変更を防いで、提出物の完全性を担保できる
ステータスが条件を満たしたらロックされるから、うっかりミスを仕組みで防げるよ。
製造業以外でも、記録の信頼性を守りたい場面ならどこでも使えるんですね！
バージョンアップ無料！買い切りの条件分岐フィールド非表示プラグインで編集ロックを実装
ジョーさんのおかげで、ボクの悩みはきれいに解決しました！ ここで、条件分岐フィールド非表示プラグインのポイントをまとめておきます。 ▼条件分岐フィールド非表示プラグインのポイント・ステータスなどの条件に応じて、フィールドを編集不可にできる ・フィールドは表示したまま参照はOK、編集だけ制限できる ・AND/OR条件の組み合わせで、細かい制御も可能 ・同ドメイン内の複数アプリに設定できる
ジムリン、導入費用も気になってるんじゃない？
はい、聞いてもいいですか……。
これだけ機能が豊富だと、費用もそれなりにしそうで……。
180,000円（税抜）/ドメインの買い切り制だから、月額費用はかからないよ。
買い切りなんですか！
バージョンアップしたら別途費用がかかったりしませんか？
バージョンアップは無料だよ。
kintoneの仕様が変わっても継続して対応してもらえるから、安心して長く使えるね。
それは助かります！
月額もかからないし、バージョンアップも無料なら、導入のハードルが低いですね！
30日間の無料体験もあるから、まずは実際に試してみるといいよ。
まとめ：条件分岐フィールド非表示プラグインで大切な検査データを誤編集から守ろう
「検査完了後も誰でも編集できてしまい、データが書き換えられてしまう……」 「口頭で周知しても操作ミスは防ぎきれない……」 そんな悩みを抱えている人は、ぜひ条件分岐フィールド非表示プラグインを試してみてください。 ボクみたいに、ステータスの条件に応じてフィールドをロックするだけで、大切な記録を誤編集から守れますよ。 口頭ルールに頼らず、仕組みとしてデータを守る環境を作りましょう!(^^)! まずは体験版で、実際の業務でどれだけ安心できるか試してみてください。 30日間無料！ 体験版に申し込む" ["post_title"]=> string(151) "kintoneで入力後のデータを書き換えられないようにしたい！フィールドを編集不可にして誤編集を防ぐ設定を紹介" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(27) "kintone-fields-non-editable" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2026-03-26 15:59:27" ["post_modified_gmt"]=> string(19) "2026-03-26 06:59:27" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=16584" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [8]=> object(WP_Post)#5022 (24) { ["ID"]=> int(16453) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2026-03-19 11:30:53" ["post_date_gmt"]=> string(19) "2026-03-19 02:30:53" ["post_content"]=> string(12527) "
こんにちは、ジムリンです！
前回、ボクは大きな決断をしました。
「工場長の課題に集中する。追加機能は一切つけない！」
そう宣言して、なんとか同僚たちの理解を得たんです。
でも、宣言したからといってすべてが丸く収まるわけではありません。
今回は、ついに正式リリースした日のこと、そしてそのあとに起こった出来事についてお話しします。
工場長への「電話を減らすためのアプリ」が完成！リリースしたあと、正直怖かった
工場長への電話を減らす！それだけを考えて、ボクは機能を徹底的に絞り込みました。 アプリを保存して、ホッとするかと思いきや……、襲ってきたのは、えもいわれぬ恐怖感。使ってもらえなかったら……。
電話が減らなかったら……。
そんな風に、まだ起こっていないことを想像しては不安になるということを繰り返していました(..;) しかし、その日の午後、さっそく工場長がデスクでアプリを開いているのが見えたんです。 ボクは離れた場所から、固唾を飲んで見守りました。 内心ドキドキです……。 工場長はしばらく画面を見つめたあと、無言でアプリを閉じました。 やっぱりダメだったかな……(T-T) ボクは落ち込みながら、デスクに戻りました。工場長への電話が減った！？「小さな成功」が現場を変える
アプリのリリースから数日後のことです。 ボクは気づいてしまいました。工場長のデスクの電話が……鳴っていないことに！ いや、正確には「減っている」んです。 以前は午前中だけで何度も鳴っていましたが、営業や各工程からの進捗確認や納期確認の電話が明らかに少なくなっていました。 しばらくして、営業担当さんが「ちょっと確認します」と言いながら、スマホを取り出す場面も見かけました。 いつもだったら工場長に電話している内容を、営業用のスマホからkintoneにアクセスして確認できている……。もしかして……、ボクの作ったアプリが機能してる？
ボクは思わず声に出しそうになりました。 それくらい、嬉しかったんです。これって成功じゃないですか！？ 全部の要望を入れようとしなかったこと、正直後悔するときもありました。 工場長の「電話対応がつらい」という、たった一つのボトルネックを見つめたことが、ほかの人たちを蔑ろにしてるんじゃないかって。 これでうまくいかなかったらって……。 でも、今ボクは目の当たりにしているんです。 小さな成功を。変わったのは「電話の数」だけじゃなかった。広がり始める「改善」の空気
よくよく見ていくと、電話が減っただけじゃなかったんです。 現場の空気が少し変わったような気がします。 何かが、動き出しているような……。工場長からのぶっきらぼうな「ありがとう」
その日の夕方、廊下を歩いていると工場長が歩いてきました。 「お前は何も分かってない！」と激怒したあの工場長です。 アプリのリリースから、まだ一度も言葉を交わしていませんでした。 工場長の電話は減ったように見えるけど、一体どう思っているんだろう？ ドキドキしていると、工場長が立ち止まり声をかけてくれたんです。 「……ジムリンさん。」 工場長は少し間を置いてから、ぽつりと言いました。 「……電話、減ったね。」 「前にシステム導入があったとき、えらい目に遭ったから、また同じことになると思ってた。」 「今回は、とても助かっているよ。ありがとう。」 その言葉に、すべてが込められていました。やってよかった……。
ボクのやったことは間違いじゃなかったんだ！
工場長に頼らなくて済む！笑顔の同僚たち
翌日、「Excelの方が速い」と言っていたあの同僚が、興奮した様子でボクのもとにやってきました。 「ジムリンさん！さっき客先で納期を聞かれてさ、その場でkintoneで確認して即答できたんだよ。 ほら、作ってくれたアプリを使って！スマホからすぐに見られるからさ。」 「いつもならExcelで管理しているから、会社に戻って折り返し電話してたところだよ。」 「Excelのほうが作るのは速いかもしれないけど、利便性で考えるとkintoneのほうが上かも！」お役に立ててよかったです！
その場でスマホから確認するなんてナイスプレーですね！
顧客もすぐに情報を得られて、安心したんじゃないでしょうか。
同僚がアプリを使ってくれている！ボクは内心ガッツポーズをしていました。 結果的に、みんなの声を無視した形になってしまったけど、こんな風に現場が変わるなんて。 そこまでボクは予想してなかったんです。 ああ、ボトルネックを解消するってこういうことなのかも？ ボクはようやく、ジョーさんから教わったことを体感的に理解しはじめていました。次の一手は「みんなで考える」、そんな空気感を作りたい
数日後、ボクは思い切って次のステップに進むために、みなさんに集まってもらいました。少しだけ、時間をもらえますか？
会議用のデスクを囲んだ工場長や各工程のリーダー、営業担当の前で、ボクは以前描いた業務フロー図を広げました。工場長へ電話が集中する問題は解決できたと思います。
でも、工場の課題はそれだけじゃありません。
ボクは今回の取り組みで、少しずつでも改善していけば現場が変わることを実感しました。
だからこそ、ここで止まってはいけないと思うんです。
今回のアプリ制作では突っぱねたみなさんの声も、たくさんあります。
だから、次に解決したい課題を一緒に考えませんか？
「ジムリンさん、実は在庫確認をもう少し効率化したくて……。」 「Excel管理の工程管理表なんだけど、納期調整のために結構時間を使ってるんだよね。」 みんなも、今回のアプリで改善の良さを実感したんだと思います。 次の課題に対して、意欲的な声がどんどん上がるんです！みなさん！ありがとうございます！
優先度を決めながら、一つずつ解決していきましょう。
そしたらきっと、みんなの負担が軽くなっていくはずです！
生産管理システムを作って！といわれて、「何からやればいいんだろう？」という地点からスタートしたボク。 まっさらな状態から始まった改善の旅は、一つの小さなゴールにたどり着きました。【教訓】小さな成功が、チームの信頼と次の改善への推進力を生む ── 第1シーズン 完 ──
ジムリン、見ていたよ。
今回のアプリは無事、成果につながったみたいだね。
はい、ジョーさんが教えてくれたTOC理論のおかげです。
本当にありがとうございます！
今回のアプリ自体は生産管理システムとはほど遠いものだよね。
だけど、この小さな成功が現場に改善の空気を生んだはずだよ。
「こうやって改善していけばいいんだ」と思えたこと、これが工場の財産になる。
そして、次の改善への推進力になる。
それが証明されたね。
おっしゃるとおりです！ボク、次の改善の話もしたんです。
もう、わくわくしちゃって。
少しずつだけと改善を繰り返して、それが大きな生産管理システムになっていけば良いなって思っています。
あの、ジョーさん。これからもボクを支えてくれますか……？
コー・ジョーは工場の妖精。
ずっとここにいるよ。
ジョーさんは、いつものようにふっと姿を消しました。 今シーズンでボクが学んだことをまとめます。・システム設計は「全体最適」から始める ── まず業務フロー図を描いて、森を見よ ・ボトルネックを見つけ、排除ではなく「支える」ことで全体の流れが良くなる ・現場の「気持ち（Why）」を聞き、最小限の「仕様（What）」に翻訳する ・完成がゴールではなく、対話しながら育てていくことがシステム開発の本質 ・小さな成功がチームの信頼を生み、次の改善への推進力になる
ボクが作ったアプリは、スタートに過ぎません。 大事なのは、小さな成功を積み重ねて、チームと一緒に少しずつ育てていくこと。 いずれ、このアプリさえも改善が必要になるときがくると思います。 そのときも、今回学んだことを胸に、みんなの子を聴きながら前に進んでいくつもりです。 そして、ゆくゆくはkintoneで生産管理システムを作る！ ボクの挑戦は、これからも続いていきます(*^_^*) ── 第1シーズン 完 ──" ["post_title"]=> string(93) "鳴り止んだ電話とチームの新しい未来―現場を変えた「小さな成功」" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(30) "system-development-small-steps" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2026-03-26 10:19:26" ["post_modified_gmt"]=> string(19) "2026-03-26 01:19:26" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=16453" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } [9]=> object(WP_Post)#5103 (24) { ["ID"]=> int(16401) ["post_author"]=> string(2) "14" ["post_date"]=> string(19) "2026-03-07 14:31:40" ["post_date_gmt"]=> string(19) "2026-03-07 05:31:40" ["post_content"]=> string(26836) "
中小製造業で総務を担当しているジムリンです(*^_^*)
ただの総務なのに、気がついたらkintoneのアプリ構築まで兼任することになり、毎日バタバタしながら過ごしています。
製造業のことはまだまだ勉強中で、現場のみなさんに助けてもらいながら日々なんとかやっているような状態です(ﾟДﾟ;)
今日は、そんなボクのもとに届いた相談と解決につながる考え方を紹介しようと思います。
テーマは「エクセルで工程表を作ること」……なんですが、話を聞いていくうちに、実はエクセルのフォーマットを工夫しても解決しない本質的な問題が見えてきました。
同じような悩みを抱えている方にも、きっと参考になると思います。
工程管理がうまくいっていない……エクセルを使った工程表の作り方を知りたい！
ある日、他社で生産管理を担当しているBさんから 「ジムリンさん、kintoneとか工程管理にくわしいって聞いて。ちょっと相談に乗ってもらえますか？」 と連絡が届きました。 くわしいかどうかは微妙なところではあるんですが(;'∀') 「もちろんです！」とお答えして、話を聞かせてもらいました。 Bさんの悩みはこういう内容でした。うちは工程別にエクセルで納期を管理してるんですけど、最近なんか管理がやりにくくなってきた感じがして。 フォーマットが古くなってきたせいかなって思ってて、直せば改善するんじゃないかと。 手軽な作り方とか、いいフォーマットってありますか？
なるほど。やりにくさを感じてきたから、エクセルで作った工程表を見直そうとしているんですね。
これ、すごくわかる話だなと思いました。 エクセルでの工程管理は多くの現場で使われていますし、「使い続けているうちにちょっとずつ合わなくなってくる」という感覚は、ボクの会社でもよく耳にします。 ボクもそこまで詳しくないので一緒に調べてみると、エクセルで作れる工程管理表にはいくつかのフォーマットがあることがわかりました。エクセルで作れる代表的な工程管理表のフォーマット
エクセルで作る工程管理表には、大きく分けて4つのフォーマットがあります。Bさん、エクセルの工程表に適したフォーマットには、種類があるみたいですよ。
どれがBさんの会社に合いそうか見てみましょう！
| フォーマットの種類 | 特徴 | 向いている場面 |
|---|---|---|
| ガントチャート式 | 縦軸に工程、横軸に時間をとり、作業期間をバーで表示 | 進捗の視覚的な確認 |
| バーチャート式 | 作業期間をシンプルな棒グラフで表示 | 全体のボリューム感の把握 |
| グラフ式 | 出来高や生産数の推移を折れ線・曲線で表示 | 生産トレンドの追跡 |
| ネットワーク式（PERT図など） | 工程の順序や依存関係を丸と矢印でつないで表示 | 複雑な生産プロセス全体の把握 |
ガントチャートにすると、管理のしにくやが改善しそうですか？
「えっと……見やすくなれば管理しやすくなるかなって。」 Bさんの答えが、ボクはなんとなく腑に落ちませんでした。エクセルの工程表だと改善するにも限界がある？
「見やすくなれば管理しやすくなる」って本当にそうでしょうか？
なんとなく気になったので、ボクはBさんにもう少し話を聞いてみました。
工程ごとにファイルが分かれていると前の工程の遅れが伝わらない
工程別にエクセルで管理しているって言っていました、それぞれファイルがあるってことですか？
その運用だと、たとえば切削で遅れが出たとき、組立チームのファイルには反映されないですよね？
「そうです！ だから組立チームは知らないまま動いてて、後から気づいてバタバタすることがあって（苦笑）。」エクセルをガントチャートに変えたら見やすくはなりますが、ファイルが分かれてる状態は変わらないですよね？
ということは、連携部分での問題って解消されない気がするんですけど……。
「……あ。」担当者ごとに違うフォーマットでは工程全体の進捗が把握できない
「ジムリンさんが言うことはごもっとも。 うちは、工程別=チームに分かれているから、それぞれに管理担当がいるんだよね。 だから、各チームの担当者がそれぞれ使いやすいようにエクセルをいじってるんだよ。 切削チームと組立チームで、フォーマットが全然違う状態になってて。 もしかしてそれもまずいのかな？」じゃあ工場全体の進捗を一覧で見ることは……？
「できないんだよ。 全体像を誰も把握できていない状態になっちゃってて。 そういう状態で回せるようにはなってるんだけどね！ 担当者が走り回って、それぞれ確認してみたいな。」リスケのたびに手作業で修正して回る手間がかかる
スケジュールが変わったときは、どう対応してるんですか？
「リスケするときは担当者が各チームにヒアリングして回って、情報共有してからファイルを手作業で修正して……。」え、毎回ですか？！
「毎回そうだよ！もしかして、このやり方って他社さんではやってないのかな？うちはずっとそうだから、疑問にも感じてなかった（苦笑） だから、とりあえずフォーマットを変えればもう少しなんとかなるかなって思ってたんだよね。」 これ……ガントチャートに変えても、解決しないんじゃないかな(..;) Bさんがずっと抱えていた「やりにくさ」の正体は、エクセルの見た目ではなく、リスケのときの報連相やファイルの修正をすべて人が行わなければならない管理の構造にあるかもしれません！エクセルじゃ解決できない？根本的な原因は個別最適化された「管理構造」にあり
Bさん、少しだけ待ってもらえますか？
そう言って、ボクはジョーさんのいるところまで走りました。どうしたの？走ってきたの？
ちょっと聞いてもらっていいですか！？
エクセルで工程表を作成して、工程（チーム）ごとに生産管理を行っている会社の方から相談が来ているんですけど……。
本人は、工程表のフォーマットを変えるつもりだったみたいで。
ただ、話を聞いていたら、本当の問題はフォーマットじゃないような気がしてきたんです。
どんな状況なのか、くわしく話してみて。
ボクがBさんの現状を説明すると、ジョーさんは少し間を置いてから言いました。たしかに、本質的な問題を見誤っているね。
やっぱり！
でも、だったらエクセルのフォーマット以外に何を変えればいいんでしょうか？
チームごとにファイルが分かれている、担当者ごとにフォーマットが違う、全体が見えない……。
まず、これはエクセルの見た目の問題じゃないよね。
どうやら、各チームが自分たちのやりやすさだけを優先して動いているみたいだね。
つまり、個別最適化された管理構造そのものが問題なんだよ。
各チームが使いやすいフォーマットに替えたところで、チームの連携部分はなんら変わらない。
むしろ、フォーマットを替えるリソースが無駄になるだけかもね。
こうして、個別最適化された構造こそが問題だということがわかってきました。個別最適から全体最適へシフトしよう！カギを握る「TOC理論」
個別最適化が問題……。
じゃあ逆に、個別最適化じゃない状態って、どういう状態ですか？
工場全体をひとつの流れとして捉えて、全体がうまく回ることを優先する状態だよ。
これを全体最適と呼ぶ。
Bさんに本当に必要なのは、新しいエクセルじゃなく、視点の切り替えだよ。
全体最適……。
チームで動いていたらチームのことを考えちゃうのは当たり前だよね。
全体最適について理解するのに役立つ考え方があるよ。
TOC理論って聞いたことある？
いや、はじめてです……。
TOC理論とは？制約に着目して全体の流れを改善する考え方
TOC（Theory of Constraints：制約理論）は、かんたんに言うと「工場の流れを止めているところを改善すれば、工場全体の流れが良くなる」という考え方だよ。
1980年代にゴールドラット博士が提唱したマネジメント理論で、ボトルネック（制約）に注目して改善することを重視しているんだよ。
TOC理論によると、全体の成果は一番流れが悪い工程、つまりボトルネックで決まるといわれているんだ。
[clink url="https://adiem.jp/blog/toc-training-overview/"]ボトルネックに注目する？
個別最適化されたエクセル管理はボトルネックになりがち
Bさんの工場の場合、情報が伝わりにくい、担当者が走って調整して回らないといけない。
つまり、連携部分がスムーズにいっていなさそうだよね？
これが、全体の流れを悪くしている「ボトルネック」になっている可能性が高い。
連携部分がボトルネックになっている？
そうだね、ペットボトルの一番狭い部分、砂時計のくびれ部分を想像したらわかりやすいかな？
くびれが狭いほど流れが滞るよね。
つまり、工場全体の流れを良くするために、ボトルネックの狭さを改善するイメージでしょうか？
そして今回は、エクセル工程表がボトルネックなのではなくて、管理構造自体が流れをせき止めている原因ってことですか？
そうだね！
担当者が各担当者を探して、ヒアリングしてリスケして回らないといけない。
この体制が、工場の流れを止めているね。
もし、エクセルのフォーマットをガントチャートに替えても、この状態は変わらないから問題はそのまま残る……。
そういうこと。
じゃあ、本当に必要な改善は何だと思う？
連携部分がスムーズにいくことですよね。
たとえば、全工程の情報が一箇所に集まっていれば、そこをハブにすればいいので、担当者を探し回る必要がなくなります。
そのハブ上でリスケできたり、各チームに伝達できたりしたら、報連相も効率化されますよね！
そのハブには、GROW工程管理というシステムがちょうどいいかもしれない。
全体最適の視点で一元管理の仕組みを検討してみよう！
え！それって、エクセルやめなさいってこと？
エクセルでやりたいなら頑張らないといけないね。
そこに割けるリソースがあるならいいんだけど、ふつう工場って現場を動かしながら工程管理するから無理じゃない？
短期的に見るとフォーマットを替えるのが早いかもしれないけど、根本的な課題を解決して工場全体を良くしたいなら仕組みそのものを見直したほうがいいよね。
たしかに……。ちなみにGROW工程管理ってどんなものですか？
kintoneをベースにした、多品種少量・受注生産型の製造業に特化した工程管理システムだよ。
さっき話したTOC理論をベースに設計されていて、ボトルネックに着目して工場全体を最適化することを目的にしているんだ。
TOC理論がベース……！さっきの話とつながった気がします。
そう。Bさんが抱えていた問題をひとつずつ解消できる仕組みになっているよ。
まず、全工程の情報を一元管理できる。
チームごとにバラバラだったファイルが、kintone上の一画面にまとまるイメージだね。
切削チームも組立チームも、同じ画面で進捗を確認できるから、前の工程で遅れが起きたらすぐ全体に伝わる。
それだけで、Bさんが言ってた「担当者が知らないままバタバタする」問題は解消されますね。
そうだね。それから、日程計画を数クリックで半自動作成できる機能がある。
設備や人員の余力を考慮した上で、制約をオーバーしないようにスケジュールを組んでくれるんだよ。
それが自動スケジューリング機能ですね！リスケのたびに各チームにヒアリングして回る必要がなくなる……。
そういうこと。あとは、現場での実績登録がシンプルな設計になっていてね。
専任のエンジニアがいなくても、製造現場の担当者が自分たちで使えるようになっているんだよ。
中小製造業だと、システム専任の人がいないところも多いですもんね。
そうそう。kintoneがベースだから、使い慣れたら他の業務への展開もしやすいし、外部システムとの連携も比較的やりやすい。
Bさんの現場みたいに、まずは工程管理の構造を整えることから始めたい会社にはちょうどいいと思うよ。
それに、低コストで導入できるんだ。
なるほど……。
GROW工程管理を選択肢のひとつとして考えると、管理構造の仕組みも幅広く検討できそうですね！
全体最適の視点を取り入れて工程管理の構造を見つめ直そう
ボクはBさんのところへ戻り、ジョーさんから学んだことを自分なりの言葉に直して伝えました。 TOC理論のこと、個別最適と全体最適のこと、今回のボトルネックのこと。 そしてGROW工程管理のことも。 Bさんは、 「エクセルの作り方を探せばなんとかなると思ってたけど。 それって結局、自分のチームの中だけをなんとかしようとしてただけで、工場全体の流れのことは考えてなかったんだ。 そもそもエクセルのフォーマットを探している場合じゃなかったんだね。 新しい気づきを得られたよ、ありがとうジムリン！」 と言って、帰って行きました。 Bさんの表情が、相談に来たときとは明らかに違いました( *´艸｀)結局、エクセルのフォーマットは見つからなかったけれど、問題の本質に気づけたことが何よりの収穫かも！
今回の話を通じてボクがあらためて感じたのは、全体最適の視点で課題と向き合わないと、問題の本質には気づけないということです。 エクセルで新しい工程管理表の作り方を探したり、便利なフォーマットを取り入れたりすること自体は悪くありません。 でも、各チームがバラバラにファイルを持ち、情報が分断されたまま運用している状態では、どれだけ見た目を整えても根本的な問題は残り続けます。 もし今、Bさんと同じようにエクセルの工程表を使っていてリスケにリソースが割かれているなら、工程表のフォーマットの前に管理構造自体を見直してみてください。 個別最適な視点で作られた構造なら、全体最適の視点で見直すと、ボトルネックが見つかり本当にやるべき施策がわかるはずです。 そして、一元管理の仕組みが必要なら、GROW工程管理のようなシステムも検討してみるとよいかもしれませんね( *´艸｀) GROW工程管理について詳しく知りたい方がいれば、連絡お待ちしています！ GROW工程管理 資料ダウンロードはコチラ GROW工程管理 個別相談会はこちらコチラ " ["post_title"]=> string(132) "エクセルで工程表の作り方を探している方へ！工程管理で悩んでいるなら全体最適の視点を学ぼう" ["post_excerpt"]=> string(0) "" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(33) "how-to-create-a-schedule-in-excel" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2026-03-07 14:43:44" ["post_modified_gmt"]=> string(19) "2026-03-07 05:43:44" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=16401" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } } ["post_count"]=> int(10) ["current_post"]=> int(-1) ["before_loop"]=> bool(true) ["in_the_loop"]=> bool(false) ["post"]=> object(WP_Post)#5014 (24) { ["ID"]=> int(17716) ["post_author"]=> string(2) "13" ["post_date"]=> string(19) "2026-08-14 10:00:27" ["post_date_gmt"]=> string(19) "2026-08-14 01:00:27" ["post_content"]=> string(18039) "kintoneの請求書発行を、案件のステータス変更に連動して自動化したいと考えていませんか。案件管理をkintoneで運用していると、「納品完了」にした案件の請求書を出し忘れる場面が起こります。この記事では、ダブルチェックでも請求漏れが消えない理由をひも解きます。そのうえで、kintoneのステータス変更を引き金にfreeeの請求書を自動発行する仕組みを解説します。読み終えるころには、出し忘れを「気をつける」対象から外す道筋が見えているはずです。ダブルチェックしているのに、なぜまた請求書を出し忘れるのか
月末の請求業務を思い浮かべてください。kintoneの案件管理を開き、「納品完了」になった案件を上から目視で拾っていきます。1件ずつ内容を確認し、freeeで請求書を作成して発行する流れです。作業前にはチェックリストも用意しています。それでも先月、1件だけ請求書を出し忘れました。
出し忘れに気づいたのは、翌月に入金の消し込みをしていたときでした。あわてて取引先へ連絡し、事情を説明して請求書を送り直します。幸い大きな問題にはなりませんでした。経理を担当していれば、「次は大丈夫だろうか」という不安を覚える場面ではないでしょうか。
チェックリストの項目を増やしても、この不安は消えません。むしろ確認作業が増えて、月末の負担だけが重くなります。なぜ、これだけ気をつけているのに請求漏れが起きるのでしょうか。答えは、担当者の注意力とは別のところにあります。
出し忘れの原因は注意不足ではなく、「人が発行操作をする」構造にある
請求書の出し忘れは、担当者の注意不足が原因ではありません。「人が発行操作をする」という業務の構造そのものが原因です。ここを取り違えると、対策の方向を誤ります。
「人が発行操作をする」とは、次のような状態を指します。月末に担当者がkintoneの納品完了案件を目視で拾い、1件ずつfreeeの発行ボタンを押していく状態です。この一連の作業は、すべて人の手と判断に委ねられています。人が介在する手順が残る限り、うっかりは一定の確率で発生します。
請求漏れの主な原因も、この見方を裏づけます。よく挙がるのは、「作成したつもりで発行操作が抜けた」というヒューマンエラーです。加えて、受注や納品のデータと請求システムが別々に管理され、連携していないことによる反映漏れもあります。どちらも、人が手で情報を突き合わせる前提だからこそ起こります。
つまり、出し忘れをなくす鍵は「もっと気をつける」ことではありません。人の発行操作という手順そのものを業務から外すことです。次章では、なぜ確認を増やす方向では解けないのかを掘り下げます。
チェックを増やしても、出し忘れは「起きた後に気づく」だけで発生自体は止められない
チェック体制の強化は、請求漏れの発生自体を止められません。増やせるのは「起きた後に気づく」確率だけです。発生源に手を付けない限り、漏れの芽は残り続けます。
理由は、確認作業の性質にあります。ダブルチェックや確認リストは、すでに起きた漏れに気づくための事後対策です。検知の網を細かくすれば、見つかる漏れは増えるでしょう。しかし、漏れが生まれる手順そのものは変わりません。人が発行操作をする限り、検知すべき対象は毎月新しく生まれます。
たとえば、確認担当を2人に増やしたとします。たしかに見落としは減るでしょう。ただ、月末の確認工数は2人分に膨らみます。しかも繁忙期に2人とも別業務に追われれば、確認そのものが後回しになりかねません。事後対策は、担当者の余力に依存する点で不安定です。
本命は、検知を増やすことではありません。発行を人手から切り離して自動化し、そもそも操作を発生させないことです。次章では、多くの現場が頼るfreee for kintoneが、この「自動化」をどこまで担えるのかを確認します。
freee for kintoneを入れても、請求書発行のボタンは結局あなたが押している
理由は、freee for kintoneが担う役割の範囲にあります。この連携は、kintoneのレコード情報をもとにfreeeで請求書を作成できます。ただし、作成を始めるきっかけは人の操作です。読者が対象レコードを選び、実行を指示して初めて請求書ができあがります。 freee for kintoneを導入しても、請求書発行の引き金は担当者の手に残ります。kintoneのステータス変更に連動して自動で発行する動きは、本記事執筆時点の公開仕様では実現しません。まずは、この線引きを正確に押さえましょう。
手作業の請求業務が負担になっている実感は、調査データにも表れています。ラクスが2020年1月に実施した調査を見てみましょう。経理部門の手作業が多い業務の1位は「請求書などの帳票発行作業」で、57.2%を占めました（出典：経理プラス）。手で発行する手順が残れば、出し忘れは入金遅延や取引先の信頼低下につながりうる課題として残り続けます。
freee for kintoneは、請求業務を大きく助ける連携です。ただし、発行の引き金を人から外すところまでは守備範囲の外にあります。ここからは、freee for kintoneでできる範囲を具体的に確認していきましょう。
freee for kintoneでできるのはレコードを選んで請求書を作るところまで
freee for kintoneでできるのは、kintoneのレコードを選んでfreeeの請求書を作るところまでです。複数レコードをまとめて処理する一括作成も用意されています。ただし、その一括作成も対象レコードを選んで実行を指示する手動の操作です。 操作の流れは次のようになります。- kintoneで請求書にしたい案件のレコードを選ぶ
- freeeへの請求書登録を実行する
- 確認画面で内容を確かめ、作成を確定する
つまり連携の守備範囲は、「案件データを受け渡して請求書を作れる」ところまでです。詳しい操作手順はfreee for kintoneの基本操作（freee公式ヘルプ）で確認できます。作成のきっかけを人が握る点は変わりません。
ステータス変更を引き金にした自動発行は既存連携にはない
kintoneのステータス変更を引き金にした自動発行は、本記事執筆時点の公開仕様では、既存の連携に用意されていません。freee for kintoneのステータス連携は、あくまで発行状況や入金状況をkintoneのレコードへ反映する仕組みです。請求書を自動で作り出す引き金とは、向きが逆になります。 整理すると、役割は次の2つに分かれます。- freee for kintone：案件データを受け渡し、請求書を作れる状態にする
- ステータス変更を引き金にする自動発行：既存連携の外にあり、別の仕組みが必要になる
freee for kintoneの連携内容は、サイボウズ公式の連携ページでも確認できます。発行の引き金を自動化するには、この線を越える別の道具が要ります。その役割を担うのが、次章で解説するn8nです。
kintoneのステータス変更でfreee請求書を自動発行する仕組みをn8nでつくる
kintoneのステータス変更を引き金にfreeeの請求書を自動発行する仕組みは、n8nでつくれます。n8nは、kintoneと外部サービスをつなぐ自動化ツールです。人の発行操作を挟まないため、「手動から自動」への差分がそのまま出し忘れの余地を消します。 n8nを使う理由は、既存連携が越えられなかった線を越えられるからです。freee for kintoneは請求書を作れますが、作るきっかけは人が握ったままでした。n8nは、kintoneのステータス変更という出来事そのものを引き金にできます。担当者が発行ボタンを押す代わりに、ステータスの更新が仕組みを起動します。 導入の規模は、大がかりなシステム刷新を前提にしません。ただし会計データを扱うため、進め方は情報システム部門や全社の方針を確認したうえで決めましょう。必要な承認の範囲は、会社によって異なります。方針を確認できたら、まず1つの案件アプリと1本のワークフローに絞って試し、動きを確かめてから対象を広げると安全です。n8nとkintoneの連携の基礎は、エンジニアに頼らず、販売管理システムとkintoneをn8nで連携してみたでも紹介しています。既存ツールが持たない動きをn8nで補う例もあります。たとえばkintoneの在庫管理データをLooker Studioで可視化し、安全在庫割れをSlackへ自動通知するワークフローです。ここからは、仕組みの中身を3つのステップで見ていきましょう。全体像はkintoneの更新をn8nが受け取りfreeeに渡す3ステップ
仕組みの全体像は、3つのステップで整理できます。- kintoneで案件のステータスが「納品完了」に変わる
- n8nがその更新を受け取り、案件情報を整える
- n8nがfreeeへ請求書の発行を指示する
この流れの中で、n8nは受け取った案件情報の整合性を確認する役割も担います。取引先名や金額がそろっているかを渡す前に点検すれば、誤った内容での発行を防げるはずです。データが十分に整っていない現場では、この点検の手順を挟む価値が特に大きくなります。3ステップの骨格を押さえたうえで、各ステップを具体的に見ていきましょう。
kintoneの「納品完了」への変更をn8nのWebhookで受け取る
最初のステップは、kintoneの「納品完了」への変更をn8nが受け取る設定です。kintone側で、ステータスが納品完了に変わったときに通知を送るように構成します。この通知をn8nのWebhookが受け取り、ワークフローが動き出します。
ポイントは、引き金を「納品完了への変更」に絞ることです。すべての更新に反応させると、余計な発行が増えます。特定のステータスに変わった瞬間だけを引き金にすれば、狙った案件だけが処理されます。
受け取った案件情報からfreeeの請求書を発行する
次のステップで、n8nが受け取った案件情報からfreeeの請求書を発行します。案件のレコードには、取引先や金額といった請求に必要な情報が入っています。n8nはこの情報をfreeeのAPIへ渡し、請求書の発行を指示します。 この仕組みは、案件データが正しく入力されていることが前提です。入力データがそろっていない現場では、自動化の前に「請求に必要な情報を確実に残す運用」から整える必要があります。土台となるデータがそろって初めて、自動発行は安定して動きます。同じ案件で二重発行しないよう発行済みフラグで止める
自動化で気をつけたい落とし穴が、同じ案件の二重発行です。ステータスが何度も更新されると、そのたびに発行が走るおそれがあります。これを防ぐ仕組みを、あらかじめ組み込んでおきましょう。
有効なのは、発行済みフラグを使う方法です。請求書を発行した案件には「発行済み」の印を付けます。n8nは処理の前にこのフラグを確認し、すでに発行済みなら止まる設計にします。フラグとステータスの条件を組み合わせれば、1案件1発行を保てます。
請求漏れは「気をつける」対象から、そもそも起きない業務に変わる
人の発行操作を業務から外せば、請求漏れは「気をつける」対象ではなくなります。ステータス変更が仕組みを動かすため、出し忘れの余地そのものが消えます。担当者は、確認に費やしていた時間を本来の業務へ戻せるでしょう。
ここで大切なのは、kintoneを「請求データの置き場」で終わらせない発想です。案件データは、蓄積するだけでは価値が限られます。データをfreeeまで人手を介さず動かしきってこそ、「納品したのに請求していない」をゼロにできます。kintoneに眠るデータをつないで動かす考え方は、kintoneユーザーのための生成AI実践大全でも軸に据えています。
前章でも触れたとおり、連携の導入は担当者ひとりの判断だけで進むとは限りません。会計データを扱うため、情報システム部門や全社での合意が出発点になります。まずは自社で「人が発行操作をしている作業」を棚卸しし、どこを自動化できるかを整理するところから始めましょう。既存連携でできることと、n8nで越えられる線を切り分けて考えると、進めやすくなります。
まとめ
請求書の出し忘れは、担当者の注意不足ではなく「人が発行操作をする」構造から生まれます。ダブルチェックを増やしても、それは起きた後に気づく確率を上げるだけでした。freee for kintoneは請求書を作れますが、発行の引き金は人の手に残ります。 この構造を変える鍵が、kintoneのステータス変更を引き金にしたn8nの自動発行です。「納品完了」への更新がそのままfreeeの請求書発行につながれば、出し忘れの余地は消えます。請求漏れは「気をつける」課題から、そもそも起きない業務へと変わります。 まずは、自社で人が発行操作をしている作業を洗い出してみてください。どこを自動化できるかを一緒に整理したい場合は、お問い合わせからお気軽にご相談ください。" ["post_title"]=> string(114) "請求漏れを解消！kintoneのステータス変更でfreeeの請求書を自動発行するワークフロー" ["post_excerpt"]=> string(291) "kintoneの案件ステータス変更を引き金に、freeeの請求書を自動発行する仕組みをn8nで解説します。ダブルチェックでも請求漏れが消えない理由と、人の発行操作を業務から外して出し忘れをなくす考え方がわかります。" ["post_status"]=> string(7) "publish" ["comment_status"]=> string(6) "closed" ["ping_status"]=> string(6) "closed" ["post_password"]=> string(0) "" ["post_name"]=> string(24) "kintone-freee-automation" ["to_ping"]=> string(0) "" ["pinged"]=> string(0) "" ["post_modified"]=> string(19) "2026-08-14 09:19:13" ["post_modified_gmt"]=> string(19) "2026-08-14 00:19:13" ["post_content_filtered"]=> string(0) "" ["post_parent"]=> int(0) ["guid"]=> string(45) "https://adiem.jp/?post_type=blog&p=17716" ["menu_order"]=> int(0) ["post_type"]=> string(4) "blog" ["post_mime_type"]=> string(0) "" ["comment_count"]=> string(1) "0" ["filter"]=> string(3) "raw" } ["comment_count"]=> int(0) ["current_comment"]=> int(-1) ["found_posts"]=> int(41) ["max_num_pages"]=> int(5) ["max_num_comment_pages"]=> int(0) ["is_single"]=> bool(false) ["is_preview"]=> bool(false) ["is_page"]=> bool(false) ["is_archive"]=> bool(true) ["is_date"]=> bool(false) ["is_year"]=> bool(false) ["is_month"]=> bool(false) ["is_day"]=> bool(false) ["is_time"]=> bool(false) ["is_author"]=> bool(false) ["is_category"]=> bool(false) ["is_tag"]=> bool(true) ["is_tax"]=> bool(false) ["is_search"]=> bool(false) ["is_feed"]=> bool(false) ["is_comment_feed"]=> bool(false) ["is_trackback"]=> bool(false) ["is_home"]=> bool(false) ["is_privacy_policy"]=> bool(false) ["is_404"]=> bool(false) ["is_embed"]=> bool(false) ["is_paged"]=> bool(false) ["is_admin"]=> bool(false) ["is_attachment"]=> bool(false) ["is_singular"]=> bool(false) ["is_robots"]=> bool(false) ["is_favicon"]=> bool(false) ["is_posts_page"]=> bool(false) ["is_post_type_archive"]=> bool(false) ["query_vars_hash":"WP_Query":private]=> string(32) "ee16ea99092ab1b90e8f425422a26cc2" ["query_vars_changed":"WP_Query":private]=> bool(true) ["thumbnails_cached"]=> bool(false) ["allow_query_attachment_by_filename":protected]=> bool(false) ["stopwords":"WP_Query":private]=> NULL ["compat_fields":"WP_Query":private]=> array(2) { [0]=> string(15) "query_vars_hash" [1]=> string(18) "query_vars_changed" } ["compat_methods":"WP_Query":private]=> array(2) { [0]=> string(16) "init_query_flags" [1]=> string(15) "parse_tax_query" } ["query_cache_key":"WP_Query":private]=> string(41) "wp_query:f0d65757b42a424ff898c422f86e9cf6" } -->他のタグから探す
- データ保護
- 生産スケジューラ
- Box連携プラグイン
- googleanalytics
- 販売管理
- MCPサーバー
- GROW工程管理
- ボトルネック改善
- 育シス開発
- Claude Desktop
- CybozuDays
- セキュリティ
- 工程表
- 生成AI
- 工程管理システム
- Box
- エクエル
- draw.io
- ボトルネック
- プラグイン
- 生産計画
- ダイアグラム図
- TOC理論
- ファイル管理
- ガントチャート
- 添付ファイル
- TOC研修
- ファイル共有
- 工程管理表
- OCR
- ジムリン
- 業務改善
- 条件分岐フィールド非表示プラグイン
- 自動化
- 関連レコード集計プラグイン
- 検索
- 編集不可
- 会社情報調査
- 関連レコード一覧
- 絞り込み
- フィールドの非表示
- kintone
- kintoneプラグイン
- 関連レコード一覧集計
- 独自ルックアップ画面プラグイン
- claude code
- もしもシリーズ
- 独自ルックアップ
- アプリ設計
- 一文字検索
- browser use
- 生産管理システム
- ルックアップ
- ユースケース図
- 部分一致検索
- 工程管理
- kintoneアプリ
- セミオーダー型アプリ
- TOC
- ルクックアップ
- 生産管理
- バックアップ
- 製造業
- DBR
- テーブル
- 事例
- n8n
- 展示会
- バッファ
- 複数行追加
- 簡単検索ボックス・プラグイン
>全てのタグ
