チーム開発レベルを底上げする方法 　 〜チャートで分かる！ プロジェクトの問題点と対策〜

　

あなたのプロジェクトチームの弱点はココだ！

　1ページ目の自己採点はどうだったろうか？ それぞれのレーダーチャートから、あなたのプロジェクトチームの弱点が浮かび上がってくる。弱点を認識していただくとともに、それを改善する方法を紹介しよう。

開発プロセスが高度かつ理想的に実現されている 　バランスの取れたプロジェクトの開発プロセスが、高度かつ理想的に実現されている。すでに理想的なチーム開発、大規模なシステム設計のノウハウがメンバー間できちんと共有されている。

メンバーの基本スキル／人的・時間的リソースの制約が低い 　メンバーのスキルにばらつきがある、あるいはそもそものリソース不足が原因となって、高いスキルの人間にも効率的な仕事が与えられない。初級SEの管理がおろそかになりがちで、システム根本の品質にリスクが伴う。 　短納期を極端な人的リソースで補おうとすることで、極端な開発費の増加が懸念される。また、管理者と実働部隊のアンバランスは、結果として設計・開発間の不整合あるいは不適切な仕事分担から上級SEへの負荷集中を招く。 解決方法 ・ ユーザー側との納期調整、開発規模の見直し、段階リリースの検討 ・ 管理者・実働部隊のバランスの取れた人員構成 ・ 開発プロセス、オブジェクト指向分析、UMLなどのスキルトレーニング

プロジェクトに対する経験のレベルが低い 　業務またはアーキテクチャに対する理解が不足しているため、システム要件に適したアーキテクチャや設計を実現できない可能性がある。ひいては、パフォーマンスや機能上の致命的な欠陥を誘発するリスクがある。 　また、システム構成や開発期間の見積があいまいとなり、著しい開発費の増大、スケジュールの遅延を招く恐れがある。当然、設計の変更にも硬直的である。 解決方法 ・ 設計段階で繰り返しユーザー側とのレビューを行い、リスクの早期洗い出しに努める ・ UMLなど標準的なモデリング手法を導入し、定量的な見積・分析を行う →上級ビジュアルモデリング機能を活用する ・ アーキテクチャ、業務両面からの有識者をプロジェクトメンバーに集める

情報の共有度と品質の維持のレベルが低い 　プロジェクト内での共通的なインフラストラクチャが構築されていない。設計者、開発者間で情報が共有されていないため、システム内での不整合が発生しやすく、デバッグに際しても新たなバグを誘発しやすい。また、アプリケーションの品質が開発者自身のスキルに著しく依存し、全体としての品質保証を取りにくい。 　状態がさらに著しい場合は、開発者間のコミュニケーションに無駄が多く、実作業よりも相互の整合に多大な時間と工数を費やしている可能性がある。 解決方法 ・ メンバー全員が共有可能なツールを導入する ・ ドキュメント、コーディング、実装に関する規約（標準）を設定・共有する →ドキュメント生成機能を活用する ・ デザインパターンやフレームワークを適用するためのウィザードの導入 →コードの再利用関連機能を活用する ・ コード品質に関して、ツールを使った定量・定性的なテストを実施。閾値の設定 →品質保証機能を活用する

運用・保守性のレベルが低い 　属人的要素が強く、開発時のメンバーが少なく（いなく）なったときにシステムの運用・改定に多大な影響を与える可能性がある。システム変更時に、改定作業よりも解析作業に工数を奪われ、改定作業の著しい肥大化を招く。改定時に想定されなかったバグや不整合を引き起こす可能性もある。 解決方法 ・ 設計から開発後まで、断続的なリファクタリングの実施 →リファクタリング機能を活用する ・ リバースエンジニアリングによるレガシーシステムの分析 →リバースエンジニアリング機能を活用する ・ システム運用・利用方法に関するユーザー／運用担当者への啓蒙

開発プロセス自体がないに等しい状況 　極めて低いレベルで、開発プロセス自体がないに等しい状況である。小規模な開発であれば問題もさほど発生しないかもしれないが、規模の拡大に従って幾何級数的にリスク率が高まる。また、リスクに対する歯止めも存在しない。 　個々のメンバーのスキルアップに努めることはもちろんだが、組織としていま一度問題の洗い出しと、上記チェックポイントに従った組織改善のマイルストーンを早急に構築すべきである。

　問題点は洗い出した。それによる解決策も見えてきた。後は、これを実行局面にシフトするだけである。その手段として、反復的（イテレーティヴ）な開発モデルが提唱されている。従来型のウォータフォール・モデルでは、懸案事項が先送りになりがちであり、開発時の戻り工数が大きくなる可能性がある。しかし、反復的な開発プロセスは、ユーザーの確認・評価を受けながら開発を進められるため、要件との不整合を早期に発見でき、状況の変化にも比較的即応できるというメリットがある。技術的な不安が完全に払しょくできないならば、これを適切なタイミングで1つ1つ取り除いていく――段階的なリスク回避の手法を採用するべきであろう。

