見出し画像

変革に必要なのはエンジニアの力!『BYARD(バイアード)』でバックオフィスの超難題に挑もう

こんにちは、BYARD(バイアード)と申します。
これまでは代表の武内からBYARDに関して発信してきましたが、企業としも公式アカウントを開設し、採用やサービスを中心に発信していくことなりました。

なお、武内のnote・Twitterの方も引き続き発信していきます。

公式noteの第1弾はCEO・武内とCTO・辰本によるエンジニア向けの対談をお届けします。

はじめに

製品開発を行うプロダクト、お客様に届けするセールス・マーケティングに続く第3の業務領域であるバックオフィス。未だ超アナログ状態で属人的な業務が残り続けているこの領域に、ついに変革の兆しが見えてきました。このコロナ禍でペーパーレス化が一気に進み、ようやく日本企業のバックオフィスが抱える複雑で難解な課題の全貌が明らかになってきたところです。

この課題に挑み「バックオフィスの業務の標準化」を実現するプロダクトを開発しようと1年前から取り組んでいるのが私たち『BYARD』開発チームです。

しかし、このプロジェクトはまるで「馬車しかなかった時代に自動車を発明する」ようなもの。既存のツールとは発想の異なるプロダクトを作っていくためには、もっともっとチームの力が必要だと痛感しています。

この記事では「私たち開発チームに将来入るかもしれないまだ見ぬエンジニア」の方々に向け、CEO・武内とCTO・辰本で『BYARD』の課題領域とミッション、プロダクト開発、求めているエンジニア像について語っていきます。

非同期・非線形そして複雑な協業を安全で快適に行う為に開発されたGitやGitHubを始めとするホスティングサービス。それらを取り巻くエコシステムはソフトウェアエンジニアの仕事を大きく変えました。今ではそれらなしで仕事をすることが考えられないほどです。私たちはソフトウェア開発におけるGitやGitHubのような、バックオフィスにとってなくてはならない存在になるプロダクトを創り出したいと考えています。

今回語るメンバーのプロフィール

武内俊介(たけうち  しゅんすけ)

株式会社BYARDのCEO。業務設計士&税理士で、バックオフィス×ITという領域で企業の
バックオフィス部門のツール導入から運用設計まで幅広く手がける。
趣味は読書と野球。年間100〜150冊のビジネス書を読破する。
Twitter▶https://twitter.com/Libero_shunsuke

辰本貴通(たつもと たかみち)

株式会社BYARDのCTO。メガベンチャーや金融機関でエンジニアリングマネージャを務めた後、BYARDへJOIN。兵庫県出身、福岡県在住。趣味はサウナ。
大切にしていることは「迷ったらワクワクする方を選ぶこと」。

過渡期を迎えた日本のバックオフィス特有の課題

『BYARD』の画面。タスクを可視していくと業務の複雑さが徐々に明らかになります。

武内:こんにちは、BYARDの代表取締役CEO・武内です。現在、私たちはバックオフィスを中心に日本のホワイトカラーが抱える「管理のための管理」をなくすために『BYARD』というプロダクトを開発しています。今日、私たちの話を聞いて「我こそは!」と手を挙げてくれるエンジニアが現れてくれることを期待しています。

辰本:BYARDのCTOの辰本です。僕はこのプロジェクトをとても興味深くて挑戦しがいがあるとものと考えています。難解だけど誰かの仕事のあり方そのものを変える可能性がある。それにはソフトウェア開発の現場で起こった変化がヒントになるし、テクノロジーへの適切な理解も必要となる。このあたりをぜひ伝えたいと思っています。

武内:とはいえ、バックオフィスの課題領域は非常に認識が難しい。まずその課題から話していかないといけないでしょうね。プロダクトによる解決策といえば自動化や処理を支援するものを思い浮かべることが多いと思いますが、それなのになぜ私たちが「業務プロセスの可視化と進捗管理を同じプロダクト上で行えるもの」を作っているのか。そこにつながりますから。

辰本:まずバックオフィスの業務がそもそも誤解されていませんか?

武内:そうですね、経理や人事の仕事は当たり前のように行われているからか、単純作業だと勘違いされがちです。機械的に処理するだけで完結する仕事なんて、今のバックオフィスの仕事にほとんどないんですけどね。

辰本:エンジニアの仕事がコードを書くことだけだと思われることと似ていますよね。作業の裏側に様々な確認や判断が必要な高度な仕事なのに。

