2012年12月15日土曜日

PHPのunit testをやってみる (基礎編1)

前回の内容

http://masatonave.blogspot.com/2012/12/macphpunit-test.html

今回の内容

目的

単体テストの書き方を覚える。

方法

PHP Unitのマニュアルの第4章を写経し、自分の理解を記録に残す。

テストの書き方


  1. テストはテストクラスを作って実行する。
    • テストクラスのクラス名は "テスト対象クラス名"+ "Test"
    • テストクラスはPHPUnit_Framework_TestCaseを継承して作る
  2. テスト項目1つに対して1つテストメソッドを実装する。
    • メソッドの名前はtestで始まる
    • テストメソッドはクラスメソッドで、アクセス制御はpublic
  3. テストメソッド
    • アサーションメソッドを使って、値の比較など検証を実施する。
      • 例 : assertEqual($val1, $val2);  → $val1と$val2が等しいことを検証
    • 1つのテストメソッド内ではテストしたいことだけ、検証する
  4. 実行順序など、テスト間に依存関係がある場合は@dependsアノテーションを付ける

実践

コード

PHP Unit 公式の例4.2
http://www.phpunit.de/manual/current/ja/writing-tests-for-phpunit.html

<?php
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testEmpty()
    {
        $stack = array();
        $this->assertEmpty($stack);
 
        return $stack;
    }
 
    /**
     * @depends testEmpty
     */
    public function testPush(array $stack)
    {
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertNotEmpty($stack);
 
        return $stack;
    }
 
    /**
     * @depends testPush
     */
    public function testPop(array $stack)
    {
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEmpty($stack);
    }
}
?>
エディタで書いて、stack_test_case.phpとして保存。

実行結果

$ phpunit stack_test_case.php 
PHPUnit 3.7.10 by Sebastian Bergmann.

...

Time: 1 second, Memory: 4.50Mb

OK (3 tests, 5 assertions)

テストコードがやっていること

この例題は、スタックのpushとpopを検証する。

testEmpty()メソッド
スタックの生成と検証の2つの役割を持っている。空の配列を作り、assertEmptyで空であることを検証し、フィクスチャとしてその配列を返す。 フィクスチャ(fixture)とは、テストしたい状況。

testPush()メソッド
ここでテストしているのは「スタックにpushできるか」ということ。依存関係としてtestEmpty()メソッドを指定しており、testEmpty()が用意した空のスタックを受け取ってarray_push()の実行結果に対して検証している。また、要素が1つ積まれたスタックというフィクスチャを用意する役目も持っている。

testPop()メソッド
「スタックからpopできるか」を検証している。依存関係としてtestPush()メソッドを指定し、要素が1つあるスタックを受け取って、array_pop()の実行結果に対して検証している。

補足: プロデューサとコンシューマ

  • プロデューサ:テスト対象(フィクスチャ)を用意するテストメソッド。 
    • testEmpty()は空のスタックを生成するプロデューサ
    • testPush()は要素に'foo'が1つ積まれたスタックを生成するプロデューサ
  • コンシューマ:プロデューサの生成したインスタンスに依存するテストメソッド
    • testPush()はtestEmpty()に依存するコンシューマ
    • testPop()はtestPush()に依存するコンシューマ

テストを書く上で大事なこと


1つの要件が変わったときに、すべてのテストメソッドを書き直すようでは、テストが開発の負担になってしまう。

テストメソッド間の独立性をできるだけ上げること。

具体的には、フィクスチャと依存関係を上手に使い、テストする対象の生成はメソッド内に書かない。

2012年12月13日木曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (後編)

読書の目的

前回のエントリに引き続き、プロジェクトマネジメントを知り、エンジニアとして参画するときにいつ何をすればよいのかを読み取る。


プロジェクト詳細設計(続き)

タイムマネジメント

WBSの最小単位はワークパッケージ。ワークパッケージをさらに細かく作業単位に落し込み、スケジュールを作成する。

アクティビティ

作業単位。 ソフトウェア開発で言えば、「プログラム作成」がワークパッケージで、プログラムを構成する「モジュール作成」がアクティビティに該当する。

アクティビティの依存関係
  1. 強制依存 : 「☓☓が終わらないと、〇〇は開始できない」
  2. 任意依存 : 「この順序で進めると無駄がなく効率的」
  3. 外部依存 : プロジェクトのアクティビティそのものではない

マイルストーン

アクティビティを実行していく過程で訪れる節目。 プロジェクトが目標を達成しているか検証し、必要であれば修正を行うタイミング。
例)「デザイン承認」「システムリリースの見極め」




→ 作業には順序と依存関係がある。 どこの作業で遅延が生じやすいか、遅延が後の工程に響く部分であるかを把握し、プロジェクト進行での時間見積もりの際に共有する。またスケジュールは変更されるので、スケジュールの書式は変更管理を前提にする。


プロジェクト運用

プロジェクトの発足

プロジェクトチーム育成の責任

マネージャはプロジェクト目標を達成するためにチームを特定し、形成し、維持し、動機付けし、リードし、奮起させる。

ソフトスキル = マネージャに要求される人間関係スキル。メンバーについて、その感情を理解し、行動を予測し、関心ごとを認識し課題を追跡することで問題を最小限にし、連携を強化できる。

プロジェクトチームの形成活動

チーム環境を作るうえで最も重要なスキルのひとつは、プロジェクトチームの問題をチームの課題として取り扱い、話し合えること。

プロジェクトマネージャが担う役割
  • トップマネジメントの指示やチームメンバーの積極的な参加を取り付けること
  • 表彰と報酬
  • チームアイデンティティの形成
  • 衝突のマネジメント
  • チームメンバー間の信頼とオープンなコミュニケーション促進

キックオフミーティング

プロジェクトの「これまで」と「現状」を共有し、リスクを検討する。
アジェンダ
  • 自己紹介 : 所属・役割を紹介
  • 制作者の提案・プロジェクトの経緯 
  • 進め方 : タスクが誰から発生し、誰へ引き継がれるか、どの段階で確認をとるか。
  • 想定されるリスク : 主たるリスクは時間不足とコミュニケーション
  • 体制の確認
  • コミュニケーションルール
  • 会議体とその参加者
  • 質疑応答
  • 次のアクションについて : とりかかること、調べて再度連絡すること

変更管理シート

「手を動かす」段階になると、考慮漏れが表面化する。
規模が小さなプロジェクトや突貫工事のようなプロジェクトでは、トラブル発生時など「いざ」というときに経緯を失念していることがあるので、品質管理はデータ化する。

参照性の高いドキュメントフォーマット

政策の前提が書かれた資料はプロジェクトにおいて頻繁に流用・転用される。
適切なファイル命名規則を定めておくことでファイルの数が増えても管理ができる。

→ エンジニアはマネージャの意図を汲み、コミュニケーションにおいてはプロジェクト目標の達成を第一に考える。口を開く前に、その情報が「チームの課題を解決できる」、「チーム間の信頼向上につながる」など、チームにとって役に立つかという判断基準でチェックし、適切に発言する。個人的な感情は抑え、チームメンバーとして求められる振る舞いを意識する。

