営業だって開発全体で必要となるドキュメントを把握していることは重要だよって話

弊社が取り組んでいること

マンハッタンコードには共通基盤チームと新分野開拓チームの2チームがあります。共通基盤チームの役割は社内で利用する、または利用している技術ノウハウやナレッジの整理・更新です。
開発プロジェクトに応じてやり方やツールを選ぶのですが、基準となるやり方やツール選定がないと、会社の技術資産にならないと経営側で判断されチームが発足されました。

共通基盤チームの目的は以下の2つです。

【共通基盤チームの目的】
1.「わかってない、やれる」を「わかってる、やれる」に変えること
2.「わかってる、やれない」を「わかってる、やれる」に変えること

チームに関して興味のある方はこちらの記事も参考にしてみてください

2022年7月~2022年9月の期間に共通基盤チームがやっていたことは「開発ドキュメントに付帯する情報を整理し可視化すること」です。
このあとに記載があるのですが、DevDocs・DevDocsIndexMapは、その中でアウトプットされたものになります。
私たちのアウトプットを社内外の方に壁打ちさせてもらい、フィードバックをもらうことでわかったことがあったので記事にしました。

具体的なアウトプット

【DevDocs - でぶどっくす】
開発に必要なドキュメントは無数にありますがアプリケーション開発で最低限必要になるドキュメントを複数定義したものです。開発ドキュメント１つに対して、なぜ必要なのか、具体的なアウトプットはなにか、どうやって作るのかといったWhy/What/HowToに加え、アウトプットを作成する上でのテンプレート情報が関連付けされています。

【DevDocsIndexMap - でぶどっくすいんでっくすまっぷ】
V字モデルを基準に、なにをインプットにしてなにがアウトプットされるのかを図解したものです。MapにはDevDocsで複数定義している開発ドキュメント名が記載されており、どの工程でどのようなアウトプットができるのかがわかるようになっています。
Mapでは、各開発ドキュメントの具体的な内容を伝えたいわけではなく、開発を進める上での全体像の可視化を重要視しています。
Mapを使って取引先やチーム間で「これはある・ない」などのコミュニケーションが取りやすくなります。

写真は実際のDevDocsIndexMapです。
スタイリング調整前のものなので今後アップデートがかかる予定です。

DevDocsとMapを併用することで、なにがいつ必要で、なぜつくる必要があるのか？具体的にどのような成果物が出てくるのか？それはどうやってつくるのか？が誰にでもわかるようになります。

もしも営業が開発のことを知らないと何が起きるのか？

【具体的なアウトプットがなにかわからない】
ここでいうアウトプットとは仕事の成果物を指します。どんなお仕事でもなにか行動をしたらアウトプットが出てきます。開発の仕事を受けた際にどのようなアウトプットが必要かを営業が知らないと、SESなどの時間とリソースの営業しかできません。

【現状把握が正しくできない】
現場から「ドキュメントがほとんどなくて困ってる」と共有をうけてもそれがどうエンジニアの仕事に影響するのかわからないため正しい状況判断やヒアリング・交渉ができません。

【開発がどのような流れで進んでいくのかわからない】
今目の前で起きていることの対処しかできないので先を見据えた提案営業はできません。

営業からのフィードバック

実際に私たちがつくったDevDocsIndexMapを社内外で営業を行っている方にみせてフィードバックをもらうことにしました。

実際に開発をしていない営業にとって、お客さんと会話するための資料があるのはありがたいとの意見をもらいました。これらのフィードバックを受けて得られた新たな発見としては、私たちエンジニアにとってわかりやすいMapと営業にとってもわかりやすいMapは異なるということです。

1. お客さんに見せながら話せるのがありがたい
2. 営業資料に書かれていた「各種ドキュメント」を具体的に話せるようになる

結論

開発の流れや開発で必要となるドキュメントの知識は、開発に実際に関わるエンジニアだけが知っていれば良いわけではありません。実際に仕事をとってくる営業が知っておくことで顧客に提案しやすくなったり、現状を正しく把握できたりします。よって、開発で必要となるドキュメント全体を把握していることは営業にとって重要です。