CSPO研修を受けてきた

会社の金でCSPO（Certified Scrum Product Owner）研修を受けてきた。期末の忙しい中、3日間終日不在してしまってほんとに不届きなのだけれど学びが多かった。

実は3年くらい前にも一回受けたことがある

前職でも実は同じ研修を受けたことがある。その時はJeff Patton氏が来てくれてプロダクトディスカバリーなどScrumに入る前段階のプロセスをメインにやった。ただその時はScrum開発がそんなに緊急課題ではなかったし、実際研修後もScrumで何かプロジェクトを推進したわけではない。いってしまえばペーパードライバー状態だった。

翻って現在は、現職の開発部隊が積極的にScrumを導入しようとしているし、UX側としてはそんな彼らにどう相対すればよいのか、本当にScrumってイケてんの？という課題意識もあったので、再度受講してみることにした。今回は日本のOdd-eという会社が主催で、内容もプロダクトディスカバリーというよりはScrum開発を進めるにあたってProduct Ownerがどうすりゃいいのか？がメインだった。

Scrumとは現状把握のためのフレームワークである

これは研修1日目に聞いた内容だったけど、これだけで受講の価値があった。

Scrumというと「短期間でリリースを繰り返す」とか「変化に適応するためのものである」とか、ヘタすると「Scrumで開発生産性上がりました」とか「Scrumで昨対30%アップ！」とか眉唾なフレーズと語られることが多いように思える。実際自分も開発生産性を上げるためのものだと思っていたし。

しかし実際はチームの現状を把握して課題を見えやすくすることまでしかScrumは担保しない。発見された課題をどう処理するのかは人に委ねられる。ましてや開発生産性があがるかどうか、ビジネスにどれだけ寄与したかどうか、などはメンバーがどれだけ努力したかの結果であり、Scrumはそこには貢献しない。

繰り返すが、チームの透明性を上げて現状把握をしやすくするための道具でしかない。

短期間Sprint開発とかSprint PlanningとかStory PointとかRetrospectiveとかProduct OwnerとかScrum Masterとか、Scrumにおける様々なルールはこの目的（現状を把握しやすくする）のために設定されたものである。ここを履き違えてしまっている人もしくは組織が多いのではないだろうか（実際自分も大いに勘違いしていた）

課題を発見しやすくするために、計画をシンプルにする（Definition of DoneやSprint Planning、Product Backlog Itemの粒度）。予実を見える化して振り返しやすくする（Story PointとVelocity、Retrospective）。それを頻繁に行う（短期間Sprint）。

Scrumで決められているルールには必ず背景があり目的がある。それらがうまく関連しあって、Scrumというフレームワークができている。

メンバーを固定化すべし。でもそれができない時はどうすればよいか？

現状を浮き彫りにするために、同じプロセスを短期間で何度も繰り返す。それによって課題は見えてくるとは思うが、そのためにはメンバーを固定してコンテキストを一定にしないといけないとのこと。自分の現状にフィットさせるには、ここが一番ハードル高いと思った。半年で組成から解散するプロジェクトなんでザラだし、人員の入れ替わりも激しい。

しかし裏を返せば、メンバーがどれだけ固定化されているかどうかがScrum導入の判断基準の一つであり、流動的なのであればできるだけ集合知を見える化して（例えばドキュメント化するとかして）ウォーターフォールで進めればいいだけのこと。メンバーを入れ替わり可能な歯車として実行へのコミットをしやすくする環境にするのがベター。無理してScrumなんてやることはない。

現場への装着課題

たくさんのことを学んだし、課題認識を持って参加したのでいろいろ持ち帰ることができた。しかしそれでもこのフレームワークをどうやって現場に導入すればよいのか？もっと根本的にScrumにする意味があるのか？の答えは見つかっていない。

既存事業のプロダクトをエンハンスする上でScrumというやり方はメリットあるかもしれないがデメリットもたくさんあるように思える。「チームの現状を把握しやすくする」ための方法って他にもたくさんあるだろうし、Scrumでないと把握できないというわけでもない。