制作ディレククションとプロジェクトマネジメント

品質 = 「本来備わっている特性がひとつにまとまって、その結果、どの程度要求事項を満たしているかの度合い」。欠陥のなさ、扱いやすいさ。 機能数などは「等級」であり、品質とイメージは似ているが、意味は同一ではない。


マネージャはプロジェクトの品質と成果物の品質を監視・管理する

→ 成果物が納期に間に合うだけでなく、そのプロジェクト自体がどう進んだかもマネージャの関心事項。 エンジニアは状態が芳しくないときこそ、遠慮無くマネージャへ報告・連絡・相談する。

計画の変更とその手順

変更 = 要件定義の段階で定めた成果物かスコープが代わること。

多くのWeb制作プロジェクトは期間が短い。 見積もりに割ける時間が短く、「やりながらわかる」ことが多い。完全にプロジェクト計画通りになるプロジェクトはない。重要なのは変更の必要が生じたとき、マネージャが誰かのスキルやリソースの「せい」にしないこと。

変更の種類
  • 成果物 (数量)
  • スコープ (仕様、メンバー、予算、期日、ToDo)
  • 変更計画および変更の手順
  • 変更管理の対象 
  • 担当者
  • 連絡体制
  • 見直しの頻度
  • 会議体

→ エンジニアはプロジェクトの変更は不可避であることを理解し、変更が必要になるときに変更内容となぜその変更が必要なのかをマネージャへ伝える。

制作フェーズにおけるヒトのマネジメント

マネージャはプロジェクト実行フェーズでは
  • プロジェクトチーム育成およびトレーニング
  • 経営企画、人事、財務おいった機能部門との調整
  • コンフリクトの解決
をおこなう。


コンフリクトのパターン
  • プロジェクトチームのメンバー同士
  • メンバーとプロジェクトマネージャ
  • 制作者と外部パートナー
  • 制作者と発注者
  • 制作者と発注者側のステークホルダー
  • 発注者と発注者側のステークホルダー

コロケーション  = チームとしての実行能力を高めるために、プロジェクト、チーム、メンバーの大部分または全員を同じ場所に集めて仕事にあたること。 面と向かって速やかに問題解決を行えることがメリット。

スキルとパフォーマンスの見極め

「スキル」と「パフォーマンス」、「モチベーション」はプロジェクトの進行によっへのどうするため、マネージャはメンバーのアサインが妥当であるか、常に確認する。 

スキルとパフォーマンスを混同しないこと。
スキル = 技量。
パフォーマンス = 性能、成績。

スケジュールにしわ寄せが着て、あるメンバーにタスクが集中した場合、そのメンバーのパフォーマンスは落ちる。


チェックイン = 近況や心境をフリートークで話す。メンバーの様子を把握するファシリテーション技術のひとつ。 

対立の芽を摘む

Webサイト制作が分業制で、全体のスコープや進捗を把握できるメンバーが限られている以上、すべてのメンバーにすべての情報が与えられているとは限らない。

マネージャはスケジュールと優先度を睨みつつ、対立の芽を先見的に摘んでいく。

→ マネージャは士気をあげようといろいろな施策を打つ。 エンジニアはその施策が何を目的としているのか、意図を理解し、妨げないようにする。


制作フェーズにおけるコミュニケーションのマネジメント

コミュニケーションモデルとノイズ

コミュニケーションの要素
  • 発信者
  • 受信者
  • メッセージ
コミュニケーションの手順
  1. エンコード :発信者は伝えたい事柄を、伝達可能なメッセージに変換する
  2. 伝達 : メッセージをメディアを介して受信者に届ける
  3. デコード : 受信者は発信者からのメッセージを、読み取り、理解する。
伝達やデコードの段階で「ノイズ」が入り、受信者の理解が妨げられる場合がある。

ノイズ
  • 発信者と受信者の距離
  • 文化や経験などバックグラウンドの違い
  • 受信者の気分

ステークホルダーの期待のマネジメント

  • プロジェクトの便益とリスクを明確に理解してもらい、適切な支援を得る
  • プロジェクトの成果物の受け入れ(承認や検収)の可能性を高める
  • 潜在的なリスク、懸案事項を早期に発見し、対処する


制作ディレクションは、ひとつひとつの判断や確認を短時間で済ませることの連続で、非常に負荷が高い。しかも、プロジェクトマネージャは、メンバーの誰もが追い込まれている状況でコンタクトを取る。

プロジェクトマネジメントにおけるコミュニケーションスキル = 主観なき情報伝達の交通整理

コミュニケーションは「無駄を省く」観点で見直す。 

→ エンジニアは「チームメンバーが理解できる表現」を心がける。 客観的に、誤解をまねかない平易な言葉で。 専門用語、カタカナ語は極力使わない。同じものに対して、2つ以上の呼称を混在させない。

制作フェーズにおける品質保証とテスト


品質管理 = 品質の基準と計画を取り決め、実施すること。

「発注者が喜ぶと思ってデザインに磨きをかけた」、「とりあえず形にした/とにかく納期に間に合わせるためやっつけた」などの対処的行動は、PMBOK本来の「品質」の基準と関係がない。納品物に求めれるのは「取り決めた品質の基準に適合しているか」。


品質管理計画と立てるとリスクを発見したり、成果物をチェックしているときにバグが見つかって納期を圧迫するなど、品質管理とリスクマネジメントは密接な関係。

Web制作におけるリスクマネジメント手法

前提条件のテスト:定性的なリスク分析。WBSやファイルリストから、「たられば」で状況を想定して、対処方法を検討する。

コンティジェンシー計画:「不測の事態」(=コンティジェンシー)が発生したさいにどのように対処するかを前もって決めておく。この計画がうまくいかなければ、さらに代案を検討する。

品質管理の観点

よいプロジェクトは 「発注者のニーズに応える」と「納品品質を満たしている」が均衡する。 発注者は人であり、満足度は感覚的・定性的。 納品物はソフトやモノであり、数値的・定量的である。

品質チェックのフロー
制作 → 内部チェック → 発注者確認 → 修正 → 発注者承認 → 確定

チェックの留意事項
  • 計画することが目的化していないか
  • チェック者が「やっつけ」「流れ作業」に陥る手段やプロセスになっていないか
  • チェック結果は後に取りこぼしを生まぬよう、整理されているか
テスト計画で決めること
  • テストの種別と目的
  • テスト手法とタスク
  • テスト要員

チェック = 中間生成物に瑕疵がないか、要件に適っているか。
テスト = 要件を満たしているか、バグなく稼働するか。
発注者レビュー = チェックやテストとは別個で発注者に依頼し、承認を得る


チェックは「他人の間違いをあげつらう」のではなく、「検収をするまでのプロセスを残す、責任をもって制作し品質管理を実施したという根拠を残す」。

