カスタマインでハマる、思いやりの沼
こちらCustomine(カスタマイン) Advent Calendar 2024
12/2の記事になります！！
カスタマインは、思いやりでできている
と、思うことがあります。
構築のしやすさ、そしてそこからくる効果の大きさ。
また「やること」一つの中に細かい調整があることに気づくと、利用者のことを考えて開発されているんだろうな、といつも感じています。
▼ カスタマインでハマる、思いやりの沼
kintoneアプリ開発者である私たちも同じです。
「こういうミスが多いからこうやって補おう」
「こうすれば見やすい、入力しやすいアプリができる」
「もっと便利にするためには…」
そんな試行錯誤を繰り返し、利用者にとって使いやすいアプリを作り上げることが、業務改善への第一歩だからです。
そんな利用者に対する思いやりが、アプリ開発のスピードや精度を上げる原動力になっていることも事実です。
カスタマインを使い込めば使い込むほど、「便利」なアプリができます。
一方で、
「どこまでやればいいんだ」と思うのも事実です。
やりすぎはメンテナンスの負担が増えるかもしれないし、システムでカバーしすぎると、本来人が気をつけるべき意識が育たなくなる懸念もあるからです。
そんな葛藤を抱えながら仕事をしていると、「思いやりの沼」にどっぷりハマっている自分に気付いてしまうのです。
▼ 当社のkintoneの歩み
当社は2020年コロナ禍に在宅勤務ができる環境を作るためにkintoneを導入しました。
当初はkrewを使ってバックオフィスでのデータ管理を中心に利用していましたが、トヨクモシリーズの導入で営業や品質管理部門、カスタマインの導入によって製造部門へとkintoneの社内利用が広まっていきました。
当社のkintone導入以前の売上や在庫などのデータの管理の多くはノートに手書きで行っていました。
そのため、すべてをkintoneに変えてしまうと戸惑いや拒否反応が起こることを想定し、入力作業も私が担当。
そこから徐々にkintoneにも慣れてきて、本来の担当者へと入力作業を引き継ぐことになります。
この入力作業の引継ぎこそが当社にとっての社内利用の拡大であり、製造部門まで広げていけたのはカスタマインでの入力補助や制御があったからに他なりません。
▼ 製造・在庫管理でのkintoneとカスタマイン
当社の製造・在庫管理の業務フローの一部で、
原料が入荷し、製造するまでのフローとその中でkintoneとカスタマインをどう使っているか、業務フローの前半と後半に分けて紹介します。
原料入荷～在庫反映までのフロー
前半部分は原料入荷～原料在庫表に反映するまでになります。
もともとこれらはすべてノートで管理していました。
仕入管理ノート
試験結果記録ノート
作業日報
具体的な内容はここでは割愛しますが、まず第1段階としてこれらをkintone化し、「原料入荷管理アプリ」で原料の発注～入荷～試験適合までを一元管理するようになりました。
kintone化した後の業務フローは次の通りです。
原料入荷後受入担当者が入荷「済」にチェックを入れる
品質管理部が受入試験を行い、合格であれば「適合」にチェックを入れる
入荷・製造による原料の出納を管理する「製造記録アプリ」に転記
そして第2段は「原料入荷アプリ」にカスタマインを設定し、さらに使いやすく、業務に生かせる機能を追加しています。
このアプリでカスタマインを使う目的は主に2つあります。
入力を補助する
監査証跡を残す 他
入力の補助はその名の通りいろいろな入力がしやすいようなカスタマイズを入れていますが今回は省略させていただきます。
監査証跡を簡単に説明すると、時系列に沿って操作や事象、その結果行われる処理を記録されているものをいいます。
つまり、「入荷・受入試験・在庫反映」がちゃんと時系列に沿って処理されていることを証明できるようにする、ということになります。
このアプリでやっていることは単純で、「入荷済」と「受入試験」が済んだ時に入れるチェックボックスがあり、以下の制御をしています。
「入荷済」にチェックが入らないと受入試験「適合」にチェックが入れられない
受入試験「適合」にチェックが入らないと製造記録アプリに転記できない
エラーダイアログを表示して処理をしないようにしています。
もう一点やっていることは変更履歴テーブルです。
kintoneの基本機能でもフィールドの「変更履歴」は残りますが、すべてのフィールドの変更履歴が残るため、必要でない情報まで見ないといけないことになります。
そこで、「入荷済」「適合」「転記」がされたときのみ履歴を残そうと、変更履歴テーブルを作成しました。
ここでの工夫は「フィールドを編集して値が変わったとき」だとチェックボックスを連打すると無限にテーブルに行が追加されるので、
「編集画面を開いたとき」と「保存する直前」に値が変わっていた場合にのみテーブルに追加するという処理をすることで必要な情報のみ変更履歴として残るようになりました。
製造指図～製造記録入力までのフロー
後半部分は製造指図〜製造〜製造記録への入力までのフローになります。
当社にとってこの部分がこれまで1番管理が大変で課題が多かった部分です。
ここをカスタマインの導入によって改善に手をつけられたことはとても大きいことでした。
ここでは「製造指図アプリ」と「製造記録アプリを作成」し、これらのアプリでカスタマインを使う目的は主に2つあります。
入力ミスを防ぐ
スマホでの使い勝手 他
これまでの業務の流れは次のとおりでした。
製造管理者が製造スケジュールを組む
各品目の製造ごとに「製造指図書」を作成
製造スケジュールと製造指図をもとに製造開始
製造現場は1日の業務後「製造記録」「日報」を記入
翌日管理者が前日の製造記録・日報をチェック
そして経理では1ヶ月分の製造を集計し、棚卸高の計算をする、という流れになります。
当然この製造指図と製造記録はアナログで紙に手書きの書類だったので、現場側・管理側両方に問題を抱えていました。
現場側
手書きによるロットナンバー等の記入ミス
手計算による製造高・残高の計算ミス管理側
アナログ管理ではミスを発見しきれない
データとして蓄積できないため効果的な改善が進まない
現場側の記入ミスが多いことも問題でしたが、管理側もそのミスに気付くことができないことが多く、特に監査前にミスの修正のために遅くまで残業をするということもありました。
正しい、より精度の高い製造の管理をするためにも、アナログ管理からの脱却が必須だと感じていました。
製造記録と製造指図をkintone化し、まずは入力ミスを減らすようなアプリの仕組みを作りました。
製造指図アプリ
原料在庫管理アプリを参照し、「その作業で使う現在在庫がある原料」をダイアログで表示し、使うものにチェックを入れると製造指図アプリの使用原料テーブルに入力製造記録アプリ
製造指図アプリを参照し、製造指図Noで紐付け、「指図に登録されている原料」のみをダイアログで表示し、製造明細テーブルに入力
在庫表から製造指図、製造記録をそれぞれ参照させることで、それまで単発で発生していたデータが入荷管理から製造記録まで一連のデータとして連携させることができるようになりました。
つまり、初めの入荷管理の部分で入力ミスをなくせば、そのままミスなく製造まで「入力ミス」がなくなります。
逆に言うと初めの部分でミスがあると最後までそのミスのまま進んでしまうので、この部分でのチェックは入念に行う必要があります。
もう一点、製造現場で使う製造記録アプリはスマホから入力することになるため、とにかく「見やすさ」と「入力しやすさ」にこだわって作りました。
レコードの一覧をスペースに表示する
モバイルアプリのテーブルは見にくいため、テーブルを非表示にし、レコードの一覧をスペースに表示
データ上は一つのテーブルを「使用した原料」と「製造した製品・中間製品」を分けて二つのテーブルとして表示入力ダイアログで入力
特にテーブルへの入力が増えると入力しにくく、なるべくスクローるをしなくてもいいようにフィールド入力ダイアログなどを表示して入力
正しい管理は正しい入力があってこそ。
今まで多かった記入ミスや計算ミスがなくなるように、とにかく現場に使い勝手の良いアプリというのをこだわって作りました。
▼ 最後に。ハマった沼も…？
「ここをこうしたらこっちもこうしたほうがいいかな・・・」
「これをカバーするとここが手薄になるからこっちも・・・」
「見やすさ」「入力しやすさ」などの使いやすさを追及すればするほど、いったいどこまでやればいいんだと、さらに沼にハマっていきます。
また、例えば上述した監査証跡のように、原料の入荷→受入試験適合→在庫への反映の処理をカスタマインで制御することについて、
本来ならこういうことは必要ないはずです。
入荷をしてから受入試験をするのは当たり前のことで、試験に適合でないと在庫に反映しないのも当然のことです。
つまり、当たり前を当たり前に徹底できていれば、カスタマインで制御する必要はないはずなのです。
こういう当たり前のレベルを上げていくことが、業務改善の重要なポイントであることは間違いありません。
それがシステムでいろいろなことをカバーすぎてしまうと、本来意識していなければならないこと、気をつけなければならないこと、違和感を感じなければならないことといった意識改善が少し進みにくいのではないか、と心配しています。
なのでどこまでシステムでカバーするべきなのか、どこまで人の手を残すべきなのか、考え出すと答えが出てこず、もうこれ以上やりたくないと投げ出したくなるのが正直なところです。
ただ、経営者や現場からフィードバックをもらうことがあります。
沼にハマりながらも考えに考え抜いたアプリや仕組みに対してこういった実際の利用者の声を聴いてしまうと、やはり現場や管理者、実際のアプリ使用者のことを思って作ってきたことが伝わった気がして、だんだんハマった沼もいい湯加減に感じてきてしまいます。
そしていつも「また明日も頑張ろうかな」と思ってしまうのです。
システムでできること、人が担うべきこと。そのバランスを模索する過程もまた、思いやりの表れ。カスタマインと共にハマる「思いやりの沼」は、決して悪いものではないのかもしれません。
長文お読みいただきありがとうございました。