お客様とコードの間

Editor's Notes

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