また、これまでWebディレクターだった人にいきなりProduct Ownerさせても重責なだけだし、他に細分化されたポジション（WebアナリストとかIAとかリサーチャーとか）をどうやってフィットさせるかも考えないといけない。

他にもあるかもしれないが、とりあえず。4月から新しいプロジェクトにジョインするのだけれど、そこがScrumを導入しようとしているらしい。そこでまた何か見えてきたら追記したい。

読書メモ：チームが機能するとはどういうことか

まだ最初の10%くらいしか読んでないけどメモ。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

「行動するための組織」と「学習するための組織」

本書では組織が何を主眼においているか？について「行動」と「組織」で二項分類している。

行動するための組織

アメリカのフォードとその片腕テイラーが開発した、プロセスを重視する組織を指す。管理と計画に重きをおき、遂行における効率性を高めることが目的。そのため、作業の単純化および作業員の作業内容の透明性を高めた。プロセスに従っているかどうか、その効率が良いかどうかによって作業員の評価を行う。作るものがはっきりしている環境においてはこのプロセスおよび組織が功を奏し、フォード社は1900年代において栄華を極めた（2000年代にトヨタにその座を奪われるまで）

学習するための組織

現代のダイナミックで不確実性の高い環境ー顧客期待の変化、グローバル化する競争、テクノロジーの発達や法的環境の変化による参入障壁の低下によるものーにおいては、複雑適応性の高い組織でないと生き残っていけない。そのため、プロセスに従う組織よりもプロセスを発展させ、イノベーションを起こす組織に変える必要がある。

これまでの効率の良い実行を可能にするマネジメントは、組織学習や革新を阻害していまう可能性がある。学習するための組織は、学習してから行動するのではなく、試みを行うリスクを許容して行動して学習する。プロセスを職能や専門知識によって分割するのではなく、これらを統合する。台本のない世界に道を作っていけるのは、学習する組織である。

ウォーターフォール開発とアジャイル開発

ここからは現時点での所感なのだが、上記の組織対比はまさしくソフトウェア開発におけるウォーターフォールとアジャイルなのではないだろうか。

計画されたマイルストン上において中間成果物を次段階に渡すことで、プロジェクトを進めていくウォーターフォール（管理計画を重視する・作業内容を透明化する）。一方、動くソフトウェアをマーケットに出すことを再優先して「顧客に問い学習すること」を旨とするアジャイル開発。

そもそもアジャイル開発が、変化の激しい環境に適応するために作られたものであるので、この対比はしごく当然なのだが。

で、最近私の身の回りでは、あらゆる案件において開発プロセスをアジャイルにするという流れがある。新規開発であっても、既存事業の漸進的改善（エンハンス）においてもだ。この流れに対して直感的に疑問を抱いていたが、この本がヒントをくれたような気がする（といってもまだ冒頭10%しか読んでないけど）。

既存事業のエンハンスにおいてはアジャイル開発はフィットしない

そもそもエンハンスとアジャイル開発の目的が一致しない。エンハンスは既存事業が抱える課題を改善するためのアクティビティだ。その問題というのはおおよそ事業の財務的KPIに変換できるものであり、エンハンスプロジェクトにおいて成果基準はそのKPIを改善できたか（目標数値にまで到達できたか）である。

このような案件にアジャイル開発部隊をあてがうと、以下のような弊害が起きると思われる。

• 「学習」を試みた結果、事業数値に悪影響を及ぼす
• 「学習」する機会を増やすために、リリースの質より量を優先してしまう
• 「学習」を基準にしたリリースサイクルに合わせるため、課題設定・解決策にかける時間も短くなってしまう

箇条書きにしてしまったけど、要するにQCDのうちDを優先するあまりQが疎かになる、ということ。

エンハンス案件においてはウォーターフォールがベストプラクティスか？

まだ自分の中に答えはないが、おそらくYES。専門家による現状分析、課題設定、解決策検討、およびそれらプロセスを何度か繰り返すことによる発散と収斂。これによって確度の高い施策を生み出す。開発工程へ入るのはその後。これを実現するのは、管理計画を徹底して行うこれまでのプロセスが良いのではないか。

