[レポート] 老舗会計ソフトウェアベンダーからクラウド会計ソフトウェアベンダーへ (CUS-49) #AWSSummit

コンバンハ、千葉（幸）です。

AWS Summit 2023 に2日間現地参加しました。4/21に行われた以下のセッションを聴講しましたので、セッションレポートをまとめます。

• 事例セッション（CUS-49）
  • 「老舗会計ソフトウェアベンダーからクラウド会計ソフトウェアベンダーへ」

なお、本セッションレポートはスピーカーの佐々木さまより掲載の了承を得て公開しています。

セッション概要

スピーカー：弥生株式会社　開発本部CTO　佐々木 淳志 氏

デスクトップ向け会計ソフトのイメージが強い弥生ですが、現在はクラウド会計ソフトの開発に力を入れています。SaaSを開発する体制をどのように作っていったのか、なぜAWSをクラウドインフラとして選定したのかについてご紹介します

ちなみに佐々木氏が好きなAWSサービスはAmazon Connect ^*1とAmazon EC2 ^*2 だそうです。SaaS on AWS でも登壇されていた方です。

「SaaS On AWS 2022」にCTO佐々木が登壇しました｜弥生株式会社 公式note

セッションレポート

既存のオンプレミス前提のパッケージで売り上げも上がっているし利益は出ている。しかしこのままでいいのだろうか？という思いから改革への一歩を踏み出した、というお話から始まりました。

弥生の現在

• 弥生は「事業コンシェルジュ」へ
  • 業務効率化を進めるとともに、事業者のあらゆるステップを支える存在へ
    • 業務支援サービスと事業支援サービス
  • 業務支援サービス
    • 弥生シリーズ
    • 弥生オンライン（SaaS）
    • 記帳代行支援サービス
  • 事業支援サービス
    • 起業から事業承認まで、小規模事業者の困りごとに対するステップごとの支援
      • 起業・開業ナビ
      • 資金調達ナビ
      • 事業承認ナビ
      • 税理士紹介ナビ

事業支援サービスの例として「弥生のあんしんM&A」が取り上げられていました。ちなみに買い手の場合は個人でも利用できるそうですよ。

弥生の未来

• 開発中の新サービス（一例）
  • 日本全国の中小・中堅企業とステークホルダーが頼る経営プラットフォーム
    • バックオフィス業務の完全自動化
    • 社内外の業務をつなげる
    • 経営状況の可視化
    • ビジネスの適切なアクションが取れるようにする
• これからの弥生はAWSを全面採用
  • 今まではオンプレミスや他社とのハイブリッドだったが、これからはクラウドファースト、基本はAWS
  • なぜAWS？
    • 早くサービスを展開するため
    • 弥生のエンジニアの支持
    • サポート
    • AWSサービス以外の各種支援

早くサービスを展開するため、というキーワードがセッション中に何度も出てきました。

未来を実現するために

ミッション・バリューの見つめ直し

• 今までの弥生、これからの弥生
  • 今までの弥生
    • 既存製品の法令対応
    • 既存製品のブラッシュアップ
    • 持続的イノベーション
  • これからの弥生
    • 新しい価値の創造
    • 破壊的イノベーション
  • 「既存製品は売れているのになぜ新しいことを？」「新しい価値ってなんだ？」
• 振り返り
  • 現状維持や現状の延長線上にミッションの達成があるのか？
    • ミッション：日本の小規模事業者の社会インフラとなる
    • 既存の製品の改善は今のお客様への価値提供のみ、社会インフラとして十分なのか？

「バックオフィス業務の自動化だけでいいのか？」お客様に実際に使ってもらって意見を聞くのが大事、とのお話がありました。

• リリース、フィードバック、イノベーションのループを回す
  • 大抵のイノベーションは失敗する
  • 何度も回すことが大事
  • サイクルを回すために開発のスピードアップが必要、そのためにAWS

開発で時間がかかっていることはなんだろう？

開発のスピードアップを考えた時に、以下のプロセスでそれぞれどんな見直しが行われたのかが取り上げられていきます。

• リリース
• テスト
• ドキュメント作成
• セキュリティ対応
• 製品の仕様決定
• MTG

リリース作業の見直し

• DevとOpsが分離している状態からDevOpsへ
  • 開発チーム：アプリ開発、デプロイ、運用、サービス用インフラ構築を担当
  • 運用チーム：共通インフラを担当
• 従来は開発チームはアプリ開発のみ、デプロイ以降は運用チームの棲み分けだったが、運用チームは共通インフラのみを責務に

開発チームの役割が増えたことで、これまで触った経験が少ないAWSサービス領域に対してセキュリティの不安が発生します。（うっかり穴を開けてしまわないか？）

• セキュリティ大丈夫？
  • ガードレール構成をとることで対応
  • 運用チームはセキュリティガードレールを管理、開発チームはガードレールの中で自由に触る
  • マルチアカウント構成で、AWS Control Towerを使っている
  • 例えばS3のパブリックアクセス。うっかりパブリックアクセス可能にしてしまっても自動的に検知され、修復される

