開発の再生「常識も進化すべきではないでしょうか？」

2010年02月25日 06時00分更新

岡本浩一郎

“開発の再生”を掲げた岡本社長。とはいえ、根本から対策を講じた場合、それなりのリスクとコストが発生する。「経営としてどちらを取るか。「とりあえず今年は」で問題を（また）先送りするか、「開発の再生」を図り将来に備えるのか」弥生は後者を選択した。

経営的観点と開発という観点

　弥生株式会社の岡本です。前回は弥生の社長に就任するまで、そして、社長として最初に取り組んだのが、開発の「再生」というところまでお話しさせて頂きました。

　繰り返しになってしまいますが、弥生の製品はどれも素晴らしいものです。スクラッチで開発すれば軽く数億円はかかるであろうものを、多くの方にご利用頂くパッケージソフトウェアという形態とすることにより数万円で提供できているわけですから、特に費用対効果という意味では、極めて優れていると自負しています。

　しかし、ソフトウェアを、ビジネスニーズの進化や、そして特に業務ソフトにとっては必須となる法令改正に対応させるために、何年にも渡って保守をしていくということは、経営的には必要なことでも、開発という観点では決して容易なことではありません。弥生に限ったことではありませんが、経営的には最小の保守コストで最大の効果を生むことを要求しがちです。ただこれは、前回お話したように、ノウハウの属人化、コード疲労、品質の不安定さ、エンジニアの疲弊といった弊害を生みがち。そしてこれらは程度の大小はあれ、弥生の開発でも無視できない状態でした。

開発の再生
まずは定石

　これらの課題に対し、打った手の多くは定石とも言えるもの。まずは、プロジェクト管理の徹底。プロジェクト管理の重要性は改めてお話する必要もないと思いますが、プロジェクト管理を徹底しなくも何とかなるサイズの案件が中心となっていたこともあり、誰がプロジェクト・マネージャー（PM）なのかはっきりわからない、あるいは肩書はPMでも実態はMicrosoft Project屋になっていることもありました。

　そこで、PMを名実ともにプロジェクトのすべてに対し、権限と責任を持つ者と明確に定義し、強い問題意識と責任感を持つ人間をアサインしました。ここで注意すべきなのは、権限と責任をセットとして与えること。よく責任だけを与えて、権限を与えないケースも見聞きしますが、PMも人間。無理なスコープや無理なスケジュールでがんじがらめにしておいて、お前はPMなんだから何とかしろというのは経営としての責任逃れに過ぎません。スコープやスケジュール、リソースなどを必要に応じ変更する権限がなければ、プロジェクト管理は成り立ちません。むしろ責任については、何が起ころうと最終的には経営者の責任です。

　2つ目はドキュメント化とレビューの徹底。当然それまでも必要性は認識されており、ドキュメントがなかったわけではありません。特にプロジェクトの当初は、キチンとドキュメント化が行なわれ、それに対するレビューもされていたのですが、プロジェクトが進み、スケジュールが厳しくなってくると、ドキュメントは省略、当然レビューもスキップということが発生していました。本来は厳しいプロジェクトほどドキュメントとそのレビューの必要性は高いはずなのですが。

　これに対しては、改めてドキュメント化とレビューを徹底。ただ、徹底と口で言うだけでは、結局何も変わりません。ドキュメント作成とレビューの工数を適切に確保すること、そしてレビューを通じ、ドキュメント化が不十分であれば次の工程に進めないようにすることが必要です。

　3つ目は、上流工程からの品質の作り込み。品質は「磨く」ものではなく、「作り込む」ものです。しかし、スケジュールの制約から、ドキュメントの作成を省略しているようでは、ホワイトボックステストの実施もおざなりになりがちです。そんな中でどうやって品質を確保するのか。それはブラックボックスかつ人員の大量投入による「もぐら叩き」。このもぐら叩きで何とかお客様にご迷惑をおかけしない品質は確保されていたものの、効率の悪さは明らか。また、一歩間違えれば大きな不具合を生みかねない状態でした。

　下流工程で一生懸命「もぐら叩き」をしても、それは所詮表面だけを磨くことに留まりがちです。本来は、上記でお話しした設計書の作成、そしてレビュー等を通じて、上流工程から品質を作り込む必要があります。当然そのために、リソースの配分を大きく見直しました。上流工程により多くの時間をかければ、逆に下流工程のもぐら叩きを（様子を見ながら徐々にではありますが）減らすことができます。

次ページ「リファクタリングのメリットは明らか」に続く

前へ 1 2 次へ

ツイートする

弥生トップへ