#2 社内大学"ASC"第2回を開催しました in メタバース
こんにちは。株式会社オートシステム、システム部の「二見ヶ浦」です。
2023年4月17日に開催された社内大学、ASC(オートシステムカレッジ)第2回ですが……Gatherのメタバースで実施しました！
第1回の記事はこちらです。
■お試しメタバース
■Gatherとは
Virtual HQ for Remote Teams
Gather helps distributed teams build digital spaces that bring everyone together.
「リモートチームの為の仮想的な本社。Gatherは分散チームが皆一緒になるデジタル空間を作る助けになります。」
Gatherは「2Dメタバースオフィス」という位置付けで、離れた拠点に居る社員の方々が同じオフィスに集まっているかのように交流できる、リモートワークを支援するツールの1つになります。
■事前検証
Gatherのビデオ会議機能はグループ分けが簡単だという話を伺ったので、ASC第2回のグループワークに使えるか検証することにしました。
近寄らないと会話ができないので、最初はちょっと苦戦。プライベートエリアに入ると、エリア内の全員で会話できるようになりました。
参加者を複数のプライベートエリアに振り分けて、各参加者にアバターで移動してもらえば、数人毎のチームに分かれてのグループワークも難しくなさそうです。
ということで、第2回～第4回はGatherで開催することに決定しました！
参加者全員がスムーズに受講できるように、ASC開催前にログイン手順と操作説明の資料を配布しておきました。（当時は英語版のGatherを使用していました。日本語版がリリースされたのは、3週間後の5月9日です）
■ASC第2回を開講して
■ASC第2回の狙い
第1回は「ASCで何を学ぶか」、説明を“聞いてもらう”授業であったのに対し、第2回は「社員同士で交流する」、“話し合う”グループワークを企画しました。
自分のことを話すだけでなく、人の意見に耳を傾けられる雰囲気づくり。
オープンマインドを目指すことが、今回の目的です。
ASCの司会、システム部の「スオミ」の自己紹介から始まり、セピア色の黒歴史を披露されていたのですが……私はその裏でネットワークトラブル対応に追われていました。
■リモート会議の為にデスクを離れ、ネットワーク障害
「リモート会議に参加する為、各々のデスクから会議室に移動する」という予定外の動きがあり、ネットワークの切り替えに手間取りました。
システム部は普段から各々のデスクでリモート会議に参加している為、「リモート会議の声で周囲に迷惑を掛けないようデスクを離れる」という意識が盲点でした……。
■グループワーク：自己紹介
障害対応の為、グループワーク開始から少し遅れてプライベートエリアに合流。
このグループワークでは各自5分の自己紹介の後、自分の次の方が自己紹介された内容を聞き取り、kintoneの「ASCメンバーリスト」に登録することになります。
普段は仕事の話しかできない方（私自身も含めて）や、事業が違う関係で顔を合わせたことが無かった方の人となりを知る良い機会になりました。
■グループワーク：普段の困りごと
次のグループワークでは、各グループで普段の困りごと、改善したい部分のアイデア出しと、その発表を行っていただきました。
その結果、20分のグループワークだけで、改善活動に繋がるアイデアが23件も提出されました。凄いです。システム部で要望が来るのを待っていただけでは、これほど多くの要望が表に出ることは無かったと思います。
これらのアイデアを形にできれば、きっと大きな業務効率化に繋がるはずですが……残念ながらシステム部の5名だけでは、出していただいたアイデアの全てをすぐに実現することは困難です。
だからこそkintoneについて学び、これらの改善活動を自らの手で形にできる環境を作り出すことが、ASCにおけるデジタルスキル教育の目標となります。
発表していただいたアイデアは、kintoneの「できたらいいなリスト」に記載していただきました。改善活動のアイデアを読み返せるようになること、kintoneに登録された改善活動の進捗が見えるようになることが今後の改善活動に役立つよう、ASC後も「できたらいいなリスト」の稼働を継続させたいです。
■講座：業務分析の手順
kintoneアプリを作って業務改善に取り組む前に、現状のフローがどうなっているのか、そして改善後のフローをどのようにしたいのか、整理すべきというお話。
現場からの要望を鵜呑みにして、背景を調べることなく改善活動に取り組もうとして、しかし品質などの関係で効率化（省略）できないため開発中止……。
このような先走りによるミスは、システム部でも頻繁に起きています。
システム部の掟にしたいほど重要な話でした。
現状の業務フローの把握
その案件に関わっている部署がどこで、モノやデータがどこからどのように流れているかの把握。
改善したい現状の問題がどこから発生しているか把握しなければ、問題の元を断つことができません。要望以前に業務フローそのものに問題がある、という場合も多々あります。（責任者を通さず、現場判断で行われているなど）現状の業務フローに決まった経緯の把握
責任者と目的の把握。改善案が目的に反していないか確認する必要があります。本当に改善すべき原因の把握
業務フローの上流で原因を食い止めることができれば、下流で問題が発生してから対応する業務フローを運用する必要が無くなります。理想の業務フローの作成
要望を鵜呑みにするのではなく、全体図（業務フロー）を把握した上で全体最適を考えます。
■業務フローを図に起こす労力
「現状の業務フロー」や「理想の業務フロー」をアップロードする枠も
kintoneの「できたらいいなリスト」に設定していますが、kintoneにアップロードされた業務フローは、講義から1か月で1件のみです。
この講座の後、私がkintoneで業務改善を行う案件もあったのですが……現状の業務フロー及び経緯・原因の把握はしっかり行ったものの、業務フロー図作成をすっ飛ばしてkintoneアプリを作成しました。ごめんなさい。
言い訳しますと、現状と理想の業務フローはテキストファイルに書き残しています。kintoneでアプリを作るより、Excelなどで業務フローを図を書き起こす方が数倍時間を食われるのですよね……。
業務フロー図、気軽に作れるようになればいいのですが。
■まとめ
「現状を把握した上で、改善活動への取り組みを始める」
この業務分析、問題定義は非常に大事な部分ですが……システム部もまだ不十分なところなので、今後一緒に学んでいくとして。
「色々なことを話し合える」
活気のある、意見を出し合える雰囲気が感じられたなら、ASC第2回は成功と言えるのかな、と思っています。
アイデアは沢山いただけましたので、それを形にできると知っていただけるように、今後もASCの取り組みを続けます。
最後まで読んでいただき、ありがとうございました。