2
1

ビジネスサイドとエンジニアサイドの知識交流

Posted at

はじめに

社内コミュニケーションにおいて、ビジネスサイドとエンジニアサイドの知識の違いでコミュニケーションコストが上がることはままあります。

ビジネスサイドはエンジニアリングのことでわかっていない事が多いと思いますし、その逆でエンジニアもビジネスには疎い人が多いかと思います。この辺のギャップは多くの企業が直面する課題の一つです。この課題に取り組むため、「Techbridge Workshop」という勉強会を開催しました。

このワークショップは、両部門の相互理解を深め、より効果的な協働を実現することを目的としています。(ちなみにこの勉強会の名前はChatGPTに考えてもらいました)

Techbridge Workshopの概要

Techbridge Workshopは、以下の2つの主要セッションで構成されています:

  1. ビジネスサイドへのエンジニア研修
  2. エンジニアへのビジネス研修

これらのセッションを通じて、参加者は相手の領域について学び、共通言語、共通知識を増やすのが目的です。

ビジネスサイドへのエンジニア研修

このセッションでは、ビジネス部門に対して、ソフトウェア開発の基本的な概念と技術を紹介しました。主なトピックは以下の通りです。

  1. プログラミング一般用語について

    • OSとは何か?
    • Dockerとは?なぜDockerを使うのか
    • 静的型付け、動的型付け言語の違い
  2. フロントエンド開発

    • HTMLやCSSの基本
    • JavaScriptの概要
    • モダンなフレームワーク(React、Vueなど)の紹介
  3. バックエンド開発

    • バックエンドプログラミングの基礎
    • REST API, GraphQL APIとは
    • ステータスコード
  4. SQL

    • リレーショナルデータベースの基本
    • 基本的なSQLクエリの書き方
    • データ分析の基礎
  5. AWS(Amazon Web Services)

    • クラウドコンピューティングの概要
    • 主要なAWSサービスの紹介
  6. ブロックチェーン

    • コントラクト開発方法(Solidity)
    • Blockchain Explorerの読み方

感想

SQLセッションが非常に好評でした。社内データやブロックチェーンデータの解析に役立つスキルを学ぶことができ、直接業務に活かせる想像がしやすいためかなと思います。

他のセッションも役に立つという評価でしたが、AWSのところはあまり業務との関連を見出せない方が多かったです。弊社ではAWSを使うことが多く、用語としてもエンジニア間では飛び交うのである程度は理解してると、ビジネスサイドの人がPMで入る時とかは割と役に立つかなと思ってたのですが、そこまでは不要なのかもしれません。

エンジニアへのビジネス研修

このセッションでは、エンジニアにビジネスプロセスの全体像を理解してもらうことに焦点を当てました。主なトピックは以下の通りです:

  1. リードジェネレーション

    • 潜在顧客獲得の方法
    • インバウンド/アウトバウンド営業
  2. リードナーチャリング&リードクオリフィケーション

    • 潜在顧客から商談化まで
    • 商談時にどんな話をするのか
  3. プレゼンテーション&クロージング

    • 提案するもの、しないものを決める
    • 金額交渉
  4. プロジェクトマネジメント

    • プロジェクトとは
    • スコープ、時間、コストの管理
    • ステークホルダーマネジメント
  5. 顧客関係管理

    • 顧客満足度の維持と向上
    • 次の契約を取れるような土台づくり

感想

このセッションを通じて、ビジネス全体の流れを理解することができたと思います。エンジニア側の満足度も高かったです。
一方で、実務に繋がるという実感を得た人はあまり多くなく、エンジニアが関われる部分にもう少しフォーカスするとより良いものになるかもしれません。

Techbridge Workshopの効果

Techbridge Workshopは、全体として好評で今後も続けたいという人がほとんどでした。特にビジネスサイドのエンジニア研修は実務に直結しやすいことから非常に有効かなと感じます。
まだ、1回開催したのみで特に具体的な効果を観測できてはいませんが、今後も続けることでコミュニケーションコストが下がることを期待しています。

注意点

気をつけないといけないのは短時間で全てを理解するのは不可能ということです。これはカバーする範囲が広すぎて全てをちゃんとは理解できないという意味ではなく、間違った理解をしてしまうということです。

ビジネス側へのエンジニア研修の資料を社内のエンジニアに作ってもらったのですが、短時間である程度カバーするために正確性より分かりやすさを重視して資料作成をお願いしました。

なるべく注釈をつけるようにはしましたが、間違った理解をしてビジネスサイドだけで技術の話が進むということも考えられるので、その辺はエンジニア側、ビジネス側双方のコミュケーションはもちろん必要かなと思います。

あくまで目的はエンジニア側とビジネス側の相互理解であり、ビジネス側だけで技術の話が進められるようになるというものではありません。仮にそのビジネス側の人が社内で一番技術に詳しかったっとしても、エンジニアとコミュニケーションは必須かなと思います。コミュニケーションコストを下げるというのはコミュニケーション量を減らすというよりはコミュニケーションの質を上げるといった観点で捉えると良いのかなと思います。

結論

参加者アンケートによると、総じて満足度は高く、今後も続けていきたいという評価をもらいました。
ビジネスサイドへのエンジニア研修では、知識としてだけでなくそれぞれの実務でも役に立つ、役に立ちそうという評価をもらいました。

ただ、一方でエンジニアサイドへのビジネス研修は今回の内容では面白いという意見が多かったものの、実務に役に立つという意見は少なかったため、この辺の内容はアップデートが必要かなと思いました。

共通言語を持つことでコミュニケーションの質が向上し、プロジェクトの成功率が高まることを期待し、今後も継続的な学習と交流を通じて、組織全体の競争力を高めていきたいです。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1