┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.298 2009/10/07
■ I N D E X
┃
┣【Topics】『iPhone SDK プログラミング実践ガイド』好評発売中！
┣【Topics】CakeMatsuri TOKYO 2009 〜CakePHPの「祭り」を開催〜
┣【要件定義】プログラマにも役立つ要件定義の技術 [4]
┃ 〜ステークホルダとの協業で価値を高める〜
┣【アジャイル】アジャイル・プラクティスの見つけ方 [9]
┃ 〜速く失敗し、失敗から学ぶ〜
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 『iPhone SDK プログラミング実践ガイド』好評発売中！
〇 〇━━━━━━━━━━━━━ ━━・
今年6月に新機種3GSが発売され、iPhone周辺はますます熱を増していますが、
アプリ開発をして一攫千金！と考えてる方は少なくないのでは？
そこでオススメしたいのが、『iPhone SDK プログラミング実践ガイド』です。
本書は、オブラブスタッフの森田、森本、近藤も執筆に参加しており、より実
践的にiPhone SDKの世界が学べるようにと、類書に比べてサンプルコードを多
く配置した内容となっています。
「いろんな入門書を読んではみたけれど、結局どういう流れでアプリを作るの
か分からない」という方はぜひどうぞ！
『サンプルプログラムでマスターするiPhone SDK プログラミング実践ガイド』
出版： ビー・エヌ・エヌ新社
価格： ￥2,835(税込)
http://www.amazon.co.jp/exec/obidos/ASIN/4861006848/xpjp-22
今回特別に、本書2冊をオブラブメルマガ読者へプレゼントします！編集後記に
記載の方法にてご応募ください。
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 CakeMatsuri TOKYO 2009 〜CakePHPの「祭り」を開催〜
〇 〇━━━━━━━━━━━━━ ━━・
世界中で人気を集めているCakePHP、そのユーザが集まる“祭り”を10月30日か
ら10月31日に東京で開催します。
各国からコア開発者に来日頂き、セッションやワークショップなどで発表を行
なっていただきます。通訳もご用意しますので、コトバが不安という方も大丈
夫。
オブラブスタッフの岸田も、ワークショップでセッションを担当する予定です。
お気軽にご参加ください！
http://matsuri.cakephp.jp/
開催概要：
■日程
・2009年10月30日(金) 9:30〜18:00 ワークショップ(18時以降に懇親会)
・2009年10月31日(土) 9:45〜18:00 カンファレンス(18時以降に懇親会)
■参加費用
・ワークショップ 10,500円(税込)(懇親会費は別途)
・カンファレンス 8,925円(税込)(1,000円の昼食費／5,000円の懇親会費込み)
■会場
・シダックスホール(東京・渋谷)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】プログラマにも役立つ要件定義の技術 [4]
┗ 〜ステークホルダとの協業で価値を高める〜
こんにちは、平田です。
前回は「お客様の発言を揺さぶる」というテクニックについて書きました。今
回は「ステークホルダとの協業で価値を高める」ということを書いていきます。
● ステークホルダの参加
要求や要件について触れている書籍などを読むと、ほとんどの場合「ステーク
ホルダの識別」を最初にやるべきと書かれています。プロジェクトの関わる人
を洗い出して、「適切な人から適切な要求」を引き出す必要があります。どれ
だけ自分たちの理解力が高かろうと、本当の要求を持っている人たちと会話で
きなければ、間違った内容を実装してしまう。ここまでは誰もが同様に感じて
いることだと思います。
ではなぜその実現が難しいのでしょうか。
ここにはいろいろな政治的な理由などが関わってくることも多いですが、開発
者としてできることは、システムを必要だと感じた経営層、実際にシステムを
使うユーザが、要件定義の場に参加することの敷居を下げること。そのために
なにをすべきかを考え、行動していくことではないでしょうか。
今日紹介する以下のプラクティスは、ステークホルダが参加しやすくなるとい
う「敷居を下げる」効果とともに、「ステークホルダとの協業の効果を高める」
ということを狙うものです。
● 言葉の選択を意識しよう
お客様へのヒアリングを進めていく際には、お客様の立場に立った言葉を選択
していくことが重要です。開発者としてはつい厳密な定義を求めがちだけれど、
実際にはもっとゆるく業務が行われていることも多い。
それをそのまま使うことで、参加者の人が発言しやすくするという効果を狙い
ます。たとえば既存の業務で使われている帳票の、番号や特別な呼称を生かす
ことで、ヒアリングがスムーズになります。「5番の帳票の件ですが」や「○○
さん(個人名)帳票が必要な理由って」などなど。
実装していくために、それを厳密な仕様に落としていくのは開発者の仕事です。
開発者の言葉でお客様からヒアリングしていくことによるリスクを考えれば、
開発者が翻訳していくことくらいは簡単だと思いませんか？
● 分かりやすい絵を使う
これも言葉の選択と同様の話になりますが、ユーザが直感的に理解しやすい、
最初に見た時点で引いてしまわないような絵を使うのがよいでしょう。たとえ
ば業務フローであればアクティビティ図、BPMNなどの記法がしっかりしたもの
よりも、絵やアイコンをふんだんに使ったフロー図を使うと良いです。
そのほかでもポンチ絵と呼ばれるような、大つかみにしたイメージ図を最初に
出していくことが重要です。当然、開発者である私たちの頭の中には、厳密な
図のイメージもできているはずだけど、コミュニケーションを行うために、あ
えてそれを崩して、お客様に提示するということを意識的に行ってみるのが良
いと思います。
● ホワイトボードを使う
会話だけだと空中戦になりやすい議論も、ホワイトボードを使うことで「問題
対私たち」の構造を作り出すことができ、議論が進みやすくなるというのはみ
なさんもご存知だと思います。これは要件定義のヒアリングの現場でも同様で
す。現状の問題点を構造化して解決していくのがわれわれの仕事だと考えれば
自明ですね。
さらに最近感じているのは、色つきのマーカーを多用することによって、ヒア
リングの場に参加している人たちの印象に強く残る議論が可能だということで
す。私の体験からの例を示します。
システムの根本的な概念に関する上位概念と下位概念を示している構造があり、
ヒアリングの中の各所でその概念についての議論が発生するという状況でした。
とある打ち合わせの中で、その概念に関する議論が混乱し始めたときに、赤と
青のマーカーで図示してみました。その日のそれ以降の議論では、みんながホ
ワイトボードを見ながら、「赤の扱いについて」などと色を使って議論を始め
出したのです。この議論がうまくいったため、その日の議論だけでなく、それ
以降の打ち合わせの際には自然と「赤」「青」という言葉でコミュニケーショ
ンが行われることになりました。「このユーザには青を意識させる必要がない
ため、赤の一覧を表示してあげて、」などの言葉がヒアリングの現場で飛び交
っていました。その場に参加していない人にとっては何のことか分からない言
葉ですが、参加している人たちの間ではコミュニケーションに関わるコストを
大きく下げることができ、新たな要求にも気づきやすいという効果を生むこと
ができました。
● アイスブレーク
打ち合わせの場が始まるときに、場の空気を作り出すことは重要です。「アイ
スブレーク」という言葉から「笑いを取る」などの行為に目がいきますが、必
ずしも笑いを取ることだけにフォーカスする必要はないと思います。重要なこ
とはヒアリングの場を機械的な情報伝達の場だと認識せず、あくまで「人間対
人間」のやり取りの場であるということを意識することです。
その意識さえあれば、自然と楽しく進めていこうという力が働くはずです。
● まとめ
今回は要件定義の現場に「適切な人」を連れてくるために、敷居を下げるため、
そして参加してくれるステークホルダとの対話を生み出すための方法について
話をしました。開発者同士では設計の言葉で厳密な議論ができるので、お客様
との接点の仕事をする場合には積極的に相手の立場に立ち、それを開発者間で
共有する際に翻訳するということを意識するのがよいでしょう。(平田)
● 過去の連載一覧
1) /ml-arch/magazine/291.html
2) /ml-arch/magazine/297.html
3) /ml-arch/magazine/303.html
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
/community/object_ml/estimate?vol=O001-03&choice=0
普通：
/community/object_ml/estimate?vol=O001-03&choice=1
イマイチ：
/community/object_ml/estimate?vol=O001-03&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【アジャイル】アジャイル・プラクティスの見つけ方 [9]
┗ 〜速く失敗し、失敗から学ぶ〜
こんにちは。こんぴろです。先日『デザイン思考の仕事術』という本のワーク
ショップに参加してきました。このワークショップは、『デザイン思考の仕事
術』と『ペルソナ作って、それからどうするの？ユーザー中心デザインで作る
Webサイト』の著者でもある棚橋弘季さんと一緒に、ワークモデル分析やKJ法、
ペルソナの作成などを行いました。
ワークショップは2つのチームに分けて行ったのですが、興味深い結果になりま
した。あるチームはうまく進んでいるのに、もう一方のチームはいまいちかみ
合わなかったのです。この2つのチームで、経験者の数には特に違いがありませ
ん。2つのチームにあった違いはなんでしょうか？
2つのチームの違いの1つは、手数口数の多さでした。
片方のチームは手も口も動かしていました。オープンな雰囲気で、自分の意見
は意見として話します。意見を出し、話し合い、チームの中で合意がとれれば、
ちょっとやってみます。そしてやってみてうまく行かないことはすぐに修正し、
次に進んでいたのです。
しかしもう一方のチームは話しているのも口を動かしているのも数人。他の人
は様子を伺うばかり。なぜ様子を伺っていたかというと、初心者なので何を話
したらよいのか分からなかった、という意見でした。でも考えてみてください。
ワークショップに参加する人は、みんな新しい何かを見つけるために参加する
のです。経験者の人だって、教えるために参加するというよりも、他の人の意
見を聞いてみてよりよいやり方を見つけて行きたいと考えているのではないで
しょうか。初心者の人の斬新な意見が、よりよいやり方につながることもある
はずです。ここは間違いを恐れず意見を述べた方が、よりよいワークショップ
になるはずです。
この違いを生んだ2つのチームの違いは「間違いを恐れること」に対する姿勢に
ありました。
片方のチームは間違える事を恐れずに意見を交換し、やってみて間違いに気づ
いたら即修正する、という姿勢。なのでみんなの手が動き、考えたことを口に
出せました。しかし「間違いを恐れた」チームは進みません。だんだんチーム
の雰囲気が悪くなっていきました。
間違いが重なれば失敗につながります。でも失敗するまでの間に修正すればよ
いのです。今回は間違いを恐れないためにはどうしたらよいのだろう、と考え
てみると、『アジャイルプラクティス』の本には素晴らしいプラクティスがあ
りました。それは「人ではなく、アイディアを否定する」や「機雷がなんだ！
全速前進」です。その姿勢が、間違いを恐れない姿勢につながるはずです。
ところで「愚者は経験に学び、賢者は歴史に学ぶ」とドイツ初代宰相のビスマ
ルクは語ったそうですが、より深く学ぶのはやはり経験からだと考えます。先
日鳩山首相も「試行錯誤の中で失敗することもあろうかと思うが、国民には寛
容であってほしい」と就任会見で述べたそうです。みんながふりまわされるの
で、朝令暮改は困りものですが、世の中の変化が速くなっている現代では、試
行錯誤の中で「失敗だ」という判断をしたら速やかに修正する、そんなアジャ
イルな政治であってもいいのかもしれません。
最後は脱線しましたが、間違いを恐れないことで速く[*1]失敗し、失敗から学
ぶ事でわかることは、本から学ぶことよりも深いので、次の行動を良い方向へ
導いてくれるでしょう。(こんぴろ)
[*1] 「早く」ではなく「速く」としたのは短い時間にたくさん失敗するという
意図で「速く」と表記しました。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
/community/object_ml/estimate?vol=G003-8&choice=0
普通：
/community/object_ml/estimate?vol=G003-8&choice=1
イマイチ：
/community/object_ml/estimate?vol=G003-8&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「アレグザンダー祭りに参加したいですか？」のホントのところ。
オブジェクト倶楽部では現在、「アレグザンダー祭り」と題したイベントを企
画しています。よりよいイベントとなるよう、ぜひ以下のアンケートにご協力
ください！
「アレグザンダー祭りに参加したいですか？」アンケートはコチラから↓
http://spreadsheets.google.com/viewform?hl=ja&formkey=dFo0LUI2eENvWlN6Qndlejl3OGc5TEE6MA
前号「家でも仕事してますか？」のアンケート結果は公開中。ぜひご覧下さい。
⇒/special/kininaru/vol263/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人のナガタユウコです。オブラブスタッフも執筆に参加した
『サンプルプログラムでマスターするiPhone SDK プログラミング実践ガイド』
が出版されました！Topicsにてご紹介しておりますのでぜひご覧ください。
出版されたての本書2冊をビー・エヌ・エヌ新社様よりご提供いただきました！
出版記念として、オブラブメルマガ読者のみなさま限定でプレゼントしたいと
思います。ご希望の方は以下の応募方法をよくお読みになり、ふるってご応募
ください。
『サンプルプログラムでマスターするiPhone SDK プログラミング実践ガイド』
プレゼント応募方法
1)Twitterで以下のようにつぶやく
「『iPhone SDK プログラミング実践ガイド』欲しい！ @objectclub」
2)http://twitter.com/objectclub にて、「@××× ご応募受け付けました」
つぶやかれたら応募完了(×××はあなたのアカウント、つぶやきがない場合
は再度応募してみてください)
3)上記のつぶやきの他にも本書についてつぶやくと当選確率が上がるかも？！
応募締切は10月21日、当選者発表は10月28日の編集後記にて行います。お見逃
しなく！
今週の強引な一言
*** 千日の萱(かや)を一日(ことわざ) ***
千日かかって刈りためた萱をわずか一日で燃やし尽くすように、長い間苦心し
て盛り立ててきた仕事を一度にだめにするたとえ。
長い時間をかけて作成したデータを保存せずに消してしまったり、ひとつ数字
を間違えて全体が合わなかったり。せっかくの労力がムダにならないよう、集
中して仕事に取り組むよう心がけたいですね。
出典参考：故事ことわざ辞典 東京堂出版
(ナガタユウコ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒/community/object_ml/help/
〇 免責事項、過去の記事は ⇒/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2003-2009 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.