ものづくりについて考えてみる

ものづくり

what

Webアプリケーションについての「ものづくり」のフレームワークを持ってなく、ほしいと思ってきたので、いままで見てきた書籍やWebの情報、イベントに参加したときの情報、意見を直接聞いたときの情報をまとめてみた。みんなどんな方法で、新しい物を生み出しているだろうなー。


Google のものづくりについて

Googleは基本的に開発者の自主性にまかされ、魅力のある（人気のある）プロジェクトが正式なプロジェクトとして認められ、Googleの正式なサービスとして提供されているようです。
Googleのイベントに数回参加したことがありますが、そこでよく耳にするのが「数字」をとにかく見ていること。
複数のヘッダを用意して、ランダムに表示してクリック率の高いヘッダを採用するなど、ユーザの動きを細かく数字で表し改良していっているようです。
以前Googleのイベントに参加したときに、Googleの人に開発について直接聞いたことがあります。
私「開発体制について聞きたいのですが、スクラムやXPといったものを採用しているのですか？」
Googleの中の人「いやー、そういうのはないなー。必要な話し合いは必要なときに行います。」

Googleは残業という概念がなかったり（年俸制）、出社・退社の時間が自由だったり、と「会社に仕事に行く」という感覚より、「成果を出しにいく」という感覚になりやすい環境があるのではないかと感じます。自分が何かやらないと、評価がどんどん下がる（Googleの給与は360度評価システム）。

また、Googleのイベントに参加すると、しきりに「アンケートにご協力ください」という声を聞く。それだけユーザの声がほしいということなのだろう。

参考→404NotFound | 株式会社ライブレボリューション

  • ポイント
    • 開発者の自主性に完全にまかされている
    • 魅力のあるプロジェクトはどんどん成長し、魅力のないプロジェクトは自然淘汰される
    • 数字をよく見ている
    • 成果を出しにいくという感覚になりやすい環境

また、

  • ユーザに焦点を絞れば、「結果」は自然に付いてくる。
  • １つのことを極めて本当にうまくやるのが一番。
  • ウェブでも民主主義は機能する。
  • 遅いより、早い方が良い。

などGoogleの企業理念がある

Googleのものづくりに関する資料
  • ものづくりの流れ 「選ばれたプロジェクトだけが生き残る」

開発者は数あるプロジェクトの中から自分にあったものを受け持つか、あるいは自分から新しいプロジェクトを提案する

誰も見向きもしないような魅力のないプロジェクトは忘れ去られてなくなります。こうして開発者自身によるプロジェクトの自然淘汰が行われ、それを生き残ったものだけがGoogleのサービスとして私たちの前に提供されることになります。

「Googleを支える技術」 より

すべてのプロジェクトの進捗状況はデータベースで管理されており、進捗に合わせて更新されます。開発者は同時に複数のプロジェクトに参加することもできます。

・明確なプロジェクトという単位によって、システマチックに仕事を片付けていくのが、Googleにおける開発の進め方のようです。
・すべての開発者は担当プロジェクトとは別に、就業時間の20%を普段とは違う新しいことに費やすことも求められます。有名な「20%ルール」です。とにかく新しいことにも手を出すことで視野を広げようというのがその主眼であるようです。

「Googleを支える技術」 より

  • 開発ポリシー 「コードレビューにより品質を高める」

・Googleではコードレビューが必須とされています。
・何かプログラムを書いたら、必ず他の開発者にもそれを読んでもらわなければなりません。
・ プロジェクトオーナーによるレビュー（プログラムが論理的に正しいことをしているかどうか確認）
・ リーダビリティ（可読性：Googleでは言語ごとにコーディングスタイルが統一されており、誰がかいても同じようなソースコードになるようになっている）

「Googleを支える技術」 より

  • 開発体制 「少人数からなるプロジェクトチーム」

