大きく2つありまして、紙で運用していた勤怠と受注案件のアナログな管理方法をなんとかしたいと考えていました。

勤怠管理は、専用の用紙に各自が手書きで記入した勤怠情報を、総務の担当者が基幹システムに手入力していました。財務情報を管理するために必要な作業とは言え、従業員約120人分の入力作業をたった2人で行っていたため、この集計に毎月1週間を費やしていたんです。

単純に手書きの内容を入力するだけではなく、夜勤など多岐に渡る勤務時間を1枚ずつ確認して、残業時間を計算した上で入力するという、挫折するくらい大変な作業でした（笑）

また、受注案件の管理は、各自が1件1件専用のExcelに入力、出力して、発行部門と総務、社長に回覧し、部門長の決裁が完了すると、最終的には総務の担当者にてその内容を基幹システムへ転記していました。さらに、全体を管理するための専用の台帳に手書きで追記していくという、独自の運用方法をとっていました。

そうですね。だいたい年間で2000件くらいあって多い時で3000件くらいあるので、いざマネージャー陣が、今どれくらいの工事が動いているかを確認したい時は、この全体台帳を全部開いて見ていくしかありませんでした。

どちらも聞いたことはありませんでしたね。今までの運用が当たり前になっていたのだと思います。とはいえ、世間でDXが話題になる中で、当時の運用方法から脱却する必要があると僕は考えていました。

DXといっても、僕の考えるDXって見える化なんですよ。見える化って、見えるようにすることが目的ではなくて、見えてから各自がどう行動するかが大事で、まずはそれを考えられるような環境にしたいと考えていました。そのひとつの手段としてkintoneが最適と思ったんです。

展示会でkintoneと出会い、勤怠と受注案件管理、両方のデータをkintoneに集約できそうなこと、また、そのデータをCSV形式で書き出すことで、基幹システムへの入力時間を削減できそうだなと感じました。運用フローのイメージを持てたことが要因で、導入に踏み切りましたね。

ただ、DXによって見える化を実現するためには従業員みんなで使わないと意味がない、とも考えていたので、全員が関わる勤怠から手をつけることにしました。

最初は検証も兼ねて5ユーザーで運用スタートしました。まずは勤怠をアプリ化するために試行錯誤していたのですが、夜勤や夜勤明けの休暇など多様な勤務体系に適用するためにはフィールド^※の設定が難しく、なかなかアプリを完成させて全社展開できずにいたんです。

ただ、2020年のアップデートでIF関数^※が使えるようになったことで状況が劇的に変化しまして、思い描いていた形でアプリを完成させることができました。

その後、受注案件管理についてもアプリ化を進めたのですが、勤怠アプリの作成を経たことでノウハウが蓄積されていたため、割とすぐに作成できましたね。

全従業員に向けて説明会を行い、その後、助走期間として2ヶ月を設けました。その間は、今までの紙運用と並行してkintoneにも入力してね、という方針にして、スタートラインを低く設定しましたね。みんなの気持ちを整える期間というか。

説明会資料にはkintone化する業務が何か、だけでなく、基本的な使い方や全体の運用フローについてと、kintone化した各業務のアプリに対してサポート担当者を記載しています。

全てのアプリを作成し、説明会で話をするのは僕だけど、実際の問い合わせは各アプリのサポート担当者に聞いてね、ということです。サポート担当者はアプリ化された各業務を元々こなしていた人を配置していまして、受注案件管理については担当していた安彦に、勤怠は勤怠管理を担当していた者にお願いしました。

僕自身現在は監査役ですが、総務部門に長く居て、総務や会計等の業務を経験し、管理業務の流れは把握しています。ただ、各業務のスペシャリストを問い合わせ先にした方が使う側も安心じゃないですか。

なので、受注台帳アプリは転記作業を行っていた安彦をサポート担当にして、勤怠アプリについては勤怠の確認・入力作業を行っていた者を担当に抜擢しました。

全社展開する前に受注台帳アプリの担当と岸さんから言われて、アプリの説明を受けた時は「難しそう…私に使いこなせるのかな、みんなにちゃんと教えられるかな」と、私自身、ITの知識は高校の授業の一環で受けたぐらいだったので、不安はありました。

