匠塾第10回 企業改革からIT構築までの見える化事例大集合
http://www.takumistyle.net/takumijuku/ps-010.html
大手町サンケイプラザにて開催された匠塾第10回 企業改革からIT構築までの見える化事例大集合に行ってきました。
客層はSIerのリーダーから管理職クラスが中心といった印象で、自分の様な若年層は少数でした。
企業改革での見える化事例
「ビジネス改革における見える化（モデリング）のポイント」
株式会社 匠BusinessPlace 代表取締役 萩本 順三
概要見える化に関して
- 職人気質とビジネスにつなげる力の2つが“見せる化”ではなく“見える化”のポイント
- 見える化にもビジネス戦略、組織構造、サービス、ビジネスオペレーション、ビジネスシステム、プロジェクトプランと色々ある
- ビジネス戦略(目的)とビジネスオペレーション(手段)を分けて見える化
- ビジネスとシステムの軸と戦略、オペレーションの軸で4つに分類すると、ビジネス戦略(ビジネス&戦略)→ビジネスオペレーション(ビジネス&オペレーション)→システム要求(システム&戦略)→システム設計(システム&オペレーション)の順につながっている
- エンジニアはシステム要求ではなくビジネス戦略とシステム設計から考えて設計を行う必要がある
- 見える化にはstep1)関係者の理解の為の見える化、step2)問題点、改善点の為の見える化、step3)覚悟の為の見える化の3つ段階がある
- 結局、見える化しても、その結果を受け入れる覚悟が現場になければ絵に描いた餅になる
- ビジネス価値とビジネス戦略は切り離して考える
- よくあるビジネス戦略はHowの勝ち組がパターン化されたWhatとして、概念化されただけ
- 価値を描く意識が必要で、エンジニアは描く力が足りない
- 最初に価値を描くことでブランディングが行える
ソフトウェアの見える化事例
「ソフトウェア開発に役立つビジュアル思考〜マインドマップ/UMLを現場で有効活用しよう〜」
株式会社チェンジビジョン 代表取締役 平鍋 健児
概要マインドマップとUMLによる見える化の事例紹介とastah*を使ったデモ
- マインドマップの紹介、本を読んだ際は本のマインドマップを描いて、表紙にホッチキスで止めていると実践されているらしい
- 日本ではUMLの利用者はセミナーで質問すると大体10％程度、でも今日は50%程度で珍しい
- ユースケース≠機能の抽出、ユースケースは重要だけどやっている人は少ない
- ユーザーの利用場面を捉えるものとして、利用する機能の抽出にしてしまうと細分化するだけになってしまう
- 要求収集の際はマインドマップは良い
- チケット管理システムのユースケース抽出のワークショップ
- 全てUMLで表現しようとしないで、人が読むことを意識する
- ユースケースにコメントはがしがし入れるべき
- こういうノウハウは本に載っていないので要チェック
- 平鍋さんのマインドマップのテンプレートの紹介
- マインドマップからユースケースを作成するデモ
IT構築での見える化事例
「ビジネス価値につなげたアジャイル開発」
株式会社永和システムマネジメント サービスプロバイディング事業部 木下 史彦
概要アジャイル開発について
スライド：ビジネス価値につなげたアジャイル開発
- お客の要求が常に変わっていく為、“ふつうのシステム開発”としてアジャイル開発をしている
- チームの人数は基本2、3人だが、最近だと10名のプロジェクトがあり、この人数でも回っている
- 設計はホワイトボードに書き、残しておかずに消してしまう
- 消して次の打ち合わせで書けないと、それは実は理解が出来ていなかったということが分かる
- お客様に対して悪いことも含めて正直に話すことで信頼が生まれる
- 1週1イテレーション
- 毎週受入テストを行っている
- プロジェクトの半数近くがB2Cサービス
パネルディスカッション
「ユーザー視点からみた見える化するメリットとビジネス価値の関係」
パネラ
- 東京海上日動システムズ株式会社 商品・プロセスソリューション本部 契約データデザイン部 ソリューションプロデューサ 佐藤 元紀様
- 株式会社 匠Business Place 取締役CTO 細川 努
- 株式会社 チェンジビジョン 代表取締役社長 平鍋 健児
- 株式会社 永和システムマネジメント サービスプロバイディング事業部 アジャイルコンサルタント兼マネージャ 木下 史彦
モデレータ
- 株式会社 匠BusinessPlace 代表取締役社長 萩本 順三
概要
アジャイルの見える化に寄ったりしつつも、東京海上日動の401kシステム開発事例を元に見える化
- ユーザー企業に業務が分かり、開発力がある情報システム部門の人が減っている
- “見せる化”に時間を取られて、“見える化”まで出来ていない
- “見える化”とは？
- 東京海上日動での事例
- 最初にセンターに行って作業を教えてもらっても見えてこなかった
- なので、まずはワークフローを作った、また問題を見える化した
- チームワークが素晴らしかったが、どうやって作ったの？
- 目的を何度も話したら、段々良くなっていき、何度も作っては壊した
- 問題が見えると、やらざるを得ないという意識になるので、困ったマップを作ったりした
- 作る人に現場を見てもらう様にする為、ビデオを撮ってそれを見てもらうようにした
- 困ったマップってどんなもの？
- ExcelでA3で1枚
- 業務と工程を入れ、そこにふき出しを入れた
- この手のものは一度作成すると更新しなくなるが、その点はどうしたのか？
- 見える化が目的であったので、完成した時点でお役御免なので更新する必要がなかった
- 問題を放置すると、感覚が麻痺してきて、問題がある状態が当たり前になってしまう
- ある車屋さんの話(皆さんご存知のT社)
- ひたすら何に困っているかを言い続ける
- そうすると、相手がそれに共感してくれる
- ちなみに、共感までが仕事でそれ以上口をはさむとかえってやる気を無くす
- 人と仕事をする際は、その人ではなく、その人の仕事の先の人まで考えてする
- 技術はボトルネックにならない
- 日本の産業構造の中でいかにしてアジャイルをやっていくか？
- アメリカはインハウスだが、日本は契約
- 日本も重い腰を上げて、“非ウォーターフォール研究会(?)”なるものを立ち上げた
感想
- 木下氏が予想以上に若かった
- といっても自分より年配の方なのだが
- 萩本氏がアジャイルにビジネスの観点を付与した“ビジネスアジャイル”が必要と言っていた
- 東京海上日動の事例紹介はプレゼンもパネルもなく、「これはすごかった」*2と細川氏と萩本氏が言っているだけで具体的にどういう風にすごかったのか分かり難かった
- プレゼン資料かパネルとかあると分かり易いんじゃないかな
- 平鍋氏はパネラ、講演者として、格段にレベルが周囲と違っていた
- こなしている数の違いか、それとも能力の違いかは分からないが、聞いている方としては非常に分かり易くかった
- 木下氏は本に寄せているコメント(開発者だけがアジャイルなプラクティスを導入している状況をアジャイルごっこと呼称)からアジャイル純粋主義者だと思っていたが、小さくはじめるべきとも言っている
- プラクティスは全てを最初から行うのかな？ それとも関係者全員がかかわる様にすれば、全て出来てなくてもいいのかな？ ここら辺が少し疑問
- 木下氏がアジャイル開発を“ふつうのシステム開発”と感じているのには同感
