[案件]ビジネスアナリスト(BA)として実際に案件内で行ったこと

まず初めに

新卒から今まで約６年間ビジネスアナリスト(BA)というポジション名で行ってきたことと、このポートフォリオの見出しは下記です。

• ビジネスアナリスト(BA)とは？
• ビジネスアナリスト(BA)として実際に行ったこと
  • 顧客折衝
  • 要件定義
  • 仕様書作成
  • PM補佐
• ビジネスアナリスト(BA)として働いて身についたスキル
  • 自分の意見/考えを持つこと
  • 問題がどこにあるのか見極めること
  • 予測すること
• まとめ

ビジネスアナリスト(BA)とは？

ビジネスアナリスト(以下BAと称します）とは何をする人なのか？についてですがネットで調べたものとは異なると思いますので、私の会社の中でのBAの役割についての説明だと思っていただければと思います。

まず、私の会社は受託開発・自社開発を行っている開発会社です。私が携わっていたのは受託開発の方で、BAは簡単にいうと日本人クライアントとベトナム人エンジニアの間にいるディレクターのようなものです。ブリッジSEではないので技術的なことに関してはエンジニアを介したコミュニケーションとなりますし、PMではないのでチームビルディングやスケジュール作成はベトナム人PMの仕事になります。

自分の会社の募集要項を見てみると下記のように記載されていました。補足ですが、私が案件にアサインされるのは契約が決まった後からなので、基本的には契約開始後から参画します。

ビジネスアナリスト(BA)として実際に行ったこと

では実際に私が行った業務を紹介します。

🏋🏻‍♀️顧客折衝
基本的には日本人クライアントとベトナム側チームの2者間のみで開発を行っていたため、ベトナム側チームの日本語話者は自分一人もしくは通訳・翻訳のためのベトナム人日本語話者がチームにいるという体制がほとんどでした。なので、ディレクターと呼ばれる人はいなかったため、クライアントコントロールは自分の役割でした。

例えば、下記のようなことを行いました。
・スケジュールがタイトな場合の提案の準備、ネゴシエーション
・障害が起きた場合の障害報告、諸々の対応
・定期的な振り返りのミーティングでディスカッション
・案件の進め方の導入/改善提案
・開発体制の提案
ただの通訳・翻訳を行う橋渡し役ではなく、案件を円滑に進めるために動く人、というイメージです。

🏋🏻‍♀️要件定義
やりたいことはあるけど具体的に要件が決まっていないということも多いと思います。そういった場合に、ゴールをまず聞き、それに必要な要素をヒアリングしながら進めていくことも行っていました。また、要件と期限はあるけど進め方が分からない、というときは進め方も提案してリリースまで持っていくことも行っていました。

下記を意識していました。
・ゴールはどこなのか？
・ゴールに対して絶対に譲れないものは何か？
・ゴールに対して必要なこと/ものは何か？

🏋🏻‍♀️仕様書作成
要件を詰めていきながら仕様書の作成も行います。日本語もしくは英語で作成していました。
形式は様々あり、
・バックログで画面ごとにイシューを立ててそこに記載
・Githubのwikiで作成
・Googleスプレッドシートで作成
などです。
仕様書は軽視されがちな印象ですが、これがあることによってお互いのすり合わせができたり、追加要件がある場合に現状と追加点を簡単に見比べることができたり、仕様に関して思い出せないときに見返せたりと、作成した後も結構使われます。
↓Googleスプレッドシートで作成する場合は大体下記のテンプレートでした。DBからデータを取ってきているものは一番右のDB欄に`テーブル名.カラム名`を記載していました。

🏋🏻‍♀️PM補佐
ベトナム側の開発メンバー内にPM（ベトナム人であることがほとんど）が一名アサインされますが、PM歴が浅いメンバーも中にはいたので、その場合は補佐的なことも行っていました。
具体的には、
・スケジュールの立て方に感してアドバイス
・チームの振り返りMTG内での深掘りサポート
・体制の提案準備に関してアドバイス
特にスケジュールの部分に関してはPMが作成したものを毎回かなり慎重にチェックし、想定されるリスクが考慮されてないもの、こちらの祝日休暇が考慮されてないもの、想定よりも工数がかなり掛かるもの、などが無いかチェックしていました。私はPMではなかったのですが、PMが作成したものをクライアントに持ち寄るのは自分の役目だったので、基本的に開発メンバーの進捗やスケジュールは常に把握しておくことが必須でした。

ビジネスアナリスト(BA)として働いて身についたスキル

実際に6年程BAとして働いてみて身についたスキルを考えてみました。

👩🏻‍💻自分の意見/考えを持つこと
日本人のクライアントとベトナム人エンジニアの間に立つものとして、伝言ゲームのように両者にそのまま伝えても上手くいかないと考えていました。
理由としては、下記かと思っています。
・言葉には色々な意味が込められていることもあるため
・自分が理解出来ないものをそのまま伝えても相手は理解できないため
なので、間に立つものとして、相手の発言した言葉に対してしっかり自分の理解を伝えすり合わせをし、両者の詳細な状況等を唯一把握している立場での自分の意見もしっかり伝えることが大事だと学びました。

👩🏻‍💻問題がどこにあるのか見極めること
開発をしていていると日々色々な問題に出くわします。一見問題のように見えても実は問題ではないことも沢山ありました。問題を間違えてしまうと解決策も間違えてしまい、結局本当に解決したいことが解決出来ない状態になりえます。なので、何か問題について話す時にはその詳細をまずヒアリングしつつ深堀りをし、根本原因を突き止めるということがとても大事だと感じています。

👩🏻‍💻予測して仕事を行うこと
スケジュールなどのチェックをする際にも例えばここでこういうことが起きた場合のためにこれも入れておこう、と考えられるリスクを予測しながら最終チェックをしていました。また、クライアントとチームの間に立つ者として、コミュニケーションの数を減らす工夫が特に必要でした。なので、なるべく先を予測し、事前にチームやクライアントに確認した上で、「〜はどうですか？YESの場合はこちらで、NOの場合はこちらで進めようと思いますがどうでしょう？」のように質問する場合は回答も予測して準備しておくことを心掛けていました。

まとめ

以上がこのポートフォリオの内容となります。
BAとしてというよりかは、割とどの仕事でも役に立つスキルを身につけられたかなと、振り返ってみると感じます。