 |
|
チーム開発レベルを底上げする方法
〜チャートで分かる！ プロジェクトの問題点と対策〜 |
開発プロジェクトが大規模かつ短納期化する昨今、チーム開発の重要性はますます高まっている。だが、チーム開発といっても、ただ頭数がそろっていればよいというものではない。
| |
チーム内のスキルがバラバラ |
| |
|
高スキルの開発者もいるが、初級SEが書いたコードのチェックや資料の作成で忙殺されてしまう |
| |
| |
メンバー間で設計情報が共有できない |
| |
|
ドキュメントのメンテナンスは追い付かないし、コード・ベースで情報共有するのは効率が悪過ぎる |
| |
| |
エンドユーザーからの要件がコロコロ変わる |
| |
|
設計ドキュメントは陳腐化するし、開発メンバー間でのコミュニケーションにオーバーヘッドがかかり過ぎ、プロジェクトマネージャも全体を把握できていない
|
チーム開発におけるこのような声は、もう聞き慣れてしまったかもしれない。だが、これは別に「あなただけ」の悩みではない。「オープン化」といわれて久しいが、結局勉強しなければならないことが増加し、個人のスキル差はますます著しくなっている。そして、頻繁に変化する状況に対応するために、みんな苦労しているのだ。
技術の進歩は早く、ビジネスの状況は頻繁に変化する。技術的な不安が一切ない状況で、絶対不変の要件に基づいてシステムを開発するなどという状況はありえない。だとすれば、さまざまな不安定要素を含む開発プロジェクトに立ち向かうために、われわれチームにできること、なすべきことを探ることが重要だ。
あなたのプロジェクトチームがなすべきことを理解するには、まず自分自身のプロジェクトにおける問題点・弱点を分析する必要がある。以下に、いくつかにカテゴライズしたチェックポイントを挙げてみた。現在進行中のプロジェクトあるいは過去に実行したプロジェクトに即して、本音で回答してみよう。以下のチェックポイントに対して、「○」「×」を付けてみてほしい。
| ■カテゴリ1 |
| |
□ |
開発者の能力は人それぞれ。スキルにバラツキがあるのは仕方ない |
| |
□ |
開発プロジェクトに徹夜はつきものだ |
| |
□ |
最初からスキルが充実した開発者を集める必要はない。開発者は、OJT（On the Job Training）でその都度育成していくものだ |
| |
□ |
ソフトウェア開発は労働集約的なもの。開発者の数をそろえることが第一だ |
| |
□ |
スケジュールは遅れるのが当たり前。スケジュールどおりに進行するなんて理想論だ |
| ■カテゴリ2 |
| |
□ |
採用するアーキテクチャに対する経験は問わない。プロジェクトが開始してからの調査こそが重要だ |
| |
□ |
業務内容に関する詳細まで、開発者が知っておく必要はない。必要に応じて、エンドユーザーにヒアリングすれば十分だ |
| |
□ |
システム設計は開発者が行うもの。エンドユーザーに口出しはさせない |
| |
□ |
開発工数や見積をあらかじめ算出するのは無理だ。開発していく中で大きく変動するのも仕方ない |
| |
□ |
システム要件はプロジェクトの最初にユーザーに確認すれば、それで十分だ |
| ■カテゴリ3 |
| |
□ |
プロジェクトで利用する開発ツールは、開発者個々人の判断に委ねている |
| |
□ |
ソースコードが最も正確。ソースコードで情報を共有している |
| |
□ |
要件書や開発仕様書のフォーマットは、開発者（個々のグループ）に任せている |
| |
□ |
データベースの構成情報は、データベースサーバをのぞくのが最も確実だ |
| |
□ |
ユーザーとのやりとりは開発担当者が分かっていれば十分。プロジェクトマネージャへの報告は、必要に応じてメールを転送している |
| ■カテゴリ4 |
| |
□ |
フレームワークやデザインパターンは開発者個々人の自由なコーディングを阻害するので、積極的には利用していない |
| |
□ |
ソースコードが人によって異なるのは当然だ |
| |
□ |
設計／開発時の問題点は、個々の担当開発者がきちんと理解していれば十分だ |
| |
□ |
システムが仕様どおりの動作すれば、どのようなコードの記述方法をしているかは重要ではない |
| |
□ |
コーディングの標準化は、標準化チームがドキュメントを作成してメンバーに周知徹底するものだ |
| ■カテゴリ5 |
| |
□ |
開発・改定作業が最優先。ドキュメントの修正が伴わなくても構わない |
| |
□ |
運用・業務フローはユーザーの問題であり、開発者が口を差し挟むべきものではない |
| |
□ |
再利用性や保守性などは、開発が完了するまで分からない |
| |
□ |
改定作業が発生すると、まずソースコードの解読作業から始まる |
| |
□ |
開発したメンバーが1人欠けると分からない部分が出てくる |
カテゴリごとに「×」の数を合計して、以下のレーダチャートにマッピングしてみよう。
どのような図ができただろうか？ 大きく以下のようなパターンに分類されるだろう。ピッタリのパターンがなくても、似ているパターンが1つあるいは複数あるはずだ。グラフをクリックすると、そのパターンの分析結果と解決方法にジャンプする。
|
