新卒１年目で業務改善プロジェクトに参加したら苦難だらけだった話

アドプラットフォーム事業で業務改善を行なっている24新卒アプリケーションエンジニアのなおっちです！私は新潟が地元なのですが、今年はあまり雪が積もらなかったようです。昔はよく家の前でかまくらをつくっていたのですが、今はかまくらを作れるほどの雪がないようで物悲しく思っています。

話は変わりますが、最近、配属されてから7か月間行なってきた業務改善のプロジェクトが終了しました！そこで今回は、新卒として業務改善チームに配属されてからの苦難についてお話ししたいと思います。今では業務に貢献できるようになってきましたが、最初の頃は何もわからず大変なことが多くありました。業務改善のプロジェクトで右も左も分からない状態に対し、どう対応してきたのかについて詳しくお話ししたいと思います。

プロジェクトについて
大変だったこと
学び・得られたもの
まとめ

プロジェクトについて

アドウェイズでは、社内申請をするためのアプリケーションをkintoneに用意しています。この中の1つのアプリが、合計17個のプロセスで成り立っており、非常に複雑でした。特に営業の方々にとっては、申請するたびに手間と時間がかかり、本業の時間を奪ってしまうという問題がありました。

そこで、営業の方々が快適に業務を行えるよう、社内申請アプリを改善するプロジェクトが立ち上げられました。このプロジェクトは2024年の2月から2025年の1月まで動いており、約1年の時を経て完遂されました。

今回改善するkintoneアプリは自社サービスの費用に関わるもので影響範囲が広く、多くのステークホルダーがいました。

実際の改善内容としては、ユーザーヒアリングや影響範囲を確認して申請フロー簡略化の実現、入力項目の削減やバリデーション実装による入力ミスの削減などを行いました。最終的には、作業工数を約3分の1に削減できました！

大変だったこと

早速本題に入っていきます。新卒の私が業務改善チームに配属されて大変だったことは以下のとおりです。1つずつ詳細に説明していこうと思います。

改善する業務について知らない
ステークホルダーを一人も知らない
会議が多い
kintoneについて何も知らない

改善する業務について知らない

1つ目に大変だったことは改善する業務について知らなかったことです。

業務改善チームが、私にとって初めての配属だったわけですが、そもそも改善する業務について何も知りませんでした。業務についての理解が浅かったため、行なっている作業の意義がわからなかったり、元の業務フローのボトルネックがわからず改善提案が思いつかないなどの問題が発生しました。他にも、会議の内容を理解できないことも多々ありました。

解決方法として、業務フローを理解するために、資料や実際の申請アプリを見ていくことで、少しずつ業務内容を理解していきました。業務の内容を把握するために何度も資料を読み直し、わからないことをメモして先輩に質問する日々が続きました。

今では、会議の際に改善提案や意見を言うことができるようになり、業務理解に対して成長を感じています。

ステークホルダーを一人も知らない

2つ目に大変だったことは、ステークホルダーを一人も知らなかったことです。

今回改善するアプリは、社内のさまざまな部署(Div)やユニットの方が使用しており、多くのユーザーがいました。さらに、今回改善するのは費用に関するアプリだったので、コンプライアンスに関わるチームや計上に関わるチームとも連携する必要がありました。研修を通じて、同じDiv内のメンバーのことは知っていましたが、業務改善では他のDivとの連携がメインで、知っている人が全くいなかったのです。

それにより、問題が発生した際に聞くべき人がわからなかったり、会議中の発言者の役割がわからず発言の意図が読めないといったことがありました。

解決方法として、会議前に参加者の名前と役割を把握しておいたり、何度も会議を繰り返すことで、少しずつ関係者の名前や役割を覚えていきました。アドウェイズではコミュニケーションツールとしてSlackを採用しており、調べれば社員のプロフィールから役割がわかるようになっていて助かりました！

会議が多い

3つ目に大変だったことは、会議が多かったことです。