でも、自分でアプリを触っていく中で「こんなこともできるんだ」といった発見があって、どんどん楽しくなっていきましたね。みんなに教える立場になることが前提ですので、間違ったことを教えてはいけないし、何を聞かれるかも想定しながらだったので必死でした。

そうですね（笑）当時は大変でしたが、今は他のアプリ担当者3人で切磋琢磨しながら新しいアプリの作成や改修を行っています。実際にアプリを作ってみて、うまくいかないところを相談して、こういう方法もいいんじゃないか、とか、いろんな観点から意見を言い合っています。

まさにそうですね。継続していくために担当者が変わることは当然のことだと思っています。

紙の枚数も各業務に要していた時間も削減されました。現在の運用になってから勤怠と受注台帳の紙は廃止されましたし、保管しているのは過去のものだけです。

勤怠の部分でいうと、総務の担当者側は、各自で入力されたデータを書き出して基幹システムに読み込むだけになったので、2人で1週間かかっていた作業がワンクリックで済むようになりましたね。入力する側は、手書きがなくなったことで、わざわざ現場から会社に戻ってくる必要もなくなりましたよ。

受注案件管理の部分だと、紙での出力が無くなったことで、回覧が不要になり、タイムラグが解消されました。全体台帳への転記も不要になったので無くなりましたし、全体の工事件数を確認する際、マネージャー陣は全体台帳を全部広げて確認する必要がなくなりました。

目に見えるでいうと、見える化できたことで生まれた効果がありますよ。

今までは紙での管理だったので、誰が出張に行っていて誰が休んでいるのか分からず、部門内でも把握できない状況でした。それをkintone化したことで、ポータル画面に出張や休暇情報をカレンダー表示で見えるようになったので、一次の電話対応を対応する人が案内しやすくなりました。また、休暇申請を出しやすくなったようですね。

あとは、誰が何時間残業しているのか分かるので、現場責任者や上長が部下に対して「今月ちょっと多いね」と声がけしているようです。見えるようになったおかげで自然とそういう声がけができるようになっているので、意図していた見える化に近づいているのかなと思います。

そうですね。勤務体系によって係数を変えたり、夜勤や早朝勤務などいろんなパターンにも対応できるように頑張りました（笑）また、工事ごとの収支管理を行うために工数管理を行う必要があるので、勤怠には工事番号を登録してもらっています。

最終的には、kintoneからCSVに書き出して基幹システムに読み込む運用にしていますね。

はい、同じ運用方法ですね。レコードの内容は入力する側が違和感を感じないよう、基本的な入力情報はあまり変えず、同じような作りにしています。

金額が決まらないで進む場合もあるので、必須項目は工事番号と件名くらいにしています。工事番号は種類別で過去の情報を関連レコードで表示させているので、それを参考に入力してもらっていますね。

また、入金状況を各会計担当者が入力する仕組みにしているので、レコードを見ると請求や入金がいつされているのかも全部わかるんですよ。

社員であれば無料で宿泊できる福利厚生施設がありまして、その予約状況を管理するアプリを作成しました。アプリは２つありまして、申し込みと予約状況確認とで分けています。

予約したい人は、申し込みアプリに必要情報を入れて申請します。すると私に申請内容が回って来るのですが、申し込みが来てから1週間は、ほかの希望者がいないか待つルールがあるので、1週間後の日付を自分で入れて保存し、1週間後にリマインド機能で私に通知される設定をしています。

そんな機能まで教えてないんだけど（笑）

リマインダー機能があればいいのにと思って、ヘルプを見ていたらできそうだと思って自分で設定しました（笑）とっても便利ですよね！

申し込みアプリは、プライベートな情報なので、本人と私しか見られない設定にしています。予約状況を確認するアプリの方はみんなが見られるように設定していますので、申し込みから1週間後、予約が確定したら私の方で申し込みアプリから最低限の情報を転送させて、リアルタイムな予約状況を確認できる仕組みにしています。