第11回sia例会プレゼン資料

グリップ（責任と執行）をとりもどせ！

2012/02/17

株式会社東急ハンズ

執行役員ＩＴコマース部長

長谷川秀樹 Twitter:@sakuramaru55

TOKYU HANDS INC. All Right Reserved.

2 印刷日：2012/05/18

東急ハンズのご紹介

ヒントマーケットをストアコンセプトとし、お客様にヒントを提供できる企業を目指す

YouTubeで動画も配信しています

ネットストアもあるよ

(www.hands-net.jp)

コレカモさん、商品を探してくれるツイッター連動カモ型ロボット(korekamo.net)


3 印刷日：2012/05/18


• 業態ヒントを提供する会社

• 売上高 756億円（2011/03)

• 従業員数約2800

• ネット販売 http://www.hands-net.jp

• ツイッター @HandsNet（商品お得情報）

• ツイッター @TokyuHands （軟式）

• ツイッター @HintMarket（公式広報）

• ツイッター @korekamo コレカモさんhttp://korekamo.net/


4 印刷日：2012/05/18


• 1971年三重県の田舎に生まれる

• 1994年アクセンチュア入社

– 業務改善、コスト削減、新規事業開発（小売業）、システム開発に従事

• 2004年プロクワイヤ株式会社（出向）

– 米国Retek社のアジアパシフィックエリアの事業アウト

ソーシングとして、プロクワイヤ社を立ち上げ、営業の責任者に就任

– オラクル社によりRetek社の買収により、事業をオラクル社に引き継ぎ、アクセンチュアに出戻り。

• 2008年東急ハンズ入社

– 店舗主導の業務を本部主導に業務改善、システムの総入れ替え、自社開発に切り替え

– 経済産業省の委託事業として「korekamo.net」を受託

コンサルタントとして企業の改善・改革の日々

ベンチャー魂、営業の日々

今が一番オモシロイ


5 印刷日：2012/05/18

システム業界をもっと、潤滑させ、よりより業界にしていきたい

• 私は、94年から、ＳＩ業界で働いており、この間、システムエンジニアも営業も経験しました。

• 2008年より、ユーザ企業（東急ハンズ）で働いております。

• 東急ハンズでは、ＳＩ企業で得た知見をフルに活かし、プロジェクトを推進しております。

• 数年経過し、私の中で、

– ＳＩ企業の考え・やり方 vs ユーザ企業の考え・やり方

– 理想と現実のバランス

• の整理もついてきました。本日は、システム業界の発展のため、発言させていただきます。辛辣な発言もありますが、何とぞ、よろしくお願いします。


6 印刷日：2012/05/18

最近、DeNAの方と知り合ってですね、

• 自社開発と、自社サービス開発をしているWEBエンジニアとは、非常に似ていると感じました。

• また、ＩＰＡのＩＴ人材ガイドラインの委員会でも、バーサタイリストの台頭は必至であるという話題もでております。

• DeNAの方のコメント

– 本質的にコードが書ける人、がサービスのアイデアを考えないとダメ

• 仕様書と実装を行き来しているとスピードが遅い

• 上流と下流は分けることができない

– 小さいチームのほうが、むしろ機動性が高く生産性が高い

• これは、外注だと儲からないからそうはしない

• 人を管理する、ドキュメントを書く時間が小さい

• アジャイル開発が可能

• 決定は、自分であり、お客様ではない。

ユーザ部門

ＩＴ部門ＳＩベンダー

ニーズを調査？

要件を整理？

要件ヒアリング？

ニーズを調査？

要件定義？

業務知ってる？業務知ってる？


7 印刷日：2012/05/18

システム業界で悶々としていたこと

• システム構築の工数（見積費用）が、企業規模に比例してしまうのは、おかしいのではないか。例えば、何人の企業であろうとも、１つのシステムの要件定義は、1人でできないのか？

• 原因

– 企業規模に合わせてた提案をベンダーがするから（企業の売上比で予算編成がされる傾向が強いので、予算をユーザ企業がもっているから）

– 組織数や人数が多いからという人もいるが、それも見積もりドライバーの一つであるが、それ以上に、工数がふくらんでいる

