【17-E-4】未来はどこにいても誰にでも平等にある。未来を創るのは自分自身だ。～SIerの中で生きるということ～

【17-E-4】

未来はどこにいても誰にでも
平等にある。未来を創るの
は自分自身だ。
～SIerの中で生きるということ～

川島義隆
TIS株式会社
産業事業統括本部
サービス&コミュニケーション事業部
サービス第1部

Developers Summit 2011

略歴

● 1999年 TIS株式会社入社
● 2011年現在まで同じ顧客の案件を担当

　　　　　　　　　　　　　　　　　　以上

artifact
● solr-jdbc
– http://code.google.com/p/solr-jdbc/
● dry-validator
– http://code.google.com/p/dry-validator/

2部構成でお話します

第1部 SIについて考える
第2部 SIerも変わらなきゃの事例

第1部

SIについて考える

終わったコンテンツ

SIerはオワコンか?

SI(er) への悲観論が
最近多いですねー

SI業界からはさっさと
抜けだしたほうがい
い。

日本のIT業界は救い
ようがない。
絶望的としか言いよう
がない。

「IT企業」という、よく意味の分
からないイメージだけで虚像の
信用を作り上げて、口先三寸で
仕事を受けて、一定の利益を
吸い上げて、下請けに仕事を
流しているだけの実態のない
会社の総称。
真・コンピュータ用語辞典より

確かに

建築業や製造業を模倣
してきた

でも何か違う
same different
・多重下請・生産性
・請負・品質
・工事進行基準・原価構造
・無形

情報サービス産業
なんです
構築するシステムはその手段。
だから作らないという提案も存在する

よって今日主張したいのは

SIはサービス業である
ということ

ここで言いたいサービスは

サービス精神
(も重要だけど)

ではなくて

他のサービス業の

お客さまとの信頼関係
生産性・品質

に学ぼう

こと細かく指示しなくても
エエ感じにやってくれる

こだわりの披露宴内容を
余すとこなく撮影し、
その最後に感動的に
Releaseする

究極のアジャイル

片や現在の受託開発は…

1から10まで全部聞かないと
作れない

(例)要件定義で出てくるもの

下のサムネイルだけではなんか寂しいか
ら、「次の写真」「前の写真」へのリンクを
つけたい

前へ　| 次へちょっとこの画像のサイズ大きすぎてメイ
ンの外観写真のインパクトが薄れるから
もうちょっと小さいサイズにしたい

3列表示だと隙間ができちゃう場合って、
4列にできないかなぁ。

(例)開発側からの確認事項

タブ押したときって、どの写真に遷移
するんですか?

規定より小さいサイズで入稿された
場合、どう表示しますか?
前へ　| 次へ

一番最後の写真に関しては「次へ」
のリンクは出さないでいいですか?

サムネイルの並び順は写真のコード
昇順でよいですか?

これでは…

SIはサービス業として再生しなくては！

(例)「フォトアルバム系の機能はこれできまり！」って
カタログがあればいちいち確認しなくてもよい
● メイン画像とサブ画像セットで1回の入稿として扱う。
–
それぞれの画像に対してキャッチコピーをつける。
–
画像ごとのキャッチコピーとは別に一覧表示用のキャッチコピー
もつける。
–
一覧表示用のキャッチはサムネイルと同時に出す。
–
写真にはタグ付けができ、それで検索が可能。
–
写真が規定より小さいサイズの場合は、センタリングして余白を
埋めて、規定サイズにする。

● 他へのページのリンクをつける (相互集客効果)
前へ　| 次へ –
入稿物は並び順の属性をもち、写真の入稿時に指定する。
–
一番最後の並び順の写真からは一番最初の写真へリンクする。
–
掲載主で1件の写真しかない場合だけ、「前へ」「次へ」のリン
ク自体をトルツメする。

–
● これでお任せしていただければ○○円で提供できます。

SIerのサービス業化のために必要なこと

たくさんのプロジェクトの経験を活用し
お客様にプロフェッショナルな
「サービス」を提供しよう！

第2部

SIerも変わらなきゃの事例

第2部の事例のベースとなる環境

開発プロセスモデル
ウォータフォールだがSCRUMに近い

開発言語
Java BTS
フレームワーク redMine
SAStruts Build
DB Maven2
Oracle / MySQL / Solr CI
IDE Hudson → Jenkins
Eclipse QA
Testlink

「おまかせ」してもらえる
プロフェッショナルな
開発ができるようになろう

プロジェクトマネージャに
権限が集中していて
専門性が発揮できていない
ことが多い

計画と遂行での
役割を分ける

拡大解釈してこう考える

ITA 計画に責任を持つ

PM 遂行に責任を持つ

ITAが
計画フェーズで行うべき
5つの設計

1. System meta design
2. Process design
3. Automation design
4. Communication design
5. Presentation design
※これらは直行してないので内容にはダブりがあります