武内:マニュアルさえあれば誰でもできるようなものではないんですよね。一見単純そうに見えても、たくさんのステップに分かれていたり、都度確認することが必要だったりして、しかも関係する部署が複数にまたがっていることも多い。

辰本:例えば社員の「入社対応」ひとつをとってみても、よく考えるとかなり複雑な流れですよね。まず入社の約束を交わす「内々定」がスタートでしょうか。

武内:そこから採用担当者が雇用契約をすり合わせる「オファー面談」を行いますね。その後、労務や法務による「内定承諾」「雇用契約」に進みます。会社によってはその間に採用するための「稟議」を回さないといけないかもしれない。これだけでも大きい業務が4つ。更に「各種システムのアカウント発行」「社会保険手続き」「給与計算ソフト等の設定」も必要です。社員を迎えるにあたっては「オリエンテーション」「パソコンの準備」も必要です。

一つひとつのプロセスも細かいタスクが集まってできていますから、その内訳も見ていかないといけない。例えば「オリエンテーション」を実施するなら「当日の講師を選ぶ」「講師の依頼をする」「会議室も含めて社内カレンダーを押さえる」というタスクがありますよね。

辰本:各タスクは普段は言語化されていないものも結構あるでしょうし、関わる人間も作業量も洗い出していくと、結構な数になりそうですね。

武内:しかも、一つひとつの処理に個別のコミュニケーションが発生していきますからね。確認する作業には知識が必要な場合が大半です。さらに部署間の担当者の意図があったりもするので、個別性が高くて経験も必要になる。一つひとつは単純作業のように見えるのですが、思っているよりも難易度の高い仕事です。

辰本:これらの全体進捗も管理していくっていうのがまた難しいですね。

武内:これを頭の中でそれぞれ進めていると、漏れがでたりどこかで業務が止まってたりすることがよくあります。責任感のある人がなんとかマニュアルにまとめ、たとえばExcelでタスクを大量に並べたチェックリストを作って管理しようと頑張るんです。「○月○日、コレ完了!」って進捗をポチポチチェックして回るわけです。

でも、やっぱり無理があって、ほとんど機能してくれないんですよ。みんなマニュアル通りには処理してくれないし、どんどん業務の流れも勝手に変わってシートの更新が追いつかなくなっちゃいますから。

辰本:「担当者が部署異動したらやり方変わった」みたいなこともよくありますね……。

武内:そうやって業務の属人化は進んでいってしまうんですよね。その結果「ベテランの◯◯さんに聞かなきゃわからないよ!」みたいな状況が生まれ続ける。ベテランの頭の中だけに地図がある状態になってしまっています。だから、みんなが共通の課題を言語化・認識できず「みんな何か困ってる」という状態にあるというのが現在のバックオフィスの現状であり、本当の課題だと思います。

辰本:世界的にみると日本のこの状況って、実は特殊なんですか?

武内:そうですね。アメリカなどでは転職頻度が高く、人の入れ替わりサイクルが早いので事務のオペレーションが属人化しづらいのです。それに元々オペレーション担当者とマネジメントをする人材がはっきり分かれてもいましたので、オペレーション系の作業を集めて、担当者に任せられるように業務を標準化してきていたという背景があります。

辰本:日本はオペレーション担当者も柔軟で優秀だったからこその状況でもあるでしょうね。でも、それがデジタルシフトではかなり足を引っ張っていますね。

武内:アメリカの場合は国内で行っていた事務オペレーションも、だいぶ前から賃金が安いインドなどの国外に出しています。それで、さらに標準化が進んだということです。
近年はそれらの国でも徐々に賃金が上がってきてしまったから、それに置き換えるためにRPAやAIを活用した自動化などが発展してきている。標準化されたオペレーションの土台がある分だけ、デジタル化しやすいんですよね。この状況では、いくら日本で優秀な人材が頑張っても差が開いていく一方です。

辰本:今、例に出たインドやインドネシアは若いIT人材も多いから、日本のような属人化状態を経ずに、アメリカのような標準化を実現していく可能性は高いですよね。

武内:そうなるでしょうね。だから今の日本にある課題は既に解消している、またはその状態を経ない国も多い。日本のオペレーション担当の方はとても高度で複雑な業務をこなしているのに、給料がそこまで高くなく、昇給もしづらいという問題もあります。これをなんとかしたいんです。

