ソフトの開発組織には何が必要

2017年12月8日2021年10月20日

 

ソフトウエアの開発組織にはいろいろあります

ソフトウエアを開発して市場にリリースしていくには様々な組織やチームが必要になりますが、ここではチームという言葉を使う事にします。ソフトウエア開発にはソフトウエアの開発に直接関わる製品企画チーム、設計チーム、実装チーム、テストチーム、保守チーム、等がまず必要です。これに加えて、間接的にかかわるプロセス改善チーム、アーキテクトチーム、品質保証チーム　なども安定したソフトウエアのリリースには必要です。ここでは、これらのソフトウエアの開発に必要な組織やチームについて、神戸のグータラ親父の考え方を紹介していきます。

ソフトウエアの開発組織 よりはチームのほうがしっくりきますね

皆さんは今、どんな組織に所属してソフトウエアの開発をしていますか？　組織というとなんかちょっとソフトウエア開発の現場と馴染まないので、チームと言い換えたほうがしっくきますね。まあ要するにソフトウエアの開発を進めるための数人から十数人で構成された同じ目的のために作業をしている人の塊の事を、チームと呼ぶことにします。皆さんは今、どんなチームに所属してソフトウエアの開発をしていますか？

チームの構成は会社によって様々でその名前も会社によって異なるので、チームの名前を聞いてもどんな業務をするのかよく判らない事もあります。場合によっては、どんな製品を開発しているかを隠すために、開発第一チーム、というようにチーム名から業務の内容が判らないような名前を付ける場合もあります。とはいえ、会社で業務としてソフトウエアを開発する場合には、なんらかのチームに所属して、他のソフトウエアエンジニアと協力しながら、１つのソフトウエアを作り上げるという作業に携わるのが一般的です。

普段のソフトウエア開発の業務をこなしていく中では、ソフトウエア開発のチームを意識する事は余りないかもしれません。でも実際のところは、ソフトウエア開発にとってチームというのは結構重要な意味を持ってきます。ここでは、ソフトウエア開発のためのチームについて、どんな事を考えておかないといけないのかという視点から、グータラ親父の考えていた事を紹介していきます。

チーム（組織）の構成

名前はいろいろでしょうが、目的から整理するとソフトウエアの開発には以下のようなチームが要ります。

• 製品企画チーム（開発するソフトウエアの要求仕様を取りまとめるチーム）
• 開発管理チーム（開発進捗や品質などを計画どおりに進めるための管理を目的としたチーム）
• 設計・実装チーム（設計と実装を行うチーム、場合によっては結合テストまでを担当する）
• テストチーム（システムテスト等の出荷までに必要なテストを行うチーム）
• プロセス改善チーム（ソフトウエア開発プロセスを作たり改善したりするチーム）
• アーキテクトチーム（設計やコードのレビューを通して技術的な支援をするチーム）
• 品質保証チーム（プロダクト品質やプロセス品質の保証とリリース判定をするチーム）
• 保守チーム（リリースした後のソフトウエアの保守を担当するチーム）

もちろん、これらがそれぞれ独立したチームとして存在している場合もあれば、１つのチームが複数の目的に対応している場合もあるでしょうし、チームではなく１名の担当者が居るだけの場合もあると思います。しかし、ソフトウエアを開発してリリースし、製品のライフサイクルに渡ってそのソフトウエアに対する保守の責任を果たすには、上記のような目的を持ったチームは必要になります。　しかし現実は、これらのチームが個別にあるのは、かなり大きなソフトウエア開発の時だけで、普通は一人か二人のエンジニアが複数の事を掛け持ちしてる場合が多いでしょう。それが現実なのですが、それでも上記のような目的別のチームが必要な事を認識した上で日々のソフトウエア開発業務をこなしたほうが、より良い結果に結びつくと思います。

チーム（組織）の規模

チームにはチームリーダが居てその役目はそのチームの運用と管理です。チームは人の集まりなのでその構成人数によってチームリーダが行うチームの運用と管理のやり方も変わってきます。グータラ親父のこれまでの経験から言うと、ソフトウエア開発のチームの場合は人数は5人、20人のあたりで運用と管理のやり方が変わる人数の境界がありました。

