きせのんです。
大浦さんによるトピックスのまとめです。
ご参考までに。
-----------------------------------------------------
知恵の和トピックス
東京タワー(の隣)
エンドユーザとボクと時々ベンダー
ユーザ企業IT部門のSEからみたシステム開発ワールド
担当：大浦さん
今日のテーマ
・システムのユーザから見たシステム開発の現場について
・東京タワーについてはスルーだそうです。
■大浦さんの経歴
■アジェンダ
・ユーザ企業のIT部門はこんなとこ
・もっと神経を使うのは
・よい開発者、わるい開発者
・価値ある開発者になるために
・Openthologyのご紹介
△突然ですが、質問
システム開発においてエンドユーザとお話する機会あります？
△IT部門の主な仕事
・ヘルプデスク
・システム開発管理
基幹
個別←大浦さんメイン
・インフラ管理
・経営企画部との協業
BPI
内部統制
△主な仕事
・新システムの提案
・ユーザへのヒアリング
・要件定義の取りまとめ
・コスト検証
・ベンダとのスケジュール調整
・基本設計、詳細設計のチェック
・顧客テストの実施
・操作説明会の開催、講師
・開発後のヘルプデスク
いわゆるフロントSEかな？
△IT部門にはどんな人がいるの？
・プロパー(もともと営業・管理部門)
・IT会社の出向、嘱託
・コンサルタント
・ヘルプデスク担当契約社員
etc
傾向としては、社内業務や手続きには詳しいけど、実装・技術関連には弱い
IT部門の質問でもっとも神経を使う仕事は？
・ユーザへのヒアリング
・要件定義の取りまとめ
→ここで問題の芽を摘まなければ、後で修正する事が困難
→ユーザの要求は鵜呑みに出来ない。洗練させる必要あり。
△何故ユーザは正しく要求を伝えられないのか？
・ユーザは自分の本当の要求を知らない事がほとんど
・自分の業務を抽象化して説明するのが苦手
→業務者は自社の業務の本質的な目的を知らない場合が多いから。
→マネージャレベルでもはっきり認識出来ていない場合がある
△たとえばこんな会話はよくある
ユーザ「ホストの帳票配布作業は廃止しないで」
私「なぜです？自分で出力指示かけられるようになるんですよ」
ユーザ「だって、あの棚に置かれるのを見て、エラーの発生を知るんですから」
私「それって、エラー通知メールがあなたにいくからそれでいいのでは？」
ユーザ「あ、そうか、じゃいいです。」(または、「やり方を変えたくないのでそれはいやです」)
△ではIT側はどうすればいいのか？
・一言で言うと「価値観を共有する」
△価値観を共有するには
・業務知識を身につける
・IT側が業務の本質を捕らえ、ユーザよりも先回りする
どうしたら可能なのか？
・顧客の顧客を見る
→顧客の顧客にとって何がうれしいのかを考える事で価値観が共有出来るようになれる
△価値観が共有出来ると・・
・ユーザとの意思疎通がスムーズになる
→業務上の危機感や目的意識が共有出来るため
・洞察力が働くようになる
→ユーザの要求が予想出来る
→仕様に内在する問題点を察知出来る
・実装、テストの設計が過不足なく行える
△価値観が共有できていないと引き起こされる現象
・拡張の方向性を見誤り、後々の改造に多大な労力を必要とする
・テストの方針が的外れになり、テスト範囲やパターンの網羅性が低くなる
・テストしていても何が間違っているか分からない為、不具合を見逃す
→ユーザから見たら超初期的な知識で判断出来るにもかかわらずスルーする
△よい開発者、わるい開発者
「こいつ、動くぞ・・・・」
△IT部門から見た良い開発者、悪い開発者
・IT部門にいると複数のベンダと話す事になる
・ベンダから見ると良い開発者もユーザから見ると悪い開発者になります
△悪いパターンその1「こういうものを作ります」だけ話す
・このシステムはこういう設計になって・・・。ばっかり。
→ユーザが聞きたいのはそんな事じゃない
・自分や自社の都合を優先してしまう(つまり、責任持てる事しかやりたくない)
△良いパターンその1「結局何がうれしいの？」に答える
・システムの構成や技術ではなく、ユーザのメリット、デメリットについてひたすら書く、話す
△悪いパターンその2ユーザとケンカする
・だってあんたがそう言ったから作ったんじゃんか。今さら何を！
・そんなもん作れって言った覚えないよ！この仕様がこんな問題起こすなんてあんた想定してなかったのかよ！
・そもそも仕様を承認したのはあんたじゃないか！
△良いパターンその2人ではなく、問題と向き合う
・You vs Me でなく、 Problem vs Us
・ユーザを説得する事よりも自ら納得してもらう態度で
・合意＝同意＋サポート意思
・最終的にはファシリテーション能力？
△価値ある開発者になるために
「俺も変わったし、君たちも変わった。誰だって変われるはずだ！」
またまた質問です。IT部門の最大の弱点は何でしょうか？
→実装とテストに対する評価
△IT部門の最大の弱点=ベンダの出番
・IT部門はようやく固まった仕様に対してどのような設計やテストがもっとも妥当なのか判断出来ない
→仕様と実装のトレーサビリティを説明する事が高評価につながる
△IT部門が知りたい事
・実装
→何故この仕様に対してこの設計を施したのか
→その設計を選択する事でどのようなメリット、デメリットがあるか
・テスト
→システム要求を満たすべき品質確保を担保するために、どこまでテストすべきか
→システムテストの品質基準と受け入れてストの基準は大きく違うことをお互い認識すべき
■危ない話
△危険その1「柔軟性の高いシステム」
・柔軟性という言葉から連想するのは・・・
→ベンダ：記述しやすい、変更がしやすい、つくりやすいツールかFW
→ユーザ：改造に費用がかからない。
抽象的な話でなく、具体的な話をしましょう
△危険その2「小さく始めて大きく育てる」
・ロバを育てても絶対サラブレットにはなりません
・とりあえずシステムを作って後で修正すればいいやと思わせると・・・色々とね。
小さく始めるとしても方向性はきちっとすべきです。
■Openthologyのご紹介
△Openthology(要求開発論)とは？
→ビジネス的な価値を生み出す情報システムのシステム要求を体系的に開発する方法論
△要求は「開発」するもの
・要求分析、要求定義などは要求が既に存在しているという前提に立っている
・ユーザからヒアリングした要求の実現が業務効率につなぐとは限らない
△要求開発宣言
詳しくはサイト・書籍で・・・
オープンソロジー公式サイトとか。
以上
大浦さんによるトピックスのまとめです。
ご参考までに。
-----------------------------------------------------
知恵の和トピックス
東京タワー(の隣)
エンドユーザとボクと時々ベンダー
ユーザ企業IT部門のSEからみたシステム開発ワールド
担当：大浦さん
今日のテーマ
・システムのユーザから見たシステム開発の現場について
・東京タワーについてはスルーだそうです。
■大浦さんの経歴
■アジェンダ
・ユーザ企業のIT部門はこんなとこ
・もっと神経を使うのは
・よい開発者、わるい開発者
・価値ある開発者になるために
・Openthologyのご紹介
△突然ですが、質問
システム開発においてエンドユーザとお話する機会あります？
△IT部門の主な仕事
・ヘルプデスク
・システム開発管理
基幹
個別←大浦さんメイン
・インフラ管理
・経営企画部との協業
BPI
内部統制
△主な仕事
・新システムの提案
・ユーザへのヒアリング
・要件定義の取りまとめ
・コスト検証
・ベンダとのスケジュール調整
・基本設計、詳細設計のチェック
・顧客テストの実施
・操作説明会の開催、講師
・開発後のヘルプデスク
いわゆるフロントSEかな？
△IT部門にはどんな人がいるの？
・プロパー(もともと営業・管理部門)
・IT会社の出向、嘱託
・コンサルタント
・ヘルプデスク担当契約社員
etc
傾向としては、社内業務や手続きには詳しいけど、実装・技術関連には弱い
IT部門の質問でもっとも神経を使う仕事は？
・ユーザへのヒアリング
・要件定義の取りまとめ
→ここで問題の芽を摘まなければ、後で修正する事が困難
→ユーザの要求は鵜呑みに出来ない。洗練させる必要あり。
△何故ユーザは正しく要求を伝えられないのか？
・ユーザは自分の本当の要求を知らない事がほとんど
・自分の業務を抽象化して説明するのが苦手
→業務者は自社の業務の本質的な目的を知らない場合が多いから。
→マネージャレベルでもはっきり認識出来ていない場合がある
△たとえばこんな会話はよくある
ユーザ「ホストの帳票配布作業は廃止しないで」
私「なぜです？自分で出力指示かけられるようになるんですよ」
ユーザ「だって、あの棚に置かれるのを見て、エラーの発生を知るんですから」
私「それって、エラー通知メールがあなたにいくからそれでいいのでは？」
ユーザ「あ、そうか、じゃいいです。」(または、「やり方を変えたくないのでそれはいやです」)
△ではIT側はどうすればいいのか？
・一言で言うと「価値観を共有する」
△価値観を共有するには
・業務知識を身につける
・IT側が業務の本質を捕らえ、ユーザよりも先回りする
どうしたら可能なのか？
・顧客の顧客を見る
→顧客の顧客にとって何がうれしいのかを考える事で価値観が共有出来るようになれる
△価値観が共有出来ると・・
・ユーザとの意思疎通がスムーズになる
→業務上の危機感や目的意識が共有出来るため
・洞察力が働くようになる
→ユーザの要求が予想出来る
→仕様に内在する問題点を察知出来る
・実装、テストの設計が過不足なく行える
△価値観が共有できていないと引き起こされる現象
・拡張の方向性を見誤り、後々の改造に多大な労力を必要とする
・テストの方針が的外れになり、テスト範囲やパターンの網羅性が低くなる
・テストしていても何が間違っているか分からない為、不具合を見逃す
→ユーザから見たら超初期的な知識で判断出来るにもかかわらずスルーする
△よい開発者、わるい開発者
「こいつ、動くぞ・・・・」
△IT部門から見た良い開発者、悪い開発者
・IT部門にいると複数のベンダと話す事になる
・ベンダから見ると良い開発者もユーザから見ると悪い開発者になります
△悪いパターンその1「こういうものを作ります」だけ話す
・このシステムはこういう設計になって・・・。ばっかり。
→ユーザが聞きたいのはそんな事じゃない
・自分や自社の都合を優先してしまう(つまり、責任持てる事しかやりたくない)
△良いパターンその1「結局何がうれしいの？」に答える
・システムの構成や技術ではなく、ユーザのメリット、デメリットについてひたすら書く、話す
△悪いパターンその2ユーザとケンカする
・だってあんたがそう言ったから作ったんじゃんか。今さら何を！
・そんなもん作れって言った覚えないよ！この仕様がこんな問題起こすなんてあんた想定してなかったのかよ！
・そもそも仕様を承認したのはあんたじゃないか！
△良いパターンその2人ではなく、問題と向き合う
・You vs Me でなく、 Problem vs Us
・ユーザを説得する事よりも自ら納得してもらう態度で
・合意＝同意＋サポート意思
・最終的にはファシリテーション能力？
△価値ある開発者になるために
「俺も変わったし、君たちも変わった。誰だって変われるはずだ！」
またまた質問です。IT部門の最大の弱点は何でしょうか？
→実装とテストに対する評価
△IT部門の最大の弱点=ベンダの出番
・IT部門はようやく固まった仕様に対してどのような設計やテストがもっとも妥当なのか判断出来ない
→仕様と実装のトレーサビリティを説明する事が高評価につながる
△IT部門が知りたい事
・実装
→何故この仕様に対してこの設計を施したのか
→その設計を選択する事でどのようなメリット、デメリットがあるか
・テスト
→システム要求を満たすべき品質確保を担保するために、どこまでテストすべきか
→システムテストの品質基準と受け入れてストの基準は大きく違うことをお互い認識すべき
■危ない話
△危険その1「柔軟性の高いシステム」
・柔軟性という言葉から連想するのは・・・
→ベンダ：記述しやすい、変更がしやすい、つくりやすいツールかFW
→ユーザ：改造に費用がかからない。
抽象的な話でなく、具体的な話をしましょう
△危険その2「小さく始めて大きく育てる」
・ロバを育てても絶対サラブレットにはなりません
・とりあえずシステムを作って後で修正すればいいやと思わせると・・・色々とね。
小さく始めるとしても方向性はきちっとすべきです。
■Openthologyのご紹介
△Openthology(要求開発論)とは？
→ビジネス的な価値を生み出す情報システムのシステム要求を体系的に開発する方法論
△要求は「開発」するもの
・要求分析、要求定義などは要求が既に存在しているという前提に立っている
・ユーザからヒアリングした要求の実現が業務効率につなぐとは限らない
△要求開発宣言
詳しくはサイト・書籍で・・・
オープンソロジー公式サイトとか。
以上
|
|
|
|
|
|
|
|
智恵の和（技術知識の和） 更新情報
-
最新のアンケート
-
まだ何もありません
-
