肥大化し、複雑度を増していくソフトウェアに対し、抜本的な改善を施すのはリスクが高いと考えています。
実装ルール・テスト手法などの下流工程や開発環境など、リスクがあまり高くないところから徐々に秩序化を図る活動を実施しており、当初は品質面で一定の効果がもたらされていました。可視化などにも取り組んでいますが、ソフトウェア構造の複雑さは改善されていないため、その効果もいまひとつで、開発者の多忙さは混沌状態とあまり変わりません。所謂、腫れものに手を触れず、それを壊さないような仕組みの構築に腐心している状態なので、あまりこの状態を続けていると、仕組みだけが肥大化し、逆に生産性を下げるといった不良債権化する危険性があります。組織の中には、当初の効果が忘れられずこの状態を是とする開発者と、抜本的改善の必要性を感じている開発者が混在しています。
- ソースコードは、コーディング規約や静的解析ツールが導入されたおかげで、一見すると整然としている。
- ただし、設計内容は複雑なまま。少しずつ長年にわたって追加・修正が加えられ、老舗そばやの「秘伝のたれ」と化している。
- さらに、書かれている内容の目的をきちんと説明できる人がいない。おかげで、ソースコードは増える一方（だけどリソースは少ない）。
- 簡単な変更依頼にも、びっくりするぐらいの工数がかかるので、ハード屋さんからは「ぼったくりバー」と呼ばれている。
- 90％再利用していても、残りの10％がありとあらゆるところに拡散し、その箇所を探すのが大変だし、直した後も自信が持てない。
- だけど、毎回なんとかこなしている自分は熟練工か。
- プロセスを整備したおかげで、ドキュメントが存在するが、ただ書くだけとなっており、中身が薄い。
- 思いつきのテストケースが通ればOK。
- 個人レベルでバージョン管理。フルバックアップを重ね、日付フォルダでHDD容量が圧迫される。
- 製品の規模が大きいか、品質要求が厳しいかで、ソフトウェア自体の見直しには及び腰。
- 見直しても、せいぜい小さなリファクタリングが限界。
- コーディングルール、ネーミングルールなど、ルール系はきっちり。でも、決めた後の見直しは稀。
- プロジェクト管理も比較的きっちりやります。
- 改善当初の成功体験が忘れられず、気がつくとルール化だけがどんどん肥大化。
- おまけに最近は効果がサチってきていて、大胆な手が打てず袋小路的な細かい手をどんどん仕掛けている。
- なので、現場は大変。
- 自社の開発スタイルが唯一と思っている。
- 最新の開発技術はあまり知らないし興味もない。
- 業界誌は読むが、ソフトウェア関連の雑誌・書籍はほとんど読まない。
- いつも忙しく、改善している割には、
ちっとも楽になっていないと感じている。 - オブジェクト指向＝C++やJavaだと思い込んでいて、コード量が増えたり最適化できないからやってもしょうがないと結論づけている。
- プロセスを定義した一部の人は満足しているが、仕事が増えて厄介だ、と思っている人もいる。
- たいして使っていないツールの使い勝手に難癖をつける。
- 開発コストを把握しておらず、ツールの費用対効果が判断できない。
- どうせ一人で全部やる（縦割り）ので、中間成果物を作る必要性を感じられない。
次のフェーズ「改革」とのギャップを乗り越えるために、エクスモーションのトータルコンサルティングでは、上流工程からの見直しで、さらなる生産性の向上に着手します。