辰本:日本のオペレーション担当者は、すごく頑張り屋で優秀な方が多いんですよね。だから私もプロダクトの力でその優秀な方々の頑張りどころをもっと価値のあるところに充てられるサポートをしたいんです。それだけのホスピタリティと創意工夫があったら、もっと価値の高い仕事ができるはずですから。このイノベーションの実現に貢献できるというのが『BYARD』の開発に取り組む大きな価値だと僕は思います。

テクノロジーは魔法じゃない。自動化より先にすべきこととは

デジタルが得意とする単純作業の自動化は個別最適化。それだけでは全体最適は達成できません。

武内:デジタル化の進行で情報量は指数関数的に増えていますし、日本の労働人口は減ってきています。このまま昔のやり方を続けていれば仕事が回らなくなるのは明白です。だからこそバックオフィスを変革していく必要がある。ここ5年から10年ぐらいが日本のバックオフィスの過渡期でしょうね。

辰本:エンジニアとしてはこの過渡期の変革をテクノロジーで後押ししたいと思うんですよ。でも、今はDXブームでテクノロジーへの過度な期待感があるからか「RPAやAIといったテクノロジーを使って自動化したら魔法のようになんでも解決できる」と思われてしまうことも結構あります。

エンジニアの立場としては「プロダクトですべてを解決してほしい」というニーズそのものが間違っていることを理解してもらわないといけない。だから「実際には、今RPAやAIでできる個別最適化よりも先にすべきことがある」という共通認識を作っていかないといけないとも感じています。

武内:そうですね。RPA等は単純な繰り返し作業の自動化には向いていますが、逆に言えばまだ自動化できるのは単純作業の域を超えていないという側面があります。しかし、それだけだと全体最適にならず、全体としての業務工数はそこまで減っていない、ということも起こり得るのです。

辰本:たとえば、全体最適化がされずに個別最適のためにRPAやAI等の仕組みを適用しても「あの自動化の仕組みを修正するためには、◯◯さんに聞かないとわからない」「理由や意図はわからないけど、この自動化の仕組みを回すことになっている」といった状態になることが容易に想像できますね。

武内:バックオフィスの課題解決のためのプロダクトを提供する我々も、バックオフィスの実務とテクノロジーの特性をより深く理解する必要がありますね。

辰本:そうでなければ、プロダクトで解決する課題を誤って捉えてしまう可能性がありますよね。逆に、我々プロダクト開発側が課題を単純化しすぎて捉えてしまうと、真の課題解決が難しくなることも起こりえますね。

武内:課題を単純化しすぎると弊害が大きいですよね。真の課題を掘り下げた上で、プロダクトで解決するべきなのはどこなのか、という部分にきちんとフォーカスをあてなければいけない。

辰本「人間が対応すべき複雑な判断と処理」「正確性やスピードが重要な単純作業」の切り分けが必要だということですよね。そのためには今あるバックオフィス業務の全体像から見直さないといけないということになるんでしょうか。

武内:そうです。だからまずは「その仕事のゴールと全体像」そして次に「その仕事の中での各業務のつながり」をバックオフィスで業務にあたるチーム全員が理解し、可視化することが先決です。それにより、全体最適、ひいては「人間が本来やるべき仕事は何なのか」といった本質的な問いに対しての思考が可能になり、本当の意味でのバックオフィス改革ができるようになるんです。

辰本:こうしたことを可能にして「人間とデジタルの力を融合させるプロダクト」こそが日本のバックオフィス変革に必要なものだと僕も確信しています。

武内:「バックオフィスの現場とデジタルツールの間の差分を埋め、融合させるためのプロダクトを作る」というのが私たちのミッションだと私も思っています。

『BYARD』で「バックオフィスの改善を民主化する」

辰本:バックオフィスの課題と私たちのミッションについてお話ししたところで、くわしく『BYARD』というプロダクトについて説明していきましょうか。

武内:私たちの立てた仮説は「デジタルシフトに向けての順序が間違っている」というものです。自動化を有効に機能させるためには、テクノロジーが高速に処理できる単純作業だけをまとめておかなければならない。でも、今はそれがバラバラな上に、要所要所に人間の判断が必要で、とても複雑な業務プロセスになってしまっています。