配属前は、エンジニアとして業務改善に配属されるため、9割くらいは開発業務だと思っていました。実際の開発業務の割合は6~7割程度で、会議が半分近くを占めている週もありました。kintoneを管理しているユニットとの情報共有、計上チームの計上作業への影響確認、ユーザへのユースケースヒアリング、チーム内での進捗報告など、どれも必要な会議ではありましたが、想定より多くて驚きました。

最初は会議の多さに圧倒され、何を話しているのかも理解できないことが多くありました。会議のスピードにもついていけず、理解できないことによって意見すら思いつかないので、ただ聞いているだけの時間が多かった印象です。

会議に何度も参加することで、慣れによって自然と話についていくことはできるようになりました。しかし、最初の頃はただ傍観していることが多く、ただいるだけの存在になっていました。

解決方法として、会議の前にアジェンダを詳細に確認しておいたり、不明点や質問事項を洗い出しておくことで、自然と発言できるようになっていきました。また、会議の中での他のメンバーの発言から、学ぶこともありました。特に、異なる業種視点からの意見を聞くことで、プロジェクト全体を俯瞰して見られるようになったことも、発言できるようになった要因だと考えています。

kintoneについて何も知らない

最後に大変だったことは、kintoneについて何も知らなかったことです。

私は学生時代、さまざまな言語で開発をしていました。研修では、インフラからCI/CD、自社サービスの研修などがありました。しかし、kintoneは触ったことがありませんでした。何ができるのか、どんな設定があるのか、どんな仕様なのか、全くの未知でした。しかも、kintoneについては、私の所属しているDivに知見のある人がいませんでした。そのため、人に聞くこともできない状況でした。

最初は戸惑いましたが、kintoneの公式ドキュメントや書籍を活用して、少しずつ理解を深めていきました。特に、kintoneの公式ドキュメントは非常に充実しており、基本的な使い方から応用的な設定まで幅広くカバーされていました。さらに、kintoneの資格を取得することで、kintoneの仕様や実現できることを網羅しました。

それにより、kintoneで実現できる範囲がわかるようになり、改善提案や、実現が難しい提案の指摘などが行えるようになりました。

学び・得られたもの

以上の大変だったことを通して得られたものは以下の通りです。

インプットの大切さ

大変だったこと4つのうち3つが知らなかったことに依存していました。 新しい業務を始めるにあたって、知らない=何もできない、に繋がってしまうことが多かった印象です。アウトプットももちろん大切ではありますが、「インプットなくしてアウトプットなし」という言葉もあるように、アウトプットのためにはインプットが必須になります。例えば、kintoneの仕様を知らなければ、他者の提案に対して実現できるか否かを答えることができません。他にも、業務を理解していなければ、その業務のどこを改善すればいいかわかりません。こういった経験を通して、インプットの重要さを再実感できました。

自主的に動くことの大切さ

今回挙げた大変だったことは、自分から何か対策をして動いたことによって解決できました。実際は、何もしなくても先輩が助けてくれることもあると思います。しかし、先輩が気づいてくれるかどうかもわからないですし、先輩も全知全能ではないので、全て解決してくれるわけではありません。自分で問題の原因を考え、原因の排除のために動く、仮説検証のサイクルが業務では重要なのだと実感しました。

業務を改善することの大変さ

業務改善というと、現状のアプリから使っていない項目や、必要のないフローを削除するだけと思う方もいるかもしれません。しかし実際は、1つ1つの削除項目に、ユーザーの作業や計上作業で問題が発生しないか調査しなければなりません。大半のユーザーには必要なくても、数人のユーザーが使っている機能があったりします。その場合、アプリに残すか、別のツールやアプリで代替機能を実現するかを、他への影響を考慮して決める必要が出てきます。それにより、今回のプロジェクトでは会議が多くなっていました。そして、この確認を1つでも怠ると、アプリ開発後に差戻しが発生することになります。今回の経験を通して、業務を改善することは簡単ではないことに気づくことができました。私たちのチームでは、これから先も業務改善をしていきます。その際に、今回の経験からの学びを活かし、プロジェクトを成功に導くことができると信じています。