ソフトウェア構造の抜本的な見直しを決意し、開発の上流工程から全面的作り直しを行った（あるいは行っている）状態です。
再構築したソフトウェアは量産へ適用され、ソフトウェア構造の可視化による品質の向上や新しいチャレンジをやりきったことによる開発者のモティベーション向上など、多くの効果がもたらされています。
しかし、当初の予想ほどには品質・生産性が向上せず、採用した技術や、再構築の妥当性に疑問を感じている開発者が徐々に増えつつあります。また、再構築したソフトウェアの構造が、特定の開発者にしか理解されず、組織的な取り組みになり得ていないケースもあります。
変革の推進力は、リーダーの度胸とリーダーシップに大きく依存しています。
- 設計段階である程度可視化されている。
- しかし、その後の変更が反映されておらず、アーキテクチャは絵にかいたモチになってしまっている。
- 一部の推進者以外は、きちんとした教育を受けておらず、なんちゃってUMLやなんちゃってオブジェクト指向が氾濫。
- なので、メソッドを100個以上持つクラスや双方向依存のクラスやパッケージが、割とフツーにあったりする。
- ○○制御や、○○駆動とかいったクラスが多い。
- 何が正解なのか分からないので、とりあえず、一番よく知っているだろう人に右へ倣えになっているが、意外とそれが的を外している。
- 結局、オブジェクト指向やモデリングを取り入れてはみたものの、思ったより楽になっていない。
- 共通メカニズムを担当する人がおらず、各自が仕組みを作ってしまっている。
- 技術習得や開発に目がいってしまい、ビルド環境の構築が軽視されている。
- 設計段階でのレビューが定着してきた。
- プロセスを定義しながらプロジェクトを進めていっているので、プロセスに人がついてきていない（周知化の仕組みがまわっていない）
- 技術習得に意識が向きがちで、プロセスは以外といい加減。
- プロマネがオブジェクト指向による開発のマネジメント経験が浅く、人を機能単位にアサインしてしまい、複数の人が一つのオブジェクトを共有してしまっているが問題に気づいていない。
- プロマネが反復プロセスによる管理に慣れておらず、反復計画がウォーターフォール的になってしまっている。
- できないことを次の反復に回してしまう。
- チームリーダが、新技術に詳しく、かつ業務推進能力が高い。
- 自己流でも、なんとか頑張ればものになる、と考えている。
で、そのとおり頑張っている。 - なんとか作ることができて、上層部にも改革成功をPRしているが、
内心では、本当に良いものができたかどうか怪しいと考えている。 - さらに、オブジェクト指向やモデリングを取り入れてはみたものの、実は思ったより楽になっていないと感じている。
- 一部の人しか、新しい設計内容についていけていない。
- できる人のモデルと、そうでない人のモデルの差があり、差を埋める努力がなされていない。
- 新しい技術の習得のできる/できないと入社年数の相関がなく、ベテラン社員でできない人はモティベーションが下がっている。
- ソフトウェアの改革よりも商品開発のプレッシャーが大きく、改革活動が形骸化しつつある。
- 構造改革のための人がねん出できず、できる・任せられる社員はおらず、協力会社社員が頼みの綱となっている。
- 改革に対する抵抗勢力が多い。
- 推進者がソフトウェア構造改革のプレッシャーが大きく、経営層への報告・アピールで疲弊している。
次のフェーズ「展開」とのギャップを乗り越えるために、エクスモーションのトータルコンサルティングでは、上流工程の洗練で生産性の向上を目指します。