　しかし一方で、実際の開発現場は、理想的な開発プロセスを導入し得ないさまざまな外的・内的要因が存在する。プロジェクトマネージャにとっては、従来の手馴れた開発モデルは何物にも変えがたい保証であるし、これを全面的に捨てることはプロジェクトへのリスクヘッジを失うことでもある。

　自己診断によって、チームが抱えている問題点を理解できたと思う。次に行うべきアクションは、この問題点を解決するために、理想的な開発プロセスのコンセプトを（部分的にでも）導入し、チームの問題を是正することだ。

　もう1つ考えなければならないのが、これらの是正策を推進するための強制力だ。コミュニケーションを円滑にするために、ドキュメント作成の手間が増えては意味がない。コーディング規約やデザインパターンの適用などに対する強制力が、「この標準化ドキュメントを読んでよく理解してください」では現実味がない。チームによる開発を支援するツールは、空虚なドキュメントや取り決めに実効的な強制力を与えるものである。

　強力なモデリング環境によってチームの生産性と品質向上の両面を支援する「Borland Together」（以下Together）は、今後のチーム開発に対する最適なソリューションの1つである。

■上級ビジュアルモデリング機能

　特許技術「LiveSource（Single Source Architecture）」によるモデリング図とソースコードとの完全なリアル同期は、設計者と開発者との溝を埋め、アプリケーションとプロジェクトメンバー間の整合を保証するには欠かせないツールである。

　UMLによるモデリング結果は即座にコードに反映され、逆にコードの変更はモデリング図に反映される。ドキュメントの作成・メンテナンスに対する負荷は発生しない。テンプレートもデフォルトで用意されたもの、独自にカスタマイズしたものを一元管理可能だ。

■コードの再利用

　デザインパターンを自動コード化するウィザード機能も豊富に用意されており、開発時における個人のスキル差を最大限に吸収する。もちろん、プロジェクト独自のパターンをテンプレートに拡張することも可能である。

■品質保証機能

　「Audit & Metrics機能」を利用することで、最終的にコード規約に準拠しているか否か、コードの品質が最低限の水準を満たしているかどうかを定量的に観測でき、一定の閾値内に強制的に納めることが可能である。

■リバースエンジニアリング機能

　「リバースエンジニアリング機能」を利用することで、レガシーなアプリケーションについてもさかのぼって分析を行い、モデリング可能である。開発中のプロジェクト案件ばかりではない――すでに開発が完了したシステムについても、Togetherを使えば高品質に維持できる。

■リファクタリング機能

　個々のモジュールの整合性を保ちながら、コードの最適化や変更を可能とする。クラスや属性、オペレーションの移動、カプセル化、インターフェイス／スーパークラス／メソッドの抽出など、すべての変更を正しくアプリケーション全体に反映する。「リファクタリング機能」は、常にシステムを最適な状態に保ち、長期の運用にも耐えるシステムの維持には欠かせない機能である。

■ドキュメント生成機能

　ソースコードからドキュメントを生成する「ドキュメント生成機能」により、ドキュメント作成に手間をかけることなく、必要なときに最新のソースコードと同期したドキュメントを用意できる。「ドキュメントテンプレートデザイナ」というツールを利用して、独自のテンプレートを用意することも可能だ。ドキュメントの形式は、HTML、PDF、RTF。これにより、ソースコードとドキュメントのかい離によるドキュメントの陳腐化を防ぐことができる。

■既存開発ツールでTogetherを使う

　Togetherには、マルチ言語対応でIDEも含んでいる「Together ControlCenter」のほかに、「Together Edition」がある。Together Editionは、各種開発ツールでTogetherの機能を利用できるようにするプラグイン（あるいはインターフェイス）のようなものだと思っていただければよいだろう。Together Editionを介することで、JBuilderやEclipse、WebSphere Studioなど、使い慣れた開発ツールを使い続けながらにして、上記の機能を利用することが可能だ。特に、複数の会社が合同で開発を行う場合などに、「ツールを限定しない」という意味で絶大な浸透力を発揮するだろう。

　ボーランドは、現場の開発者の視点で、開発の効率化に長年取り組んできた。開発プロジェクトがさまざまな問題を抱え、なかなか生産性を高められない昨今、ボーランドが開発者個人の生産性を高めるだけでなく、チーム全体の生産性を高めることに着目していることは興味深い。このコンセプトは、Togetherに限らずほかのボーランド製品にも共通している。「アプリケーション・ライフサイクル・マネージメント（ALM）」 ―― ボーランドが最近掲げているコンセプトも、このような視点で見れば、開発者にとって身近な考え方だ。

　ボーランドは開発現場にどのような変化をもたらすのか？ 今後も、ボーランドは開発者にとって気になる存在となりそうだ。

2/2

チーム開発レベルを底上げする方法 トップページへ