だから一見地味なんですが、私たちのプロダクト『BYARD』ではまず複雑化・属人化してしまっている業務プロセスやノウハウを可視化・共有化して全員が同じものを見られるようにしています。全体が把握できるようにすれば、実際にその業務プロセスがそのままで良いのか議論できるようになりますからね。

辰本:共通して見えるものがあるからこそ「これって本当にいる?」「順番を入れ替えた方が無駄がないよね」ということにも気づけますよね。

武内:実は全体の最適化の方が、個別の自動化よりずっと効果が高い。言ってみれば、複雑で入り組んだ一方通行や一時停止だらけの道を、シンプルで運転しやすい高速道路に変える作業をまず行うということですね。自動化せずとも、これを行うだけで業務は大幅に効率化されるはずです。

辰本:無秩序に積み上げられた膨大な処理を疎結合・高凝集になるように上手に整理すると、驚くほどシンプルになるということはプロダクト開発の現場でもよくあることです。バックオフィス業務でも同様のことが実現できると思います。

武内:そこまでいって、ようやく自動化ツールの検討をするべきでしょうね。業務プロセスの可視化や整理が進んでないと、実際必要な自動化ツールなどもなにがいいのかわからないと思います。でも、業務プロセス全体を可視化してみると「必要な機能って意外とシンプルだな」って気づくはずなんです。

辰本:やはり「⑴業務の可視化・共有化」「⑵全体最適化への議論・検証」「⑶自動化による個別最適化」というのが適切な順序ですね。

武内:日本のバックオフィスではアナログで複雑な業務をなんとか終わらせようと頑張ってきたので、作業の完了がゴールという意識になりがちでした。でも、これからは業務プロセスの見直しが重要な役割になっていきます。

主体的に「私たちは何のためにこの業務をしているのか?ビジネスの目的を成し遂げるためにはこの工程は本当にいるのか?」と考えて、業務改善策をボトムアップで上げていかなければいけません。こうした転換を支えることも重要です。

辰本:そのために『BYARD』は、可視化した業務プロセス上で作業とコミュニケーションも一元的に行えるように設計しましたね。そのログの蓄積により「一人だけが担当しているこの仕事、このやり方ならチームで分担できるんじゃない?」という議論が生まれやすくなるのは、ソフトウェア開発の現場でも体験してきたことです。

武内:ソフトウェア開発の現場でそうした議論・検証を支えているのが『Git』や『GitHub』、それら周辺のエコシステムですね。

辰本:はい。これらが「当たり前」の存在になったことで、ソフトウェアエンジニアの仕事のあり方が大きく変わったと思っています。チームメンバーそれぞれが安全に素早く試行錯誤できて、変更に対して他のメンバーが快適にレビューできる。だから協業が容易で、プロダクトの品質もどんどん向上していきました。

僕らが『BYARD』で目指しているのは、『Git』や『GitHub』のようにバックオフィスの協業の基盤となるプロダクト・エコシステムを作り「当たり前」に支えていく存在になるということですね。

武内:「バックオフィス業務を行う人自身が業務を見直し、チームでの全体最適実現を支えるプロダクト」、それが『BYARD』です。

辰本:過渡期だからこそ、全体最適化に向けて担当者一人ひとりが業務改善に関わっていく過程が重要になるでしょうね。DXもそうした過程を飛ばしてしまうと失敗しがちですよね。

武内:その通りです。あるユーザーさんが『BYARD』を「改善を民主化するツール」と言ってくれましたが、この言葉はこのプロダクトの性質をよく表しているなと思います。チームで共有し、議論し、一人ひとりが声を上げ、自ら改善できるようにする。

業務が変わっていくことはいつの時代も避けられません。でも、業務を変えていくときに自分がそのプロセスに参画していれば、心理的抵抗感や痛みは和らぐし、やりがいだって感じられるようになる。

辰本:もちろん何でも勝手に変えればいいわけじゃないから、マネージャーや経験のある社員がレビューできて、承認が下りたら業務フローが変更されるような機能も必要になりますね。

武内:バックオフィスはその複雑さ故に、進化が遅れてきた部門です。ただ、デジタル技術や法律がようやく追いついてきて、今一気に業務を変えることができる波が来ています。ここで日本企業とバックオフィス人材が進化し、変わっていくことで、また世界と戦えるようになるはずです。