→ エンジニアとしては品質の数量化・定量化を行い、品質が確認できるようにする。  
人力によるチェックを計画する際はチェック実施時の「めんどくささ」を考慮し、「やっつけ」を防ぐ。ソフトウェアモジュールなら単体テストがGREENになった件数などで定量的に品質が評価でき、自動化も可能。


読み終えて

品質に対する考え方、士気に対する考え方は改める必要性を強く感じた。
凝り性を抑えて実装する方法、コミュ障が士気を下げないようにする方法など、自分用の指針は別途考えないといけない。



2012年12月9日日曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (中編)

読書の目的

前回のエントリに引き続き、プロジェクトマネジメントを知り、エンジニアとして参画するときにいつ何をすればよいのかを読み取る。


特にプロジェクトがうまくいかなくなるのを未然に防いだり、立て直すためのコミュニケーションの方策を知りたい。

詳細見積もり

WBS (Work Breakdown Structure)

プロジェクトの作業と要素成果物を細かく定義する。
ボトムアップによる見積もりにつかう手法。

WBS作成のポイントと留意事項

ポイント
  • 必ず一度、実施項目を書き出す
  • 完璧を目指さない
  • レビューを通じて無理や破綻をつぶす
留意事項
WBS作成者は制作のワークフローや要領がわかり、各工程に慣れていることが前提。
不正確なWBSは重要なタスクを見落としたり、不必要なタスクを実行するなど失敗の元凶となる。

WBSは修正がされることを前提に、メンテナンスのしやすさとバージョン管理を考慮する。

見積もりの認識がズレがちなポイント

  • スコープ
  • 金額そのもの
  • 数量と単位の認識
  • 制限や制約

→ エンジニアとしてできることは、実現不可能な見積もりにNOを言うこと。技術的な制限や制約などを非エンジニアにわかりやすく、誤解のない表現にすること。 プロジェクト開始後に変更されそうなポイントの指摘、対策。

プロジェクト立ち上げ時の計画

PMBOKの計画プロセス群

  • プロジェクト総合マネジメント
  • プロジェクトスコープマネジメント
  • プロジェクトタイムマネジメント
  • プロジェクトコストマネジメント
  • プロジェクト品質マネジメント
  • プロジェクト人的資源マネジメント
  • プロジェクトコミュニケーションマネジメント
  • プロジェクトリスクマネジメント
  • プロジェクト調達マネジメント
マネジメント対象はリソース(ヒト、モノ、カネ)、スケジュール、アウトプット(スコープ、品質、リスク)、そしてプロジェクト自体の制御やコミュニケーション。

人的資源マネジメント

プロジェクトを推進する「人」の役割の明確化。
「ステークホルダー全員を、プロジェクト達成のために効率的に活かす」体制づくりがおろそかにされがち。

RACI (Responsible Accountable Consulted Informed) 

責任分担のマトリクス。どのタスクに対してどのような役割を果たすのかを示す。
R : Responsible 実行責任者。
A : Accountable 説明責任者。
C : Consulted 協業先
I : Informed 報告先
「誰を説得するか」「どこまでフォローするか」といったコミュニケーションの道筋がはっきりする。

リスクマネジメント

プロジェクト開始前にあらかじめありえるリスクを予想し、対処法を決めておく。

特性要因図 (fish-born chart)

リスクをリストアップして、リスクの程度と頻度、対応策を計画に落としこむ。
特性:現象や結果などのよくないこと。
要因:特性に影響する要素。 要因の抽象度(粒度)でレベル分けする。


調達マネジメント

「今回のプロジェクトでは、何を狙いとしてやるべきか?そのためには何が必要でどう取り寄せるか?」

対象はヒト(人員)・モノ(什器、ネットワーク)・カネ(予算、費用)・コト(手配、契約行為)。またプロジェクト終了後の返却や破棄・処分も計画する。


品質マネジメント

品質 = 「プロジェクトのステークホルダーが、プロジェクトに何を期待するか?」を満たすこと。

品質マネジメントの分類
  • 評価に関する作業 
    • 品質の維持するためのテスト計画、テスト実施
  • 予防に関する作業 (事前対応)
    • 欠陥を予防し、結果として欠陥対応にかかるコストを削減するための作業
  • 失敗に関する作業 (事後対応)
    • 成果に瑕疵やミスがあったときに、改修やクレーム対応を行う
→ エンジニアとしては、欠陥が発生したときの被害の大きさ、起こりやすさを把握し、計画段階で説明する。説明する範囲は責任分担マトリクスに従う。

コミュニケーション計画

プロジェクトは人が進めるもので、メンバーの作業と行為によって成し遂げられる。メンバー同士の意思疎通がうまくいかない状態や、想定の食い違いを放置していればプロジェクトは失敗する。

プロジェクト管理におけるコミュニケーション

コミュニケーションの分類
  • 情報配布 : 必要な情報をタイムリーに提供する
  • ステークホルダーへの期待のマネジメント : 関係者のニーズに応え、課題を解決し、プロジェクト破綻を防ぐ
  • 実績報告 : 実際のプロジェクト進捗とベースラインの差異を明らかにする。

プロジェクトの実行時はルールを元にコミュニケーションを図る。
ルールは堅すぎず流動的すぎず運用する(状況が変わればルールは変更する)。

コミュニケーションマネジメントに用いるドキュメント
  • プロジェクトマネジメント計画書
  • ステークホルダー登記簿
  • 課題や変更のログ : 課題管理票もしくはサービス(Excel,JIRA,Redmine,Backlog)
  • 実績報告書

コミュニケーションマネジメント計画書

記載項目例
  • ステークホルダーは誰か、どんな情報を必要としているか
  • コミュニケーションの手段、書式
  • コミュニケーション手段ごとの頻度
  • コミュニケーションの発信者、受信者、責任者
  • コミュニケーションマネジメント計画書の変更手続き
  • プロジェクトでの用語、コミュニケーション様式、書式関連の用語と説明

コミュニケーションの実践

コミュニケーションについて計画を立て、実行する目的は
  • 作業を効率化(タイムロスを減らす)
  • 混乱を起きにくくする、起きても早々に収束する
  • 各メンバーのストレスを減らし、作業に集中する
無駄を排し、意思疎通をしやすくするためにルールがある。
ルールに従う時やルールそのものを作ったり変えるときには
「プロジェクト推進の全体最適化」
「その情報伝達の先に何が控えているか」
「トラブルが発生したときに、どこを参照すればよいか」
などを考慮する。

コミュニケーションには感情が入り込むため、規格化とルール化でコミュニケーションの品質を担保する。
コミュニケーションが円滑であることは、必ずしも仲良しである、意見が一致しやすいといったこととは同じではない。

コミュニケーション計画で決めておくこと

  1. 決裁ルートと連絡体系
    • 「ものごとを取り決める」ために、誰が誰に相談し、誰が決めるか。
    • 「責任の所在」を含めた「取り決めの道筋」を事前に用意しておく。
    • 決裁ルートの「往路(打診)」と「復路(返答)」を押さえる。
      • 特に復路に不備があると、認識漏れが生じる
    • 決裁要件は「現象」、「プラン」、「どうして欲しいか」、「期限」
  2. 会議体
    • 種類、頻度、曜日と時間帯、所要時間、参加者、場所、司会、議事録
  3. 手段
    • 打ち合わせ、会議、メール、グループウェア、ファイル