DevOpsを進めることで運用チームの作業量が減り、また、副次的にマネージドサービスの利用比率が増えたとのこと。AWSの知見が少なかった開発チームの方も、ガードレールで守られている安心感の中で作業を勧められた、といった「利用者の声」が紹介されていました。

テスト・ドキュメント作成の見直し

• テスト
  • 必要な時に環境を立ち上げられるので、テストのための「環境待ち」が無くなった
  • IaC 化しておくことでより有効活用できる
  • テスト自動化を日々改善中
• ドキュメント
  • ドキュメントの自動生成
    • 手動で作成するドキュメントを洗い出し、AWSの構成図は自動生成

セキュリティ対応の見直し

• マネージドサービスの積極的な採用により、カスタマー側が責務のセキュリティ観点を減らす
  • DevOpsにしたことで試行錯誤がしやすい
  • 未来を実現するために「とりあえずEC2」の禁止

（「とりあえずEC2」の禁止、みなさんはできてますか？）

• 全AWSアカウントをセキュリティ管理下に入れる
  • AWS Control Tower
  • Amazon Inspector
  • Amazon GuardDuty
  • AWS Security Hub
• CI/CDにセキュリティチェックを組み込む
• 外部ベンダーでのセキュリティ診断も利用

製品の仕様決定の見直し

• これまでは本部横断で調整しながら製品仕様を考えていた
• 本部間で決定に至らない場合、エスカレーション先が経営会議（CEO）
  • CEOはお客様のことも技術のことも分かるスーパーマンなので頼られがち
• 時間がかかること、特定の人物に頼ってしまうという問題がある
• 問題の解消のために、新サービス開発チームの立ち上げ、CEOの交代を実施
  • CEO岡本氏の退任の際のコメント：卒業: 弥生社長の愚直な実践

会社はGoing concern(永続が前提であるもの)であるのに対し、人はGoing concernではありません。ですから一人に極度に依存することは、場合によって害をなしかねない。適切なタイミングでバトンを渡していくことが自分の役割であると考えていました。

スーパーマン、と称された岡本氏は以下のイベントにも登壇されていました。スーパーマンですね。

弥生、「AWS re:Invent 2022(開催地 米ラスベガス)」に登壇｜会計ソフトなら弥生株式会社

新サービスの開発、と聞くとともすれば技術的な面についてばかり注目しがちですが、組織的な構造改革も重要な観点なんだな、と新鮮な気づきがありました。

MTGの見直し

• MTG（調整業務）が多いのはなぜか？
  • 先述の本部横断の事情に加え、開発本部内の事情もある
  • システムが密結合になっているため、一箇所を直すと他に影響が出るかもしれない
    • ので、調整が不可欠
• API経由にして疎結合にすることで調整の機会を減らした
  • APIでお話しする部分が変わらなければ、システムの内部で変更があっても他システムに影響を与えない

密結合と疎結合、よく聞くやつです。知識としては知っていましたが、チーム内での調整業務にも関わってくる、というのはこれまで気づけていない視点でした。

AWS の協力を得ながらやってきた

• ここまで述べてきた内容はAWSの各種協力を受けながらやっている
  • Monoliths To Microservices :: DevAx::Academy - Monoliths To Microservices
  • AWS プロフェッショナルサービス (AWS クラウドのコンサルティングサービス) | AWS
  • Office Hour（ZoomにAWSの担当者が常駐していて質問に答えてくれる）
  • デジタルイノベーションプログラム（DIP）
  • エクスペリエンスベースドアクセラレーション（EBA）
    • アプリケーションのモダナイゼーションを加速するEBA | Amazon Web Services ブログ

まとめ

最後に弥生開発本部のミッション/バリューが紹介されました。

• 弥生開発本部のミッション・バリュー
  • 「1クリックであらゆるバックオフィス業務を完了させ、お客さまの1日の労働時間の100%を本業に費やすことができる状態を目指す」

さらに細分化された内訳はここでは割愛しますが、よくよく読んでいくと Amazon の OLP と重なる部分がある、という言葉と共に締め括られました。

終わりに

「老舗会計ソフトウェアベンダーからクラウド会計ソフトウェアベンダーへ」のセッションレポートでした。

特に印象に残ったのは以下の観点です。

• マネージドサービスによって気にすべきセキュリティの観点を減らす
• セキュリティガードレールによって開発チームと運用チームの棲み分けがいい感じに
• クラウドファースト、の中で他のクラウドサービスでなくなぜAWSなのか？
  • 問い合わせ時のサポート対応、障害発生頻度が少ない印象など、社内のエンジニアからの支持が多かった
• サービス開発を行なっていく上では技術的な観点だけでなく組織的な観点も重要

これまでのやり方でもうまくいっているのになぜ新しいことをやろうとするのか？という背景から、実際に新しい取り組みを行なっていくプロセス、その勘所が聞けて大満足なセッションでした。

また、セッションレポートを書く中で以下のようなコンテンツがあることも知れたので得した気分です。

以上、 チバユキ (@batchicchi) がお送りしました。

脚注