1つのプロジェクトは2〜6人程度の少人数チームで構成されます。大きなプロジェクトは複数の小さなプロジェクトに分割され、階層的なチームが構成されます。いずれにしても、１つのチームは少人数に保たれ、チーム内で密にコミュニケーションをとりながらプロジェクトをすすめる

「Googleを支える技術」 より

リクルートのものづくりについて

世の中の「不満、不安」を洗い出し、理想とのギャップを埋める手法をとっている模様。リリースした物については、売り上げ、ユーザの声などで検証し、新機能や既存機能のブラッシュアップに取り組んでいる模様。シートなどの道具もいろいろあり、フレームワークは確立している感じがする。

ものづくりの流れ 「１、２が肝。どこまでターゲットの気持ちになれるか？」

1. シーズ・ニーズ想定
不満足・不安など「不」の視点からファクトを洗い出す。仕掛けるターゲットとなる「人（＝生活者）」を見つける。ビジネスになるのはどんなひと？
2. 価値提供の設定
ターゲットカスタマーの気持ちをリアルに腹に落とす。→カスタマーになりきるために何をやっているのか？　ターゲットカスタマー×クライアントの双方価値設定
3. 競合・ポジショニング
4. 企画設計
コンセプトメイクし4Pでヌケ・モレないよう設計
5. 実行
世の中にリリース
6. 結果検証・修正
予め設定した検証軸（効果・売上）カスタマー・クライアントの声

クックパッドのものづくり

詳しくは、こちらに譲るが、ユーザの疑いのない欲求を調べ、それを具体化していくのがクックパッドのものづくり手法。欲求はeogs(emotion oriented goal setting) というフレームワークを利用して、かなり研究している模様。開発ポリシーが多く、ものづくりのフレームワークがしっかりと出来ている。

ただ、クックパッドのものづくりをすぐにマネ出来るかというと大変そう。特に、「疑いのないユーザの欲求を理解する」という部分の質を高めるには、多くの時間を要するだろう。

37signalsのものづくり

ユーザ視点が強く、本当に必要な機能（ユーザが実現したい目的が達成出来るかどうか）を考えて実装する。

より少ないシンプルな機能で競争する

37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」 - Goodpic

  • 機能が少なければ、はやく進化させることができる。開発もテストも時間がかからない
  • ユーザビリティー・テストなどの、特殊な状況ではなく、実際にユーザーが使っている様子を観察して、ユーザーの使い勝手を改善する物だけ実装する
  • 最初にリリースする時に、ユーザーが実現したい目的が達成できる必要がある
  • 本当に要望が多い場合のみ、必要かどうか検討を始める
  • 開発する時間があまったら、新しい機能を追加するのではなく、既に作った機能のブラッシュアップに時間をつかう
  • 新しい事をするより、今もっているものをよくすることを重視
  • 変化し続ける事が何より重要。そのためにシンプルで、小さな規模を保つ
  • 何かを決断するときも、つねに変わることを前提にする
  • 変化させられないプロダクトは、間違ったプロダクト
  • リアルさが重要。設計書などのドキュメントも書かない。ユーザーが実際に使うユーザーインターフェースから作り始める
  • ユースケースなどを書きたい場合は、紙に簡単にメモする程度。時間をかけない。
  • ユーザーが体験する、実際の経験が一番重要
  • ユーザーも、サービスを使って慣れながら、新しい機能や使い方を学習していく
  • ユーザーからのクレームや意見をよくチェックするべき。ユーザーから不満が多い部分は、自分でも不満に思うはずなので、サービスをなおすためのモチベーションになる
Getting Real

Getting Real: The smarter, faster, easier way to build a successful web application

Getting Realは、問題にさし当たった際、あなたの問題の考えに集中せず、問題自体を見るよう、現実を把握する様にリードしてくれるからです。本当に必要な実体と取り組むように仕向けてくれるのです。

ライブドアのものづくりの一部