コミュニケーションについての心づもり

  • 自分ができることは何か : 権限上可能なこと、状況として可能なこと
  • 主観を疑う : メンバーからのフィードバックを受ける
  • コミュニケーションツールの変更を想定する

 すべての情報を記憶し追うことは不可能。参照不可能な情報は存在しない。

→ エンジニアは、ルールに従い、感情の影響をした品質の高いコミュニケーションを心がける。 マネージャーが想定したコミュニケーションルールの問題に気づいたとき、その状況と改善方法を提案する。



まだまだあるので後編に続く




2012年12月8日土曜日

読書記録:失敗しないWeb制作 プロジェクト管理のタテマエと実践 (前編)

読書の目的

自分の興味があることはプロジェクトにおいてどのようなタスクがあり、どのような役割分担がされているかということ。

上司やチームメンバーへの報告、連絡、相談は、どのような事柄について、どのようなタイミングで、どのような粒度で行えばよいのかを明らかにする。


プロジェクトとは

  • プロジェクト = “独自”のプロダクト を“創造”する“有期性”の業務
  • 監視コントロールによって“計画”と“実行”を繰り返す
  • 要求 (作りたいもの) と資源 (ヒト + モノ + カネ + 時間 )のトレードオフ
→ まず計画段階ではどのくらいの資源が必要になるか、見積もりを行う必要がある。エンジニアがマネージャへ情報を伝える際には精度を伝える必要がある。
実行において見積もりが外れた場合、マネージャは要求を変更するか、資源を追加するかを判断する。

PMBOKの9つの知識エリア

  • 総合マネジメント 
  • スコープマネジメント (実施すること)
  • タイムマネジメント (スケジュール、何をいつまでにやるか)
  • コストマネジメント
  • 品質マネジメント
  • コミュニケーションマネジメント
  • 人的資源マネジメント (チームの編成・育成・管理)
  • リスクマネジメント (リスクの予測と対処)
  • 調達マネジメント 
→  これらの計画と実行結果異なっていれば、報告する。
成果物がスコープと異なる、納期に間に合わない、費用がかかる、品質が不十分、障害など予期せぬ悪影響が発生する

見積の種類

見積もりは「ざっくり」から「概算」を経て、「確定」へと進化させていく。

ざっくりとした見積もり 

提案書作成段階まで に行う見積もり。  過去の蓄積と比較し、だいたいこのぐらいという相場を提示する。

概算見積 もり

受注確定前までに行う見積もり。金額はまだ確定しない。与件や提案内容をもとにタスクやリソースなどの項目を洗い出す。

確定見積もり

プロジェクト終盤 で発注者に請求する段階での見積もり。プロジェクトの途中で成果、期日、使用リソースが変動したものを加味して確定する。

→ エンジニアは「ざっくり」と「概算」の見積もりにおいて、求められる情報の粒度が異なること理解し、伝えるべき情報の取捨選択する。
特に私の場合、情報をすべて(広範囲に、詳細まで)伝えようとするので、マネージャがそれを噛み砕いて状況を整理し、判断するコストが高い。


要件定義と詳細見積もり

心構え

  • 要件定義とは、与件や要望を実現するためにまとめ、明文化すること
  • 要件を作らなくてもプロジェクトはスタートできるが、逐次決定ではスタート以降のコントロール能力とスピードが低下する
  • 詳細見積もりは「正解を出す」よりも「あいまいさをなくす」


スコープ

「何を」「どう作るか」という「範囲」。それがそろってはじめて「いくらかかるか」がわかる。


Web制作のスコープ = 「プロジェクトのスコープ」 +  「成果物のスコープ」
プロジェクトのスコープ =  「成果物を提供するための作業」
プロジェクトのスコープ定義 =「その作業範囲を限定すること」
成果物のスコープ = 「何を制作し、何を納品するか」
成果物のスコープ定義 = 「要素成果物の洗い出し」

ベースライン

発注者と制作者で握り合った「基準」。成果物スコープ、プロジェクトスコープ、コストにおいて設定する。

コストコントロール


プロジェクト実行時に予算に変更をおよぼす要因を明らかにし、必要性を決定し、変更をコントロールするプロセス。


要件定義の作業

  1. 情報収集
    • 掘り下げ不足のチェック、メモ適切に使ってヒアリング
  2. 整理・分析
    • 優先順位をつける(ROIと重要度でクロス分析)
    • 大目的、目的、目標、今回のスコープを決定
  3. 文書化

デスマーチが起こる要因

デスマーチ = 制作メンバーが対応しきれる以上の負荷がかかり続ける状態。起こる要因は主として、スケジュールと作業量の見誤り。また要件定義と詳細見積もりのミスに起因。

不確定要素が発生したときの対処フロー

不確定要素が
致命的でない → 棄却/制作者内部で共有。
致命的 → メールや打ち合わせで確定させる。

致命的かどうかの判定

  • それについて決定しないと次のタスクに進めない
  • それについて決定を誤ると制作者と発注者の双方が不利益を被る


→  エンジニアとして要件定義に参加する場合、与件や要望を最小限満たすためにどのような解決策があるか、甚大な失敗をしやすい箇所はあるのかという情報に絞って、マネージャへ伝達する。また要件定義なしで着手した場合、後の工程でどのようなリスクがあるかを理解する。

詳細見積もりの手法とレビュー方法

手法
  • トップダウン見積もり
    • スコープから規模算出し、作業量(単価、工数)と合わせて計算する
    • 開発コスト = 規模×作業量 + 予備費
    • 規模の想定が正しければ、客観的。弱点は想定外タスクや取りこぼし。
  • ボトムアップ見積もり
    • 作業項目など全タスクを洗い出し、作業費(単価×工数)算出
    • 開発コスト = 開発作業費 +  モノ + 変動費 + 予備費
    • タスクをもれなく列挙するので、粒度が高い。弱点は見積もりにかかる時間と工数設定に主観が入りがちなこと。

見積もりの精度を上げるにはレビューをする。
技術的な観点から
  • 「その実装方法は技術的な要件を満たしているか」
  • 「物理的な制約と矛盾していないか」
などをチェック。
  

長くなってしまったので、残りは別の機会に。

MacでPHPのunit testをやってみる (準備編)

動機


  • もう回帰テストを人力でやりたくありません。
  • リファクタリングのためには、テスト自動化。

自分Python使いなのになんでPHPなのよ?


人を増やすときに「Python使ったことないです。PHPならできます。」という状況で泣きをみたくないです。

環境構築

マシン

MacBookPro、OSはMountain Lion


PEARをインストール

