Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie 第11回SIA例会プレゼン資料
Ähnlich wie 第11回SIA例会プレゼン資料 (20)
Mehr von Tae Yoshida
第11回SIA例会プレゼン資料
- 1. グリップ（責任と執行）をとりもどせ！ 2012/02/17 株式会社東急ハンズ 執行役員 ＩＴコマース部長 長谷川秀樹 Twitter:@sakuramaru55
- 2. 東急ハンズのご紹介 ヒントマーケットをストアコン セプトとし、お客様にヒント を提供できる企業を目指す コレカモさん、商品を探 してくれるツイッター連 動カモ型ロボット (korekamo.net) YouTubeで動画も配信 しています ネットストアもあるよ (www.hands-net.jp) 印刷日：2012/05/18 2 TOKYU HANDS INC. All Right Reserved.
- 3. 東急ハンズのご紹介 • 業態 ヒントを提供する会社 • 売上高 756億円（2011/03) • 従業員数 約2800 • ネット販売 http://www.hands-net.jp • ツイッター @HandsNet（商品お得情報） • ツイッター @TokyuHands （軟式） • ツイッター @HintMarket（公式 広報） • ツイッター @korekamo コレカモさんhttp://korekamo.net/ 印刷日：2012/05/18 3 TOKYU HANDS INC. All Right Reserved.
- 4. 東急ハンズのご紹介 • 1971年 三重県の田舎に生まれる • 1994年 アクセンチュア入社 コンサルタントとして – 業務改善、コスト削減、新規事業開発（小売業）、シス 企業の改善・改革の テム開発に従事 日々 • 2004年 プロクワイヤ株式会社（出向） – 米国Retek社のアジアパシフィックエリアの事業アウト ソーシングとして、プロクワイヤ社を立ち上げ、営業の ベンチャー魂、営業 責任者に就任 の日々 – オラクル社によりRetek社の買収により、事業をオラク ル社に引き継ぎ、アクセンチュアに出戻り。 • 2008年 東急ハンズ入社 – 店舗主導の業務を本部主導に業務改善、システムの 総入れ替え、自社開発に切り替え 今が一番オモシロイ – 経済産業省の委託事業として「korekamo.net」を受託 印刷日：2012/05/18 4 TOKYU HANDS INC. All Right Reserved.
- 5. システム業界をもっと、潤滑させ、よりより業界にしていきたい • 私は、94年から、ＳＩ業界で働いており、この間、システムエンジニアも営業も 経験しました。 • 2008年より、ユーザ企業（東急ハンズ）で働いております。 • 東急ハンズでは、ＳＩ企業で得た知見をフルに活かし、プロジェクトを推進し ております。 • 数年経過し、私の中で、 – ＳＩ企業の考え・やり方 vs ユーザ企業の考え・やり方 – 理想と現実のバランス • の整理もついてきました。本日は、システム業界の発展のため、発言させて いただきます。辛辣な発言もありますが、何とぞ、よろしくお願いします。 印刷日：2012/05/18 5 TOKYU HANDS INC. All Right Reserved.
- 6. 最近、DeNAの方と知り合ってですね、 • 自社開発と、自社サービス開発をしているWEBエンジニアとは、非常に似て いると感じました。 • また、ＩＰＡのＩＴ人材ガイドラインの委員会でも、バーサタイリストの台頭は必 至であるという話題もでております。 • DeNAの方のコメント – 本質的にコードが書ける人、がサービスのアイデアを考えないとダメ • 仕様書と実装を行き来しているとスピードが遅い • 上流と下流は分けることができない – 小さいチームのほうが、むしろ機動性が高く生産性が高い • これは、外注だと儲からないからそうはしない • 人を管理する、ドキュメントを書く時間が小さい • アジャイル開発が可能 • 決定は、自分であり、お客様ではない。 ニーズを調査？ ニーズを調査？ 要件定義？ 要件を整理？ ＩＴ部門 ＳＩベンダー 業務知ってる？ ユーザ部門 業務知ってる？ 要件ヒアリング？ 印刷日：2012/05/18 6 TOKYU HANDS INC. All Right Reserved.
- 7. システム業界で悶々としていたこと • システム構築の工数（見積費用）が、企業規模に比例してしまうのは、おか しいのではないか。例えば、何人の企業であろうとも、１つのシステムの要 件定義は、1人でできないのか？ • 原因 – 企業規模に合わせてた提案をベンダーがするから（企業の売上比で予算編成 がされる傾向が強いので、予算をユーザ企業がもっているから） – 組織数や人数が多いからという人もいるが、それも見積もりドライバーの一つで あるが、それ以上に、工数がふくらんでいる – （直接的原因ではないが）大規模プロジェクト経験者と小規模プロジェクト経験 者に、同じ企業への提案書を書かせれば、必ず、大規模プロジェクト経験者の 提案書のほうが、見積もりが高い。だから、自分の経験したプロジェクトの延長 線上で見積もりをするといが、まずいのかな。 • どうすればよいか – エンジニアに、小規模プロジェクトを経験させる。 – 大企業だからといって、“予算感にあった提案“はしてはいけない 印刷日：2012/05/18 7 TOKYU HANDS INC. All Right Reserved.
- 8. システム業界で悶々としていたこと • 仕様書、設計書作成に相当な工数をさいているが、もっと、シンプルになら ないか。（そもそも、プログラムコードと一致してる設計書は、この世に存在 するのか？） • 原因 – 大規模プロジェクト、ウォーターフォール型プロジェクトで引き継ぎが必要だから。 – 納品成果物に指定されているから。 • どうなったか – 開発後の設計書の変更作業は、工数がかかり、プロジェクト費用を圧迫する。 – 実際には、仕様変更時もプログラムを追い、設計書の本来の使われ方をしてい ない場合がおおい。 • どうすればよいのか – ソースコードのコメントに、スペックを記載する。 – 納品成果物のドキュメント種類を減らす 印刷日：2012/05/18 8 TOKYU HANDS INC. All Right Reserved.
- 9. システム業界で悶々としていたこと • ガチガチのウオーターフォール型のシステム開発手法は、そもそも、無理が あるのではないか。 • 原因 – Ｖモデルというのに沿って、要件定義をするが、所詮、ユーザというものは、“紙 の上で、１００％理解し、仕様を言える人はいない”。だから、そもそも、無理な 事に向かって、仕事をしていると言っても良い。 • どうなったか – ユーザ企業側は、「当初要件にはいっていたはず」と仕様変更料金を支払わな い→ＳＩ企業はそれを見越して見積もりをする。 – エンジニアは、意味のない仕様変更に嫌気がさし、モチベーションが下がる どうすればよいのか – ユーザ企業は、カットオーバー後の仕様変更費用を確保しておく。 – ユーザ自身が、システム開発をする（自社開発） – ７割程度の完成度でリリースし、ユーザのフィードバックをもとにシステム改修・ リリースするサイクルを高速にまわす。 印刷日：2012/05/18 9 TOKYU HANDS INC. All Right Reserved.
- 10. システム業界で悶々としていたこと • ＳＩの請負契約には、そもそも無理がある。業務委託契約にしよう。 • 原因 – ユーザ企業が、リスクをとりたくないがために、請負契約とベンダーと締結する. • どうなったか – そもそも、完成型イメージが完全でない（プロトタイプもない）システムに初期の 段階で、請負契約（金額をフィックスする）のは無理がある。 どうすればよいのか – 業務委託契約とし、ユーザ企業がグリップしていく。 印刷日：2012/05/18 10 TOKYU HANDS INC. All Right Reserved.
- 11. システム業界で悶々としていたこと • 何故、ホスト時代は、情報システム部でコボルを書いていたのに、だんだん、 プログラミングは外注になってしまったのか。 • 原因 – オープン化になり、複数の技術スキルが必要となったこと – それぞれ、専門性の高い人間がやるべき、という風潮になったこと – ＳＩ企業の営業戦略により、アウトソースの風潮になったこと • どうなったか – 情報システム部の弱体化がすすんだ – ＳＩ企業のＳＥも分業化がすすみ、全体をみることができるバーサタイリストが 減った • どうすればよいのか – シンプルな技術で１人で上流から運用までできる開発基盤が必要 印刷日：2012/05/18 11 TOKYU HANDS INC. All Right Reserved.
- 12. システム業界で悶々としていたこと • ハードウエア性能は、昔のスパコン＝今のケータイなのに、何故、朝まで夜 間バッチがまわってるのか。 • 原因 – 余分なミドルウエアが増えた？ – ＲＤＢのＳＱＬに任せすぎ？ – ＯＳも余計なサービスが立ち上がっている？ • どうすればよいのか ・ システムアーキテクチャのレイヤーを少なく（薄く）する 印刷日：2012/05/18 12 TOKYU HANDS INC. All Right Reserved.
- 13. システム業界で悶々としていたこと • ＯＳやミドルウエアをバージョンアップするに、（業務効果はないのに）何故、 費用が発生してしまうのか（バージョンアップしなくてもよいシステムにはなら ないのか） • 同様に、ＯＳ、ミドルウエアの2世代前しかサポートしないと宣言しているアプ リケーションソフトもどうにかならないのか。 • 原因 – ＯＳの、ミドルウエアの特定バージョンの機能に依存してしまっている、システム 開発基盤だから • どうなったか – 非常に無駄かつ虚しい作業・費用が発生している。 • どうしたらよいか – ＯＳ、ミドルウエアの細かいバージョンに依存しないシステム開発基盤が必要 印刷日：2012/05/18 13 TOKYU HANDS INC. All Right Reserved.
- 14. システム業界で悶々としていたこと • 保守料、運用費、これは、いったい、どんな作業が発生しているのか？経営 的には、“税金”のように見えてしまうのがおおい。 • 原因 – 赤字プロジェクト、提案時の無理な値引きのため、保守による儲けでＳＩ企業が 利益をだしていく構造となっている – 実質的には、保守、運用は、グレーなコスト構造が多く、ユーザ企業として納得 できる支払いにならない（付加価値の対価が不明確） – ユーザ企業も初期投資費用、初年度保守費用しか比較検討しない企業がある のも、原因の一つ • どうすればよいのか – 実費請求のビジネスに変更 – 初期投資＋5年分の保守・運用費用で、コンペの比較を行う 印刷日：2012/05/18 14 TOKYU HANDS INC. All Right Reserved.
- 15. ハンズでは、それを自社開発で解決しました。 • 今まで、悶々としてきたことが解決する方法、それが、「ユニケージ手法」に より自社開発を行うことです。 • 何がよいのか – リナックスＯＳだけあればいい。だから、速いし、落ちにくい。 – バージョン問題も気にしなくて良い。 – シンプルなコマンドによる生産性の高い開発。 – スペックはソースコード内にコメント記載 – 安い（リナックスサーバ＋コマンドライセンス料＋自社の人件費） • ユーザ企業で自社開発を開始したいという企業があれば、是非、オススメし ます。 印刷日：2012/05/18 15 TOKYU HANDS INC. All Right Reserved.
- 16. 実際の経営会議資料（2008年当時） – 今後のハンズの業務対応に俊敏に対応できるシステムが必要になるため、商売系のシステム は、基本的に自社開発をしていくことを検討しております。 – 外部業者に依頼する要員数を自社で抱えることになりますので、ＩＴ物流企画部の要員数は増 えることになりますが、コスト低減（80％削減）、ハンズの商売への俊敏な対応（2倍のスピード） などメリットがありますので、会社としてメリットがあると考えております。（例：良品計画、しまむら、ニトリな ど独自の業務モデルを志向している小売業は、自社開発をしております。） 1. 自社開発のメリット 1. コストメリット（ベンダーに依頼するよりも、開発コスト（システムエンジニア費用部分）が、五分の一程度に抑えることができる。（外部 業者は、人月１３０万～２００万必要） 2. 早く開発できる。（ベンダーに頼むよりも、開発期間が短くできる。約二分の一以下の開発期間が可能 自社開発に向いてい 自社開発が向いてい るシステム領域 ないシステム領域 商売系のシステム ・優れたパッ 財務会計システム 優れたパッケージ （データ分析） ケージがない。 人事システム システムがあるた （情報共有系） ・俊敏なシステ 給与システム め外部パッケージ （オープンセントラル） ム変更対応 勤怠システム を購入したほうが （ＨＣＣ分析） が必要 ＰＯＳシステム よい など 現在は、ＰＯＳ、人事領域も、自社開発のほうがいいなと考えております。 印刷日：2012/05/18 16 TOKYU HANDS INC. All Right Reserved.
- 17. 自社開発が向いているシステム領域 自社開発に向いている 自社開発をする必要が システム領域 ないシステム領域 「仕様変更がほぼない」 「仕様変更が頻繁にある」 かつ システム領域 「優秀なパッケージが存在する」 システム領域 印刷日：2012/05/18 17 TOKYU HANDS INC. All Right Reserved.
- 18. ユーザ企業へのメッセージ • 「グリップを取り戻せ！」 • 語弊があるかも知れませんが、我々ユーザ企業は、ＳＩ企業に、「舐められ ている」のではないか、と思います。 • その理由は、我々、ユーザ企業にあると思います。 – 「当初要件に入っていたはず」となんでもかんでも、押し込むから。 – ユーザ部門よりも、業務のことを真剣に考えないから。 – システムのことを勉強しないから。（ＳＩ企業に任せきりだから） • 自社開発化すれば、上記のことは全て解決します。少し、「システムダウンし たらどうしよう（もう、ベンダーのせいにできないなー）」ということのみ気にな りますが、根性をきめてやってはどうでしょうか。 印刷日：2012/05/18 18 TOKYU HANDS INC. All Right Reserved.