コミュニケーションは大切

twitterで得た気付き

「隣の人に勧められた本は読むのに、amazonで高得点を取っている本には見向きもしない。なんでなんだろ？」

物と人の距離を縮めるためには，人が興味を持つ必要がある。興味が無い物に人は自分から寄付こうと思わない。

人は他人の行動に興味を魅かれやすい。「口コミ」や「オススメ」もその一例と言える。

単にドキュメントやソフトといった「物」と顧客やエンドユーザーを繋ぐために，間に開発者や営業といった「人」を仲介するのが良い例である。

だから，コミュニケーションは大切なのである。

サービスを売るということ。

メーカー系企業では、「技術」はできてあたりまえ。自己啓発で勉強するのも当たり前。

持っている技術を使って、いかに顧客が喜ぶサービスを考える点が重視される。

単にモノを作っても、顧客が買わなければ意味がない。

顧客が欲しがるモノで、低価格かつ高品質でなければ売れない。

ソフトハウス系企業は、「顧客要求の満足度」という指標があり、これを満たすために顧客から仕様を引っ張り出そうと努力する。

しかし、単に引っ張り出しただけでは足りない。
それでは、「伝言ゲーム」になってしまう。言った／言わないの水掛論争が始まる。

顧客の言った言葉の意味を、受注側が１２０％汲み取り、製品に反映しなければならない。

「１２０％汲み取る」とは、すなわち顧客の言っていることが正しいか間違っているかまで判断するということであり、顧客が言い間違っても、それを間違いであると訂正できなかった受注側のミスだと認めるくらいのレベルであると言える。

顧客の要求を理解するだけではまだ足りない。顧客の要求を踏まえた上で、顧客が「欲しい！」といわせるだけの提案を行って、初めて顧客に受け入れてもらえる製品となる。

僕は未だに、顧客に「欲しい！」と言わせる提案を行っているソフトウェアハウスに出会ったことは無い。

ソフト開発における成功の道筋

今の世の中，薄利多売がはびこり，それが最も簡単かつ確実な方法だと考えていた。

しかし，ソフトウェアで薄利多売を実現することは難しく，受託開発によるビジネスモデルが当たり前になっていると感じる。

薄利多売を実現するためには，売れるソフトウェアを大量生産し販売する事を意味するが，このビジネスモデルは大きなリスクを孕んでいる。もし不具合が見つかった場合，回収／修正／返送費用がかかり，売上が一瞬で消し飛んでしまう。

このビジネスモデルを実践しているのが，主にゲームメーカー，一部のビジネスソフトメーカー，特定用途向けソフトウェアメーカーぐらいである。

成功しているメーカーが少ない事から，リスクの削減が難しく，利益も不透明で不確定要素が強いと思われる。

一般的なソフトウェアハウスでは，薄利多売のビジネスモデルを成功させる道は無いのだろうか。

繋がり

私は，ソフトハウスから転職し，現在メーカー系の会社で働いている。

メーカー系とは，自社で機器を開発する企業を意味する。

ソフトハウス系企業とは比較にならない程業務範囲が広い。

一つの製品を創るのに多くの企業と提携し，それらの企業との調整も必要となる。

今関わっているプロジェクトは，初期メンバーが地道に様々な所へ提案活動をして回った結果，糸口を掴み，様々な企業とのパイプが繋がり始めた。

それは，最初の提案活動で名前を売り歩いた成果だと聞く。

様々な企業との連携は，簡単で綺麗なものではない。自分達の得意分野を活かし，お互いの利益を守り，チャンスがあれば別のビジネスを広げるべく，虎視眈々と狙っている。真に弱肉強食の世界。

いずれにしても，先は点から始めなければならない。点から始めるためには，他者が持っていない強力な武器と，地道な努力が必要であり，どちらが欠けても上手くいかないだろう。

強力な武器があれば，他者が現れても，自分達のポジションを奪われる事なく，ビジネスを進める事ができる。

ただし，そうやって勝ち取ったビジネスも，数年立てば模造品，類似品が出回り，利益回収は困難になる。
だから，安堵すること無く，新しい商品やサービスを次々開発しなければ生き残れないのである。