コマンドを叩く
sudo php /usr/lib/php/install-pear-nozlib.phar
実行結果
No log handling enabled - using stderr logging
Created directory: /var/db/net-snmp
Created directory: /var/db/net-snmp/mib_indexes
[PEAR] Archive_Tar    - installed: 1.3.7
[PEAR] Console_Getopt - installed: 1.3.0
[PEAR] Structures_Graph- installed: 1.0.4
[PEAR] XML_Util       - installed: 1.2.1
[PEAR] PEAR           - installed: 1.9.4
Wrote PEAR system config file at: /private/etc/pear.conf
You may want to add: /usr/lib/php/pear to your php.ini include_path

参考 http://memorandum9.blogspot.jp/2012/11/macos-x-mountain-lionpear.html

PHP Unitをインストール

コマンドを叩く
pear config-set auto_discover 1
実行結果
config-set succeeded

もう一つ叩く
pear install pear.phpunit.de/PHPUnit
実行結果
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "pear.phpunit.de", adding to registry
unknown channel "pear.phpunit.de" in "pear.phpunit.de/PHPUnit"
invalid package name/package file "pear.phpunit.de/PHPUnit"
install failed
 エラーったので、sudoる

sudo pear install pear.phpunit.de/PHPUnit
実行結果
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "pear.phpunit.de", adding to registry
unknown channel "pear.phpunit.de" in "pear.phpunit.de/PHPUnit"
invalid package name/package file "pear.phpunit.de/PHPUnit"
install failed
watanabe-shouhito-no-MacBook-Pro:php_unit_test watanabemasato$ sudo pear install pear.phpunit.de/PHPUnit
Attempting to discover channel "pear.phpunit.de"...
downloading channel.xml ...
Starting to download channel.xml (804 bytes)
....done: 804 bytes
Auto-discovered channel "pear.phpunit.de", alias "phpunit", adding to registry
Attempting to discover channel "pear.symfony.com"...
downloading channel.xml ...
Starting to download channel.xml (811 bytes)
...done: 811 bytes
Auto-discovered channel "pear.symfony.com", alias "symfony2", adding to registry
Did not download optional dependencies: phpunit/PHP_Invoker, use --alldeps to download automatically
phpunit/PHPUnit can optionally use package "phpunit/PHP_Invoker" (version >= 1.1.0)
phpunit/PHP_CodeCoverage can optionally use PHP extension "xdebug" (version >= 2.0.5)
downloading PHPUnit-3.7.10.tgz ...
Starting to download PHPUnit-3.7.10.tgz (117,079 bytes)
...done: 117,079 bytes
downloading File_Iterator-1.3.3.tgz ...
Starting to download File_Iterator-1.3.3.tgz (5,152 bytes)
...done: 5,152 bytes
downloading Text_Template-1.1.4.tgz ...
Starting to download Text_Template-1.1.4.tgz (3,701 bytes)
...done: 3,701 bytes
downloading PHP_CodeCoverage-1.2.7.tgz ...
Starting to download PHP_CodeCoverage-1.2.7.tgz (157,806 bytes)
...done: 157,806 bytes
downloading PHP_Timer-1.0.4.tgz ...
Starting to download PHP_Timer-1.0.4.tgz (3,694 bytes)
...done: 3,694 bytes
downloading PHPUnit_MockObject-1.2.2.tgz ...
Starting to download PHPUnit_MockObject-1.2.2.tgz (20,347 bytes)
...done: 20,347 bytes
downloading Yaml-2.1.4.tgz ...
Starting to download Yaml-2.1.4.tgz (38,574 bytes)
...done: 38,574 bytes
downloading PHP_TokenStream-1.1.5.tgz ...
Starting to download PHP_TokenStream-1.1.5.tgz (9,859 bytes)
...done: 9,859 bytes
install ok: channel://pear.phpunit.de/File_Iterator-1.3.3
install ok: channel://pear.phpunit.de/Text_Template-1.1.4
install ok: channel://pear.phpunit.de/PHP_Timer-1.0.4
install ok: channel://pear.symfony.com/Yaml-2.1.4
install ok: channel://pear.phpunit.de/PHP_TokenStream-1.1.5
install ok: channel://pear.phpunit.de/PHP_CodeCoverage-1.2.7
install ok: channel://pear.phpunit.de/PHPUnit_MockObject-1.2.2
install ok: channel://pear.phpunit.de/PHPUnit-3.7.10
うまくいっているらしい。コマンド叩いて確認
phpunit --version
実行結果
 PHPUnit 3.7.10 by Sebastian Bergmann.


最初のテスト

テストコードを書く
vim sample_test_case.php
動くかどうかを知りたいので、中身は公式からコピペ
<?php
class StackTest extends PHPUnit_Framework_TestCase
{
    public function testPushAndPop()
    {
        $stack = array();
        $this->assertEquals(0, count($stack));
 
        array_push($stack, 'foo');
        $this->assertEquals('foo', $stack[count($stack)-1]);
        $this->assertEquals(1, count($stack));
 
        $this->assertEquals('foo', array_pop($stack));
        $this->assertEquals(0, count($stack));
    }
}
?> 
参考 http://www.phpunit.de/manual/current/ja/writing-tests-for-phpunit.html

実行する
phpunit sample_test_case.php
結果
PHPUnit 3.7.10 by Sebastian Bergmann.

.

Time: 0 seconds, Memory: 4.50Mb

OK (1 test, 5 assertions)
大丈夫らしい。










2012年12月1日土曜日

これから勉強したいこと

背景と動機

一言でいえば、自分の力不足でチームに迷惑がかかることを実感したから。

ソフトウェアは学生時代からつくっていたが、自分の好きなやり方で開発してきた。
作るソフトウェアの規模も一人で十分に把握できる範囲であり、また開発速度が優先され、他の人が保守することが考えられていなかった。

チームでの開発では他の人と仕様を共有したり、さらにはエンジニア以外の人に仕様を技術用語なしに平易な言葉で説明する必要がある。だからチーム開発を円滑にするためのスキルを強化する。

何を身につけたいか

  • 開発マネジメント
    • なにをやるか・やらないか
    • やるべきことをどんな順番でやるか
    • 状況の変化に対してどのように対処するか
  • コミュニケーション
    • 必要なときに必要な情報を必要な量だけ共有する判断力
    • 説明する言葉の選び方と話し方
    • ドキュメント作成

どうやって学ぶか

既存のうまいやりかたに倣うのがいちばん手っ取り早い。 それを試してみて、自分に合わなければ自分なりにアレンジをすればよい。

会社の先輩に聞く

幸運なことにMobile Web開発については百戦錬磨の先輩方がたくさんいる環境にいる。まずは自分がどのような状態にいるのか、何をすべきなのかを相談する。

本を読む・社外の勉強会に参加する

受託が中心の会社であるので自社サービス開発の進め方については、自分で勉強しておく必要がありそう。

今のところ読む予定なのは
  • 失敗しないWeb制作 プロジェクト監理のタテマエと実践
  • Webプロジェクトマネジメント標準 PMBOK(R)でワンランク上のWebディレクションを目指す
  • アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法

開発全体でどのような工程があり、どのような意思決定がされ、どのような分担をすればよいのか、基本知識を仕入れたい。

学んだこと、実践したことを見える形で残す