どのようなサービスが向いているか？

サービスのライフサイクルを誕生・成長・成熟・衰退と分けて考えた時、成長・成熟ステージにあるサービスはウォーターフォールで開発を行うのが良い。これら段階にあるサービスは事業方向性がすでに定まっており、スケールしていくことが優先課題である。作るものが決まっており、それをどう磨いていくか？を考える段階。

一方、誕生ステージにあるサービスは（何をもって誕生とするか定義が必要だが、ここではあくまでイメージ）Product/Market Fitにまで達しておらず、顧客開発やPivotを繰り返して、サービスの方向性を探る必要がある。このような状況では事前計画を立てることができないので、アジャイル開発でとにかく顧客に問うタイミングを増やし、フィードバックによって学習して次の打ち手を繰り出すことが重要（Lean的な）

また衰退ステージにあるサービスは、このまま手なりで死んでいくことを避けるために、新しいサービスの方向性を探る必要がある。そのためには誕生ステージにあるサービスと同様、様々な釣り針をマーケットに垂らしてどれが食いつくかを試したい。よって誕生ステージにあるサービスと同じスタンスで挑む。

まとまらないが、とりあえず。まとまったら別タイトルのエントリを書く。

フルスタックな人たち

35歳定年説より怖いフルスタックエンジニアしか生残れない未来とは - paiza開発日誌

最近の求人で注目されている人材は"フルスタックエンジニア"と"UI/UXデザイナー"であるという話をどこかで聞いたことがあります。私はエンジニア畑ではないので、最初聞いたときは「フルスタックって？？」と思ったのですが、どうやら解決方法や技術をたくさん持っているエンジニアをイメージしているようです。

一方私は現在UXデザイナー的な肩書きで仕事をしているため、LinkedIn経由でいろいろなポジションの紹介を受けることがよくあります。そこでは前述の"UI/UXデザイナー"と書かれている案件もあり、その時点で「この会社はこのポジションに何を求めているのかな？」と疑問に思うのですが、さらに読み進めると、ユーザーリサーチからUXデザイン、ワイヤーフレームやUIデザイン、さらにはフロントエンド開発まで、、ともりもりにスタックされたJob Descriptionだったりします。

いうなれば"フルスタックデザイナー"ですね。いやひょっとしたらWebディレクター的な要素も多分にふくんでいるので、"フルスタッククリエイター"なのかもしれません。言うならば、ね。

思えばWebディレクターという仕事もフルスタックです。顧客の要求整理と課題特定。市場分析・競合分析・現状分析などなどを経てソリューションを企画・提案します。決裁を得れば具体的な詳細設計。もちろん見積もり作成やスケジューリング、およびハンドリングと顧客へのレポーティング。制作フェーズ・実装フェーズに入ればデザイナーやエンジニアとの協業。リリースとかその後のPDCAプランのための仕組み作り・・とかもありますが、書いていて気が滅入ってしまいました。なお、これらはあくまでプロセスであり、それを遂行するためにはコミュニケーション能力、ドキュメンテーション力、マルチタスクや長時間労働に耐えうる強い体が必要なのは言うまでもありません。

ちょっと書いていることが散らばってきましたが、これだけフルスタックだと全てにおいて手を抜かざるを得ず、自然とクオリティは下がってしまうので、自分のフォーカスポイントを見つけるキャリアプランと、一所に注力できる環境を作ったほうがいいかも、ということが言いたかったのです。

おそらく"フルスタック"は積んである状況を言っているだけで、その引き出し全てを100%使いこなして活躍できる人材、というのは雇う側も望んではいないのではないでしょうか。スキルが幅広いことは器用貧乏を意味します。経営課題が複雑になればなるほど、より深い専門知識や知見が必要になるのは当然なので、そうなったときに広くて浅い人材だと、課題解決の可能性を狭めてしまう可能性があります。

ただ、いろんな分野において経験や知識があるということは、他領域のスペシャリストと会話をするのにとても役立つのも事実です。同じ言語で話ができるので、コミュニケーションがスムーズに進み、信頼関係が簡単に築けます。