1.開発者が何を決めるかを決める
2.アーキテクチャにあわせて体制
を決める
3.高度のスキルを要求する機能を
集中させる

システムのデザインコンセプト
inject

フレームワーク
サブシステム分割
設計ドキュメント
開発環境
・・・

PMとの関わりの部分で

アーキテクチャが重要な
のは、チーム体制を左右
するから

コンウェイの法則
システムを設計する組織は、そ
の構造をそっくりまねた構造の
設計を生み出してしまう

失敗例:
アーキテクチャが密なところで、
チーム分割してしまう。

アーキテクチャが疎なのに、○
○共有会なるものをたくさんやっ
てしまう。

プログラマの生産性の問題
プログラマの生産性は、その能力に
よって10〜20倍違いがある

本当にそう思うが、エンタープライズの
開発では、そうでないプログラミングの
領域もたくさん存在するのも事実。

体制とアーキテクチャを結び付けた例

例えばこんなシステム間連携をする
プロジェクトがあったとする
Aシステム Bシステム

Cシステム Dシステム

ハブ-スポーク型のアーキテクチャを
採用し、高スキルなエンジニアを集めて
チームを作ると効率よく開発できた。
Aシステム Bシステム

Mediator

Cシステム
Dシステム

1.アーキテクチャにあわせてタス
クの順番を決める
2.開発者の日々の作業のリズム
を設計する

WBSじゃ分からないこと
どういう順序でタスクを進めるか?
ボトルネックとなりそうなタスクは
どれか?

そしてこれはアーキテクチャにも
依存する

Serviceクラスを作るためには、
Entityクラスを先に作る必要があって、

Entityクラスを作るためには、
ER図に物理名が埋まっている必要があって、

ER図に物理名が埋まっているためには…

【17-E-4】未来はどこにいても誰にでも平等にある。未来を創るのは自分自身だ。～SIerの中で生きるということ～

1.ボトルネックタスクのところを中
心に自動化する
2.自動化によって浮いたパワーをど
こに使うかを設計する

例

DBAがボトルネックになると、開発全
体に影響がでるので、徹底してそこ
を自動化しています。

Project repository Programmer

DBA

Source Maven
codes projects
Maven
Entity
projects

Data H2
for Tests Database

ERD Apache
Solr

自動化のアンチパタン
xxxをxxxツールによって自動化
し生産性向上しました (おわり)

例えば、
「redMineを使いたいんですけど」
「今のExcelと何が違うの？」
「更新のメール送んなくても自動で送信してく
れるんすよ」
「そんなこと面倒臭がってちゃダメだ。社会人
なんだから。」
「…分かりました(やれやれバカな上司だ)」

な会話は効果の狙い所が異なるから起こる

自動化を導入するときは、効果を定量化する
までいかなくても、

自動化によって○○という役割にあてて
いたパワーを△△に使うことができます
という文脈で話をするとよいです。

1.コミュニケーションパスを
設計する
2.コミュニケーション手段を
設計する

チケットをどういう順序でまわしてい
くかは、トラッカ毎にこと細かに決め
ています。

SIerのコミュニケーションはメールに
依存しすぎ。1日200通とか…

多い人でも1日100通以内に収まる
ようにコミュニケーションパスと手段
を設計する

連絡的なものはIMにしている。
「チケット確認してください」
「tomcat再起動します」
「ビルド失敗だよ」

Presentation Design

Most important

1.成果の見える化を計画する
2.形式知を暗黙知に変換させる

ふりかえりのアンチパタン

突発のタスクがたくさんあって、進
捗遅れの原因となった。
次からはタスク見積りにバッファを
もたせて、余裕のある計画作りをし
ます。 (おわり)

こういうふりかえりでないと

どういうものを作ったのか?
お客さまが喜んでくれたところは?
時間がかかったことは何か?
それはそれだけの時間をかけるもの
だったのか?

※収益的な話は外してます

SIのプロジェクトにおける課題

共同化表出化

内面化連結化

内面化→共同化
連結化→内面化に壁がある

プロジェクト間のキャズムを超える

超えさせる手助けをするのがITAの
役割。ここは今考えています。

本日のダイジェスト
SIはサービス業に立ち返ろう
そのためにはまずプロフェッショナルな
仕事が必要なんじゃないかな

プロジェクトを計画と遂行で
責任の所在を分けて挑戦してみてます
(参考になれば！)

ありがとうございました

【17-E-4】未来はどこにいても誰にでも平等にある。未来を創るのは自分自身だ。～SIerの中で生きるということ～

More Related Content

What's hot (20)

Similar to 【17-E-4】未来はどこにいても誰にでも平等にある。未来を創るのは自分自身だ。～SIerの中で生きるということ～ (20)

More from Yoshitaka Kawashima (20)