チームの構成人数が5人以下の少人数のチームなら、個々のチーム員が今何の作業をしていて、困っているか順調なのかも本人と話しをすれば大抵の事は判るので、チームリーダは難しい管理の方法を使わなくてもチームの状況を把握する事ができます。週１回～２回のチームの連絡会議をしていれば、大体の開発状況がつかめて、問題があれば早めに気づく事もできるので、それほど問題は起きません。もちろん、工程進捗やレビュー進捗の管理などの基本的な管理のために全員で共有できる情報は必要なのですが、簡単な表形式のＷＢＳ（Work Breakdown Structure）があれば事足りるでしょう。

チーム員が6人～20人程度の中規模のチームになるとＷＢＳだけでは開発管理が難しくなるので、何等かの開発管理のツールを使う必要性が出てきます。マイルストーンを使った日程管理や、個々のエンジニアの作業状況はWBSを見ていればだいたいは把握できます。しかし、日程計画のクリティカルパスがどこにあるのか、作業のボトルネックがどこの在るのか、などは前後の作業の関係性をある程度表現できるガントチャートの様なツールも必要になります。また、レビューやテストの実施効果を測るためのソフトウエア開発メトリクスも、何件から使う必要性が出てきます。また、複数のエンジニア間での作業の受け渡しを確実に行うには、チケットベースのアクション管理システムも必要になるかも知れません。

チーム員が21人を超えて大規模なチームになってくると、１つのチームとして運用するのは難しくなります。１人のリーダでは全員を把握できないので、サブリーダが１名～２名任命されるでしょうが、それでも１人のリーダやサブリーダが細いところまで把握してレビューなどで指導をできるのは、多くても10人程度までです。ですので、21名を超える場合はチームを分割するのが良いです。

チームを分割して１チームの人数を 10人前後に抑えたとしても、5チーム程度を超えてくるとエンジニアの総数としては 50名以上になります。　こうなると、各種のソフトウエアメトリクスを駆使して、チーム間の進捗や、中間成果物の品質状況や、最終成果物品質の状況を数値化して見える化し、問題のあるチームがどこかを素早く洗い出せるツールが無いと、開発管理は難しくなります。

このように、チームを構成するエンジニアの人数によって開発管理に必要なツールが変わってきます。まあ、どんな場合でもちゃんと開発管理ができていれば問題ないのですが、開発管理の良し悪しは実際にソフトウエアがrリリースされるまでよく見えない事も多いので、注意が必要です。

チームの外にある関連組織

ソフトウエアを開発するのは開発部門ですが、その開発部門の外にはそれ以外の会社の部門もあって、直接的に或いは間接的に、ソフトウエア開発に関係してきます。要求資料の元となる市場情報を集め、最終的にソフトウエアを客先に納品する営業部門、客先のシステムに当社の製品を組み込むための提案や調整を行う営業技術部門、他社製のソフトウエアを購入する手続きを進める購買部門、開発費用を用立てる経理部門、そして会社全体の管理の中でソフトウエア開発を進めるか止めるかを決める経営層など、ソフトウエア開発に関連する部門はいろいろ存在します。

純粋にソフトウエアの設計や実装だけをやっていれば良い新入社員の間は別として、５年、１０年とソフトウエア開発の現場で仕事をしていてリーダとして開発を進めるようになると、当然の事としてこのような社内の関連部門との連携も必要になってきます。

その時に注意しなければならない事は、各部門の使う言葉で会話をするという事です。ソフトウエアの開発を行うエンジニアは、ソフトウエアの技術用語を使っては会話をしてしまう事が多いです。日頃の仕事では、会話の相手もソフトウエアエンジニアなので、それで全く問題ありません。しかし、社外の他の部門と話しをする時は、ソフトウエアの技術用語を使わないように、十分に注意してください。意思の疎通ができなくなってしまいます。　

他の部門ではそのような事は余り起きないのですが、ソフトウエア開発部門では周囲に居る人が殆ど全てソフトウエアエンジニアという環境がよくあるので、ソフトウエアの技術用語を使っての会話が普通のようになってしまう事がよく起こります。他の部門の人からすると、意味の分からない話をする人に写ってしまいますので、注意しましょう。