第11回例会報告
2月17日に第11回システムイニシアティブ研究会（例会）が開催されました。
今回のテーマは「ベンダーからグリップ（責任と執行）をとりもどせ！」。
講師は、東急ハンズCIOの長谷川秀樹さんです。長谷川さんは、SIer側でコンサルタントをされた後、東急ハンズに移られた方です。SIer側とユーザー側の両方を経験して長谷川さんから、SIer側でモヤモヤしていたこと、そしてユーザー側でそれをどう受け止めて現実的なバランスのとり方をしているか、をお話しただきました。
「バーサタイリスト」が必要とされている
バーサタイリストとは、「これだけがすごくできる」という「スペシャリスト」ではなく、「あれもこれもできる」という「多能工型の人材」。IT業界では「システムばかりでなく、業務をわかるようにならないと」と言われてきたが、いざユーザーに「でも実際の業務はこうだよ」と言われたら、結局それに従ったりする。それならば、業務を知り尽くしているユーザーがシステムの作り方を知って作った方がよいのではないか、と長谷川さんは考えられ、東急ハンズでは現場の人（店舗で販売をしている人）がシステム開発をすることにしたそうです。
ユーザー側で「バーサタイリスト」育成をされているわけです。
SIer側でモヤモヤしていたこと
- システム構築の工数（見積費用）が、企業規模に比例する。 ただし、大企業に小さいSIer、あるいはその逆で仕事をした場合、コンフリクトが起こりやすい。 なぜなら、求めるドキュメントや手続きなどの感覚のずれがあるから。
- 仕様書、設計書作成に相当な工数をさいているが、もっとシンプルにならないか。 プロジェクトのカットオーバー後は、仕様書のメンテナンスはユーザーに移るが、できない。 結局ソースコードを読むことになる。
- ガチガチのウオーターフォール型のシステム開発手法は、そもそも、無理があるのではないか。 ソフトウェアの場合、要件がモヤモヤしている状態でつくり、目に見えるものができてくるのが カットオーバーになってから。モヤモヤしているのに、予算が固定しているので、 途中で変更しずらいし、「これは要件に入っている」「入ってない」という争いになりやすい。
- SIの請負契約には、そもそも無理がある。 自社開発でなくても、要件が決まり切っていない状態では、発注側のユーザーが責任をもって、 時間でエンジニアを雇い「こう作って」と言い、違っていたら自分の責任で「変えてくれ」というべき。
- 何故、ホスト時代は情報システム部でCOBOLを書いていたのに、 だんだん、プログラミングは外注になってしまったのか。 オープン化によって、覚えないといけないことが増え、業務も複雑化したのが原因。
- ハードウエア性能は、昔のスパコン＝今のケータイなのに、何故、朝まで夜間バッチがまわってるのか。 売上が伸びて少しはデータが増えたかも知れないし、より細かいメッシュの分析が必要になったかも しれないが、ハードウェアの性能の伸びと比例していない。
- OSやミドルウエアをバージョンアップするのに、何故、費用が発生してしまうのか 保守料、運用費、これは、いったい、どんな作業が発生しているのか？ ユーザーが要求したことでないのに、保守切れなどが原因で変えなければいけない。 しかも、パッケージソフトのメジャーバージョンアップは、0から同じだけの労力がかかったりする。 ユーザーは保守料を、税金のように「払わないといけないもの」と思っている。
自社開発による解決
自分たちで自分たちのわかっている業務のシステムを作るメリット
- 長時間の業務ヒアリングや設計が不要
- 管理や引継ぎ、納品するための大量のドキュメントは不要
- 現場のニーズにあわせてシステムをどんどん変更できる
- 日々使っているデータのことだから、DB設計もやりやすい
- パッケージのバージョンアップ対応が不要
そのために気をつけていること
- あまり多くの技術を取り入れようとしない。なるべく単一の技術に絞る
- ユーザーニーズに応えて似たようなシステムが別々に作られたりしないよう、CIOが「これは作る」「作らない」を判断
- 加工前のローデータは全部もらうようインターフェイス設計をし、管理をきちんとする
- 他の人がみてわかるプログラムを書く
自社開発実現へのステップ
長谷川さんは、東急ハンズに入られたときから自社開発を志向されていたそうですが、 自分でも実現できるかどうかわからなかったので、既存のパッケージのやっていない範囲のシステムで、 かつ、お客様に迷惑のかからないシステムから着手し、できることを実証しながら徐々に範囲を広げていったそうです。 結果としてベンダーとの摩擦も少なかったとか。
効果
自社開発にして、コストは5分の1から10分の1に圧縮でき、開発期間は半減したそうですが、 「自分たちが優秀だからではない」と長谷川さんは言います。 ユーザーに納品するものや手続きが違うのだから、同じ土俵では比べられない。 自社開発にして省けることがたくさんあったからだ、ということです。
自社開発メンバーのキャリアパス
ファシリテータの田口さんから、80年代以降の記者としての経験の中で、情報システム部門で 問題になっていたのはキャリアパスだったという指摘がありました。システム開発会社でない ユーザー企業が、プログラムを書ける人をたくさん育てても行き先がないという問題です。 これに対して、長谷川さんから東急ハンズでの例を示していただきました。 東急ハンズでは、5年をめどに人事ローテーションの制度があり、情報システム部門のメンバーも 他部門の社員と同様にローテーションが行われるとか。プログラミングは営業では役に立たないかも しれないが、システムを開発することによって、営業の使うシステムが「なぜこうなっているか」を 理解し、業務がどういう風に回っているかを理解していることには意味がある。たとえば経理の 人が営業に異動したとき、数字の流れがわかっていることが営業に役立つことがあるのと同じだと いう説明に皆が納得しました。
ユーザーの根性
「自社開発でやらないとしても、我々ユーザーが『自分でやるんだ』という根性が足りてないのではないか」 と長谷川さんは言います。自社開発したシステムが止まったら、それは自分の責任。全部丸投げしたら 楽だけれど、モヤモヤは解消されない。 設計書などのドキュメントを大幅に省けたのも、開発スピードを短縮したり、コストを圧縮できたりしたのも 誰か他のステークホルダーにおうかがいをたてたりするのではなく「自分で決めるから。」という言葉には その「根性」が感じられました。 「講演ではSIer側の問題として語っているけれども、実は原因はユーザー側にあるのではないか、 という『システムイニシアティブ』の本質的な話」という田口さんのコメントに、 参加しているベンダー、ユーザーともに、自らを振り返る会となったのでした。
吉田太栄（システムイニシアティブ研究会事務局）