XP寺子屋第5回「ペアプロ体験」ふりかえり

盛況の内に終了しました。

あらかじめ参加者にパソコンとペアを各自用意して頂いた。その結果，欠席者ゼロというスゴイ記録が生まれた。通常，参加者の１〜２割が欠席するのが常識となっているのに，「欠席者ゼロ」とはスゴイ事である！

当初，参加条件が厳しかったためか参加者集まらなくて焦りを感じたので，下記２点の初の試みを実施。

■その１：資料の事前公開
いつも資料は当日まで公開されないが，参加者が内容を事前に把握した方が安心できると思い，事前公開してみた。

■その２：目立つテンプレートの使用
見た人に興味を持ってもらう様，目立つテンプレートを使用した。
いつもお世話になっているMS様のテンプレートでは物足りず，フリーのテンプレートを探し，印象に残るものをチョイス。

実際のワークも盛り上がった。
最初の15分でインストラクション＆アイスブレイク。アイスブレイクで久々に「しりとらず」を実施したが，凍り付いた場が数分で和やかな空気に変わるのを感じた。
残りの時間をペアプロに割り当てた。あるペアはタスクかんばんを使い，あるペアはデザインパターンで熱い議論を交わし，会場は静かにヒートアップ

最後に「拍手２回でふりかえり」を行い全員の感想をシェア。「有効なやり方」「会社では教えられない細かい事を指導できた」「楽しかった」「もっとやりたい」等々，前向きな意見が多かった。

◆◆◆◆◆◆◆◆◆
自分自信のふりかえり

■KEEP
・ペアプロのワークショップを実現した
・期待していた効果が得られた
・参加者が１０名を超えた
・ソフト業界以外の方も参加

■PROBREM
・ヘルプファイルを忘れていた
・見学者への対応が不十分だった
・自分も開発していたので十分フォローできなかった

■TRY
・XP寺子屋継続
・XPの全プラクティスを使ったWSの開催
・IT業界へのペアプロの展開


これからも，XP寺子屋を続けて行きたい。

XPの真価を伝えたい

2007年，XPJUG関西のスタッフにして頂いた。

当時，「XPをもっと世間」に広めたいという思いを強く持っていた。

人に自分の知識を教えるのが好きな性格だったため，XPJUG関西を通じて誰かにXPの良さを伝えたかった。それを形にしたのが「XP寺子屋」である。

今まで通算4回開催し，本当に多くの方々に参加頂き，様々な気付きを頂いた。

今月，5回目を開催する。
内容は，念願のペアプログラミング。「やってみたいXPのプラクティス」で常に上位にランキングされるプラクティスである。

ただ，予算の都合上，様々な制約事項をつけなければならなかった。

機会があれば，制約事項を減らして再度企画してみたい。

ペアプログラミング

ＸＰのプラクティスの中で注目度の高いプラクティスの一つである「ペアプログラミング」、通称「ペアプロ」。

「ＸＰを知ってますか？」と聞くと、殆どの方が「ＴＤＤとかペアプロするんですよね」と答える、ＸＰの代名詞と言っても過言ではないプラクティスである。

ＴＤＤ、リファクタリング、コード共同所有、シンプル設計、ペアプロなど、開発に直結するプラクティスの内、ペアプロだけが一人で試すことができない。できないからこそ、注目度が高いのではないのだろうか。

或いは、「２人で１台のパソコンを使って開発すると、生産性を落とさず高品質になる」という、従来の考え方（個々人の能力の高さが生産性と品質に直結する）と相反する考え方だからだろうか。

私は、両方の理由からペアプロに挑戦しようと考え、約３年間取り組んできた。
その経験から学んだ事は、「ペアプロは、ペアを組む相手により結果が変化する」という事である。
 特に、ペアプロを有効と感じないメンバーが居るプロジェクトでは、上手く機能しない。つまり、２人１組で開発することの弱点となる。

ここを上手くクリアできなかればべ、ペアプの有効性を感じることは難しい。