– （直接的原因ではないが）大規模プロジェクト経験者と小規模プロジェクト経験者に、同じ企業への提案書を書かせれば、必ず、大規模プロジェクト経験者の提案書のほうが、見積もりが高い。だから、自分の経験したプロジェクトの延長線上で見積もりをするといが、まずいのかな。

• どうすればよいか

– エンジニアに、小規模プロジェクトを経験させる。

– 大企業だからといって、“予算感にあった提案“はしてはいけない


8 印刷日：2012/05/18


• 仕様書、設計書作成に相当な工数をさいているが、もっと、シンプルにならないか。（そもそも、プログラムコードと一致してる設計書は、この世に存在するのか？）

• 原因

– 大規模プロジェクト、ウォーターフォール型プロジェクトで引き継ぎが必要だから。

– 納品成果物に指定されているから。

• どうなったか

– 開発後の設計書の変更作業は、工数がかかり、プロジェクト費用を圧迫する。

– 実際には、仕様変更時もプログラムを追い、設計書の本来の使われ方をしていない場合がおおい。

• どうすればよいのか

– ソースコードのコメントに、スペックを記載する。

– 納品成果物のドキュメント種類を減らす


9 印刷日：2012/05/18


• ガチガチのウオーターフォール型のシステム開発手法は、そもそも、無理があるのではないか。

• 原因

– Ｖモデルというのに沿って、要件定義をするが、所詮、ユーザというものは、“紙の上で、１００％理解し、仕様を言える人はいない”。だから、そもそも、無理な事に向かって、仕事をしていると言っても良い。


– ユーザ企業側は、「当初要件にはいっていたはず」と仕様変更料金を支払わない→ＳＩ企業はそれを見越して見積もりをする。

– エンジニアは、意味のない仕様変更に嫌気がさし、モチベーションが下がる

どうすればよいのか

– ユーザ企業は、カットオーバー後の仕様変更費用を確保しておく。

– ユーザ自身が、システム開発をする（自社開発）

– ７割程度の完成度でリリースし、ユーザのフィードバックをもとにシステム改修・リリースするサイクルを高速にまわす。


10 印刷日：2012/05/18


• ＳＩの請負契約には、そもそも無理がある。業務委託契約にしよう。

• 原因

– ユーザ企業が、リスクをとりたくないがために、請負契約とベンダーと締結する.


– そもそも、完成型イメージが完全でない（プロトタイプもない）システムに初期の段階で、請負契約（金額をフィックスする）のは無理がある。

どうすればよいのか

– 業務委託契約とし、ユーザ企業がグリップしていく。


11 印刷日：2012/05/18


• 何故、ホスト時代は、情報システム部でコボルを書いていたのに、だんだん、プログラミングは外注になってしまったのか。

• 原因

– オープン化になり、複数の技術スキルが必要となったこと

– それぞれ、専門性の高い人間がやるべき、という風潮になったこと

– ＳＩ企業の営業戦略により、アウトソースの風潮になったこと


– 情報システム部の弱体化がすすんだ

– ＳＩ企業のＳＥも分業化がすすみ、全体をみることができるバーサタイリストが減った


– シンプルな技術で１人で上流から運用までできる開発基盤が必要


12 印刷日：2012/05/18


• ハードウエア性能は、昔のスパコン＝今のケータイなのに、何故、朝まで夜間バッチがまわってるのか。

• 原因

– 余分なミドルウエアが増えた？

– ＲＤＢのＳＱＬに任せすぎ？

– ＯＳも余計なサービスが立ち上がっている？


・システムアーキテクチャのレイヤーを少なく（薄く）する


13 印刷日：2012/05/18


• ＯＳやミドルウエアをバージョンアップするに、（業務効果はないのに）何故、費用が発生してしまうのか（バージョンアップしなくてもよいシステムにはならないのか）

• 同様に、ＯＳ、ミドルウエアの2世代前しかサポートしないと宣言しているアプリケーションソフトもどうにかならないのか。

• 原因

– ＯＳの、ミドルウエアの特定バージョンの機能に依存してしまっている、システム開発基盤だから