アンブレラ型の人材を探せ！ | 月刊「事業構想」2014年1月号

多分こんなイメージなんだと思います。

さて、あなたの引き出しはどのくらいスタックされているでしょうか？ 

フルスタックエンジニアを雇うには、まず経理•プロマネ•法務•営業•トイレ掃除•メンタルケアを全部やってくれるフルスタック経営者か必要。話はそれからだ。

— 深津 貴之 (@fladdict) 2014, 5月 14

 はは、確かに。フルスタックを望んでいるあなたのボスはどのくらいフルスタックでしょうか？

うまくいかないデザインレビューとWebディレクターとしての役割

デザインレビューとは

Webディレクターという仕事の中に「デザインレビュー」という避けては通れないプロセスがあります。クライアントの要件をヒアリングして、コンセプトを決め、そのコンセプトのもとデザイナーにデザインを作ってもらい、そのアウトプットをクライアントにお披露目するレビューです。関係者各位に「今までみんなで話して決めたことってデザインとして表現するとこういうことだよね、OKだよね」という確認の場です。

Webディレクターとしては確認および承認を取りたいだけなので、そのレビューでデザインの細かい部分に関して意見は求めていません。というかそれはデザイナーの仕事であって、ディレクター＆デザイナーが裁量と責任を持って遂行しているつもりです。

うまくいかないレビュー

しかしこのレビューにおいて、往々にして、クライアントの方々からとんでもない意見が出てくることがあります。

「この色は好みでない」とか「このアイコンはよくわからない」とか「競合ではこうやってるんだけど・・」とか。

デザインにもロジックがあり、事前に決めたコンセプトと表層デザインをつなぐ道筋をこちらが説明します。ディレクターとしてはこのロジックこそが価値発揮のポイントであり、それが仕事であると同時に、それを関係各位に理解してもらうのもまた大事な仕事です。

そもそも表層のデザインは眼に見えるものです。それまで決めてきた要件やコンセプトは眼に見えないものであり、そのイメージはデザイナーがデザインをおこすまでは具体化される機会はありません。なので、関係各位がそれぞれ抱えていたイメージの差異がレビューの場に集められるのです。

根本的な部分で考えの違いが発見され、それを補正すべしということになれば、そのレビューはまだ有意義だと思います。（そもそもの話が違う、ということになりますので、そのディレクターは解任されるかもしれませんが・・）

しかし、デザインそのそものレビューは、非デザインの方が抱くアイデアは、ほとんど素人考えなので、それに時間を多く割いてしまうのは有効ではありません。

人は眼に見えるものに口を出し、理解できるものに時間を使う

パーキンソンの法則に自転車置き場の理論というものがあります。原子炉のような巨大で複雑な専門家が必要なものについての議論において、一般人は理解を越えていたり誰か別の人が決めてくれるだろうと思い、あまり口を挟まないため着々と進む。しかし自転車置き場のような身近はものは、皆がイメージ付きやすいためトピックが些末な点に陥りやすく、本質的な議論がないまま時間だけが膨大に必要である。

難航するデザインレビューにおいて発生している事象とよく似ているように思えます。

このような事態を避けるため、本来であれば前段である戦略とか要件とか仕様などをじっくり関係各位で議論をして合意を得るべき-- というウォーターフォール的なアプローチと、前段でのプロセスを行いながら同時並行でデザインを作っていく-- アジャイル的なアプローチのどちらかを取ることになります。

流行り、でいうと最近では後者がよく話題に登っているように思えます。ただ私個人的にはまだ圧倒的に前者が現場に適応しやすく、（まぁまぁ）成功することが多いです。チームが大きく、関係者が多いと、すぐアウトプットしてフィードバックもらうまでのリードタイムが長くなってしまうので（下手すると社長にまでデザインを見せないといけないこともある）、どうしても土台をしっかりしてから・・となってしまいます。

眼に見えないものを見えるようにするチカラ

デザイナーやエンジニアの「それまでなかったものを作るチカラ」「見えないものを具現化するチカラ」はかけがいのないスキルです。クライアントはそのチカラを事業推進に使いたいし、Webディレクターはその意図とデザイナー・エンジニアのチカラをうまくブリッジすることに価値を発揮させなければなりません。

