ポストSIビジネスのシナリオ: アジャイル型請負開発（3）実践事例

アプリケーション | コンサルティング | システムインテグレーション | ビジネス

» 2014/08/01

「なんだかんだと言われても日本の製造業が世界で一目置かれているのは、生産技術を極めてきたからですよ。ＱＣサークルによる不断の改善活動、多能工を育てて小ロットでもこなせるセル生産、ジャストインタイム……そういうプラクティスを日本は生みだしてきましたからね」

岐阜県にあるＮＰＯ法人　ドットＮＥＴ分散開発ソフトピア・センター理事長　戸田孝一郎氏から、そんな話を伺った。

「岐阜県にもたくさんＩＴベンダーがあるけど、どこも大手の下請けで仕事をしています。だから、ＳＥやプロマネができる人なんてほとんどいません。当然、安い単金でこき使われて、利益もわずかです」

そんな現実をなんとかしたいと、このＮＰＯ法人を立ち上げたとのこと。

「ＳＥやプロマネはいないけど、実直に仕事をこなすプログラマはたくさんいます。そういう人にアジャイル開発のスキルを身につけてもらい、儲かる仕事を増やしてもらうのが、設立の目的です」

このＮＰＯ法人は、ユーザー企業から受託開発案件を受注、エンジニアを地場のＩＴベンダーから出してもらい、アジャイル開発で案件をこなす仕事をしている。

「研修で学んでも実戦で使えるスキルは身につきません。だから、私たちが営業して案件を受注し、実際の仕事をアジャイル開発でやってもらいながら、スキルを身につけてもらっています」

その成果は、想像以上のものだった。

＊８ヶ月のプロジェクト期間中、残業や休出はゼロ

まずは、自治体向けの会計パッケージを販売しているベンダーから受託した案件。自治体の会計が単式簿記から複式簿記へ変わることになったので、それにあわせて機能追加の開発をしてほしいという依頼だった。当初は大手ＳＩ事業者へ発注することが決まっていたそうだ。それを半額に近い金額を提示し、ひっくり返して受託したのだという。開発は２００８年５月に開始、12月に納品するという約束で仕事を引き受けた。

「最初は先方も半信半疑でしたよ。地方のベンダーにどれだけのことができるんだ、とね。そんな折、先方の考えを変えるある事件があったんです。開発の条件として、既存システムのプログラム部品を流用することになっていたのですが、その出来が悪くて、思うようにはかどらないんです。そこで、そのことを詳細な理由とともに指摘し、自分たちで直しちゃったんですよ」

また、こんなこともあったそうだ。

「単式簿記から複式簿記に変えることは決まっていたのですが、国からは詳細な手順がまだ示されていなかったんです。そこで、複式簿記をすでに適用していた岐阜県のやり方を参考に、その仕事を手がけた会計士にアドバイスを受けながら、開発チームがどんどんと先に作って、発注側に確認してもらうやり方で開発を進めました」

そんなことをやりながら、納期まで２ヶ月を残して、10月にシステムは完成した。

発注側は、残りの２か月かけて徹底してシステムを検証することになっていました。ところが、既存システムで大きなトラブルがあって、検証どころではない事態になったそうです。

「先方は、こちらが優秀だってわかっていたので、検証は後回しでいいから、トラブルの火消しを手伝ってほしいと頼まれましてね、それで１ヶ月をそれに使いました。それからやっと検証となったのですが、重大なバグはなく、ほとんどやることもないままに、予定どおり納品しました」

８ヶ月のプロジェクト期間中、残業や休出はいっさいなかったそうです。

もうひとつ、戸田氏が「アジャイル開発の本領を存分に発揮できたんじゃないかなぁ」とおっしゃる、特殊織物を作る工場の生産管理システムの開発事例も興味深いものだった。

「中小企業のイノベーションを支援する国の助成金があって、その会社がＲＦＩＤを使った部材管理のシステムで申請したところ、受理されたんですよ。これまで手作業でやっていた膨大な部材の管理をシステム化できれば大幅なコスト削減になるし、ミスもなくなり、品質向上にもつながるということで」

そこまではよかったのですが、プロジェクトの条件は厳しいものでした。

「受理されたのは２００９年10月末、11月からプロジェクトスタート、納品は翌年の３月。ほとんど時間がありませんでした。やりたいことは決まっていましたが、詳細な仕様は何も決まっていなかったんです」

ユーザー企業は、新しい生産技術を作らなければなりません。それにあわせて、織機メーカーが、機械を改造する必要がある。そのうえで、システムを開発しなければならない。

関係者が相談の結果、すべてを同時にスタートさせることを決めたそうだ。

「最初は、生産方式を決める打ち合わせが続いたのですが、詳細になると必ず複数案が出てきて、１つに決められない。仕方がないので、システム開発チームは、適用される可能性が高い２つの案を選んで、翌週にはシステムを作ってしまうんです。そして、それをデモして、どうしましょうと迫る。それを繰り返しながら仕様を固めていきました。システム開発チームが常に先行し、全体を引っ張っていましたね」

そして、１ヶ月間程度で仕様を固め、12月から本格的な開発をスタート。翌２月にはコーディングを終えて、３月にはバグなしで納品できたという。

「これまでにお付き合いのなかった、初めてのお客様でした。しかも、生産技術がわかるエンジニアは１名だけ。あとは、みんな生産管理システムを開発するのは初めてでした。もちろん、残業や休出はいっさいありませんでしたよ」

これはまさに日本の「ものづくり」のやり方そのものではないか、と話を伺いながら考えていた。なぜ、このやり方を日本のＳＩ事業者は取り入れられてこれなかったのだろうか。

「ソフトウエアの業界は、これまで、人を大切にしてこなかったと思いますよ。自分たちが何を作っているのか、どんなふうに使われているのかを伝えようとはせず、言われたとおり作ればいいという考え方です。人を工数としか見ていない。そんなことでは、仕事にプライドを持てないし、がんばろうという意欲も湧かない。だから、３Ｋ（きつい、帰れない、給料が安い）な職場だなんて言われるんです。そんなところで、プログラマの自発性や自律性を前提とするアジャイル開発なんて育ちませんよ」

「アジャイル開発は、システム開発の手法じゃないんです。システム開発の現場での働き方なんです。だから、そういう職場を作らなきゃいけない。それがなくて、手法だけ取り入れても、アジャイル開発なんてできません」

簡単なことではないという方もいるだろう。しかし、これまでのやり方を続けてゆくことのほうが、もっと簡単なことではなくなる時代になるだろう。

＊更新しました＊　今週のブログ ---

専任の “「お客様の立場」責任者” を持つ

「なんで、俺たちが、そんなことしなきゃいけなんですか？」

ある社内プロジェクト会議で、ベテランのエンジニアが、営業の責任者にかみついていました。こんな不毛な議論を続けても、仕事がうまくすすむわけはありません。

なぜこんなことになるのでしょうか。どうすれば良いのでしょうか。

今週のプログは、そんなことを考えてみました。