お客様とコードの間

3,422 views
3,372 views

Published on

2011.12.10 DevLOVE HangarFlight でお話しした内容です。

Published in: Technology
1 Comment
8 Likes
Statistics
Notes
  • ファビオに習ったエンパシーの話と似てるなあと思った。(なんでダウンロードできないんだろ)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,422
On SlideShare
0
From Embeds
0
Number of Embeds
1,718
Actions
Shares
0
Downloads
6
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide
  • 今夜は月食。このイベントがあった日のことを覚えてたいと思ってこのスライドに。\nこのセッションを選択された人がこれだけ。\n
  • こくちーずのサイト。この第6機がこのセッションですね。\n
  • \n
  • \n
  • これが昔は面白かったと評判で。。。DevLOVEとのからみでは\n
  • 前にオブジェクト倶楽部と呼ばれていたオブラブで、ブログを定期的に書いてます。\n
  • DevLOVEとの関わりはそんなに多くはない。今年のデブサミでは市谷さん野村さんのセッションに\n壇上で参加させてもらった。変わっていけると信じている人が青をあげてます。\n
  • 永和システムマネジメントという会社で受託開発\n
  • \n
  • よくありがちなピラミッドですね。SEとPGという区分が今やってるところである人?\n
  • お客様が依頼をしてそれを開発チームが作る。依頼の仕方がRFPなのか、要件定義書なのか、ユーザーストーリーなのか、開発チームが一度に作るのか、イテレーティブに作るのかいろいろあっても基本はこの形\n
  • 永和システムマネジメントでは、ほぼ全員のメンバーがプログラマとしてお客様と直接対面しながら、コードを書いている。\n
  • いわゆるアジャイルさが強い組織。\n
  • 不幸な話、僕があまりコードを書くのが得意ではない。Railsバトル、日常業務。コードを書いていない。\n一方だからといって仕事をしていないわけではない。\n
  • 数日前くらいの同僚のtweet\n平田業と呼ばれる何らかの仕事を期待されている。実はよくわかっていなかったのでよく考えてみると\n
  • で、僕がやっているのは、お客様とコードの間をつなぐような仕事\nここで価値を出そうと試行錯誤している僕の話。なので対象は\n
  • お客様と絡まない、絡もうともしない人が受託開発をやっているのは不思議な感覚。\n
  • ということではじめます。\n
  • 僕らの仕事、ソフトウェア開発、システム開発でやらないといけないことはこれに尽きると思っている\n
  • 正しく作る方法はいろいろ出てきてるし、個人的にはプログラミングがあまり得意ではない。\nちなみに好きではあるんだけど、同僚のみんなのコードへの執着というかパワーを見てると好きとも言いづらい\n
  • 正しいものを見出す活動を要件定義と置く\n
  • 正しいものを見出す活動を要件定義と置く\n
  • \n
  • まず技術。\n
  • 大前提として、要件定義そのものも技術。身につけることが可能だということ。必要な知識もある\n
  • 技術なので、技術要素に分解可能。この他に要求管理という分野がある。これは要求開発。\n個人的にはとてもあいまいな要件定義という言葉が好き。要求開発は固有名詞にしようとしているグループが。。。\n
  • 今日は技術の中では、引き出しの話を簡単に紹介。引き出しは楽しい!\n普段平田業をやっていない人でも、たとえばプログラマでお客様にインタビューやデモをやりにいく人\n
  • 技術のひとつとして、理由を追い求める\n
  • \n
  • つまり、相手の話に「なぜ?」と問い続けることで、より上位の要求を見出すという作業\n僕ら開発者としては、ついつい「どう実現するか?」という下向きの力が働くのをいかに上に向かうか\n
  • つまるところソフトウェア開発はコミュニケーションで成り立っている。コミュニケーションの質を上げるために取り組めることはなんでもやりたい。そのひとつとして、自分の質問にも理由を示す。\n
  • \n
  • 誰もが自分の立場から発言している。本当に全体にとってよいシステムにつながるのか\nたとえばその機能を追加することで、「現場の人にとってうれしい?」\n
  • 制約はつきもの。だけどそれを取り払ったとしたら、どういう業務ができるかを考える\n暗黙の制約によるコミュロスを避ける。新たな要求を生む\n
  • これもコミュロスを避ける手。さらに、システムを作るエンジニアとしての視点からの解釈は貴重\n\n
  • しゃんしゃんと進もうとするのを、いったん立ち止まらせる。\nこの辺の話はさっきのHowと同様で、「早く仕様を決めて開発に入りたい!」というフォースへの対応\n\n
  • まあ用語集なんかの話は、まじめな要求の本などには載ってるし、一般的にやると思うけど\n引き出しの段階ではあいまいな言葉はあいまいなままで、お客様の言葉はそのままで\n
  • \n
  • 要件定義に限らず受託開発はそもそもサービス業。\n汚い飲食店の話。ただしイケメンに限る\n
  • \n
  • \n
  • \n
  • \n
  • これは僕も最初に聞いたときはただの言葉遊びだと感じたんだけど、心の持ちようを変えるということが重要。\n
  • お客様の立場で考えると、自分たちからすると大変なことが増える。でもそれを提供するのがプロフェッショナル\n
  • ちょっとやらしい話なんだけど、社内とかだけじゃなくプロジェクトのお客様との間でも信頼貯金がある。最初に何もない状態なら何でもやる。プラスならちょっと速度をあげるために確認を怠ってもいい。マイナスなら、どうでもいいようなことでも丁寧な説明をする。一回の失敗の取り上げられ方が違う\n
  • 機嫌が悪い日もあるだろうし、子供の誕生日で帰りたい日もあるだろう。ふだんチームメンバーを気遣う優しさを、ずっと机を並べているわけではないお客様にも向けよう\n
  • 最後にまとめ\n
  • いろいろ話したけど、受託開発をやるにあたって、お客様との関係をどうとらえるかが重要。技術とは言ったものの、相手をしっかり見て、相手の立場でコミュできるかどうか。技術の話はお客様にもよるので、そんなにしたくない。いかに自分がお客様の立場でものを考え抜けるか\n\n
  • アジャイルな見積りと計画づくりという本があります。アジャイルに興味のある人は必読だと思いますが\nここに要求に関して、とてもいい言葉が書いてあります。失敗条件にこれを加えるというもの\n
  • アジャイル開発はもとより、UXなど、よりよいアイデアを途中でどんどん生み出せるような仕事をやれるような考え方がどんどん進んでいっています。この波にのっていい仕事をしましょう!\n
  • \n\n
  • お客様とコードの間

    1. 1. お客様とコードの間 平田守幸 @m_pixy2011/12/10DevLOVE Hangar Flight http://www.flickr.com/photos/jamoutinho/5837633078/
    2. 2. 顧客と要求と平田?
    3. 3. 平田守幸@m_pixy
    4. 4. m_pixyの読書日記
    5. 5. デブサミ2011
    6. 6. 受託開発
    7. 7. お客様 PM SE PG
    8. 8. お客様 開発チーム
    9. 9. お客様 開発チーム
    10. 10. 開発メンバー全員で お客様と相対しコードを書いていく
    11. 11. 大変残念ですが... http://www.flickr.com/photos/fuyoh/525160894/
    12. 12. http://twitter.com/#!/kakutani/status/144619654957117440
    13. 13. お客様とコードの間お客様 コード
    14. 14. 対象お客様と触れる機会のある人、お客様に近づきたい人
    15. 15. お客様とコードの間お客様 コード
    16. 16. 正しいものを正しく 作る
    17. 17. 正しいものを見出す
    18. 18. 正しいものを見出すために必要なものと は何か
    19. 19. (話をしやすくするために、「正しいものを見出す活動」を「要件定義」としま す)
    20. 20. その目的を果たすために僕らに必要なも の
    21. 21. 技術
    22. 22. 要件定義は技術である
    23. 23. 要件定義の技術要素1.引き出し2.分析3.仕様化4.妥当性確認
    24. 24. 要件定義の技術要素1.引き出し2.分析3.仕様化4.妥当性確認
    25. 25. Tips.1理由を追い求める
    26. 26. 理由を追い求める =ゴールを探す
    27. 27. WhyHow
    28. 28. 自分の発言にも理由 を示す
    29. 29. Tips.2お客様の発言を揺さ ぶる
    30. 30. 視点を変える
    31. 31. 制約を取り除く
    32. 32. 自分の解釈をぶつけ る
    33. 33. 全会一致を避ける
    34. 34. Tips.3言葉をお客様にあわ せる
    35. 35. http://www.flickr.com/photos/buddawiggi/5987710858/ 態度
    36. 36. 受託開発はサービス 業である
    37. 37. お客様のために
    38. 38. お客様のために
    39. 39. お客様の立場で
    40. 40. 顧客のために は自分の経 験が前提になるのに対し、 顧客の立場で 考えるときは、自分の経験をいったん否定しなければなりません。
    41. 41. お客様の立場で考える
    42. 42. 信頼貯金を意識する
    43. 43. お客様も感情を持つ個人だととらえ、誠実に 行動する
    44. 44. まとめ
    45. 45. 態度 重要http://www.flickr.com/photos/buddawiggi/5987710858/
    46. 46. 最初に定義した要求よりもいいアイデアを、最後まで誰も思いつかなかっ たプロジェクト
    47. 47. 態度 重要http://www.flickr.com/photos/buddawiggi/5987710858/

    ×