そのためには事業・デザイン・エンジニアリングの素地が必要ですし、またどのようにして具現化するかの道筋を整える必要もあります。小さいチームには小さいチームなりの、大きいチームにはそれなりの、最適な方法と場を作ること。関係各位お互いの責任範囲を定義する。などのプロジェクトマネジメントとしての役割も必須です。

パーキンソンの法則 (至誠堂選書)

iPhoneを落下破損して復活するまで

iPhone5sを落として破損しました。

どうしてこうなった

自慢でも何でもありませんが、iPhoneを初めて手にして4年あまり。落としたことがありませんでした。いや、正確に言うと何度か落としてはいたのですが、目立った破損事故になることもなく。完全に驕っていました。

ある金曜の朝。通勤途中の池袋埼京線のホームでそれは起こりました。列の一番前で電車が来るのを待ちながらiPhoneをいじっていました。何をしていたかははっきり覚えていません。ふと、背負っていたリュックを外そうと、iPhoneを手にしたまま肩紐をくぐろうとしたとき。

iPhoneは手から滑り落ちました。

何度か落としたことはあっても大した事故になっていなかった。そんな記憶が、点字ブロックの上にひっくり返ったiPhoneを見ても「あ、線路に落ちなくて良かったな」ぐらいしか感じないほどに、私の思考回路にこびりついていたのです。

そのひっくり返ったiPhoneを取り上げたとき。バッキバキに割れてしまったiPhoneが、見覚えのない姿になって、最初は本当に「あ、これオレのiPhoneじゃない」と思うぐらい、衝撃でした（今も冷静に書けないくらい動揺を引きずっています）

それでどうしたか

会社に着くまで、割れてもなお動く健気なiPhoneを手にしながら、このような場合どうするのかを検索していました。ガラス面だけ交換するとか、◯万円かかるとか、臨時出費になるから近々買おうと思っていたタブレットはキャンセルしないといけないとか。

この日ほどあっという間に会社に着いた日は今までなかったと思います。とんでもない集中力。

Appleサポートへ連絡

偉大な先人の方々がインターネットに残してくれているので、ちょっと検索すればすぐ情報は見つかるのですが、このような場合auやsoftbankなどのプロバイダはアテにならず、Appleへ問い合わせるのがスムーズなようです。

また、落下破損の場合、修理ではなく交換になると。都内にいくつか対応してくれる場所があるらしいのですが、とりあえずはサポートへ電話。

とても感じの良い電話対応で、交換になる旨、都内にいくつかあるApple Storeか「正規サービスプロバイダ」に行けば即日交換になること、そして交換代金としてApple Careに加入している場合は7800円かかることを教えてくれました。

https://locate.apple.com/jp/ja/

Apple Store か Apple 正規サービスプロバイダか

交換には3つ方法があるそうです。

1. SIMを抜いた壊れたiPhoneを送り、新しいSIM無し端末を送ってもらう。手続きはネットで可能
2. Apple Store の Genius Bar へ持っていく。即日交換。ネットでアポイント可能
3. Apple 正規サービスプロバイダへ持っていく

1. については時間がかかるのと、数日とはいえ手元にiPhoneがない期間ができるので却下。2.についてアポ無しでいくと待たされる。アポは即日で取れるレベルではない。可能な時間帯はおよそ2-3日後。

そこで3.にかけることにしてみました。幸い都内は該当するショップがたくさんあります。電話をして、交換用の端末在庫があるか聞いてみたところ、ありますとのこと。しかし電話で取り置きおよびアポイントの受付はやっていないようです。仕方がないので、金曜の夜に立ち寄ってみることにしました。

正規サービスプロバイダで交換することの困難さ

結果からいうと、私はプロバイダで交換することはあきらめました。

金曜の夜に立ち寄ってみると、閉店1.5時間前にも関わらず、待ち人が多く当日の受付は終了していました。仕方がないので土曜の午前中、他用事のついでに寄ってみることに。