辰本:このプロダクトによって、日本のバックオフィスの頑張りどころを日々の作業から業務設計になんとか転換したいですね。そのためにバックオフィス業務の共通基盤として何の機能が必要なのか、私たち自身が議論・検証・開発を行わないといけない。しかももっと速度を上げて……。やることは見えているだけに焦ってしまいますね(笑)

武内:だからこそ、私たち『BYARD』には優れたエンジニアの力が必要なのです。

【最適解を見つけ続けていく】本質的な議論が好きなエンジニアの方求む

現在の『BYARD』のチームメンバー。一緒に未知のミッションに取り組みましょう!

辰本:あと私たちのチームに新たに加わってくれるメンバーへ伝えておくべきことは……『BYARD』の価値観でしょうか。

武内:私たちは「良いプロダクトを作る」ことを中心に据えたチームにしていきたいと思っています。役職や年齢の上下・入社年次は関係なく、フラットに「良いプロダクトのために自分は何ができるか、何を解決したいのか」というイシューを常に意識して議論し続けるということを重視していきます。

そのように抽象的な議論を重視するのは「過渡期にあるバックオフィス」という非常に複雑な課題領域に向け、誰も作ったことのないプロダクトを作るため「馬車しかなかった時代に自動車を発明する」というような難易度が高く、エポックメイキングなことに挑戦していると考えているからです。

そして、それはスマホのようにいずれは当たり前で、なくてはならないものになるとも思っているんです。

私たちが取り組むミッションに共感し、細かな一つひとつの機能をチームで議論し合って試行錯誤していくことを楽しめる方だと、知的な刺激も得られながら裁量を持って活躍していただけるのではないでしょうか。

辰本:付け加えるなら、そもそも正解がわからないから試行錯誤しながら作っていくと同時に「全体を破綻させないように、仮説が違ったら、作ったコードを潔く綺麗に捨てられる」能力とメンタルが必要ですね。そこを面白いと感じるかということが、このプロダクト開発においてはとても重要だと思っています。

武内:開発状況も共有しておきましょうか。

辰本:開発状況はまだ実験レベルですが、これまで約1年間作ってきて、実際のバックオフィスの課題とプロダクトでのアプローチや仮説にズレはあまりなかったと思っています。ここ数ヶ月は基本的なUIや基盤など見直しているところです。

武内:『BYARD』はまず業務の可視化をして、それを直感的に整理しながら思考を深めていくことベースにしたツールです。だから、人間の思考速度や動きにUIがついていかないと、思考が妨げられてしまって、議論や整理するところまで行けないことがわかってきました。

辰本:情報処理のスピードや精度を上げるために裏側を今全部作り直していて、ここは今後も幾度となく調整を行うことになると思います。これを面白がってくれる方、ぜひ力を貸してください!

武内:私たちがやりたいのは「答えを作る」のではなく、変わっていく最適解を見つけ続けていくことの支援です。今取り組んでいる「過渡期にあるバックオフィスの課題」のように認識するのが難しくてまだ答えがない問題だからこそ、取り組み甲斐があって面白いんです。でも、これを面白いと感じる人は100人に1人ぐらいかもしれません。

辰本:少ないと思います。だからこそ、この長い記事を読んで「ワクワクしてきた!」というエンジニアさんがいたら、ぜひ気軽に連絡してほしいですね。カジュアル面談、下記ページから受付中です。

今日は語り切れなかった開発体制など気になっている点があれば、私からくわしく伝えられますので。

武内:私も『BYARD』についてはもちろん、今回お話したバックオフィスの課題や人間とシステムが共存してつくるバックオフィスの未来についてでも、興味を持ってくださったことを気軽に話せたらと思ってます。

採用の募集要項は『プロダクトデザイナー』『バックエンドエンジニア』『フロントエンドエンジニア』の職種別にご用意していますので、面白そうだと思った方はぜひご覧ください。

いずれも必須要件は「私たちのミッションに強く共感してくださる」こと。今日の話で「面白そう!ワクワクしてきた!」と感じた方なら大丈夫です。

辰本:最後までお読みいただき、本当にありがとうございました!

武内:バックオフィスの変革に期待してくれている方は「そういえばあの人、こういうの好きそうだな」という人に届くよう、ぜひこの記事のシェアをお願いします。

一緒にこの課題に取り組もうという新たなメンバーの登場、お待ちしています!


この記事が気に入ったらサポートをしてみませんか?