これまでは溜め込んだ知識は自分の中にしかなかった。脳には限界があり、しばらく経つと忘れてしまう。同じことを学びなおすことになるのは避けたい。
自分のためにも、そして自分が学んだことを他の人にも役立てるためにもblogに残していく。

2012年11月30日金曜日

アプリ開発でよいものを早く作るためにできそうなこと

事の発端

アプリ開発の途中で手戻りがあったり、作り替えて言ったら当初の案と異なるものが出来上がったりする。もう少し開発速度を上げるために、エンジニアの自分には何ができるのかを考えた。

前提条件

アプリ開発はチームで行う。

プランナーがまず実現したいことを箇条書きやラフスケッチで提示する。
エンジニアはプランナーのスケッチや、デザイナーの画面構成案をもとに実装する。

課題

プランナーが提示できるのは正常系である。どんな異常が発生するかはエンジニアがある程度わかっているが、実装しているうちに判明することもある。

解決策

エンジニアが企画段階から参画する

企画や設計の初期段階でうまくいかない事態があることを説明し、画面構成の修正が必要であれば、提案する。

早めにプロトタイプ作成を行い、改善サイクルを回す

レイアウトが決まってしまう前に、見た目は大まかでよいのでロジックだけ先行して作ってしまう。動かしているうちに、動作の問題に気づくことができる

ラピッドプロトタイピングでやりがちな失敗は正常系をまず作ってしまうこと。正常系がいくら素晴らしくても、異常系が粗末だとユーザからの評価を下げてしまう。特にモバイルアプリでは通信状況が変化しやすく、ユーザの誤操作の発生率も高いので、異常系を目にすることが多くなる。

2012年10月14日日曜日

自分の仕事力に関する課題


担当する仕事が変わり、いろいろとうまくいかないことがあった。
自分の何が悪かったのか振り返ったので、忘れないように書き留めておく。

何が悪かったのか

スタンドプレーに走ろうとする

私は一人でなんとかしようと考える傾向にある。
問題が発生してもチームメンバーに連絡する前に、まず自分で解決しようとする。
このため、メンバーは課題の存在すら認知できない。

また課題をすべて解決しようとして、オーバーワークで能率も下がるという悪循環。

コミュニケーションの不足

仕事を分担するときに、相手に何をして欲しいのかを伝える力が足りない。
目的は伝えられても、その実現方法の指示があいまいなら、成果物の品質も劣化する。
また成果物やプロセスの情報が正しく伝わったか、認識合わせをするということを怠っていた。



どうすればよいか

課題を早めに共有する

問題が発生したら、即座に共有する。 また、問題になりそうことも気づいた段階で相談する。

また、「何が問題であるか」という認識のすりあわせも重要。

成果に対する認識あわせをする

最終成果は何か、いつまでに作るのか、品質はどの程度か、
そしてそれらに対して誰が責任を持つのかを明確にする。

作業計画と進捗をこまめに共有する

作業計画を作り、共有する。
作業者は何を報告すればよいのか、確認者はどのような基準で判断すればよいのかを明文化する。

2012年8月22日水曜日

一人ブレスト サービス価値関数

価値を感じる状況は何か?

いろいろなモノやサービスを使うとき、たいていはそのサービスに価値を感じている。

サービスに価値を認め、対価を支払うのは人間である。
価値があるサービスを提供できれば、対価を支払ってくれる可能性は高い。


ここで着目したいのは、価値は受け手の頭の中に存在する、ということ。
だからあるユーザに対して、サービスの価値を左右する要素としては
  • サービス自体の持つ状態
  • ユーザの持つ状態
の2つを考慮する必要がある。


言い換えれば、価値 はサービスの性質と利用者の性質の関数である。
価値 v = f(x,y) 
ここでx:サービスの状態 y:利用者の状態
という式を考える


いろいろなユーザに対して df/dyを計算してみて、その分散が小さいサービスほど利用者の状態に影響を受けない。
yを年齢や性別と考えれば、万人受けするサービスの検証となるだろう。
yをユーザの利用期間と考えれば、熟練度が変わっても心地良いUXが提供できているサービスとなるだろう。

サービス提供者側ができること

yの定義域に対して、fを最大化させるには、
x = h(y)
のようにユーザの状態に応じて提供するサービスを変化させることが考えられる。

モノであれば、作ったままを届けることしかできないが、Webサービスであればユーザの状態を知ることができるし、それに応じてコンテンツの見せ方を変えることができる。


では、コンテンツの見せ方をユーザの状態をどうやって対応付ければよいのだろうか?
h(y)はどのような写像となるべきか?

普通ならこの部分はクリエイティブな仕事であり、法則化はされていない。
この写像を導出する方法論を確立できれば、いろいろなことがうまく廻るはず。





2012年8月19日日曜日

読書記録 アジャイルユーザビリティ


ユーザビリティテストをアジャイルに行うには?


  • 手を動かしながら考える
  • 上手に失敗する
    • Fast: 手遅れになる前に、“早め”に失敗する
    • Small: 大失敗は致命傷、“小さく”失敗する
    • Often: “何度も”失敗する。(1回の失敗ではすべての問題がわかるとは限らない)
    • Smart: 同じ過ちを繰り返さない。 “賢く”失敗を重ねる。



「使えない」製品が開発されてしまう理由


  • 「開発時にユーザテストを省略」している
  • 「製品が(ほぼ)完成してからテスト」している
なぜ省略もしくは後回しになってしまうのか?
“専門家”にテストを頼むと「高い・遅い・重い」
 = コストがかかるのであれば、あきらめるか、1回で済ませようとする。


ユーザビリティテストはよい製品を開発するための手段。

ユーザビリティテストをしっかり行うことが目的ではない。
よい製品を作るためにテストが貢献できれば、それで十分。

高速で低コストかつ“軽い”手法を使う
= アジャイルユーザビリティ


誰がこの本を読み、ユーザビリティテストを行うべきか

専門家でなくてもよい。プロダクトに関わる人ができる範囲で実施する。
  • プロダクトマネージャ / プロダクトオーナ
  • 開発者 / デザイナー






2012年7月1日日曜日

勉強会参加記録 BPStudy58

勉強会 BPStudy#58

株式会社ビープラウド様主催の勉強会 BPStudyの58回目に発表者として参加しました。http://connpass.com/event/582/

私の発表は第1部で、ゆめみで提供しているiPhoneアプリ Nailbook について、アプリ開発で得たノウハウを紹介しました。


BPStudy58 第1部 Web系エンジニアがiPhoneアプリ開発を1年続けてみて学んだこと

View more PowerPoint from Masato Watanabe

各所で紹介したゆめ技の技術要素は会社の先輩がたが作ってくださったもので、
私は主にAppleの規約関連と継続開発について苦労話?をしていた感じです。




スライドの最後で紹介したPythonプロフェッショナルプログラミング は本当に良書なので、Python使いで継続開発始めたい人は必読だと思います。


懇親会

欧風居酒屋 タンネ
http://www.tanne-pf.co.jp/

