テーマ： アジャイル開発によるシステム内製化成功事例
日 時： 2011年7月26日（火）16:00～19:00
場 所： アーク情報システム（市ヶ谷）
講 師： 熊野 憲辰 氏 ゼリア新薬工業株式会社 情報システム部
■ はじめに ～ ユーザ側とベンダー側の問題
ゼリア新薬の熊野と申します。
本日は、当社がシステム内製化をした事例をご紹介いたします。
はじめに、自社の例をお話しする前に、現在のＩＴ産業の諸問題について、簡単に考えてみたいと思います。
現在、ユーザ側にもベンダー側にも様々な問題があります。
ユーザ側の一番の問題は、ベンダーへの丸投げが多いということではないかと思います。ユーザ側は、常識では考えられない額を支払っていて、まるでおカネを収奪されている様にさえ見えます。
ユーザ側のこうした背景には、技術力の低下、人材不足などがあると思います。 従業員1000人の会社で、ＩＴ部門の技術者が４～５人で、それも全員が50歳代などという例は、そんなに珍しくありません。
一方、ベンダー側でも、顧客囲い込み構造が見られます。一度食らいついたら離さないで、たくさんの人間を貼りつける構造があります。
ここには、ユーザ側の心理として、おカネを出しているから問題が起きたときに責任を押し付けられるという気持ちも働いていると思います。
このような問題には、以下のような背景があると思います。
1990年代後半に、アウトソーシングブームがあって、上流の仕事が上等で、プログラミングなどの下流の仕事を軽視する傾向が見られました。
このような背景の中、ユーザ側は、コア・コンピタンスに注力ということで、プログラムを軽視して、外注をする傾向が見られました。しかし、プログラムは、情報システムにおいてコア・コンピタンスであるはずです。
また、受託開発というビジネスモデルで、プログラマを人月単位で大量に企業に送り込むモデルの成功が、いまだに呪縛となっているともいえそうです。
しかし、もはやこのビジネスモデルは成立しなくなるだろうと思います。
ユーザ企業は、自社のシステムがどうやって、なぜ働いているのかわからなくては、身動きが取れなくなってしまいます。これこそ、コア・コンピタンスであります。
システム内製化が必要な理由もここにあります。
■ 変化は成長
(1) ソフトウェアをソフトに
日常でよく取り交わされる会話で、昨日言ったことと違うとか、朝言ったことと違うじゃないかという話になることはよくあります。
これを仕様変更だとか要求の変更だというのではなく、成長であると考えたいのです。
つねに変化し続けながら、成長していく必要があります。Agile開発について言えば、変化は友達であるということになります。
ソフトウェア開発というのは、よく自動車工学や建築工学と比較されます。共通の部品をたくさん作り、それらを組み合わせて構造物を作っていくという点は、似ているといえるでしょう。
ただ、ソフトウェアは「目に見えない」という点で難しさがあります。数学や芸術などが扱う概念や美というものは、やはり「目に見えない」ものを扱います。それでも、こちらは個人の産物です。
ソフトウェアの場合、多人数の組織で開発していきますので、共通の理解が得られないままもの作りを進めなければなりません。ここに、ソフトウェア開発の難しさがあります。
一方で、ソフトウェアには、明らかに強みがあります。簡単に作り直すことが出来るということです。マイホームを簡単に作り直すことは出来ませんし、マイカーを買うのも、そう簡単にはいきません。
モノには、しばらく使ってみて、初めてわかるニーズがあります。これがまさに成長にあたるものです。したがって、ソフトウェアが存在することによって、新たなソフトウェアのニーズが生まれる、ということがおきます。
その意味で、しばらく使ってみることが重要です。動くものを作ってみて、自分が変わっていけるということが、ソフトウェア開発のすばらしさで、この利点を生かすことが大切だと思います。
高速で回転する独楽は、常に変化を続けているといえます。この間、つねに外からエネルギーが与えられています。独楽がとまっていたら、それ を以って安定しているとは言いません。頻繁にバージョンアップをしたり、業者やサービスを変更したり、変化することが成長につながります。
その意味では、ソフトウェアは、「ソフト」という柔らかいものでなくてはなりません。簡単に作り変えられて、バージョンアップが出来てという存在である べきです。しかし、バージョンアップに多大なコストがかかったり、少し画面の構成を変えるのも、それなりのコストがかかったり、全くもって柔らかいとは思 えません。
現在はかえって、ハードウェアの方が柔らかいのではないでしょうか。仮想化にしろクラウドにしろそうです。サーバーの数を増やして全体のパフォーマンスを上げるスケールアウトも簡単に出来ます。
(2) Agile開発のイメージ
それでは、Agile開発というのはどういうものか、具体的なイメージをつかんでいただくために、家計簿の話をします。
友人から家計簿をつけたいと相談された場合です。その友人が以前から帳面などで家計場をつけていた経験があるなら話は簡単です。どういうことをしたいのか聞けば、ソフトを作るなり、アプリを紹介することが出来ます。
ところが、初めて家計簿にトライする場合、何がしたいかを聞いて話を進めると失敗します。聞けば言葉を返すかもしれませんが、友人は明確なイメージを持っているわけではありません。後になって、こんなはずじゃなかった…ということになりかねません。
この場合、正解は「一緒に考えよう」ということです。対話とフィードバックの中で、要求を実現していくことです。
こうした過程を辿ることは、ベンダー主導の受託開発では難しいと思います。
理由の一つは、ユーザ企業とプログラマが離れすぎていること。元請ベンダーが下請けベンダーに丸投げし、さらに孫請け～オフショアにというように、つぎ つぎ伝言ゲームが続いて、やっと末端のプログラマに到達します。これでは、一緒に考えることなど出来ません。
また、もう一つにベンダーはコストをどこかでFIXしたい、という要求があります。どこで終わるか分からないAgile方式では、リソースの手配等が難しい、ということになりAgile開発はうまくいかないでしょう。
■ 当社の事例
(1) 社内体制
これから、当社のAgile開発の事例をお話します。 上述のような問題意識の中、当社では自社での内製開発をすることにしました。具体的にはプログラミングとモデリングを行います。
その一方で、外部から技術コンサルを採用しました。しかし、リスクは当社で保有することとし、成果責任なし、瑕疵責任なしで来ていただきました。
社内体制は、構築チームが８名、モデリングチーム３名で、スクラムマスタ１名、技術コンサルが１名です。
構築チームが主役を担い、概念モデルから物理モデルを作成したり、アプリケーションの実装、それからモデリングチームと協働で、テストの実施まで行っています。
私は、モデリングチームにおりますが、このチームでは、データモデル、ユースケース、クラスモデル、画面定義などの作成を行っています。こうしたモデルを、構築チームに「発注」することになります。
スクラムマスタは、構築チームとモデリングチームが円滑に作用するようファシリテートする役割です。こちらも、技術コンサルと同様、社外から呼んでいます。
(2) Agile開発の実際
私たちは、1ヶ月単位で動くものを作るという方式を取りました。これを「スプリント」と呼んでいます。月初に構築チームに発注をかけて、月末までに週単位で４回まわすというイメージです。
不完全でもいいから、１週間でひとまず動くものを作ろうということです。それをレビューし、ブラッシュアップしていきます。
１週間単位のフィードバックループを「イテレーション」と呼んでいます。
こうしたスプリントとイテレーションがリズムを生んでいます。スプリントが、半年という単位だと長すぎてリズムにならないでしょう。
それから、朝会を、30分程度ですが、毎日行っています。朝、本日の仕事の確認と問題の共有を行います。
朝会で確認しているのがチケットです。チケットとは、行うことが明確である一つの仕事の単位で、Ａ５サイズの紙に書き込んだものです。１枚のチケットの仕事は、２～３時間で完成するものが目安です。
チケットの一番上にタイトルがあって、その下の領域が３分割されています。左側に担当者氏名、真ん中に予想時間・予定日を書き、右側に実績時間・実施日を書きます。
チケットを発行するのは、構築チームとモデリングチームです。この11名で、一年間に約4000枚が発行されています。業務の半分がチケットの仕事になります。
仕事の見える化が大切ですので、パーテーションを区切った４つのキャビネットにチケットを磁石で貼りつけて管理しています。「今週やること」、「今日や ること」、「今日やったこと」、「今週やったこと」に分けて、完了したものをそれぞれのパーテーションに移動させています。
基本的に、１つのチケットを２人で行う体制をとっています。このペアは、毎日変わります。二つの頭で考えようということです。それからナレッジの流動化をさせようという考えがあります。また、メンバー間の風通しをよくする意味もあります。
Agile開発を支えるツールは、ほとんどがOSS（オープンソース・ソフトウェア）です。システム開発には、継続的インテグレーションが 必要となりますが、そのツールとしてJenkins というOSSを使っています。これによってテストの完全自動化が行われます。どこかを直すと自動的に全システムを再チェックすることが可能です。
対話Appのテストには、SeleniumというOSSを使いました。その他のツールもほぼ、OSSを利用しています。
■ 技術獲得・人材育成
自社で開発を行う場合、技術が必要です。技術の獲得、人材育成は非常に大切になります。
そのためには、優秀なエンジニアを見つけることです。いろいろな人を紹介してもらう必要があります。
それで気がついたことは、優秀なエンジニアというのは、どこの会社の人ということではなくて、一人ひとりの個人的な資質であるということです。そして、フリーランスに優秀なエンジニアが多く存在します。
そして、優秀なエンジニアというのは、一種の引力で引き合い集まる傾向があります。そのような優秀なエンジニアの集まるコミュニティに行き仲間に入っていくのです。
優秀なエンジニアを考えるときに、イノベータ理論というのが、当てはまる気がします。これは、新商品を購入する段階から導き出された理論です。
新商品を真っ先に導入するのが、イノベータであり、次がアーリーアダプタ、そのあとに、アーリー・マジョリティ、レイト・マジョリティ、最後がラガード となります。この中のイノベータとアーリーアダプタという領域に、優秀なエンジニアがいるという感じがします。
この二つのあとには、溝（キャズム）があるようです。そしてこのキャズムは、そのメンタリティの違いから生じていると思われます。
イノベータやアーリーアダプタといわれる、新しいものに飛びつく人には、世界を変えてやろう、という気持ちで物事を考えています。そういう人を探すことが重要です。
同時に、優れたエンジニアを育てなくてはなりません。優れたエンジニアというのは、自ら進んで技術を学び成長できる人間だろうと思います。
そのような人材になるには、外に出て、優秀なエンジニアに会うことが必要です。優秀な人に出会って、それに刺激を受ける必要があります。そして、自分とのギャップを感じて、それをエネルギーに変えて、自ら学んでいこうという原動力にしていかないといけません。
もちろん、人材育成が簡単だとは言いません。教育には多くののお金がかかります。しかし、これはコストではなく投資であるのです。
■ エンジニアリング～モデリング
技術獲得のためにとった方針のお話をします。
技術は短く、原理は長いと言うように、トラディショナルなものをすることが大切だと思います。そのため、エンジニアリングに注力しました。
具体的には、モデリング技術の習得です。オブジェクト指向モデリング、ＵＭＬを習得していきました。モデリングは思考そのものですから、モデリングをやることによって、物事や世界を見る目が大きく変わります。
実際の例で見てみましょう。よくある社員マスターです。
社員コードを主キーとして、その下に、氏名、性別、役職コード、所属コード、入社日、退職日が並んでいます。
このようなテーブル設計をするエンジニアはたくさんいます。しかし、これではまずいのです。間違いがいくつかあります。
まず、氏名と性別を社員の属性にしている点が間違いです。社員コードで管理すべき事項ではありません。人員コードで氏名と性別を扱うべきです。それから、所属コードがここに入るのも間違いです。これは、人員と組織との関係として扱うほうがいいでしょう。
また、入社、退職は出来事です。イベントとしてモデル化することが正しいといえるでしょう。
実際、派遣社員が正式社員になり、あるいは正式社員が派遣社員になるということもあります。属性が変わって、いったん退職して入社してとなると、まったく同じ仕事を継続していても、先のモデリングだと、社員コードから変えなくてはなりません。
したがって、ERモデルを作る場合にも、人員コードを作り、役職コードと組み合わせることで社員をあらわし、さらに組織コードと組み合わせることで所属を明らかにすることになります。
さらにモデリングの例として、UMLのクラス図を書く場合を見てみます。
役員は従業員ではありませんので、人員を役員と従業員に分けなくてはなりません。さらに派遣社員も分けて考えないといけません。従業員は組織に所属す る、という表現を使いますが、役員がどこかの組織に所属するという表現には違和感があります。この場合、委嘱する、という言葉が適当でしょう。
また、従業員にも、正社員がいて、契約社員がいて、パートなどがいます。こうした社内の体制を一つずつ書いていかなくてはなりません。
こうやってモデリングをしていくと、結局、会社を書くことになります。会社のことが誰よりも詳しくなります。モデリングをすることは、現実世界を説明していくことに他なりません。
その意味で、オブジェクト指向のアーキテクチャが重要だと思います。情報（データ、又は属性）は現実世界のどこにあるのかという風に考えていくものですから、自然な考え方です。
こうしたことは、自社の人間でないとわかりにくいことです。ベンダーではわかりませんから、全てを説明しなくてはなりません。それが出来るでしょうか。
■ 原因について考える
おそらく従来型のSIベンダーや受託開発モデルは崩壊していくだろうと思います。現在の馴れ合いのような体制は続かないでしょう。
そのためにも、ユーザ企業が変わらなくてはならないと思います。ユーザ企業が変われば、ベンダーも変わってきます。繰り返しますが、変化は成長そのものです。変わることを恐れていてはいけません。
今後は、現場と一体化したITでなくてはいけないと思います。リテラシのある人が、現場と一体になってIT化を進めていくことでしょう。その結果として、ユーザ企業の情報システム部門も、拡散的に消滅するということも起こるかもしれません。
実際、企業の中にある様々なデータを、単に集計しても意味のある情報を得ることは意外と難しいのです。
例えば、顧客の成長度や、顧客の中での自社のシェアなどは、自社だけの販売実績では見えません。
ところが、営業マンは、この辺のところをみんな知っています。暗黙知というべきなのでしょうか、どの得意先に勢いがあって、そこに並べられている商品が どんなものであるのか、こうしたことを現場はわかっています。このような暗黙知を仮説検証することで、ITを真に武器にすることができるのです。
ただ問題なのは、10人の町工場なら、一番困っていることを明確に語ることが出来るのに、1000人規模の会社になると説明できなくなっていることでしょう。
やはり、自分たちで業務フローが書けなくては困ります。自分たちで自社を語れるようにすべきです。自分たちは何をしたいのか、それが語れるようにすることが大事です。
また、日本発のイノベーションを起こすためにはどうすればいいでしょうか？それには、失敗を繰り返すことが必要でしょう。日本には、失敗を穢れと感じる文化があるのかもしれません。
しかし、変化を成長とするためには、失敗が大切です。失敗を許容して、組織横断的な知識を練りあわせしていくことが大事になってくると思います。
日本には和を大切にする文化がありますから、チームワークや組織力という強みがあります。こういう強みを生かして、もの作りだけでなく、ルール作りにおいても、IT産業を盛りたてて行けたらと思います。
ご清聴ありがとうございました。
「講演記録・丸山有彦」