次の日土曜の11:00AM頃に寄ると、これまたたくさんの人がすでに並んでおり、1時間近く待ちになります、とのこと。貴重な土曜の時間を浪費したくなかったので、この時点でGenius Barにネット経由でアポイントを入れることにしました。

Apple正規サービスプロバイダを名乗っているにも関わらず、予約ができないとは何とも片手落ちなサービスだなと感じました。平日昼間などであればそれほど時間はかからないのかもしれませんが、私は二度とサービスプロバイダを使おうとは思いませんでした。

Genius Bar に

結局次の火曜日の夕方にアポイントを入れて、渋谷のApple Storeへ。18:00に予約をして18:10には新しい端末を手に入れていました。よく設計されたカスタマーケアです。コントロール可能な部分をできるだけユーザーに提供することが顧客体験を向上するためのファクターだと感じました。

Apple Careについて

5sだと交換は通常28000円ほどかかります。Apple Careに加入していると、2年間内2度に限り7800円ほどで交換できます。Apple Care自体、毎月お金を払っているので、交換時にさらにお金が掛かるとはなんとも微妙なケアですが、他に選択肢がないので仕方ありません。

実はApple Care、5sに交換したときに代理店に半ば無理やり押し付けられて加入したものでして。解約のためにまたショップに行かなければならず、面倒だったのでなんとなくそのまま契約を継続しているだけでした。が、今回はそれのおかげで出費を抑えることができました。

上述の通り、ランニングコストを請求しながら実行時に再度実費請求をするという、Appleというブランドにあぐらをかいているのでは？と思われても仕方がないような設計ですが、個人的には20000円近く出費を抑えることができたので助かりました。Appleのサポートコール対応もとても親切で交換が持てました。前職でカスタマーケアビジネスをやっていた妻に言わせると、ああいうのはスクリプトで用意されているものらしいですが、わらにもすがる思いで電話をかけた人にとっては、心を救われるものだとも思います。

まとめると

1. iPhoneは落として画面破損だと、端末交換に。
2. 方法はいくつかあるが、スピードを考えると Genius Bar か正規サービスプロバイダに持ち込み
3. 多少待ってもいいからすぐに欲しいという人はサービスプロバイダへ。待つ時間も惜しい人は Genius Bar へアポを。
4. Apple Care だと 7800円で交換。ないと28000円くらい取られる

落として破損して気づきますが、iPhoneへの依存度はかなり高くなっていました。何より、画面の割れたiPhoneを見るたびに心がエグられます。落下紛失のたぐいのトラブルは付き物なので、出来る限り避ける努力をしたほうがいいなと思いました。

概念的に考えるということ

サイト改善の仕事をしていると、ペルソナを作ったりジャーニーマップを作ったり、いわゆる「モデル化」をすることがよくあります。これはユーザーインタビューや顧客アンケート、ログ解析など事実から共通項を取り出し「それらしいもの」を一つに仕上げたアウトプットになります。

しかし、これをクライアントさんに見せると「（別の）こういうユーザーの場合どうなんだ」とか「うちのサイトはこういう使われ方もある」と言われてしまうケースがたくさんあります。

このようなことを言われてしまう背景として、我々の方での説明不足が多いことが挙げられると思います。特に「数あるパターンを概念的に考えてモデル化し、問題をシンプルに捉えるためにこういうことをするんです」ということに納得いただけてない。

これをご納得いただくためにどのように説明すればいいかな？と思っていたところ、ある本からインスパイアを得ました。

知的複眼思考法　誰でも持っている創造力のスイッチ (講談社＋α文庫)

 本書は概ね「常識にとらわれずに多角的に物事を捉えて考えよう」ということが書かれているのですが、概念的に考えるということについて以下のように書いていました（うるおぼえのまとめです。抜粋ではありません）

目の前の具体的な事例にとらわれ過ぎると思考停止に陥る。当面の問題は親しみを感じてしまうだけにそれを当たり前に発生していることと見なしてしまい、そのケースを越え出る問題の広がりに目が向かなくなってしまう

