【12-A-7】「使う」と「作る」がつながるシステム開発
12-A-7 「使う」と「作る」がつながるシステム開発
[モデレータ]平鍋健児
[パネラー]倉貫義人、千貫素成、橘浩則
[グラフィッカー]藤原士朗
パネルディスカッション。ファシリテーションを用いた議事録が発散しやすい議題を
うまくまとめていて、普段馴染みのないSI業界を中心にお話されていましたが
わかりやすかったです。
12-A-7 「使う」と「作る」がつながるシステム開発 ※パネルディスカッション ◆テーマ システムは利用されてはじめて価値が創出される。 システムを使う側とつくる側でどの程度コミュニケーションが取れているのか? 日本でアジャイル・価値の高いシステムを作りたいが、とてもやりにくい実感がある。 技術的問題からなのか、SIといったビジネス構造の問題なのか。 ユーザとシステム部門でもっと密なコミュニケーションをとれないだろうか? イメージとしては作る人と使う人の間に川が流れている。 その両者でどうやってコミュニケーションをとるのか？ 作る人 |_(川)_| 使う人 ?フェリーを使う：船に仕様書を乗せてやりとりを行う。 ?橋をかける ：人が行き来して人同士のコミュニケーションをとる ◆問題提起:仕様書だけに頼るリスクが存在 フェリーのやりとりは万能ではない、人同士のコミュニケーションを活用できないか?★ 【以下自己紹介、課題意識、立場表明のあとディスカッション】 ◆倉貫 義人 XPユーザー会、SKIPユーザーグループ TISでデスマを経験、XPとの出会い SIerの開発を「ディフェンシブな開発」と表現。 問題意識:SIer と 顧客でシステムの思っている形が違う SIerは最初の要求以上のことをやりたくない(追加コストを恐れる) ⇒ ディフェンシブな開発 ソフトウェアを受託以外で開発するには? ビジネスオーナーとなってサービスの提供をする会社になればいい ＝ ユーザとシステムを内部に抱えるサービス会社を立ち上げ ◆千貫 素成 三菱UFJフィナンシャルグループのIS子会社 グループ内のIT基盤構築など全体最適化を推進 勘定系メインフレームを担当、最近では電子商取引基盤やJEE共通基盤などビジネス展開 問題意識:要件・設計・実装といった役割分担が弊害を生む 要件:ユーザ部門 設計:システム部門 実装:外注企業 ⇒ 勘違い、あいまいさが原因で手戻りが発生。組織の違いが壁となる。 ユーザ部門全部できればいいんじゃないか★ → 優秀なSEでコミュニケーション能力が高い人を引き抜いて部下にしてしまう。 ハイレベルな人材が必要で高コスト。 コストをかけなくても将来的には 設計・実装技術の進歩によって一体化も考えられるでは？ ◆橘 浩則 TIS株式会社 1986年 知識ベース開発、構築 ミドルウェア作成、ビジネスシステム・商用WEBサイトの開発プロジェクトマネージャ 現在のSIerは価値の生産性が低い。 例としてリフォーム屋に500万わたすと劇的だが SIerに500万わたしても大したものがないのが問題 使われないシステムがつくられるより 間違ったシステムを全員が使っていることのほうが問題 SIerとは Sierは人材の育成、チームをつくる。 サービスの創造：同じようなシステムを繰り返し作成により、ノウハウを蓄積 不確実性の担保：ソフトウェア開発はつくり始めるときはちゃんときまってない。 その段階でのコストをFixしてしまう保険業でもある。いつまでもコストが増え続けるリスクを減らす。 製造業、プロフェッショナルサービス業、アウトソーサー、サービサー いずれでもあるややこしい、面白い仕事。 【ディスカッションはじめ】 ◆SIerが何故あるのか? 現在の業態の位置づけ SIerが関わらず、ユーザ部門でのシステム開発の全部を賄っている場合もあり ただし、一部のお金を持ってるユーザ部門のみ。 → 全部に適応できる範囲ではない システム部門ではSIerをつかわず、設計まで行うべきだが 現状として人員がないときはSIerさんに一緒になって仕事をする必要がある ◆SIerからは全部内製するシステム開発はどう見えるか? 一つの統合された体制でシステム開発を行うプロジェクトは1つの方法。 ディフェンシブな開発が発生しにくい。 しかし、一緒にやる場合はSIerとしてではなく直接雇用のほうが幸せではないか。 → 直接雇用は流動性が確保できない。 偽装派遣などコンプライアンス上の問題も発生しやすいので契約上の整備が必要で難しい。 開発プロジェクトのなかで責任分解点があると 共通のゴールを「作る」側と「使う側」が共有できない。 ⇒ 本来の姿としてビジネスを一緒にやっていきたい。 パートナーとしてやっていけるのが一番。 ◆SIの役割 もし仮にユーザ企業が技術者をすべて雇うとすると技術者の技術的な幅が狭まる。 プロジェクトマネジメント、ソフトウェア開発の専門的な技術者はSIerが担当すべきでは？ 現在のSI業務形態、プロジェクトは否定するべき。 なんでもかんでもプロジェクトにして大きくする必要はない。 → 優秀なデザイナは問題を小さく分解する 問題の極小化の先にあるのはSaas(基礎があって個別に少しカスタマイズ)ではないか そもそも今回のテーマであるシステム開発という言葉の定義が広すぎる 管理を小さく分解することが必要、 小さいほうがコントロールもしやすい。 → 一つのプロジェクトを小さくしていく流れができればよい★ ★【脱線】企業で評価されるには 大きなプロジェクトを起こす！ 問題を小さくした方が優秀なはずなのに… トラブルを起こす！ トラブルシューティングでなぜか評価される。起こした責任は? → いずれも設計能力のある人は不在。 設計能力のある人をどうやって評価してあげるかが課題 SIerの場合 評価基準はまったく違うのでなかなか技術者同士を比較できない実態がある ◆今後、アジャイルのようなシステム開発は増える? ⇒ SIerとしてYES いろんなサイズの仕事があるが、ボリュームゾーンは数億レベルの仕事 このレンジは今後、SIerのビジネスモデルが不適当に。 → Saasの拡大 → オフショア → フレームワークの発展で低価格化していくため★ 現在の流れとして ITは本業回帰で内製したいものでアウトソーシングする対象では無くなってきている★ ⇒ 内製した場合、本当の下流しか外注されないため、SIerが必要な開発とはいえない。 それでは内製化されたあとも残る部分とは? 可能性の一つとして → 大規模開発は分解して全体をくみ上げる必要があるのでSIerがいるかも → SIerの専門性を確立するべき。 → ほとんどの企業はマネジメントやるのがシステム部門。 内部にSEを持てない企業に対してSIerが必要 ◆SIerとIS部門の価値が異なっている SIerはプロジェクトが大きいほうが「おいしい」 IS部門はちいさく分解した方が「おいしい」 ⇒ 価値観の違いをなくすためには ハイレベルのコンサルティングにフィーを払う仕組みが必要 上記の現象がおきることはそもそも人月単位での契約がまずいのではないか。 SEがうれしいのは注文住宅のように一坪いくら。 画面一枚いくら、という別の物差しを持つ必要がある★ → 建築業界は人足を絶対に見せない。 かわりにボルト一本9万円とか。たとえばスクロールバー１つ10万円とか？ ◆使うと作る側がつながるシステム開発とは 【回答?】アジャイルが一つの解。 ただし産業構造もあり、現在の仕組みの中ではむずかしい。 エンドユーザが自分でSEを雇っていくことがゴールを共有できる例。 【回答?】 コンサルティングという業務形態をひろげていく=橋をかける オフショアのフェリーとうまく使い分けること。 【回答?】「使う」と「作る」がつながるのはSaasで! ミッションを共有していく、その中に開発者を置く方がいい。 開発規模 大 もはや公共事業に近いので、専用の運営会社(ジョイントベンチャーでもよい) ｜ を作って、ユーザ企業と一緒にゴールを目指せばよい ｜ ------------------------------------------------- 小 Saasでよい分野 ｜ ユーザが独自に開発した方がよい分野 ｜ (開発者を中にかかえて作る) 基本機能 ←-----→ 特殊機能