ドイツビールのレパートリーが豊富なお店でした。

飲んだのはPAULANER Hefe-Weissbier。
小麦を使った、濃厚で甘みのあるビール。


飲み会では、ビープラウドの皆様の技術トークに圧倒されました。
JavaScriptの深い話を聞いて私の頭がStackOverFlowを起こしたので、
積み本の「パーフェクトJavaScript」を真面目に読もうと思いました。

ひとつ気づいたのは、他社のエンジニアと話すということは、自分の技術レベルを見直すよい機会になるということ。
非コミュなのでこれまで勉強会の懇親会にはあまり参加してこなかったのですが、
これからは積極的に参加しようと思いました。

2012年6月7日木曜日

女子向け写真アプリ調査



知りたかったこと

どんな写真投稿されているのか?その見せ方は?
どんなユーザ体験があるのか?ユーザ間のコミュニケーションはあるのか?
ビジネスモデルは?

girls pic

写真のカテゴリ:ネイル、ファッション、コスメ、ライフスタイル
コンテンツの見せ方:人気、新着、お気に入り、ユーザの投稿履歴、ユーザのfav履歴、運営からのお知らせ
コミュニケーション:niceボタン (写真投稿者へのフィードバック) favボタン(写真やユーザのブックマーク)、SNS投稿(Twitter,Ameba)

ユーザ体験:雑誌を読むような感じ、写真にフィルターやフレームを選んで加工するのが楽しい、niceされるとうれしい(ほめられ、共感)、写真や自分自身がfavされるとうれしい
ビジネス:???

感想:カテゴリが多いのでなんとなく眺めるという用途がよさげ

snapeee

写真のカテゴリ:グルメ、おでかけ、ペット、買い物、ファッション、イベント、おもしろ
コンテンツの見せ方:フォロー関係にある人のタイムライン、カテゴリ別新着、ボタン別おすすめ、イベントタイムライン
コミュニケーション:Greatボタン、Cuteボタン、Yummyボタン、Likeボタン、コメント、ユーザのフォロー、アクティビティ履歴、SNS投稿(Twitter,Facebook,GREE,mixi)

ユーザ体験:デコるのが楽しい、各種ボタンがおされるとうれしい、コメントされるとうれしい
ビジネス:広告、現在は無料アイテムだけだがデコパーツに課金

感想:ボタンの種類がおおいのでフィードバックされる確率が高そう、友人と一緒に使うと楽しそう

DECO PIC

ほぼ加工専用アプリ
コミュニケーション:SNS投稿(Facebook,Twitter,mixi,Ameba,renren,SinaWeibo)
ユーザ体験:デコるのが楽しい

ビジネス:デコパーツ課金
感想:中国のSNS対応、日本のAmeba対応、つぎはPinterestあたりだろうか?


cotto

写真のカテゴリ:イベント、気持ち、食べ物、動物、風景、日常、ファッション&ビューティ
コンテンツの見せ方:ユーザがテーマを選択するタイムライン、キーワード検索、お知らせ
コミュニケーション:写真をお気に入り、写真にコメント、ユーザをフォロー、SNS投稿(mixi,Twitter,facebook)
ユーザ体験:雑誌をながめるような感じ、自分の投稿した写真がお気に入りになったりコメントがつくとうれしい
ビジネス:???

感想:投稿の敷居が低そう(カテゴリがとても多いので、どれかひとつぐらいはよさげ写真を持っているはず)










2012年6月5日火曜日

読書記録 彼女があのテレビを買ったワケ 第3章 1節

第3章 女ゴコロをつかむ8つのキーワード ①【幸せ】

私の幸せを形にしてくれる人いませんか?

女性は「幸せ」という言葉に弱い。(中略) では、女性が「幸せ」を感じるときは、どんなときだろう?


住宅メーカーが行った家を建てることに関するグループインタビュー


女性たちは、家を建てるという行為の向こうに、一家団欒の家族の笑顔をとてもリアルに描いている。近所の奥様方とのゆったりしたティータイムを、子どもたちを招いてのにぎやかな誕生日会を。そんななかで、忙しく、でも幸せそうにキッチンやリビングを行き来している自分の姿を想像している。

女性は家族のことを思いながらも自分が主役の夢を描いて幸せを感じ、 
男性はそんな家族を客観的に眺め、手に入れた、何かを成し遂げた喜びに幸せを感じている

グループインタビューを受けて、チラシのスタイルを変更
変更前:家のデザイン、間取りなどスペック中心
変更後:一家団欒の写真、幸せな毎日を語ってもらう取材型


「家を建てるのが目的ではない。家族との幸せな毎日を過ごすのが目的」

女性が心の中に持っている漠然とした「幸せ」のイメージを引き出し、増幅させ、あなたの「幸せ」を具現化するためにこの商品はどのようにあなたの役に立つのかをイメージさせることが、潜在的なニーズを呼び起こす

女性はいつの時代も愛されたい

女性は人から好感を持たれることが大好き

客観的な評価や、名誉、数字の達成感よりも、 自分や、自分が大切に思っている人たちが幸せかどうかが重要

「儲ける」を「幸せになる」に、
「買っていただく」を「幸せになっていただく」に、
そういい換えるだけで、女性の共感度はグッと増す。

「この商品で、どんな女性の、どんな幸せをかなえるお手伝いをするのか」というポリシーのない商品では女ゴコロはつかめない。



女性がキュンとくる言葉

「愛される」「ほめられる」という言葉は女性にとっての媚薬

女性の幸せは、人との関係であることが多い。自分をほめてくれる、愛してくれる、あるいは自分が恋をする相手があってこその幸せ

ラッキーな気分

女性はちょこっとした幸せを与えてくれるものに弱い。
占いでよい運勢がでる、コアラのマーチのまゆげ付きに当たる

幸せな気分は、友達と共有しあいたい



まとめ

  • 商品を買ってから始まる「幸せ」ストーリーをイメージさせる商品が女ゴコロをつかむ。
  • 「愛される」「ほめられる」は、女性が満たされるための魔法の言葉。
  • 「占い」「おまじない」は日常のラッキーな気分を盛り上げるアイテム。



















2012年6月2日土曜日

読書記録 彼女があのテレビを買ったワケ 第2章

第2章 モノが売れない時代



どうしてモノが売れないのか?


モノや情報がありすぎて、何を選んだらいいのか、どう使ったらいいのかわからず、困っている人が多い。

人の生き方、価値観は多様化している


昔の女性のカテゴリー分け(ロールモデルが一つ)
10代=学生、20代=OL、30代以上=主婦、60代以上=シニア

-> 20代で稼ぎのよい旦那様を見つけて結婚し、子供を産み、過程を守る



現在は、晩婚化、高齢出産、離婚率の上昇など、20~30代の女性に多様化現象がみられる


昔の30代女性 (結婚していて、子供がいる)にたいするマーケターの認識
「子育てに一生懸命でお金持っておらず、まして自分のことになんてお金を使わない」


現在、結婚していない、子供がいない30代女性が存在し、
「お金を持っていて、自分のためには惜しみなくお金を時間を使う」


