業務のシステム化Web化 : 業務とシステムの両面から構築する必要性
Web制作業務として近年増えつつあるのが、クラウドのサービス・SaaSあるいはツールを設定・カスタマイズして業務用のWebを構築するというものではないでしょうか。Webサイト制作やECサイト制作でもCanva・WixやShopifyなどのクラウドのサービス (SaaS) で構築してしまうことが増えてきていますが、請求書作成サービス: BOARD、人事管理などのバックオフィス向けのクラウドサービス: JINJER、クラウド人事労務ソフト: SmartHR、クラウド会計ソフト: freee、プロジェクトの工程管理・タスク管理であればタスク管理ツール: backlogなどさまざまなSaaSのサービスを利用して業務をこなすことが増えてきています。
これらのSaaSは多くの場合、外部とのI/FのためのAPIを用意しており、さまざまな業務をSaaSでこなす企業が増えてきて、ひとつの企業でさまざまなSaaSを利用するようになる中で、複数のSaaSを連携させる開発ニーズが増えてきています。また、SaaSのUIをカスタマイズあるいはリッチ化するためにWebフォームを開発するような例もあります。
これらの例はクリエイティブというよりは開発案件ですが、ユーザが操作する画面がありますので、UIやデザイン・HTMLコーディングが必要とされる場合もあります。また、開発/システムが関係してくる面は多いのですが、ベースはSaaSで構築してしまうので、一からシステムを開発するような大きな工数の開発とはならず、小規模な開発案件であることも多く、各種Webの知見は要求される面があるので、構築を担当するベンダーとしてはSierやシステム開発会社というよりはWeb制作会社系の方が向いている案件ともいえます。
このような、これからWebディレクションしていくにあたって、対応することが増えていく可能性が高い、業務系のWeb構築・業務のシステム化Web化案件について、「業務」と「UI・システム」の両面から要件定義・設計・構築を行うことが、どのように重要となってくるのか、二つの例を取り上げて解説していきます。
1. SaaSのUI拡張のためのWebフォーム開発
さまざまな業務分野で、それぞれの業務を行うためのSaaSが多数生まれ、急速にいろいろな企業で使われるようになっています。これらのSaaSはそれぞれの業務に特化していて、その業務分野の業務フロー・提携となる文書・フォーマットに従ったものがあらかじめ用意されているので、簡単に導入することができて、使い方を覚えるのも簡単なことが多いことも多く、それによって急速に普及が進んでいます。
営業管理・会計などのそれぞれの業務範囲に限定して、典型的な使い方をするのであれば、必要な機能はSaaSにそろっていて、画面もその業務に対応して使いやすいものになっています。個別に作るよりも、多くのユーザに使われて、さまざまな要望を受けて改善されている場合が多いので、画面UI的にも悪いものはあまりありません。
しかし、企業によっては特有な事情・業務制約・要望などがあり、SaaSにはない項目を追加して入力したい場合など企業独自のニーズに従ったカスタマイズを行いたい場合があります。また、企業活動はさまざまな業務を行っており、ある業務についてSaaSを用いるようになると、そのSaaSに入力された内容も関係する隣接業務についてもシステム化したいというニーズが出てくることは珍しくありません。
たとえば、請求書作成ソフト : BOARDというのは受発注業務のためのSaaSで、見積書・発注書・納品書・請求書などを対顧客向けおよび対発注先向けに作成することができます。見積書・発注書・納品書・請求書は記載されている内容に重複が多いものですが、案件・発注内容を入力すると、見積書も発注書・納品書・請求書も基本的にできてしまう便利なSaaSです。また、承認ワークフロー機能ももっており、承認されると捺印済みの発注書や請求書がPDFで生成できる機能などもあります。
BOARDのこのような機能を用いて受発注業務をシステム化して、受注決裁・発注決裁などもBOARDのワークフローで業務をまわすようになると、ほしくなる機能のひとつが、案件の原価情報です。案件の受注決裁フローの承認者としては、案件の見積書に記載されるレベルの案件内容と金額・金額内訳はBOARDで確認できるにしても、その金額で受注した場合にどれだけの利益ができるのかが判断できないような場合があります。
たとえば、Web制作会社などのようなサービス業の場合でも、原価を決めるのはデザイナ・コーダ・エンジニア・ディレクタの工数だったりします。見積書上も職種ごとの数量 (工数) が入っている形態の見積書であれば承認者も見積書の内容から原価と売価の関係を把握しやすいと思いますが、対クライアント向けには機能別の内訳が記載されているだけの見積書も多かったりすると思います。その場合には、見積書の記載内容とは別に、その案件に対応するために、それぞれの職種のスタッフとしてどれだけの工数が必要となり、各職種の単価としていくらと設定したことによる売価となっているのかという情報が、承認者の判断のための情報としてほしくなります。
また、ここまでの情報を登録するのであれば、各月ごとの各職種のアサイン (工数) まで入れてくれれば、その各案件ごとのアサイン計画をまとめることにより、人員アサイン調整のための情報ともできるので、下記のような情報をBOARD上で案件担当者に入力してもらった上で、受注決裁フローにまわしてもらいたくなったりします。
BOARDには案件情報として、上記のような情報を登録するUIは存在しないのですが、案件情報を外部とやりとりすることができるAPIが用意されています。BOARDにすでに入力されている顧客情報や納品日・合計金額などの情報はAPIから取得して、各月の各職種のアサインについては上図のようなWeb画面のフォームで入力していくようなWebアプリケーションを作ることが可能です。
Webフォーム上で入力されたアサイン情報をプロジェクト管理に用いたいのであれば、プロジェクト管理のSaaSに連携することになると思います。プロジェクト管理用の各種SaaSもAPIを用意していることが普通なので、Webフォームのアプリケーションがそのプロジェクト管理SaaSに登録させることも可能です。
また、なんらかの理由で受注決裁フローはBOARDのワークフロー機能を用いるのではなく、上記のWebフォームで入力された情報も含めて、別途ワークフローのSaaSに連携してカスタマイズしたワークフローを構築するようなことも考えられます。
a. 特定の業務を標準的な使い方をするのであれば、その業務の代表的なSaaSを使用すれば簡単に利用を始められます。
b. その企業に特有の事情があり、カスタマイズしたい面があるのであれば、多くのSaaSにはAPIが用意されているので、SaaSに入力されたデータを参照しながら、追加の情報を独自のUIで入力してもらうことを可能とするWebフォームを作成することもひとつの選択肢です
c. 営業段階のアサイン計画の情報をプロジェクト管理などに連携するような、複数の業務の間のデータ連携まで行う場合には、それぞれの業務用のSaaSに用意されているAPIを用いて外部に連携用のWebアプリケーションなどを構築することにより、連携することが可能です
次に、上記のc.の例を深堀して、複数のSaaSを連携する場合に、システム化したい業務内容の詳細の違いによって、実現方法がどのように変わってくるのか、したがって業務理解とUI・システムの両面を考慮してWeb構築を行うことが重要かみていきたいと思います。
2. 複数のSaaSを連携して、受注決裁フローをシステム化
業務に関するSaaSは特定の業務に特化しているものが多く、一方で営業と受注決裁のような隣接業務・関連業務の両方でシステム化を行おうとする場合、先行業務で入力した情報をもう一方の業務で重複して入力するのは手間なので、システム間・SaaS間のデータ連携を行いたいということがよくあります。
たとえば、営業でSFAを利用していて、見込み段階の案件情報を入力しているとします。また、営業が値引きをして受注する場合には、この金額まで値引きして受注してよいかどうか決裁を求める受注決裁フローで関係者の承認を得ないといけないという業務があるというのはよくある会社の業務の仕組みかと思います。
受注決裁フローには、承認を求める案件情報として、顧客・案件見積もりなどの情報は基本情報として当然必要となりますが、これらの情報はSFAに入力されている情報ですので、受注決裁フローの最初に申請内容として顧客情報や案件見積もりなどの情報を再度入力しないですむようなシステム構成としたいということになります。
受注決裁フローという業務は多くの企業で行っている一般的な業務のため、NOTESあるいはkintoneなどのさまざまなグループウェアを利用するだけでも、シンプルなワークフローであれば実現できますし、HubSpotのようなMAツールでも対応可能です。
しかし、受注決裁フロー上で経理・事業部長などが判断するための情報としては、申請してきた値引き金額でどれだけの営業利益が残るのか、その金額でいくらの受注/売上金額となるのか、当該顧客からのこれまでの受注実績と今後の受注見込み (今回値引きして受注すると今後のプラス効果がどれだけあるか) などさまざまな情報が必要となります。どこまでの情報をシステム的にサポートするか、原価情報を決裁判断上はほしいものの申請者としての営業担当にまではみせないかなど、実現したい業務要件により実現するシステム構成にはいろいろな選択肢があり得ます。
受注決裁フローのシステム化ということなので、営業がSFAをすでに利用している場合には、そのSFAでワークフローを実現できないかを検討するのが第一のポイントとなります。SFAは利用しているものの、そのSFAでは実現できない場合には、SFAとワークフローのシステムを連携させて実現することになります。
基本的には、各種SFAもワークフロー構築用のサービス/ツールなども外部連携のためのAPIを用意しているのが一般的となっていますので、それらのAPIを呼んでシステム連携を実現するアプリケーション開発を行えば一般的にデータ連携は実現可能です。また、SalesforceやHubSpotのような多くの人たちに利用されているサービスでは、外部連携用のアプリがいろいろ用意されている場合もあります。そのようなアプリがすでにあるのであれば、システム開発をする必要もなくSFAとワークフローとの連携を実現することができます。
もし、そのようなアプリが存在しなかったり、一部の情報はすでにSFAに入っているものの、受注決裁フローの申請内容としてはさらに追加で情報を入力してもらう必要があるような場合には、外部にWebフォームを開発するのもひとつの選択肢となります。Webフォームから受注決裁の申請をしてもらうわけですが、そのWebフォームを開いたタイミングで、そのWebフォームアプリケーションがSFAのAPIを呼ぶことによりSFAに入力済の情報を取得して、すでに入力済の状態でフォーム画面を表示した上で、申請にあたっての追加の情報を営業担当に入力してもらい、申請処理としてWebフォームアプリケーションがワークフローのシステムのAPIを呼ぶことにより、ワークフロープロセスを起動する構成とすることが考えられます。
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。