– 非常に無駄かつ虚しい作業・費用が発生している。

• どうしたらよいか

– ＯＳ、ミドルウエアの細かいバージョンに依存しないシステム開発基盤が必要


14 印刷日：2012/05/18


• 保守料、運用費、これは、いったい、どんな作業が発生しているのか？経営的には、“税金”のように見えてしまうのがおおい。

• 原因

– 赤字プロジェクト、提案時の無理な値引きのため、保守による儲けでＳＩ企業が利益をだしていく構造となっている

– 実質的には、保守、運用は、グレーなコスト構造が多く、ユーザ企業として納得できる支払いにならない（付加価値の対価が不明確）

– ユーザ企業も初期投資費用、初年度保守費用しか比較検討しない企業があるのも、原因の一つ


– 実費請求のビジネスに変更

– 初期投資＋5年分の保守・運用費用で、コンペの比較を行う


15 印刷日：2012/05/18

ハンズでは、それを自社開発で解決しました。

• 今まで、悶々としてきたことが解決する方法、それが、「ユニケージ手法」により自社開発を行うことです。

• 何がよいのか

– リナックスＯＳだけあればいい。だから、速いし、落ちにくい。

– バージョン問題も気にしなくて良い。

– シンプルなコマンドによる生産性の高い開発。

– スペックはソースコード内にコメント記載

– 安い（リナックスサーバ＋コマンドライセンス料＋自社の人件費）

• ユーザ企業で自社開発を開始したいという企業があれば、是非、オススメします。


16 印刷日：2012/05/18

実際の経営会議資料（2008年当時）

– 今後のハンズの業務対応に俊敏に対応できるシステムが必要になるため、商売系のシステムは、基本的に自社開発をしていくことを検討しております。

– 外部業者に依頼する要員数を自社で抱えることになりますので、ＩＴ物流企画部の要員数は増えることになりますが、コスト低減（80％削減）、ハンズの商売への俊敏な対応（2倍のスピード）

などメリットがありますので、会社としてメリットがあると考えております。（例：良品計画、しまむら、ニトリなど独自の業務モデルを志向している小売業は、自社開発をしております。）

1. 自社開発のメリット 1. コストメリット（ベンダーに依頼するよりも、開発コスト（システムエンジニア費用部分）が、五分の一程度に抑えることができる。（外部

業者は、人月１３０万～２００万必要）

2. 早く開発できる。（ベンダーに頼むよりも、開発期間が短くできる。約二分の一以下の開発期間が可能

自社開発に向いているシステム領域

自社開発が向いていないシステム領域

財務会計システム

人事システム

給与システム

勤怠システム

ＰＯＳシステム

商売系のシステム

（データ分析）（情報共有系）（オープンセントラル）（ＨＣＣ分析）など

優れたパッケージシステムがあるため外部パッケージを購入したほうがよい

・優れたパッケージがない。

・俊敏なシステム変更対応が必要

現在は、ＰＯＳ、人事領域も、自社開発のほうがいいなと考えております。


17 印刷日：2012/05/18

自社開発が向いているシステム領域

自社開発に向いているシステム領域

自社開発をする必要がないシステム領域

「仕様変更がほぼない」かつ

「優秀なパッケージが存在する」システム領域

「仕様変更が頻繁にある」システム領域


18 印刷日：2012/05/18

ユーザ企業へのメッセージ

• 「グリップを取り戻せ！」

• 語弊があるかも知れませんが、我々ユーザ企業は、ＳＩ企業に、「舐められている」のではないか、と思います。

• その理由は、我々、ユーザ企業にあると思います。

– 「当初要件に入っていたはず」となんでもかんでも、押し込むから。

– ユーザ部門よりも、業務のことを真剣に考えないから。

– システムのことを勉強しないから。（ＳＩ企業に任せきりだから）

• 自社開発化すれば、上記のことは全て解決します。少し、「システムダウンしたらどうしよう（もう、ベンダーのせいにできないなー）」ということのみ気になりますが、根性をきめてやってはどうでしょうか。

第11回sia例会プレゼン資料

Documents