消費の鍵を握る女性


あなたが射止めたい生活者(女性)は、
どんな暮らしをし、
何が好きで、
どんなことにワクワクし、
何を不安に思い、
どんなことに困っているのか?


二極化する買い物


コスト(手間と時間とお金)の観点から消費を分類する

  • コストを極力抑えてする買い物 = 効率消費(コンビニエンス)
  • コストをかけ、プロセスを楽しむ買い物 = 娯楽消費(エンターテインメント)


書籍における例
Amazon => 効率消費
ヴィレッジヴァンガード => 娯楽消費



「売り方」次第でモノは売れる

価値は商品の特徴だけで決定されるものではない。

  • 商品とのワクワクする出会いの演出
  • この商品と一緒なら幸せになれそうなイメージづくり
  • 買った後も愛し、愛され続ける関係づくり


「売り方」「商品と買った人の関係づくり」を商品開発前の段階から考える
























読書記録 彼女があのテレビを買ったワケ 第1章

第1章 男女の買い物行動


テレビ購入、決意の真相


ある女性がテレビを買おうと量販店を訪れる。
店員は液晶とプラズマの画質の違いなどを事細かに列挙。
結果、女性はリモコンがかわいいテレビを買った。


スペックにこだわる男性、イメージにこだわる女性



商品のスペックひとつひとつを丁寧に比較するのではなく、まず、全体をイメージでとらえる。
そして、それは恐ろしく、主観的だ。


その商品と一緒にいるハッピーな私がイメージできたら、迷うことなく即買い


まとめ
男性客 -> とことんスペック比較
女性客 -> 幸せになれるイメージ発信


勝負にこだわる男性、共感したい女性


男性は店員に話しかけない人が多い
女性ははじめて入る店でも気軽に店員に話しかける人が多い

女性がストレス発散の手段に買物をあげるのは、欲しい商品を手に入れるという行為に快感を覚えているのではなく、この買物のプロセス、好きなものが揃っているお気に入りの空間で自分が主役になり、人と共感しあえる時間を楽しんでいるからではないかと思う。

男性は、買ったものや、お気に入りの店を知人にクチコミする人が少ない


まとめ
男性客 -> 「人より勝った」と思う自己満足を
女性客 -> 「私のことをわかってくれている」という自己満足を


結果がよければいい男性、買い方にこだわる女性


男性は商品を買った結果、得られる成果にこだわる人が多い。
女性は商品の買い方、プロセスにこだわる人が多い。


駅ビルの中で喫茶店を選ぶポイント
男性の傾向は、「のどが渇いた」「時間があまった」そのときに、「目の前に」「便利な場所に」気軽に入れる店があるとそこを選ぶ

女性は「ケーキがおいしいのはA店」「雰囲気がいいのはB店」「置いてある雑誌のセンスがいいのはC店」という具合に、お店に対して主観的な評価を設定し、そのときの気分で選ぶ。

「冷たいドリンクでのどをうるおし、時間をつぶした」という結果は変わらないが、「どのように選んだか」「どのように過ごしたか」という、プロセスのこだわりには大きな差がありそうだ。

まとめ
男性客 -> 結果として何が得られるのかを主張する
女性客 -> 買うプロセスを大切に、楽しく演出する
















2012年3月16日金曜日

LAMPの次

GUNDAMはさすがにないだろうと思い、自分なりに考える。

LAMPはWebサービスを提供するための環境
・Linux : OS
・Apache :  サーバミドルウェア
・MySQL : データストア
・Perl,PHP,Python : プログラミング言語
の組み合わせ。

OSはLinuxが圧倒的であることには異論がない。

WebサーバミドルウェアはC10K問題対策としてNginxが使われるケースがある。
また各種アクセスログ解析など、Webサーバとは別にHadoopなどを分散処理環境が必要となる

データストアに関しては特性の異なる技術がたくさんある
・Key-Value Store : キャッシュに使うmemcached、 永続化可能なTokyoTyrant
・スキーマレスDB : MongoDB
・列指向DB
それぞれ一長一短なのでMySQLなどのRDBを完全に置換するわけではない。

プログラミング言語はJavaScriptの台頭が著しい。
Flashの終焉に伴い、クライアント側での処理はJavaScriptの独壇場。
そしてnodeによるサーバ側への進出。


この他に、提唱された1998年当時と比べて大きく変わったことは
・PaaS : GAE, Herokuなど利用者からすれば、OS部分が隠蔽される
・マッシュアップ: REST APIなど自分のサービスを超えて機能利用・連携
だろうか。

いろいろと洗いだしてみたが、
LAMPは別の何かに代替されたわけではなく、コモディティ化したと思う。

LAMPに別の何かを足したり、一部を置き換えることで
より高い性能を出したり、少ない労力で実装できるようになった。

LAMPはたしかに古いが、勉強する価値はある。

2012年3月13日火曜日

XCodeでバイナリアップロードの不具合

XCodeからアプリを審査にだそうとして失敗。

OrganizerからValidateボタンをクリックすると、
Archive: のセレクトボックスにアップロードしたいアプリ名が表示されない ( No Value のみ表示)。
もちろんiTunesConnectのステータスはWaiting For Uploadになっている。

アーカイブのビルドは通るのだが、バイナリを作る際にキーチェーンへのアクセスがなかったので、おそらく署名関連でこけていると推測。

キーチェーンを見るとSystemのところにApple関連のものが数点あったので、Loginへ移動。
ApplicationLoaderがらみの警告もあったので、XCodeを再インストール。

なんとか治った。

Preview Release版のXCodeに正式版を上書きインストールして使っていたのがまずかったのだろうか?
途中までうまく動いていたので原因がよくわからない。

2012年3月9日金曜日

写真共有アプリが持つユーザ価値

意味付けされ、整理された写真には価値がある

あるテーマに絞った写真共有アプリは、そのテーマを好むユーザに対して
「興味のある写真だけが集まっている」という価値を提供する。

投稿者同士のコミュニケーション要素を除き、
写真だけで提供できる価値を考えたとき、
「写真の背後にある文脈」や「写真間の関係を活かした見せ方」
などが重要なものとして挙げられる。

my365は写真に対して「その日の1枚」という日記的な文脈を付けている。
slidropではユーザは伝えたいことをスライド(写真の集合)で表現する。


写真は複数枚数集まることで投稿者の属性をあらわす


例えば、自炊写真を共有するアプリを考えてみる。
同じ料理に対して作った時期の違う写真が複数枚あり、
投稿の新しい写真ほどおいしそうなできばえになっている。
これは投稿した人の料理の腕があがったという物語を提供できているのではないか?

写真を共有することは文章よりも簡単に自分を表現できる。
言い換えれば「投稿された写真を見ればそのユーザがどんな人かわかる」。

流行る写真共有アプリをつくるために、アプリ提供者は
「人をうまく表現できるような写真の組み合わせとは何か?」
「その組み合わせを実現するための仕掛けは何か?」
の2点をきちんと考え、設計する必要がある。