UMLは手段 成功/失敗するプロジェクトの違いとは

3101viewsnoriyo_tcpnoriyo_tcp

このエントリーをはてなブックマークに追加
UMLは手段 (技評SE新書 005)

負け組パターンを分析する

トレーニングを言語研修と考えている

  • プログラミング言語の表現対象は”プログラム”だが、UMLの表現対象は”モデル”

ツールに過剰な期待がある

  • ツールはあくまで”支援”のためのもの

メンターの不在

  • デザインパターンは複数のプロジェクトを経験した人向け

これをやったら負け組になる

目的なき導入

UMLの導入理由が受動的なものであった

  • 「これからはUMLだ!」
  • 受動的理由によるUMLの導入は、ほとんど失敗に終わる。なぜなら、プロジェクト側にUMLを導入する「目的」がないから。

UMLと設計方法を混同している

  • UMLはあくまで表記でしかない。設計方法論や設計技法が不可欠

UMLと開発プロセスの分離

  • 設計モデルと実装の関係を理解していないと、設計モデルは作りっぱなしになる

目標なきトレーニング

トレーニングレベルの設定をしていない

トレーニングレベルは以下の3つ

  • UML表記のみ
  • 設計方法とUML表記
  • 開発プロセスとUML表記

技術の違いに対する認識不足

勝ち組はここが違う

1.勝ち組に共通する成功パターン

  • 目的を明確化する
  • 企業ニーズに合わせた適用と技術者育成
  • 企業ニーズに合わせたUML表記のフィルタリングをする

2.目的の明確化

  • UMLにどのような期待をしているか
  • 開発工程のどこにUMLを適用したいのか

3.企業ニーズに合わせたUML適用と技術者育成

  • 資産構築技術者
  • 第一線技術者
  • 構築技術者

以上の3つのタイプの技術者がバランスよく配置されているほうが、ビジネスとしては有効

4.企業ニーズに合わせた表記のフィルタリング

コアコンピタンス経営によるUML戦略

1.システム開発における開発プロセス

  • 記述粒度は、現在の工程に対応するテスト工程で使用するテストケースの粒度

2.コアコンピタンス別UML適用法

企業のコアコンピタンスは、次の4つのタイプに分けることができる

  • 専門重視型
  • ソフトウェア開発型
  • IT資産構築型
  • 保守運用型

3.残る課題

  • モデラーの発掘
  • 3つのタイプの技術者への誤解

4.企業ニーズに合わせてUMLを適用するには

  • 目的をはっきりさせる
  • 企業のコアコンピタンスを意識する
  • 適材適所で技術者の配置と育成を行う

アーキテクトに向いている人、向いていない人

アーキテクトに必要なセンスは、次の5つ

1.ピープルスキル
2.テクニカルスキル
3.コミュニケーションスキル
4.変化予測力
5.美的センス

間違いだらけのアーキテクト選び

1.適任者がいない

2.間違った選抜基準

  • 開発経験が長いだけの技術者
  • ルーティンワークをしている技術者
  • 分散系システムのプログラマー・設計者
  • 最新技術だけが好きな技術者

3.アーキテクト候補のいる場所

正しいアーキテクト候補とは

  • ミドルの開発経験がある
  • 保守開発の経験がある技術者

アーキテクトを育成する

1.訓練が必要

2.基礎訓練

①アセスメントとポジショニング
②道具を使えるようになる
③見習い
④定期的なフィードバック

3.自己成長のサイクルに乗ったアーキテクト

やはりプロジェクトは「人」であり、ソフトウェア開発はピープルウェアなのだ

関連まとめ

本のまとめカテゴリー


コメントを書く