こちらは、Webに紹介されていた一部の情報だが、ユーザ視点が特徴。ユーザの意見、アンケート、数字（ページビュー）などを見て、新機能追加、既存機能のブラッシュアップを行っている。

  • モバイル向けコミュニティサイト「ワイワイクラブ」

ユーザーが求めてるものを提供することの大切さ

”ユーザーの要望に常に耳を傾け、ユーザーが喜んでもらえるものを考え、更にもう1歩踏み込んでそこに埋もれているマイナス部分をいかにプラスに変えるか？そこまで追求できて初めてユーザーに受け入れられるものができるのではないでしょうか。”

"関連ページのPVや登録数 (率) の推移を追っていくだけでなく、ヒューリスティック評価や、ユーザーアンケートの結果など、多方面から本質的な問題を慎重に抽出して、新しい機能の追加・UI改善などを行います。そして、必ず検証と評価をします。"

書籍、Webから得たものづくりのヒント

狩野モデル

狩野モデル | 用語集 | ミツエーリンクス

狩野モデルとは、製品の品質を検討する枠組みのひとつです。狩野モデルは、顧客の反応が、次の3種類に分類できるとしています。(1)基本品質（例：レストランで料理が出る）、(2)性能品質（例：レストランの料理が旨い）、(3)興奮品質（例：食欲旺盛にさせる程に料理の見た目が素晴しい）。要は、基本品質が満たされない製品は、どれだけコンセプトがすぐれていようが顧客にとっては無価値であることを示しています。

魅力品質を語る前に、基本品質を見つめなおせ、と。自戒的に。（狩野モデルから考える） - kokepiの日記

  • 基本品質
    • 満たされても意識されず、満たされない場合にだけ酷い不満要因となるもの
      • クルマ：走る
      • レストラン：料理が出てくる
      • マンション：震度5で倒れたりしない
  • 性能品質
    • 満たされていれば満たされている分だけ、満足度が向上するもの
      • クルマ：きびきび動く
      • レストラン：旨い
      • マンション：住みやすい
  • 興奮品質
    • 満たされなくても全く不満にはならないが、満たされた場合、満足度が大きく向上する
      • クルマ：空を飛ぶ
      • レストラン：酒池肉林
      • マンション：どこでもドアがついている


狩野モデル－品質とは - techdmba

システム開発現場のファシリテーション　P149

アイデア出し：商品・サービスの提案など、全く新しいアイデアを創出するような話し合いのときは、できるだけ意見が出やすいようにうくふうします。たとえば、デジタルカメラの新機能を検討しているときなどは、カメラの大きなイラストを描いて、そこに出てきた意見を書きだすようにします。文字で議論するよりずっとイメージがわいてくるはずです。思いつく意見を出していくようなブレインストーミングでは、付箋を併用すると効果的です。意見が一通り出てきた後に、付箋を並び替えて、色ペンでグルーピングしたり議論の内容を追記していくことで、イメージが固まってきます。ここで、サークル型の図を下地に書いておくと、組み合わせで新しいアイデアが出てくることもあります。

非常識経営の夜明け

P69
精密な計数管理をし、詳しく分析して現状把握をしたところで、やたらに忙しくなるばかりで、売り上げが増えるわけではない。むしろ経理処理は徹底的に手を抜いて、昔ながらの「どんぶり勘定」に戻せば、社員は暇になり楽しいことを企画するようになる。その方がはるかに売り上げが上がる。

P110
最後は自分の感覚なんです。直感、勘なんですね。でも、結論を勘で出すからといって、理論的に考えないで、最初から最後までヤマ勘でやる人は、なんかうまくいってないですよ。それから、理論的に考えて、考えて最後まで理論的な人、つまり、最後にエイヤーと勘に明け渡すことができない人もやっぱりダメ。だからまず、セルフ１を使って、とことん理論的に考え抜いて、いろんなシミュレーションをやって、最後の最後に新皮質を取り除いて、セルフ２に明け渡す。その最後のところで、まだああだこうだと考えていると決断は当たらない。何かこう、すーっと純粋になって、素になれたときの決断がいいんですね。

