- 香川大学DXラボのスタッフブログでは、DX推進の現場で活躍する学生やスタッフのリアルな声をお届けしています。
今回は、企業からクロスアポイントメントで香川大学に参画し、DXラボの立ち上げ当初から大学DXに携わってきた、DX推進研究センター 特命准教授・久我透さんへのインタビューです。
勤務時間記録システム「カダキンタイ」の開発を通じて久我さんが実感したのは、DXの課題は必ずしも技術だけではないということでした。
利用者の声を聞きながら改善を重ねること。誰が担当するか曖昧な“お見合い状態”を解消すること。そして組織の間に落ちる仕事を拾いながらプロジェクトを前へ進めること。
本記事では、企業出身者の久我さんが感じた大学DXの現場と、カダキンタイ開発を通じて得た学びについて伺いました。
教員
【DXラボスタッフに聞いてみた】教員 久我 透
DX推進研究センター特命准教授 久我 透
DX推進研究センター教授 米谷雄介
「システムを作れば解決する」——そう思って始まった勤務時間記録システムの開発で、最初に必要だったのはプログラミングではなく制度の理解でした。この記事では、企業から参画した久我さんの経験から、他の組織でも使える知見をお伝えします。開発に必要な業務知識は事業部門にしかないこと。まず最小限の機能で使ってもらうと、「毎日の文字入力が手間」といった、要望を聞くだけでは出てこなかった声を得られること。そして、プロジェクトを止めるのはバグではなく、担当が曖昧なまま誰も拾わない“お見合い状態”であること。発注者と受注者ではなく同じチームとして話せる関係をどう用意するか。内製化に取り組む方へのヒントが詰まっています。
スタッフが開発したシステムはこちらをご覧ください
※インタビュー内容の一部はMicrosoft Copilotを用いて自動要約し、一部修正を加えたものです。
自己紹介
米谷：DX推進研究センター教授の米谷です。今日はよろしくお願いします。
久我：DX推進研究センター特命准教授の久我です。民間企業からクロスアポイントメントで参画しております。企業ではメカ設計・開発業務に携わってきました。現在は、顧客の課題を整理し解決策を提案する技術営業職に携わっています。 DX推進研究センターでは、開発組織であるDXラボのメンバーとして関わっております。
カダキンタイ開発で最初にぶつかった壁は「制度」だった
米谷：DXラボで携わったプロジェクトの中で、特に印象に残っているものはありますか？
久我：やはりカダキンタイですね。
米谷：人事企画課と一緒に進めた勤務時間記録システムですね。
久我：そうです。当時は「システムを作れば解決する」と思っていたんです。
米谷：DXに関わり始めた頃はそう考えていた、と。
久我：はい。でも実際に始めてみると、最初に必要だったのはプログラミングではありませんでした。
米谷：そうなんですね。
久我：まず制度を理解しなければいけなかったんです。勤務制度は複雑で、有給休暇や勤務区分ひとつ取っても様々なルールや例外があります。
米谷：確かに外から見ると分かりにくいですよね。
久我：そうなんです。しかも、その知識はシステム開発側にはありません。事業部門である人事企画課の方から教えていただかないと理解できないんです。
米谷：まず制度を学ぶところから始まったわけですね。
久我：今振り返ると、あれはシステム開発というより業務理解のプロセスでした。DXは技術から始まると思っていましたが、実際には現場の仕事を理解することから始まるのだと学びました。
最初から完成形を目指さなかった
米谷：どのように開発は進められたのでしょうか？
久我：まず最低限使えるものを作っていきました。
米谷：いわゆるMVP（Minimum Viable Product）ですね。
久我：はい。まずは使える状態にして、人事企画課の方に実際に触ってもらいました。
米谷：反応はいかがでしたか？
久我：想像していなかった意見がたくさん出てきました（笑）。
米谷：例えばどんなことでしょう。
久我：初期のカダキンタイは、チャットボットに「勤務開始」や「勤務終了」と入力して勤務時間を記録する仕組みだったんです。
米谷：今のような画面ではなかったんですね。
久我：そうなんです。開発側としては、「文字を入力するだけなので簡単だろう」と考えていました。
米谷：実際に使ってもらうと違った。
久我：はい。人事企画課に使ってもらった際に「毎日使うものなので、文字入力が意外と手間になる」という意見をいただきました。
米谷：なるほど。1回の操作は数秒でも、毎日のことになると大きいですね。
久我：そうなんです。開発する側は機能が実現できているかに目が向きがちですが、利用者にとっては操作のしやすさの方が重要だったりするんですよね。
米谷：そこで改善につながった。
久我：はい。その後はPower Appsを活用して、文字を入力するのではなくボタンをクリックするだけで記録できるように改善していきました。
米谷：利用者の声を聞きながら育てていったわけですね。
久我：まさにそうです。この経験を通じて、最初から完成形を作ろうとするのではなく、まず使ってもらいながら改善することの大切さを学びました。
米谷：実際に使ってもらわないと見えないことがある。
久我：はい。要望を聞くだけではなく、実際の利用場面を見ることで初めて分かる課題も多いんです。利用者と一緒に改善を続けることが、結果的には良いシステムにつながるのだと思います。
米谷：利用者とのやり取りで意識していたことはありますか？
久我：要望をそのまま実装するのではなく、その背景にある課題を理解することですね。利用者と開発者では、同じ言葉を使っていても思い描いているものが違うことがあります。
米谷：認識のズレがあるということですね。
久我：そうです。だからこそ「何を作るか」だけではなく、「なぜそれが必要なのか」を一緒に考えることを意識していました。実際には、そのすり合わせの方が開発そのものより重要な場面も多かったですね。
プロジェクトを止めるのはバグではなく「お見合い状態」
米谷：カダキンタイの開発で、技術以外に苦労したことはありますか？
久我：ありますね。その中でも印象的だったのは、誰が担当するか決まっていない仕事ですね。
米谷：例えばどんな仕事でしょうか。
久我：制度の確認や利用者への説明、資料の準備などです。システム開発のタスクとしては見えにくいのですが、意外とそういう仕事が多いんです。システム開発そのものではないのですが、誰かがやらないと前に進まない仕事です。
米谷：なるほど。
久我：そして、その仕事を誰がやるのか曖昧だと、お見合い状態になって止まってしまうんです。
米谷：技術的な問題ではないんですね。
久我：むしろ人と人の間で止まることの方が多かったですね。特にDXラボは学生が中心の組織なので、開発以外の仕事がどうしても間に落ちてしまうことがあります。
米谷：その部分を久我さんが拾っていた。
久我：そうですね。企業での経験もあったので、「このままだと止まりそうだな」と感じたら、自分で引き取ったり担当を整理したりしていました。
米谷：かなり泥臭い役割ですね。
久我：そうですね（笑）。でも、そうした間に落ちる仕事を誰かが拾わないと、プロジェクトは前に進まないと考え、積極的に拾うようにしました。
発注者と受注者ではなく「同じチーム」だった
米谷：大学のDXだからこそ実現できたことはありますか？
久我：事業部門との距離感ですね。
米谷：と言いますと？
久我：一般的な開発だと、発注者と受注者という関係になります。
米谷：確かにそうですね。
久我：一方で本件は同じ大学の仲間として活動していました。
米谷：同じ目標に向かうチームだった。
久我：そうです。だから何度も相談できますし、「一緒に考えましょう」という関係が作りやすい。
米谷：それが利用者理解にもつながった。
久我：はい。要望の背景を聞けたのも、その関係性があったからだと思います。
米谷：システム内製化の強みですね。
久我：カダキンタイも、あの距離感がなければ今の形にはなっていなかったと思います。
大学という場が企業の壁を低くしてくれた
米谷：企業から大学に来て、考え方が変わったことはありますか？
久我：ありますね。大きかったのは、他組織と一緒に働くことへの抵抗がなくなったことです。
米谷：抵抗というのは？
久我：私はずっと一つの企業で働いてきたので、以前は他社の方と話すときに少し構えてしまう部分があったんです。
米谷：企業同士だとどうしてもありますよね。
久我：そうですね。でも香川大学で様々な方と一緒に活動する中で、その感覚が変わっていきました。
米谷：どのように変わったのでしょうか。
久我：実際に一緒に課題解決へ取り組んでみると、所属する組織は違っても、みんな同じように悩みながら仕事をしているんですよね。「他組織の人」ではなく、「同じ目標に向かう仲間」だと感じるようになりました。
米谷：会社の看板ではなく、一人の人として向き合えるようになった。
久我：まさにそうです。大学という同じ組織の中で働いていたからこそフラットに話せたのだと思います。
米谷：なるほど。大学ならではという視点もありますか？
久我：はい。例えば先生方と話していると、物事を学術的に整理したり、本質から考えたりする視点でアドバイスをいただくことがあります。
米谷：企業とはまた違った観点ですね。
久我：そうなんです。企業だけにいると気付かなかった考え方に触れることができました。様々な専門性や価値観を持つ人と関われることも、大学で活動する大きな価値だと感じています。
米谷：香川大学のDX推進の仕組みの中で、特に特徴的だと感じることはありますか？
久我：事業部門の方々がDX推進に主体的に関わってくださることですね。特にデジタルONEアンバサダー制度（※）の存在は大きかったと思います。利用する側と開発する側が対話しながら一緒に進められるので、課題を共有しやすいんです。発注者と受注者という関係ではなく、同じチームとして取り組める環境だったことが、カダキンタイの継続的な改善につながったのだと思います。
※DX活動を業務の一環として位置付ける制度。各部局から毎年50～60名を任命し、常勤事務職員の6割超えが経験済みの規模にまで拡大している。制度設計の詳細は、こちらの記事をご覧ください → 小寺 賢志 | 職員 | インタビュー | 香川大学DXラボ
学生が最も成長するのは技術ではなく説明力
米谷：最後に、学生スタッフの成長について感じていることを教えてください。
久我：もちろん技術力も伸びます。でも一番変わるのは説明する力だと思います。
米谷：説明力ですか。
久我：定例会や報告会で話す機会がたくさんありますからね。
米谷：確かに学生時代にそういう経験を積める場は貴重です。
久我：最初は緊張していた学生でも、1年後には見違えるほど話せるようになっています。
米谷：それは実感します。
久我：社会に出てからも必要になる力ですし、その経験が就職後にも活きると思います。
まとめ：再利用可能な知見として
久我さんへのインタビューから見えてきたのは、DXの成功要因は必ずしも技術ではないということでした。カダキンタイの開発で実際に機能していた実践を、他の組織でも試せる形に整理すると、次のようになります。
● 開発に着手する前に制度・業務を理解する。その知識は事業部門にしかないため、教わるプロセス自体を開発工程の一部として見込んでおく
● 最小限の機能で早く使ってもらい、利用者の声を聞きながら改善を重ねること。また要望を聞くだけでなく実際の利用場面を観察する
● 「何を作るか」だけでなく「なぜそれが必要なのか」を利用者と一緒に考え、同じ言葉が指す中身のズレを埋める
● 担当が決まりにくい“間に落ちる仕事”を洗い出し、組織の間で発生する「お見合い状態」を解消すること
● 発注者と受注者ではなく、同じチームとして対話できる関係と、それを支える仕組みを用意する
● 定例会や報告会などはメンバーの成長機会になる、説明する機会を業務の流れの中に組み込む
DXというとシステム開発や技術に注目が集まりがちです。しかし実際には、誰が担当するのか曖昧な“間に落ちる仕事”が存在し、それを一つひとつ解決していくことがプロジェクトを前へ進める原動力になっていました。また、利用者と開発者が対立する立場ではなく、同じチームとして課題を共有しながら改善を進められる環境も、大学DXを支える重要な要素でした。
これらは香川大学固有の事情に依存するものではなく、体制や仕組みとして設計できる要素です。私たち自身が自分たちの取り組みを振り返る手がかりとするとともに、同じ課題を抱える組織の参考になれば幸いです。