UXに関連するアウトプットはおおむね問題を可視化することだと思っています。Design Thinking Method的にいうと、共感して（Empathize）課題を定義する（Define）するためのものです。決して網羅するためのものではありません（そういう使い方はそれで有効なこともあるかもですが）

運営側の持っている中から見た問題点だけに固執せず、利用者側視点での問題を抜き出し、どこが一番ネックになっているのかを知るためのものです。

このような考え方には3つのメリットがあると本書にかかれています。

1. 物事どうしの共通性を高め、個々の出来事をシンプルに捉える
2. 一つの概念から新しい考えを産み出す。「ジェンダー」を例にとると、以前は性差は生物学的な違いにフォーカスがあたっていましたが、ジェンダーの発見により社会的役割（女性が子育てをするべき）という常識から抜け出し、社会的に作られた性差という新しい発見がなされた
3. 概念同士に新しい共通点を見つけて定義しなおす。「セクシャル・ハラスメント」を例にとると、以前は性犯罪にいたるほどにならないと問題にならなかったが、セクハラの概念ができることによって、女性が不快に思ったかどうかに目が向けられるようになった。またさらに発展して男女間で起こる嫌がらせ、というように定義された

 UXがサービスおよびサービス運営者にもたらすメリットとよく似ています。課題をシンプルにとらえリソースを投下すべきフォーカスポイントを見つけ、内在する課題を発展させたり取捨選択する過程で新しいアイデアが発生する。

サービスを運営していると機能的なアイデア（この機能があればユーザーは使うはずだ）が真っ先に出てきてしまいますが、その前になぜそれが必要なのか、抽象度をあげて考えると視野が広がるのだと思います。

最近買った本 2014年3月

久しぶりに本屋へ立ち寄る機会がありまして、探したかった本を探してきました。

ここ半年ほど、仕事で「アクセス解析ができるようになったなぁ」と手応えを得ることがありまして。勤め先はとてもとてもリッチなツール（Adobe Analytics 旧 Site Catalyst）が導入されています。以前はなんとなくダッシュボードを眺めたり基本的なレポートをチェックするぐらいでした。しかし、最近は欲しいデータを欲しい状態で得ることと、それをちょっとした統計処理を用いて加工することを覚えました。データをただ平面的に眺めるだけでなく、ブレークダウンしてそれぞれの傾向を見たり、別のデータと突き合わせたりしすることで多種多様な発見ができるものなんですね。直接クラウドで提供されているレポートを見るのではなく、データをExcelにダウンロードしてあれやこれやと自分で工夫をするようになったのです。

そうなってくると今度はより立ち入った分析をしたくなり、もっと統計の知識やユースケースが欲しいな、と感じる機会が多くなり、「アクセス解析と統計をうまくがっちゃんこした書籍とかないんだろうか」と本屋へ立ち入った次第です。

でも、そういう本ってないんですね。。ニーズ自体はありそうなんですけど。

マーケティングリサーチや売上データ、ビジネス分析と統計を絡めたものはたくさんあるんですが、どうもWebディレクター・アナリスト向けのノウハウ書はないようでして。

仕方なく、実務に応用できそうなものを2つほどピックアップしました。どちらも「Excelで」と銘打っているのが特徴です。あまり本質的な統計学を説明されても実務と遠いので。（というかそういう本を今までに何度も読んでは途中で諦めたことがあるので・・） 

EXCELビジネス統計分析 [ビジテク] 第2版 2013/2010/2007/2003対応

 今この本を読み進めています。基本的な統計知識から相関・単回帰分析、多変量解析などを架空の設定に基づいてどのように処理すればどのようなアウトカムが得られるかを具体的に説明しています。少しExcelのオペレーション説明が多い気がしますが（同じ結果を求めるのに分析ツールを使うケースと関数手入力で出力するケースとが説明されている）、まぁ初学者にはそちらの方が易しいのかもしれません。

1億人のための統計解析 エクセルを最強の武器にする

 こちらはまだ開いていませんが、帯に「さよならデータサイエンティスト」と書いてあるのに惹かれて購入しました。分析が本職ではないけれどもきちんとした手順とデータ処理をもとに正しい数字の読み方をしたい、という私のニーズに応えてくれそうです。