素晴しいアイディア」が採用されない理由

" 技術的な面, 財務面, 経営面, 人的資源, 先行事例を十分調査, 市場規模 などを考えていない"

mixi engineer blog

常にユーザー視点に立ち、全体の利用者を意識した考えができる

YAGNI(You Ain't Gonna Need It)

年末の大掃除におけるYAGNI(You Ain't Gonna Need It):Geekなぺーじ

「こうなるかも知れない」をドンドン積み上げていって不要に時間を割くべきではないという考え方です。

リーン開発の本質

P65

　優れた製品の背後にはかならず、顧客の身になって考え、何が出来るかを見抜き、絶対不可欠なものや、なくてもよい事柄を判断できる人物がいる。この人物は、顧客を深く理解しているし、自分たちのチームの能力もよく知っている。知識と自信という頑丈な基盤の上で、チームを動かすのである。そして、市場にもっと優れた価値を提供する為に考えをめぐらせ、努力すれば実現にこぎつけられる優れた製品を定義する。この人物は、プロダクトマネジャーという肩書きかもしれないし、製品チームのいちエンジニアから創業者までの誰かかもしれない。重要なのは、この役を担う人物がいなくてはならないこと、そして、その役割に必要な技術と才能を備えた人物が責任を果たさなくてはならない、ということである。

まとめ

Webアプリケーションの開発について、いままで見てきた書籍やWebの情報、イベントに参加したり、意見を直接聞いて分かってきたことで共通していることは、以下である。

  • ユーザ視点（問題解決型）
  • 変化に対応する
  • 少ない開発人数

色々なページや書籍を見て思うのだが、ものづくりについて、「スクラム」や「XP」といった言葉を聞かないことだ。
考え方などを「いいとこどり」して取り入れているのかな。もしくは、そもそもそんな概念しらない？知らないってことはないか・・・。自然とそうなるのかな。

ユーザ視点で問題だなと思うのは、ユーザの視点以上のことが出来なくなってしまうのではないかという恐れ。まぁ、そんなことより、とりあえず使ってもらえるサービスを作れという感じもする。ユーザの視点を超え、ユーザが使ってもらえるサービスを生んでいる会社ってAppleかなー。iPodなどはユーザの想像の領域を超えているような気がするんだよな。iPodが出た当時、あれだけシンプルなデザインと大容量ハードディスクの考え方をユーザの意見を参考にして生み出せただろうか。

企業の分類の例である、

1.業務の卓越性（オペレーショナルエクセレンス）
　品質、価格、購入の簡便性を含む総合力において市場で最高の水準を保っている企業（例：デル・コンピューター）
2.製品リーダー
　発明・製品開発・市場開拓に焦点をあて顧客により広い範囲の製品やサービスを提供する企業（例：インテル、ジョンソン＆ジョンソン、マイクロソフト）
3.カスタマー・インティマシー（顧客との親密さ）
　顧客と親密な関係を築き上げ、特定の顧客ニーズに応えるため、製品やサービスを継続的に提供する。 （例：ＩＢＭ、リッツカールトン）

※参考：ナンバーワン企業の法則

これがWebアプリケーションにも当てはまるだろうか。当てはまるのだとするの、いままで見てきた情報は、「カスタマー・インティマシー（顧客との親密さ）」に近いと思う。製品リーダーやオペレーショナルエクセレンスなどの形はあるのだろうか？製品リーダーだとGoogle検索だろうか？



まだまだ、事例が足りないので、これからも考えていって、自分で実践して見ようと思う。


何か、「ものづくり」について「ご意見」、「事例」、「自分はこんなことやってるよ！」など、大歓迎です。お気軽にご意見ください。