下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

データ集計業務の勘所について話しました@データマイニングMeetup

ウィルゲート様が主催する統計やらNight!!データマイニングMeet up #2でLTをしました。

スライド

『データ集計業務を半年で300案件捌いて見えてきた勘所』

企業内のデータ分析チームが陥りがちな課題とその解決策についてのケーススタディとなります。 PyCon JP 2017でベストトークアワード優秀賞を受賞した発表(構築編)の続き(運用編)をチラ見せです。

集計業務のインパク

f:id:yuzutas0:20180515111950p:plain

データ活用案件の目的は、業務フローの過程において「リターンを上げること」もしくは「コストを下げること」となります。 意思決定を支える「アナリティクス」(BI)と、判断や作業を自動化する「ソリューション」(AP/ML)に大別できます。

f:id:yuzutas0:20180515112215p:plain

組織のデータ活用は段階的に進化します。今回は2番目のフェーズについて深掘ります。

  1. データの品質を担保し、利用できるようにデータ基盤を構築するフェーズ
  2. データを抽出・集計して、根拠のある意思決定ができるようにするフェーズ
  3. 必要に応じて高度な解析処理や機械学習を活用し、業務フローや顧客体験をさらに磨き込むフェーズ

f:id:yuzutas0:20180515112646p:plain

集計業務といえど軽視することはできません。 データ基盤が整備されていない場合、1つのデータソースをもとにした局所最適な意思決定に陥りがちです。 複数のデータソースを繋げるだけでインパクトを生み出すこともあるのです。

データチームを苦しめる悪循環

f:id:yuzutas0:20180515113628p:plain

悪循環 打開策
1 データ抽出や集計の業務ばかりに工数を費やしてしまう 作業手順の型化・改善
(今回のテーマ)
2 ・攻めた施策を打ちにくい
・付加価値を創出できない
期待ROIの提示
3 ・周りから便利屋として見られてしまう
・自分で便利屋として売り込んでしまう
メッセージング
4 ・さらに抽出依頼が寄せられてしまう
・自分で抽出業務ばかりを取りに行ってしまう
データの民主化

これらは陥りがちな課題ではありますが(理想を言えば)分析担当なら突破してしかるべし、だと考えています。

  • データ分析の担当者は、データを分析し、その結果を関係者に納得してもらい、業務を改善することが期待されているはずです。
  • 自身の担当する業務についても同じように、分析し、改善し、周囲にメッセージできるように心掛ける存在であってほしいです。
  • むしろ自分の業務を改善できないような人間に対して、ビジネスやプロダクトを改善するためのデータ分析を依頼したいと思えるでしょうか。

なお、データの民主化についての取り組みは下記エントリーをご覧ください。

yuzutas0.hatenablog.com

そのダッシュボード、本当に必要ですか?

データ抽出・集計の業務を磨き込む時に、最初に挙がるのは「あらゆるデータをいい感じに見ることのできるすごいダッシュボードを作ろう」という意見です。 が、なかなか上手くいかないのが現実です。

f:id:yuzutas0:20180420000920p:plain

Netflixの分析チームも同じようなことを言っているそうです。

ダッシュボードは使われない

Tableau Conference 2016 at Austin [レポート]分析カルチャーを構築する(Netflix社) #data16 | Developers.IO

f:id:yuzutas0:20180515115429p:plain

現場でWEBディレクターが実際にやっていたことはもっと泥臭い集計作業でした。

  1. 自分なりに簡単なSQLを書く
  2. 日付の部分だけ手動で書き換えてSQLを叩きまくる
  3. 事務スタッフにも声を掛けて作業を手伝ってもらう
  4. データさえあれば後はExcelやSpreadsheetでどうにかできる

このケースにおいては、豪華なダッシュボードを作り込むよりも、SQLExcelを地道に使うほうが価値創出に寄与したのです。 抽象化すると「実際の業務に紐付けながら小さく試すこと」が大事だと言えるのではないでしょうか。

スタートアップ界隈に学ぶ “小さく試す” 文化

f:id:yuzutas0:20180515115900p:plain

金も時間も足りないスタートアップでは、MVP(実用最小限の製品)を最初に作ります。

  • Airbnbは自分たちのアパートの写真だけを載せたLPを公開してニーズを探った
  • Dropboxはプロダクトを開発するより先に紹介動画を作って反響を見た

データ分析においては、ちょっとしたSQLExcelがMVPに当たるでしょう。 あるいは、ホワイトボードに書いた分析モデルのコンセプトスケッチだけでも十分かもしれません。

f:id:yuzutas0:20180515120148p:plain

とはいえ小さく作るだけでは急成長・大幅改善は難しいので、アクセルを踏むべき場面も出てきます。そこで参考になるのがステージゲート方式です。 スタートアップでは、ベンチャーキャピタルによる投資判断を受けて、コンセプトを検証する段階ではいくら、量産体制ではいくら、といった形でフェーズごとに投資額を増やしていきます。 同様にデータ活用案件においてもフェーズごとに資源(工数・時間・予算など)を増資していくのが有効だと言えます。

f:id:yuzutas0:20180515120444p:plain

それぞれの案件を次のステージに進めるか否かの判断もスタートアップを参考にできます。 革新会計・リーンキャンバスといった独自の基準で進捗を計測する手法が該当するでしょう。

用語 観点
必要性 Customer / Problem Fit 本当に解決すべき課題か
効果性 Problem / Solution Fit その解決策は課題に対する打ち手になるか
効果量 Product / Market Fit 投下する資源(工数やコスト)に見合うリターンを得られるか

このように「スタートアップの経営手法をデータ集計業務に当てはめる」という改善方針が見えてきます。 考えてみると、バズワードやシーズ駆動で実需を見失うのは、まさにスタートアップのアンチパターンです。 データ活用案件でも同じことが生じがちだからこそ、スタートアップ的発想が有効なはずです。

多産多死を前提としたプラクティス

f:id:yuzutas0:20180515121224p:plain

データ抽出・集計業務を大雑把に標準化すると以下のような流れになります。

  1. 要求(目的・背景・制約事項)を整理する
  2. 得たいデータのモデルを定義する
  3. 実際にデータを活用するためのインターフェースを設計する

f:id:yuzutas0:20180515121945p:plain

この業務にスタートアップ思考を適用すると

  • アウトプットをMVP(実用最小限の製品)としてスコープ調整しながら
  • ステージゲート方式で徐々に充実させていく

という形になります。

f:id:yuzutas0:20180515122939p:plain

具体的なMVPと運用方法は以下のようになります。

  • モックアップ
    • Spreadsheetで概算値を仮置きしたり、ホワイトボードで出力シートのイメージをスケッチします
    • 「こういう値のデータがこういう風に出ました」でロールプレイして、アクションがどう変わるのか、どういうインパクトがあるのかを確認します
    • アクションが変わらなかったりインパクトがないならデータ抽出・集計するメリットはないので案件を落とします
  • CSV
    • BigQueryからCSVを出力してExcelやSpreadsheetで簡単な分析をしてもらいます
  • Data Studio
    • ダッシュボードを即席で作ることができます
    • まだ自由度は高くないですが、簡易モニタリングなら問題なく使えます

f:id:yuzutas0:20180515123528p:plain

ステージゲートにおける判断は以下のようになります。

  • Slack配信
    • 継続的にデータを使い始めたら毎朝SlackでCSVファイルやData StudioのURLを自動配信します
    • 用意してあるテンプレートに沿ってプログラミングしてmasterブランチにマージされると翌日から自動で配信されるように仕組みを整備しました
  • クリーニング
    • 不要になったBIツールやデータ配信処理は定期的にクリーニングします
    • そのタイミングで「本当に必要だったデータは何か」を振り返って次に活かします

最終的に生き残った案件だけを磨き込むことになります。 業務の実態とデータ集計処理が合わなくなり、改修の依頼を受けたタイミングが検知トリガーです。 対応方針は以下のいずれかです。

  • ホワイトボード設計からやり直す(新しいロジックを検討したり、新しいユースケースを整理したり)
  • 本格的なデータ施策としてRPA導入などを案件化する(どうしてもMVPでは不都合がある場合やデータ集計後の業務本体を改善する場合など)

f:id:yuzutas0:20180515123855p:plain

このように、案件のライフサイクルを繰り返していくことで、多産多死のスタートアップと同じように、小さくテストしながら段階的に要求・設計を磨き込みます。 組織としてデータを活用して価値を創造するための知識を習得していくことができるのです。

おまけ:データクレンジング

データ集計業務においてボトルネックになりがちですが、(少なくとも私の担当現場については)ある程度の捌き方が見えてきました。

  • 暫定対応(回避策・解決策)
    • 後工程・分析後のアクションを踏まえて会話するのが良さそうです
    • 具体的には「多少数値がズレているけど今回の目的なら許容範囲だ」
 「これを調査するのに1日使うくらいならxxの方が優先だ」といったROI軸で会話します
    • 前提として「仮に現時点で多少モニタリングがズレても後で直してくれるだろう」という関係者からの信頼
を得る必要があります
  • 恒久対応(原因・予防策)
    • ノイズデータもありますが、データ基盤整備後における数値ズレは、むしろ設計力不足に基づくことが多いです
    • ドメイン知識:数値ズレを元に詳しい人と話すと解決しやすいので、その人の脳内にある推定値を出すロジックを突き止めるのが分析要件定義の第一歩です
    • データ仕様:ノイズデータのパターンやプロダクトの状況は経験的に学習でき、明らかに慣れによって早くなります
    • 論理的思考・数理モデル:ロジックの改修前後で数値が一致しないことは数学的に証明できるのに、
気付かずに右往左往したケースがありました

まとめ

f:id:yuzutas0:20180515124601p:plain

  • 最初はSQLを書いてCSVを渡しまくります。その作業プロセス自体を型化→継続改善していきました。
  • 生き残った案件についてですが、その頃には業務やデータ仕様に詳しくなっているので、データクレンジングを含めてどうにかなるはずです。

以上、だいたいそんな感じです!

宣伝

ということで、抽象論ではなくデータ活用現場で実際に使える粒度のノウハウ・ツールをパッケージ化して公開していきたいという気持ちがあります。 そのパッケージがあれば日本の産業界はもっと上手くデータを活用し、国内経済を活性化していけるのではないか、と考えています。 一緒にやっていくチームメイトを絶賛募集中です。

  • データ分析による意思決定でプロダクト開発を支えたいアナリスト・データサイエンティスト
  • データ案件推進やデータ駆動文化の醸成を担いたいディレクター・プロデューサー
  • データ活用による業務改善(RPA)で利益創出を目指したいアプリケーションエンジニア・機械学習エンジニア・UXデザイナー
  • データ基盤の開発・運用におけるベストプラクティスを追求したいSREエンジニア

我こそはという方がいらっしゃいましたら、ぜひお気軽に@yuzutas0にお声掛けください。

他の発表

参照:統計やらNight!!データマイニングMeet up #2

最後に

運営の方々。発表者の方々。参加者の方々。 この度は貴重な機会をいただき、誠にありがとうございました。 ぜひまた機会があればよろしくお願い致します。

最強のデータ分析組織 なぜ大阪ガスは成功したのか

最強のデータ分析組織 なぜ大阪ガスは成功したのか

データの民主化とサービスレベルについて話しました@分析基盤Meetup #shinjukugl

セプテーニ・オリジナル様が主催する新宿Geek Lounge#4 分析基盤MeetupでLTをしました。

スライド

『データ基盤を支える民主化とサービスレベル』

「いかにビジネス価値を最大化し続けるか」という本来の目的から、データ基盤1を見直すキッカケになればと思います。 PyCon JP 2017でベストトークアワード優秀賞を受賞した発表(構築編)の続き(運用編)をチラ見せです。

データ基盤は使われてこそ意味がある

f:id:yuzutas0:20180420000920p:plain

  • 世の流れは「やってみた」から「価値創出・運用」志向に推移しています(例:DataOps、機械学習工学、MLOps)
  • 「俺の考えた最強のダッシュボード」では1週間で誰も見なくなります

データの民主化

f:id:yuzutas0:20180420001035p:plain

  • 事務スタッフ(非エンジニア)がBigQueryを叩いています!すごい浸透!
  • チームごとの民主化状況をモニタリングして必要なアクションを実施しています
  • 民主化には3つの壁があることが分かりました:局所化の壁、自走の壁、改善の壁

f:id:yuzutas0:20180420001054p:plain

  • どんなチームでも何かしらの施策を打つ → 効果測定を切り口にしてデータ活用を促したり
  • 複数人でモニターを囲んでモブデータ分析をやると導入しやすかったり
  • 案件の前工程(仮説・効果見立て)と後工程(検証・効果測定)のプロセスに組み込んだり
  • SQLレシピやデータ辞書を用意したり
  • 分析相談やレビュー依頼を受けたり

サービスレベル

yuzutas0.hatenablog.com

サービスレベルという言葉については上記エントリーで説明しています。 日本語で一番分かりやすく、なおかつ実務に使えるように説明した自信があります。

f:id:yuzutas0:20180420001201p:plain

f:id:yuzutas0:20180420001237p:plain

データ基盤に関するあらゆる意思決定はサービスレベルに依存します。

  • データの用途・利用者ごとに期待されている品質を明文化する
  • SLAが脅かされるときのオペレーションを定義する
    • 対応スピード
    • 補償・代替手段
    • ワークアラウンド(回避策)
    • レポーティング、記録、ポストモーテム
  • 毎スプリント終了時のレトロスペクティブ(ふりかえり)でSLA・OLA自体を見直す

これだけ聞くと伝わりにくいですが「使っていない分析レポートがクリーニングされずに大量に残っている話」が直前にあったのを受けて 「使わないツールを保守し続けるのは過剰品質です」「そういう過剰品質を定期的に見直して是正するのがサービスレベルのマネジメントです」という話をしました。 実際そのように運用しています。

他の発表

詳しくは以下のブログでレポートされています。

labs.septeni.co.jp

懇親会で話したこと

私に声を掛けてくださった方々の多くはデータ基盤を構築したばかりでした。 その先の運用イメージがまだ見えていなかったので、先行事例を聞けて良かったと仰っていました。

また、運用フェーズこそが本番なのに、知見があまり世に出回っていないという話にもなりました。

  • やるべきことをきちんと実施しているところが少ないから
  • 新システムの構築に比べてエンジニアにとって華がない(ように見える)から

といった意見を伺いました。

一方で、華がないから話したがらないという割には

  • 作ったデータ基盤が身内にしか使われない
  • 役に立っているか疑わしいBIツールを保守し続けている
  • データ分析したけど施策には繋がらなかった

これらの辛さは誰もが経験しており、運用の苦労話はつい気になって色々質問したくなってしまう、とのことでした。

おもったこと

いかにデータ活用や基盤運用の辛さを乗り越え、いかにビジネス価値の継続的な向上に役立てるか。 それができれば日本の産業界はもっと上手くデータを活用し、国内経済を活性化していけるのではないか、と考え始めています。

運用支援のドキュメントやツールをもっと充実させて、ゆくゆくはOSSとして公開していきたいという気持ちがあります。 一緒にやっていけるチームメイトを絶賛募集中です。お気軽に@yuzutas0までお声掛けください。

最後に

運営の方々。発表者の方々。参加者の方々。 この度は貴重な機会をいただき、誠にありがとうございました。 ぜひまた機会があればよろしくお願い致します。

The DevOps ハンドブック 理論・原則・実践のすべて

The DevOps ハンドブック 理論・原則・実践のすべて

  • 作者: ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス,榊原彰,長尾高弘
  • 出版社/メーカー: 日経BP
  • 発売日: 2017/06/22
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る


  1. 私のところでは呼称を変えました。分析基盤ではなくデータ基盤と呼びます。データ分析(意思決定支援)だけでなく、機械学習(ソリューション)にも活用しているからです。

学生インターンを受け入れました

以下ブログ記事に対するアンサーエントリーです。

リクルートのインターンに参加しました | monolog

※本稿は個人の見解であり、所属する組織を代表するものではありません。

短い期間ではありましたが、インターン生である@sukukyonのメンターを務めました。 あまりメンターらしいことは出来なかった気もしますが、何とか無事に修了しました。

総論:最高のインターンだった

最高のインターンで最高にやっていきを発揮して最高の成果を出しました。

ということで、概ね上手くいきました。 成功要因としては「関係者全員がお互いをリスペクトできたから」だと思っています。 非常に良い関係性を築けていました。

まず何より@sukukyonとメンター(私)が互いに歩み寄れたのが良かったです。 だけどそれ以上に多くの関係者の支えが大きかったと思います。 改めて振り返ると「学生インターン1人を受け入れるのに、これだけ多くの人がここまでお節介を焼くのか」と言えるサポートでした。

私自身が工夫したこと

上司力の高い上司でした。

だろ?(笑)

……というのは置いておいて。

マジでほぼ1~2日に1回の頻度で1on1やって想定される課題を取り除けるものは取り除いたり、設計についてアドバイスもらったり、レビューで突っ込まれたりdisられたりしてとにかくコミュニケーションの密度は高かったです。

メンターとしての基本的なスタンスは新入社員の受け入れ時と同じ要領です。 コミュニケーションは過剰なくらいでちょうど良いはず。

yuzutas0.hatenablog.com

上手く文脈の疎通ができて良い意味で雑なコミュニケーションが取れたので良かった

ブログを見ると知見が一杯あって便利です。

これは偶然だったのですが、@sukukyonは以前から私のブログやスライドを読んでくれていたようです。 初めから考え方の方向性が合致していたので話が早かった。 どこで何が繋がるか分からないですね。 普段からアウトプットすることが大事だなぁと思いました。

インターン生に工夫してもらったこと

多分僕も部下力を発揮したと思う。

まさにこれですね。@sukukyonがめちゃくちゃ優秀だったおかげで色々と助かりました。

うちのチームでは『部下力』という本を必読書にしています。 かいつまんで説明すると「上司がクソな時の対応方法」を解説した本です。 この本が必読なのはメンバー1人1人に主体性を期待するからです。 特にソフトウェアエンジニアリングは1人1人に高いプロフェッショナル性を求める仕事です。

部下力―上司を動かす技術 (祥伝社新書)

部下力―上司を動かす技術 (祥伝社新書)

今回は全能感を持ってやっていくというのを意識

全能感があると、不安が減ったり精神的なハードルが下がってストレスも減ったりで良いことづくめ

インターンとして、「○○検証しました!」「こういうの作って便利にしました!」みたいなのは比較的よく見かけますが、実際にプロダクションに載るところまではいかないことが多いと思っていて、今回はそういうの無しでちゃんと載せるぞみたいな意志でやっていました

だいたい全部やったらなんかだいたい全部できました

あまりにも話したい内容が多すぎてスライドが163枚になりました

お見事。 進め方&成果の両面において、期待に応えてくれました。

ちなみに私からインプットしたのはこれだけです。

  • ゴール
    • 現場が抱えているシステム課題:こういう点に困っている!
    • 大まかな改善の方針:こういう風にしたい!
  • スタート
  • メッセージ
    • スキル面は信頼しているし、やり方はお任せするので、成果を出してほしい
    • プロフェッショナルとして扱うから、口を開けてサポートを待つのではなく、必要なサポートを引き出せるように自分から声を掛けてほしい
    • 様々なシステムの権限を付与するので自由に触っていいが、壊したら自分で責任を持って直して欲しい
      • 注: あくまで商用環境に影響のない範囲です

ということで、ほとんどが@sukukyonの頑張りですね。 私はメンターとして本人に実力を発揮してもらえる(であろう)環境を用意しただけです。

人事担当に工夫してもらったこと

とにかく最高のやっていきチームでやっていってました。

やっていきがある環境って多分こういうことなんだなって思います。

関係者からは「やっていき」ということで環境面を評価していただけました。 ただ、どちらかというと人事担当が「@sukukyonはスキル面で信頼できる人材ですよ」と猛プッシュしてくれたお陰だと思います。 色々と話を聞いて「こいつはすげーや」と思えたからこそ「好きにやっていこう」と言えたし「自由にやれる環境を用意してあげたい」と思えました。

そういう意味ではひたすら人事担当を頼りました。 些細なことでもとにかく相談しました。

一般的な事例として、インターン制度の失敗の多くは「現場と人事の連携不足による」という話を聞きます。 そのため少しでも不安要素があれば「責任を持って現場でインターン生を受け入れることは出来ません」と断る予定でした。 このスタンスを事前に伝えたことで、人事担当と腹を割って話し合うことができました。 それなりに時間やエネルギーを割いていただき、現場と人事で信頼関係が構築できたのだと(少なくとも私は)思っています。

現場のメンバーに工夫してもらったこと

とくにオンボーディングはよく整理されていて

とにかく現状の構造だったり、社内ドキュメントだったり、場合によってはソースコードまで片っ端から目を通すようにしてました。

これは簡単なようでいて、そもそもそういったものが当たり前のように文書化されて構造化されている環境というのがそもそも恵まれていて、そういうところも含め最高でした。

これは現場の地道な努力の恩恵ですね。

yuzutas0.hatenablog.com

yuzutas0.hatenablog.com

チーム横断の立ち上げメニューがあるので、インターン生向けに多少カスタマイズして使いました。 現場のメンバー1人1人が自発的・継続的にテンプレートをメンテナンスしているからこそです。

なお、オンボーディングの終了後は「継続的に1on1を実施する」といった運用メニューに移ります。 運用メニューはアルバイトや業務委託を受け入れるときに作ったものがあるので、これをインターン生向けにフォークしました。

yuzutas0.hatenablog.com

ちなみに、現場メンバーは明らかにメンター(私)以上に活躍していて

  • PC手配などがスムーズだったのは事務スタッフのおかげ
  • システム仕様理解についてのサポートは現場エンジニアリーダーのおかげ
  • 案件要求を分かりやすく説明できたのはディレクターのおかげ

このうち誰か1人でも欠けていたら、こうは上手く行かなかっただろうと思っています。

私は特に根回しをしていなかったのですが、メンバー1人1人が普段の仕事と同じ要領で最高のサポートをしてくれました。 すごい良い現場だなぁと改めて思いました。

社内の皆さまに工夫してもらったこと

割と色々な人が絡んでくれて議論もできて技術的雑談ができる環境最高だなって思いました

噂に聞く色々な人がいるなと……

ランチは毎回色々な部署のすごい人と話すことができた

これは社内の皆さまのお陰ですね。 普段そこまで関わりがない人ともインターン支援をきっかけに交流が生まれました。

私が関与した部分としては

  • ランチ企画
  • 社内勉強会の臨時開催&インターン生向けのLT枠確保

社内勉強会は私が発起人の1人だったので、動かしやすかったというのもあります。

yuzutas0.hatenablog.com

可能な範囲でチャンスを提供しましたが、チャンスを活かしたのは本人ですし、場を盛り上げたのは他のメンバーです。 もともと@sukukyonがあちこちで実績を作っていたので旧来の知り合いが多かったらしく、スムーズに文化に馴染めたのではないでしょうか。 ひとえに本人の過去の努力の積み重ねですね。

そして、良い意味でとがったエンジニアが集まる会社を作った先人達の功績とも言えます。 本当に良い会社だ。

最後に

いちおうアンサーエントリーっぽく。

事前面談で「朝弱いんですけど、遅くてもいいですか」「日が昇ってれば」

毎日座れる時間に通勤して、いい感じにやって、座って帰って寝る、みたいな最高の生活をしていました。

流石に最後に「もっと早く来られるようになろうね」とか煽られるかなとドキドキしてたんですけど、特に何も言われませんでした……

へーきへーき! 人によって得意な時間帯違うから!

解説: フレックスタイム制を導入しています。 エンジニアが働きやすい!素敵!

なんかバランスボールが転がっていたので1週間ぐらいその上でふよふよしながら仕事してました。 さすがにふよふよしすぎて怒られるかなって思ったけど最後まで怒られは発生しませんでした。

うんうん。 わかるわかる。

解説: 作業環境をカスタマイズできる風土があります。 エンジニアが働きやすい!素敵!

Thunderbolt Display は遅延が少なくて割と最高

MacBook ProがUS配列なんだけど」「じゃあJISキーボード持ってきます」

わーい! すごーい!

解説: それなりにきちんとした開発ツールが揃っています。 椅子(名前忘れた)とかIntelliJとかオライリー全巻とかも。 エンジニアが働きやすい!素敵!

夜に、疲れたのでルートビアを買ってきて飲んでいたらメンターに酒を飲んでると思われたけど特に突っ込まれなかった。それは流石に突っ込んで欲しい。

そだねー


はい。

ということで(責任感と実力があって成果を追求できる人材であれば)楽しく働ける素敵な職場です。 部署やチームによって特色が全然違うのでそこだけご注意ください。うちのチームは楽しいぞ。スキルがあれば。

  • データ基盤の開発・運用におけるベストプラクティスを追求したいSREエンジニア
  • データ活用による業務改善(RPA)で利益創出を目指したいアプリケーションエンジニア・機械学習エンジニア
  • データ分析による意思決定でプロダクト開発を支えたいアナリスト・データサイエンティスト
  • データ案件推進やデータ駆動文化の醸成を担いたいディレクター

我こそはという方がいらっしゃいましたら、ぜひお気軽に@yuzutas0にお声掛けください。 めでたしめでたし。

再掲:※本稿は個人の見解であり、所属する組織を代表するものではありません。

自分自身のパフォーマンスをチューニングするプラクティス

某所のビブリオバトル(書評合戦)にて「いかに自分自身のパフォーマンスをチューニングするか」という話をしました。

スライド

社内ISUCONに参加する前にチューニングすべきもの

概要

『メンタル・タフネス』という書籍の紹介になります。

成功と幸せのための4つのエネルギー管理術―メンタル・タフネス

成功と幸せのための4つのエネルギー管理術―メンタル・タフネス

著者は元々アスリートトレーナーで

  1. 高い成果をあげるアスリートとそうでないアスリートの違いを分析した
  2. アスリートの成功パターンはビジネスパーソンにも当てはまることが分かった
  3. ビジネスパーソン向けのトレーニングメニューを構築・運用してきた

これらの活動で得た知見を書籍にまとめたとのことです。 いわば「人生のSRE本」として読むと興味深いものがあります。

ビブリオバトルの経緯

社内勉強会のLT枠で話しました。

  • 会のテーマは「社内ISUCON」:ISUCONというのはシステムのパフォーマンスチューニング大会のことです。一般公開せずに社内で実施したので社内ISUCONと呼称しています。
  • LTの形式は「ビブリオバトル」:オススメの1冊を数人が紹介しあって、リスナーの投票で1位を決める書評合戦のことです。

これらを踏まえて「自分自身のチューニング」というコンセプトで書籍紹介に至りました。

というのも、私たち1人1人の人間についても「1つのシステム」と見なせるからです。

  • そのシステムが最高のパフォーマンスを発揮するには何が必要か。
  • そのパフォーマンスを安定的・継続的に発揮するには何が必要か。

本質的にはシステムチューニングと同じことだと考えています。

なぜセルフマネジメントが大事か

この「自分自身のチューニング」(=セルフマネジメント)が必要になってくるのは、特に以下の2点においてです。

  1. 個人として自分のパフォーマンスを最大限に発揮するため:自分でセルフマネジメントをする
  2. リーダー・マネージャーとしてチームメンバーのパフォーマンスを最大限に引き出すため:他人のセルフマネジメントを促す

楽しいことをより多く楽しむためにも、嫌いなことを素早く片付けるためにも、パフォーマンスが良いに越したことはありません。 楽しいことをより多く楽しみ、嫌いなことを素早く片付けられるようになると、ポジティブな流れが生まれてきます。 少し大袈裟かもしれませんが、セルフマネジメントは人生を豊かにするツールの1つではないかと思っています。

もくじ

自分自身をチューニングするための3つのポイント

この書籍から学べることを強引にまとめると、以下3つのポイントとなります。

1: 時間管理よりもエネルギー管理

  • 細かいスケジュールを組んでも、どうにも調子が出ないまま時間が過ぎてしまう。よくある話です。
  • 一方で、なかなか進まなかった仕事なのに、いざ集中してみると1時間で片付いた。これもよくある話です。
  • 結局のところ、どれだけメンタルのエネルギーを注げるかが重要なのです。

2: メンタルのエネルギーは筋肉と同じ特徴を持つ

  • 筋肉と同じように、メンタルは酷使すれば疲労します。1度集中して疲れた状態のまま、また集中しようとしても難しいでしょう。
  • 筋肉と同じように、メンタルは負荷を掛けないと衰えます。楽な方向に逃げてばかりいると、いざ頑張ろうとしても頑張れないものです。
  • なので、無理のない範囲でメンタルに負荷を掛ける → メンタルを回復させる → 徐々に大きな負荷を掛ける:この繰り返しでメンタルは強化されます。
  • この特徴を踏まえてトレーニングメニューを組むことで「メンタル・タフネス」を実現できます。

3: メンタルのエネルギー管理は4つのバランスで成り立つ

メンタルのエネルギーは4つの観点によって構成されます。

  1. 身体:(例)行き詰まったときに走ってみると調子が良くなる
  2. 頭脳:(例)久々に本を読んでみると頭がすっきりする
  3. 情動:(例)家族からのサプライズなど、感動するような出来事があるとポジティブな気持ちになる
  4. 精神:(例)些細なことでも「自分はこのために生きているんだ」と思えるとモチベーションが湧き出る

※ちなみに「情動」と「精神」は違うものです。「情動」は忍耐・共感・自信といった要素で、他者や自然や文化との繋がり(≒優しさ・慈しみ)に関連します。一方で「精神」は使命感・価値基準といった要素で、自己の中にある価値観(≒正しさ・誇り)に関連します。書籍ではキリスト教徒を例にとって礼拝や地域ボランティアが精神的活動に当たると説明しています。

4つの観点から自分の調子をモニタリングする

上記の分類は自己パフォーマンスを見直す参考になります。 例えば、現代人の生活を想定するとこのようにマッピングできるでしょう。 ※主観で書いているので個人差はあります。

  • 身体
    • 酷使している:食事・栄養(高カロリー)、眼精疲労、腰や肩に負荷が掛かる姿勢
    • 不足している:食事・栄養(野菜不足)、水分補給(水)、睡眠不足、有酸素運動やストレッチの不足
  • 頭脳
    • 酷使している:スマートフォンやPCでの文書作成、インターネット上の動画・画像・テキストなどのコンテンツを流し読み
    • 不足している:知らない分野に関する読書、頭脳ゲーム、複雑な数式の計算、丁寧に文字やスケッチを書く
  • 情動
    • 酷使している:学校や職場での人間関係への配慮、キュレーション済みの感動コンテンツ
    • 不足している:家族や友人に感謝を伝えるようなイベント、映画や芸術作品を見る、旅行先で自然を感じる
  • 精神
    • 酷使している:今やっていることにどんな意味があるのかと悩む時間
    • 不足している:将来やりたいことのために今出来ることに集中する時間

なんとなく調子が悪いなと思ったときには、これらのバランスが崩れているときです。

負荷が強すぎる・酷使しているポイントについては、しっかりと休めることで回復させましょう。 負荷が弱すぎる・不足しているポイントについては、しっかりと補うことで強化させましょう。

ということで、書籍では4つのバランスを保つためのトレーニングメニューが細かく提示されています。 ただ、トレーニングメニューの各論については1人1人向き・不向きがあるはずです。 色々と試行錯誤して自分にあったスタイルを構築することになるでしょう。

私のライフハック

色々と関連書籍を読んだりライフハック的なことを試しています。

1. 身体

1-1. 睡眠:朝に光を浴びる

睡眠不足については『睡眠のはなし』という書籍が良かったです。

  • そもそも睡眠とは何か
  • どういうメカニズムで動いているのか
  • そのメカニズムのどこにどういう影響が生じて睡眠不足になるのか
  • どのようにしたら効果的に眠りにつけるのか

といったことが説明されています。

個人的に重要だと感じたのは「朝早くに太陽の光を浴びること」です。 曇りや雨の日でも空を見ること、寝不足であっても朝に起きることがコツです。 朝1番に体内時計をリセットできれば、夜にきちんと眠りにつけるようになり、快眠サイクルが回り出します。

理想としては、朝の日光が顔に当たるように窓・カーテン・ベッドを上手いこと配置できると、全てが自動化されて最高です。 まぁ、日の出の時間や太陽の角度がちょっとずつズレるので、これはこれでチューニングが手間ですが。

1-2. 疲労感:芯とセンサーを意識する

首・肩・目の疲れについては『「疲れない身体」をいっきに手に入れる本』を参考にしています。 この本では、身体の疲労を「芯」(バランス・重心)と「センサー」(五感)という概念で説明しています。

  • 例:座ったときの姿勢が悪い=体の芯がブレている → 足腰に掛けるべき負担が、首や肩に掛かっている → だから首や肩が凝る
  • 例:ディスプレイと顔が近い=センサー(目)に意識が傾いている → 遠目で(脳で)画面全体を把握してから細部を読むべきなのに、目だけで情報を処理しようとする → だから目が凝る

「芯」と「センサー」のどこに負荷が掛かっているのかを認識できるようになると、チューニングのポイントが見えてくるので、ストレッチやマッサージ(事後対応策)にも、姿勢の矯正(事前予防策)にも役立ちます。

1-3. 運動:走り方を工夫する

運動不足解消と言って真っ先に思いついたのが「走ること」でした。 いくつか比較したところ『金哲彦のマラソン練習法がわかる本』が良かったです。

以下のような練習メニューと、その組み合わせ方が紹介されています。

  • WALK:早めに歩く。脚の筋力を維持したり、フォームチェックに用いる。
  • JOG:呼吸を意識しながらゆっくり走る。有酸素運動での体力強化、疲労回復、体調整備。
  • LSD:長い時間掛けてゆっくり走る。有酸素運動での体力強化。
  • レースペース走:一定のペースで走り続ける。ペース管理の感覚を養う。
  • WS:早めに駆け抜ける。フォームを広げたり、スピード感覚を養う。
  • ビルドアップ走:徐々に加速する。心肺能力を高める。
  • ダッシュ:緩い坂をダッシュする。筋力をつける。
  • クロスカントリー:自然の地形を走る。筋力、心肺能力、バランス感覚を養う。
  • 休養:体を動かしてほぐす。もしくは完全に休める。

むやみに走るのではなく、最初はWALKから始めて足腰を鍛えたり、3日に1度は休んだり、目的に応じたメニュー設計が重要です。 中途半端に我流で組み立てて怪我をするのもよろしくないので、こういった書籍を1冊読むのはアリかなと思います。

2. 頭脳

頭を使わないといけないのに集中できない。どうするか。 色々試した結果

  • あれもこれも考えてしまうなら「10分の瞑想」をする
  • ぼーっとするなら「10分の仮眠」を取る

これがベスト対応という結論に至りました。

2-1. 瞑想:10分間だけ何もしない

瞑想のやり方が分かる書籍としては『マインドフルネス瞑想入門』が、もっともシンプルかつ実践的だと思います。

  • ざっくり言うと、何もしないで10分間呼吸に専念するだけです。
  • 自然と考えが浮かんでくるので雑念にラベルを貼って流していきます。例えば「上司への愚痴」とか「旅行への欲求」とか。
  • 10分間になんども同じ思考を繰り返していることに気付きます。SRE的に言うと「心のToil」です。
  • 慣れてくると「また自分は同じことを考えている」と気付けるようになって、思考の暴走を抑制できるようになります。

実際にやってみると想像以上に脳内をリフレッシュできます。 座り方や手の形には流派があるようですが、私の場合は剣道や柔道の黙想に慣れていたので、そのやり方を踏襲しています。

~1日10分で自分を浄化する方法~マインドフルネス瞑想入門

~1日10分で自分を浄化する方法~マインドフルネス瞑想入門

2-2. 仮眠:10分間だけ眠る

仮眠については『1分仮眠法』を読みました。 睡眠の解説は「1.身体」でご紹介した書籍と重複するのですが、より仮眠に特化した内容となっています。 例えば以下のようなTipsが紹介されています。

  • 理想は20分:それ以上だと本格的に眠ってしまう
  • 横にならない:同じく本格的に眠ってしまう
  • 昼過ぎがベスト:朝に太陽光を浴びた場合、日中の眠気ピークが昼過ぎに来るのでそこに合わせる

昼の仮眠によって午後のパフォーマンスが上がるわけです。 午後は1日の半分です。それが続けば1年の半分です。最終的には人生の半分と言っても過言ではないわけです。 そう考えると海外の昼寝文化(Siesta)は良いなぁと思っていて、私もなるべく昼に休むようにしています。

脳も体も冴えわたる1分仮眠法 (だいわ文庫)

脳も体も冴えわたる1分仮眠法 (だいわ文庫)

2-3. ペン習字:たまには文字を書いてみる

ついついスマートフォンを見てしまうと、単調なコンテンツの大量消費で頭が疲れてしまいます。 そこで最近はスマホを置いてじっくりと『30日できれいな字が書ける ペン字練習帳』に取り掛かっています。

ペン習字を選んだ理由としては、字を書く機会が最近増えているからです。 ホワイトボードでの打ち合わせ。iPad + Apple Pencil + Noteshelf2 での資料作り。 手書きによるリアルタイム図解は生産性が跳ね上がるのでオススメです。

さてこのペン習字ですが、いざ始めてみると大変です。「あ」を9回書くだけで最初は20分も掛かりました。 自分の字とお手本のどこがズレているかを分析して「次はここに気を付けよう」と書き直して、またズレを分析して。 このように丁寧に進めると、全然進まないのです。自分が普段どれだけ雑に文字を書いていたか思い知りました。

イラストレイターやフォトグラファーには同じ話が伝わると思います。 デッサンやカメラ撮影で鍛えられる「観察力」は、スマホでコンテンツを享受するのとは違った頭の使い方です。

観察とは何か?デザインにどう活きるのか?|こばかな @kobaka7|note(ノート)

30日できれいな字が書けるペン字練習帳 (TJMOOK)

30日できれいな字が書けるペン字練習帳 (TJMOOK)

3.情動

3-1. 人間関係をハックする

人間が社会的な生き物である以上、人間関係は避けて通れません。 トラブルの度に悩んだりストレスを溜めてしまうと負荷が大きいので、仕組みを理解してハックしていきましょう。

まずは営業研修の題材にもなっている『ソーシャルスタイル仕事術』です。 ざっくりと相手を4種類に分類してみて、その特徴に合わせた対応方法を変えると話を円滑に進めやすいよ、という話です。 相手と自分の特徴の違いを踏まえて、相手の視点に立ってコミュニケーションを取るための足掛かりになります。

苦手なタイプを攻略するソーシャルスタイル仕事術

苦手なタイプを攻略するソーシャルスタイル仕事術

お次が『アンガーマネジメント 怒らない伝え方』です。 私は不満を内に抱えるのではなく、外に叩きつけるタイプです。 このタイプの場合、イラっとしたときに、なぜイラっとしたのかを踏まえて冷静に話すスキルが求められます。 「なんでこうしてくれなかったのか!」ではなく「次からはこういう点を考慮してくれると嬉しい」と伝えるスキルです。 ちなみに逆パターンは不満を抱え込んでしまうタイプで、そういった方向けのトレーニングも書かれています。

アンガーマネジメント 怒らない伝え方

アンガーマネジメント 怒らない伝え方

また、組織にいると縦横斜めの人たちと上手くやっていかなければならないので

  • 全体的な勘所は『はじめての課長の教科書』
  • 先輩・上司に対する不満を感じるなら『部下力 - 上司を動かす技術』
  • 後輩・部下に対する不満を感じるなら『部下育成の教科書』

このあたりは読んで良かった本です。

  • 立場が違えど相手も同じ人間だ
  • 相手が置かれている立場上こういう言動をしやすいのだ
  • 彼らと良い関係を築くにはこういうコツがあるのだ

ということを学べます。

新版 はじめての課長の教科書

新版 はじめての課長の教科書

部下力―上司を動かす技術 (祥伝社新書)

部下力―上司を動かす技術 (祥伝社新書)

部下育成の教科書

部下育成の教科書

なお、恋人や配偶者との付き合い方については『The 5 Love Languages』(邦訳:愛を伝える5つの方法)が世界的に有名な1冊です。 アメリカ滞在時にマッチメイカー(結婚相談所)の経営者に教えてもらった本で、流し読み程度ですが目を通しました。 愛情は形で示さないと伝わらないということ、愛情を示す方法は5つに分類されるということを学べます。 某掲示板の "妻に「愛してる」と言ってみるスレ" みたいな取り組みが大事ですよという話です。

The 5 Love Languages: The Secret to Love that Lasts

The 5 Love Languages: The Secret to Love that Lasts

愛を伝える5つの方法

愛を伝える5つの方法

3-2. アニメーション x 映画

手っ取り早く前頭葉を刺激するなら読書&映画だ!という発想のもとでの取り組みです。 クリエイターの生き方や思想を知った上で、その映画をAmazonプライム動画で視聴するという楽しみ方です。

1つ目は、宮崎駿氏のインタビューまとめ『風の帰る場所』を読む → ジブリ映画を視聴する。 時代ごとに主張・価値観が変わっていき、作品に反映されていくのが見て取れます。

  • 風の谷のナウシカ』では現代社会(熱を失った大人たち)に対する拒否感が表現されており
  • 『耳をすばせば』では「この街で(=この世界で)生きていくしかない」という考えに移ろい
  • もののけ姫』では「人間を許すことはできない」「それでもいいから一緒に生きよう」という前向きな立場を明示しています

個々の制作秘話も興味深いです。例えば『千と千尋』のクライマックス。電車で佇んでいるだけのシーン。 ハリウッドなら、カオナシの暴走でピンチになった両親を主人公が助けて感動の再開で終わる。でもそうじゃない。 少女が初めて自らの意思で遠くに向かう(=電車に乗る)という精神的なクライマックスを描画する。 アクションではなく音楽と風景で精神的なクライマックスを描画している。そういえば『君の名は。』も似ているかも。

2つ目は『創造の狂気 ウォルト・ディズニー』で、ウォルト氏の徹底的な現実逃避が見て取れます。

勉強が嫌になって演劇やイラストに没頭したからこそ、ユーモラスな表現ができる。 都市が嫌になって田舎に憧れたからこそ、古き良きアメリカを描画できる。 現実が嫌なことだらけだからこそ、空想の世界を徹底して追求できる。 だからこそ、1930年代の不況で閉塞感に包まれていた人々の心を掴み、作品がヒットしたわけです。

象徴的な作品が、ディズニー初の長編アニメーション作品『白雪姫』です。 7人の小人のキャラクター設定に2年間を費やしており、恥かしがり屋だとか、意地っ張りだとか、小人の性格は一目見れば違和感なく把握できるようにデザインされています。 また、森の動物が白雪姫の家事を手伝うシーンは、まさに自然と子供の触れ合い(=郷愁)を描画しており『シンデレラ』などの後続作品でも似た場面が登場します。

ちなみにウォルト・ディズニー氏の現実逃避は徹底しており、口うるさく言われてアニメーションを作るのが嫌になると、今度は密かに雇ったエンジニアと一緒に機関車の模型を作って遊び始め、やがてその取り組みがディズニーランドに繋がるというカオスっぷりです。

創造の狂気 ウォルト・ディズニー

創造の狂気 ウォルト・ディズニー

白雪姫 (字幕版)

白雪姫 (字幕版)

3つ目は『ピクサー 早すぎた天才たちの大逆転劇』です。 最初は妄想としか思われていなかった「3DのCGで長編アニメーション映画を作る」という夢を掲げて、1960年代の基礎研究から1990年代の『トイ・ストーリー』までの約30年間、大勢の人たちが人生を賭けて意地を貫いてきた様子が描かれています。

ちなみに、長編第1作目が「おもちゃ」をテーマにしたのは、細やかな毛髪を持つ人間と違って、玩具は3DCGで表現しやすいというテクノロジー制約によるものです。 そのリベンジが『モンスターズ・インク』のサリーという毛むくじゃらの怪物だったりします。 こういったクリエイター観点での試行錯誤を知った上で視聴するとまた違った面白さがあります。

ピクサー 早すぎた天才たちの大逆転劇 (ハヤカワ文庫NF)

ピクサー 早すぎた天才たちの大逆転劇 (ハヤカワ文庫NF)

3-3. テーマのある旅

ぶらりとテーマのある旅をしたら色々と感動したのでオススメですよという自慢。

  • 関東近郊の古墳を巡ったり → 『まりこふんの古墳ブック』
  • 熊野古道で山越えをして日本最古の温泉に浸かったり → 『熊野古道 巡礼の旅』
  • しまなみ海道で往復100km以上をレンタルサイクルで踏破したり → 『しまなみ島走BOOK』

いずれは桜前線に沿って日本北上の旅とかしたいですけどね。 1花月感もとい1ヶ月間、毎日どこを歩いても満開の桜に囲まれているなんて素敵じゃないですか。

まりこふんの古墳ブック

まりこふんの古墳ブック

熊野古道 巡礼の旅 よみがえりの聖地へ!

熊野古道 巡礼の旅 よみがえりの聖地へ!

しまなみ島走BOOK <改訂版?> しまなみ海道の達人がおすすめするサイクリングの解体新書![しまなみ海道] [ガイドブック]

しまなみ島走BOOK <改訂版?> しまなみ海道の達人がおすすめするサイクリングの解体新書![しまなみ海道] [ガイドブック]

他にも外に出掛けるという意味だと、2017年はミュシャ展、ブリューゲル展、ディズニー・アート展に行きました。 特に私は、その時代の技術・技法を活用して、その時代の科学で検討して、だけどテーマは過去への憧憬だという作品が好きです。 心象風景をいかに美術作品に射影しているかという観点で楽しみます。 テクノロジーとサイエンスとヒストリーとアートが混ざり合っている感が堪りません。

とはいえ所詮は素人ですので、あれこれ妄想するために知識を補充します。 例えばブリューゲル展では『芸術新潮 2017年 05月号』を読みました。

  • ブリューゲルの「バベルの塔」はロッテルダム版とウィーン版の2作品があり、これらの共通点・相違点を比較分析することで、何を描きたかったのか、どう描きたかったのか、どんな工夫をしたのか、考えがどう変わったのかを推察しようという内容です。
  • 大友克洋氏が「バベルの塔」の内部を、芸大がレプリカ(拡大図)や模型で外側を、それぞれ再現しようというプロジェクトが実施され、その過程での学びも紹介されています。例えば、物理的構造としては塔は正丸に近くなるはずなのに、どっしりとした雰囲気を描写するためにブリューゲルはあえて楕円に描いているのではないか、といった内容です。

芸術新潮 2017年 05 月号

芸術新潮 2017年 05 月号

4. 精神

4-1. レジリエンス(対ストレス性)

レジリエンスについては『スタンフォードのストレスを力に変える教科書』が参考になります。

というのも、ストレスとは「自分の大切なものを奪おうとする脅威」に対して生じるものだからです。 例えば「言われた仕事をやらされるのが嫌だ」というストレスの背景には「自尊心を傷付けられるから」という理由があるのです。 ストレスと向き合うことで「自分が大切にしたいものは何か」を実感し、生きがいや価値観を再考できます。

ちなみに、ストレスに対しては

  • 闘争・逃走反応:思い切って逃げる
  • チャレンジ反応:緊張感とやりがいを感じて立ち向かう
  • 思いやり・絆反応:コミュニケーションを通して痛みを緩和する、人助けを通して小さな成功体験を積む

のいずれかの方法で対応することになります。 ストレスの多寡や耐性力によっては咀嚼する時間が必要なので、無理にコントロールするものでもないとは思います。

スタンフォードのストレスを力に変える教科書

スタンフォードのストレスを力に変える教科書

4-2. どう死にたいか

『死ぬ瞬間』という本では、200人の末期患者に対するインタビュー記録を紹介しています。 中には、インタビューを取り付けた翌日に亡くなった方もいます。

亡くなる本人、残される家族、医療従事者が実際に話した言葉が載っています。 死に至る過程で1人1人が何を考えているのか、心の動き(死の五段階説)を追体験することになります。

  1. 否認:自分は本当は健康なはずだと思い込む、暴食、激しい運動、治療拒否
  2. 怒り:まだ余生のある他者への妬み、なぜあいつではなく自分なのかという理不尽さ、コントロールできない現実への敗北感
  3. 取引:せめて最後にこれをするまでは待ってくれという懇願、誰かの役に立って自分の存在意義を証明しようとする焦燥感
  4. 抑鬱:手術や薬品で美しかったはずの体や自分らしさを損なったことによる喪失感、これから大切なものを失う絶望感
  5. 受容:少数の愛する人たちと何を話すでもなくただ側にいて一緒に最後の時を過ごしたいという願い

死を宣告された後になって初めて意識する「1番の気掛かり」は、本当は健康だった頃からずっと胸の奥に抱えていることだったりします。 死の追体験をすることで、どう死にたいか、死ぬ瞬間までに自分はどうなっていたいか、残された時間をどう生きるか、ということに向き合うことになります。

死ぬ瞬間―死とその過程について (中公文庫)

死ぬ瞬間―死とその過程について (中公文庫)

4-3. どう生きたいか

生き方をデザインする方法は色々ありそうですが、1つは過去の人間の生き方を叩き台にして「こうなりたいな」とか「こうはなりたくないな」といった自分の価値観を探ることではないでしょうか。

  • 『古代への情熱』:初恋の相手との約束を果たすために生涯を費やしてギリシャの遺跡を発掘したシュリーマンの自伝。
  • エジソン・ストーリー』:発明家・起業家として「電気」を軸に人々の生活様式を作り変えていったエジソンの話。
  • 『わが友マキアヴェッリ』:マキャベリさんがチェーザレ・ボルジアに影響を受けたり、フィレンツェの未来を憂いたりする話。
  • 『入門経済思想史 - 世俗の思想家たち』:アダム・スミスカール・マルクスら経済学者が、その時代ごとの社会課題や危機意識と向き合い、人類がより豊かになるための経済モデル(ビジョン)を模索した姿が描かれています。
  • 統計学を拓いた異才たち』:フィッシャーやコルモゴロフら統計学者が、データと確率論を駆使して農業・医薬品・経営・著者推定・遺跡発掘と様々な分野で隠された真実を暴く姿が描かれています。
  • 『数学をつくった人びと』:ラグランジュガロアら数学者が、身分やら宗教やら仕事やら恋愛やらに翻弄されながら数学を発展させていく様子が描かれています。

手元の読書メモを読み返して出てきた書籍たちです。

古代への情熱―シュリーマン自伝 (新潮文庫)

古代への情熱―シュリーマン自伝 (新潮文庫)

エジソン・ストーリー The Thomas Edison Story (ラダーシリーズ Level 1)

エジソン・ストーリー The Thomas Edison Story (ラダーシリーズ Level 1)

  • 作者: ジェイク・ロナルドソン
  • 出版社/メーカー: IBCパブリッシング
  • 発売日: 2011/09/27
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

わが友マキアヴェッリ―フィレンツェ存亡〈1〉 (新潮文庫)

わが友マキアヴェッリ―フィレンツェ存亡〈1〉 (新潮文庫)

入門経済思想史 世俗の思想家たち (ちくま学芸文庫)

入門経済思想史 世俗の思想家たち (ちくま学芸文庫)

統計学を拓いた異才たち(日経ビジネス人文庫)

統計学を拓いた異才たち(日経ビジネス人文庫)

数学をつくった人びと〈1〉 (ハヤカワ文庫NF―数理を愉しむシリーズ)

数学をつくった人びと〈1〉 (ハヤカワ文庫NF―数理を愉しむシリーズ)

偉人のエピソードというのは概して面白いもので、後付けにせよ盛っているにせよ捏造されているにせよ、何かを成し遂げるための意思と行動が描かれているわけです。 「どう生きるか」というのは、どのような意思で、どのような行動を選び、何を成し遂げるのか、ということなのかなと。

ちなみに何かを成し遂げるというのは、偉人としてエピソードを残すことに限らないのかなとも思うわけです。

あなたには特別な力があるんだから。たとえばさ、妻を幸せにする、とかそういう力よ

『モダン・タイムス』(伊坂幸太郎

モダンタイムス(上) (講談社文庫)

モダンタイムス(上) (講談社文庫)

まとめ

ということで、メンタルのエネルギーを管理するための原理原則と、4つの観点を補うための事例紹介でした。 ノリノリで書いたら10,000字を超えてしまった。すまん。

「どうも調子が悪いな」という違和感を突き詰めて、今の自分に足りないものを補うことで、道は開けるのではないでしょうか。 雨が降ったら傘をさすように、エネルギーが欠けているのなら、埋め合わせていきましょう。 自己啓発感が溢れる感じ(というか自分語り)になっていますが、セルフマネジメントは大事ですよねという話でした。

オチ

ちなみにビブリオバトルの投票結果は圧倒的大差でボロ負けでした。無念。

SQLをひたすら読み書きするアルバイトを募集中です

【追記】

応募を締め切りました。 ありがたいことに募集人数を上回るお問い合わせが寄せられまして、無事に採用が決まりました。 ご協力いただいた皆様、誠にありがとうございました。


f:id:yuzutas0:20171218090720p:plain

BigQueryのSQLをひたすら読み書きしまくるアルバイトを募集中です。

<概要>

【仕事内容】

  • 既存の会計系システムをBigQueryベースにリプレイスする案件です
  • そのためにSQLを大量に読み書きしていただきます

【日程・頻度】

  • 平日週2〜3日 / 1日当たり4~7時間を想定
  • 2018年2月〜3月の2ヶ月間(希望・実績によっては延長の相談余地あり)

【報酬】

月10万円(交通費別)

【勤務地】

東京駅周辺

【募集人数】

3〜4人

【条件】

プログラミング経験のある方

【おすすめポイント】

  • 商用データのSQLを読み書きすることで実践的なスキルが習得できます
  • ビジネス指標の見方、定量的に物事を考える視点を身につけることができます
  • 技術カンファレンス登壇者や起業経験者と同じ環境で仕事ができます

春休みで暇な学生さんなど、お知り合いにいましたらぜひご紹介頂けると有難いです。

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

プロダクトオーナーに入門する

この記事はRecruit Engineers Advent Calendar 2017の5日目の記事です。 4日目はy_kabutoya先輩の環境依存情報をコードから分離するというエントリーでした。

本エントリーは「プロダクトオーナーとは何ぞや」という話の整理になります。 認定プロダクトオーナー研修の内容をもとに、社内有志でディスカッションした内容に基づいております。

前提

スクラムとPO

スクラムとはプロジェクトの現状を把握するためのフレームワークである。

yuzutas0.hatenablog.com

スクラムには3つのロールがある。

  • チーム
  • スクラムマスター(以下SM)
  • プロダクトオーナー(以下PO)

POはROIの最大化に責任を持つロールである。

f:id:yuzutas0:20171203131713p:plain

ROI(投資対効果)

ROIは「R」(=Return)と「I」(=Investment)で構成される。

f:id:yuzutas0:20171203132228p:plain

POはROIを最大化するために、あらゆる場面で「R」と「I」を見極めなければならない。

  • その意思決定によって得る「R」は何か?
  • その意思決定のために費やす「I」は何か?
  • 本当にその選択肢が「R」/「I」を最大化するのか?
  • もっと良い選択肢はないのか?

ManageとControll

Return = Manageするもの Investment = Controllするもの
性質 "結果オーライ"の世界 "厳密な制御"の世界
具体例 "売上を実際に得られるか"は結果を見ないと分からない 売上を得るために"xx円で広告を出稿する"という行動は選べる
難易度 相対的にはInvestよりも取り扱いが困難 相対的にはReturnよりも取り扱いが容易(注:あくまでも相対的には)

POは第一歩としてInvestmentをコントロールできるようにならなければならない。

f:id:yuzutas0:20171203132343p:plain

なお、投資(Investment)は以下のプロセスを経る。

  1. 情報収集
  2. 選択肢の洗い出し・比較検討
  3. 意思決定

特に重要な「情報収集」のために、POは四方八方を歩き回ることになる。

f:id:yuzutas0:20171203132452p:plain

InvestmentのコントロールによるROI最大化

POは他者を誘導することでInvestmentをコントロールする。

  • 案件のスコープや受け入れ基準 → チームを誘導する
  • 交渉 → ステークホルダーを誘導する

コントロールするからと言って、そのやり方が「一方的な指示出し」になるとは限らない。 「言われたことをやれ」といった押し付けは、チームの反発を招き、逆効果になるだろう。 結果としてROIを悪化させてしまう。それではコントロールできているとは言えない。

いかに相手を尊重するか、いかに影響力を及ぼすか、どうやって誰のどういった行動をコントロールするかが重要となる。

人を動かす 文庫版

人を動かす 文庫版

チーム

スプリントセレモニーでのROI最大化

スクラムでは定期的なセレモニーによってチームの再計画がなされる。

f:id:yuzutas0:20171203133959p:plain

Whatのセレモニーでは、プロダクトを改良するための再計画を行う。

スプリントプランニング プロダクトバックログリファインメント スプリントレビュー
セレモニーの概要・特徴 - 製品を実現するための短期計画を立てる場
- 会議の内容が重視されるため、往々にして長引きやすい
- 製品の今後についての長期計画を立てる場
- 不確実な将来の話なので内容よりも時間を優先する
- 取り扱うトピックはマーケット課題やリリース戦略、技術課題など
- 現在のプロダクトの状況を踏まえて再計画する場
- 実際に動いているプロダクトを全員で触りながらアイデアを出す
POとして求められる観点 長引きがちな会議時間(というInvestmentを減らす) ロードマップについての合意形成の手間(というInvestmentを減らす) 製品仕様についての合意形成の手間(というInvestmentを減らす)
工夫例 - 簡潔に期待事項・意図を伝える
- 手戻りや認識齟齬が生じないように業務背景や利用者の声を伝える
- 案件の複雑度を下げるためにスコープを調整する
- 後から「こっちを先にやってよ」と捻じ込まれないようにステークホルダーを同席させる
- チームの開発作業を安定化できるように技術課題の詳細を聞き出す
- チームが案件意図を理解できるようにマーケットの現状を共有する
- 後から「この挙動はおかしい」と騒ぎ立てられないようにステークホルダーを同席させる
- POではなくチームが主体となって製品の改善案を出せるように意見を聞き出す

Howのセレモニーでは、POはゲストの立場で参加して情報収集を行う。

デイリースクラム スプリントレトロスペクティブ
POが収集情報をする観点 チームのコンディションを把握する チームが抱えるムダ・ムラ・ムリを排除する
どういうバックログの切り方だとチームは困るか どういうAC(受け入れ条件)だとレビューの手戻りを減らせるか

なお、方法論はSMの責任範囲となる。 POとしてROIを向上(=まずはInvestmentを削減)するために何ができるかSMに相談するのが望ましい。

f:id:yuzutas0:20171203134145p:plain

プロダクトバックログでのROI最大化

プロダクトバックログ

POが操作できる唯一のアイテムがプロダクトバックログ(以下PBL)となる。

  • PBLとはプロダクトの将来像を描くものである
  • プロダクトとはマーケットが抱える課題を解決するものである

f:id:yuzutas0:20171203134348p:plain

要求 = マーケット課題 要件 = 解決案・改善案
主体者 チーム外 = 受益者 チーム内 = 提供者
特徴 スクラムが直接扱う範囲の外にある 1つのマーケット課題に対して複数の解決案がある(1対nの関係)
注意点 - スクラムはプロジェクトの現状を把握するためのフレームワークであり、マーケットの現状を把握するフレームワークではない
- マーケットの現状を把握するフレームワークの例が"リーンスタートアップ"や"デザイン思考"(注:解釈・異論の余地あり)
- 1つ1つの解決案が1つ1つのプロダクトバックログアイテム(以下PBI)に該当する
- 1つの解決案に見えるものでも、さらに細かい解決案に分解することができる(PBIは分割可能)

PBI→PBL→プロダクト→Return

スクラムチームはプロダクトによってReturnを得る。

f:id:yuzutas0:20171203135849p:plain

  • PBIはタイトルと受け入れ条件(以下AC)で構成される
  • PBLは複数のPBIに優先順位を付けることで表現される
  • チームはPBLの順番にしたがってPBIを実現する = マーケット課題の解決案を提供する = Returnを生み出す

PBI

POはPBIの書き方を工夫することでスコープを調整し、Investmentをコントロールする。

  • タイトルとACを簡潔・具体的・過不足なく記入することで、認識齟齬・合意形成・レビューのコストを下げる
  • ACとして禁止事項・制約を設けることで、チームが想定スコープを超えて過剰に開発することを防ぐ

f:id:yuzutas0:20171203135712p:plain

PBIを(POではなく)チームが起票することは、ROI最大化におけるベストプラクティスの1つである。

  • チームの考えが分かる = 貴重な情報源となる = Investmentを減らすための判断が正確になる
  • チームに納得感・主体性が生まれやすい = 自発的にムダ・ムラ・ムリを軽減できる = Investmentを減らせる
  • 施策として実現可能性が極めて高い = Investmentをコントロールしやすい
  • 案件創出の負荷が減ることで、POとしてROI最大化(Investmentコントロール)に専念しやすくなる

※また、PO単体ではなくチームとして学びを得ることができるようになるので、不確実なマーケットに対するRの確度が上がるのではないか。

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

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

PBL

PBLを構成するPBIはいずれかの状態になっている。

f:id:yuzutas0:20171203135914p:plain

  1. Accepted = ACを満たしている状態(リリース済みを含む)
  2. 詳細にタイトルとACが書かれている状態 = チームが着手可能 = 直近2-3スプリントで扱う範囲
  3. 粗めにタイトルとACが書かれている状態 = まだ着手できない
  4. まだまだ雑な状態 = 当面着手しない

2つ目(詳細なPBI)が増えるほど将来の見通しが立てやすくなり、Investmentのコントロールが容易になる。 そのため、POにとってはPBIをなるべく細かく分けることが重要になる。

チームの成熟度にもよるが「XX機能をユーザーが使えること」といった大雑把な粒度ではなく「XX機能のデモを社内関係者が確認するためのテスト環境を構築してHello Worldを出力すること」といった細かい粒度のPBIに切り出すのが望ましい。

ACとDD

プロダクトは2つの品質を備えることでReturnを生み出す。

製品品質 テクニカル品質
概要 マーケット課題をどの程度解決するか 製品特性において最低限備えるべき品質
具体例:子供向け野菜カレー 国内の野菜嫌いの小学生のうち10%が月に1回の頻度で食べる → 1日に必要な野菜を摂取している(結果として年間売上xx円) 有害物質が含まれておらず国が定める安全基準を満たしている
リリースとの関係 リリース後に結果が分かる リリース条件として目標達成が必要となる
施策間の差分 施策によって解決する課題が異なるので指標も変わる 施策横断である程度共通の指標が必要となる
連動する概念 AC(受け入れ条件) DD(完了の定義)

※注:「完了の定義」(Definition of Done)は「サービスレベル」に依存するのではないか。

yuzutas0.hatenablog.com

リリース戦略でのROI最大化

QCDSの関係性

POはPBLによるS(スコープ)の操作を通してリリースタイミングを調整することになる。 イテレーション開発においてQCDのトレードオフは生じ得ないからだ。

Q(品質) C(費用) D(速度)
特徴 DDで定義されているため固定 - Dを改善する有料ツールなどは採用するのが望ましい
- ソフトウェア開発で最も大きいコストになりがちな人件費は安易に増やせない*
- 最終的には札束で解決できない問題がボトルネックとなる
- ムダ・ムラ・ムリを排除することで改善される
- プロダクトの成長と複雑化に伴って悪化しやすくなる
備考 製品品質は不確実なのでコントロール対象ではない(ACはスコープ調整の手段) *前提として知識労働における安易な人員増加はS・Q・Dの悪化を招くので非推奨 チームの能力を超えた速度を出そうとすると
- 正常系動作の実装を優先して異常系動作の確認を徹底しないといった形でS→Qを犠牲にする
- 過剰労働(=会社から労働者へのCの押し付け)が発生する
→ 結果として障害・炎上によってDが悪化する。

エクストリームプログラミング

エクストリームプログラミング

リリースの方程式

以下の方程式から「残スプリント数」を導出すると実現可能なリリース予定が分かる。

リリース対象PBIの完了に必要な残ポイント ≦ 期待されるベロシティ * リリースまでの残スプリント数

f:id:yuzutas0:20171203140428p:plain

Investmentコントロールの打ち手は以下の通り。

  • 見積もり精度を上げる
    • PBIを細かく分割する
    • ベロシティを採用する(高精度:単位制約がない、幅を持たせている、実績に基づいている)
  • 期待ベロシティを向上させる
    • ムダ・ムラ・ムリを排除する

見えにくいUndone(ムダ・ムラ・ムリ)を排除する

Investmentコントロールの観点では、Undoneの取り扱いに注意しなければいけない。

Undoneとは後回しにされた作業のことだ。 本来やるべきなのに出来ていない作業は少なからず存在する。

  • ソフトウェアを扱うスクラムチームの中には、負荷テストや脆弱性検査、依存ライブラリのアップデートを毎回実施できていないところもあるのではないか
  • その場合、月に(もしくは四半期に)1回、あるいは大型リリース前に慌ててテストを実施することになりかねない
  • 結果:テスト待ちの在庫が溜まる → 作業バッチサイズが肥大化 → ムダ・ムラ・ムリ(手順確認、予期せぬ作業、承認待ち、手戻り)の多発 → リリース計画が乱れやすい → Investmentをコントロールできなくなる

Undoneはチームが主体となって対応することになる。 ここでは狭義のDevOpsプラクティスが活きる。

チーム PO
暫定対応 PBIを起票してこまめに実施する - 安易にリジェクトせずに優先順位を示す
- 作業価値を認めて焦らずにじっと待つ
恒久対応 毎回の開発工程に組み込む・自動化する チームの改善活動を適切に評価する

いずれにせよPOは機能要件を並べてチームを急き立てるだけではInvestmentをコントロールできないということだ。

アイデアを出すことが企画だと思ってる奴は100万回死んでいい 島国大和のド畜生

一方で、技術的課題の解消施策については、安易に優先順位を下げてはならないが、安易に優先順位を上げてもいけない。 ありとあらゆる観点から物事を考慮してROIを判断するのがPOの責務となる。

※注:ソフトウェアエンジニア出身者以外がソフトウェアのPOを担うのは難しいのではないか。

ステークホルダー

クライアントとPOは異なる

f:id:yuzutas0:20171203141047p:plain

クライアントはInvestmentをコントロールしていない。

  • クライアントは仕事を依頼する立場である
  • クライアントはお金を支払う立場である
  • クライアントはBudget(予算)を持つ立場である
  • クライアントは結果だけを聞く立場である

あくまでもPOはスクラムチームのInvestmentをコントロールする立場である。

ビジネス部門と開発部門が分かれている場合、ビジネス部門はクライアントであってPOではないことが多い。 その場合は開発チームのリーダーに当たるソフトウェアエンジニアがPOに該当することになるだろう。

チーム以外は全てがマーケット

例えば「上司」をマーケットとして解釈することができる。

  • アプリの利用者にとっては役に立たない機能であっても、上司が喜ぶことでBudgetを確保できる(こともある)。
  • そのBudgetによってアプリ利用者の役に立つ施策が実現できる(こともある)。これが「R」に該当する。
  • だとすると、上司を喜ばせるための機能追加は、必要な投資だと判断できる(こともある)。これが「I」に該当する。

他には、提携先とコラボするためだけのコンテンツ追加や、マーケティング部門がCMで売り出すためだけの目玉機能追加、といった例も同じだ。 世の中に価値を提供するために、一見してプロダクトのためにならないようなことであっても、やらなくてはならないだろう。 つまりは、あらゆる観点を踏まえてROIを判断することが求められるのである。

関係者といかに交渉するか

交渉は「相手との関係が重要か」「取引の中身が重要か」によって4種類に分類される。

取引の中身が重要である 取引の中身は重要ではない
相手との関係が重要である Collaboratyion (協調) Accommodation (譲歩)
相手との関係は重要ではない Competition (対立) Avoidance (回避)

特にテクニックが必要となるのは「取引の中身が重要である」ケースだ。

協調型交渉 対立型交渉
概要・手法 1. 互いの得たい利益と守るべき制約を整理して争点を明らかにする。
2. 「この利益が得られるならこの制約は外せる」といったトレードオフを検討する。
3. 争点を軌道修正してWin-Winの解決策を探る。
- 相手が許容可能なギリギリの線を見極めて落としどころを探る。
- 最初に高い値段を出してから「譲歩します」と言って適正値+αを提示する。
- 相手の主張の根拠となる前提条件を会話の中で崩す。
エピソード 2人の姉妹が1個のオレンジを奪い合っている。一見すると半分に分けるのが早い解決策のように思える。ところが、妹はジャムを作りたいのでオレンジの皮を欲しがっており、姉はジュースを作りたいのでオレンジの身を欲しがっていた。きちんと話し合って、必要な部位を分かち合ったほうが、お互いにオレンジを丸々1個分使うことができるので、利益は大きくなる。 不動産の売買では互いの狙っている金額が事前にあった上で、土地・建物の状態を踏まえて契約価格のすり合わせがなされる。都心湾岸地域は今後値上がりしますよ(なので高い値段で買ってください)という売り手と、豊洲市場やオリンピックが不安ですね(なので安い値段で売ってください)という買い手のぶつかり合いになる。

なお、交渉ゲームで不利にならないためには、以下の2点が最低限必要となる。

  • 情報収集の徹底:互いの利害関係を読み取ること。
  • BATNAの用意:交渉決裂時の代替手段があること。

だが、これらの準備に掛かる負担(=Investment)は小さくない。 交渉ゲームにコストを割くこと自体がROI観点で望ましいとは言えないだろう。

そこで「信頼残高」が重要になってくる。 相手から自分への「信頼残高」があれば一部の工程をスキップできる可能性が高まる。 相手が譲歩したり、探り合いなしで協調型交渉をスムーズに開始できる。 ステークホルダーとの協力関係を構築・維持することは、無駄な交渉ゲームを回避するための投資なのである。

ハーバード流交渉術 (知的生きかた文庫)

ハーバード流交渉術 (知的生きかた文庫)

関係者との協力関係をいかに構築するか

失点を抑えながら、相手に価値を提供し続けることで、徐々に信頼は構築される。

内容だけでなく物事の進め方やコミュニケーションの取り方にも注意を払うことが望ましい。 「20点でいいから1日で持ち込む人間」と「100点にしてから1週間後に持ち込む人間」どちらが信頼を得やすいか。 答えは相手と状況によって変わる。

ソーシャルスタイル理論を軸にして適切な対応を探るのが常套手段の1つだ。

自己主張(小) 自己主張(大)
感情表現(小) Analytical Driving
感情表現(大) Amiable Expressive

自己評価や内面性ではなく実際にどのような言動を取っているかで判断する。 心の中では主張を持っていても、質問されるまで自分の意見を言わなければ左側になる。 たとえ感情を大切にしていても「それで結論は?」という聞き方をするなら上側になる。

デザイナーと働くなら知っておきたい4タイプのデザイナー像 | ベイジの社長ブログ

各タイプへの適切な対応方法は以下となる。

Driving Expressive Amiable Analytical
適切な接し方 論理的に・簡潔に 楽しそうに・熱心に 穏やかに・共感しながら 詳しく・丁寧に
適切な時間の流れ 目標優先・効率的に 迅速に・勢い良く じっくり考えてもらう じっくり(ただし納期は厳守)
適切な意思決定の促し方 本人に決めてもらう インセンティブを示す リスクや不安を一緒に解消する 納得に必要な材料集めを手伝う

これらは単純化のための四象限なので取っ掛かりに過ぎない。 相手の反応を見ながら迅速・的確に対応方法をチューニングすることが、協力関係を築きInvestmentを削減するための第一歩となる。

苦手なタイプを攻略するソーシャルスタイル仕事術

苦手なタイプを攻略するソーシャルスタイル仕事術

要するに、人間に対する振る舞いの改善サイクルを回すということだ。

SREや狭義DevOpsにおけるシステム改善と同じだ。 この考え方がなければUndoneは解消できない。 PBLによるInvestコントロールができない。

リーンスタートアップにおけるマーケット仮説検証と同じだ。 この考え方がなければ市場要求に応えられない。 PBLによるReturnマネジメントができない。

同様にPOはチームやステークホルダーを動かすことでROIを最大化するのである。

注意点

以上の話は「スクラム」というフレームワークにおける「PO」というロールについて述べている。

あくまでもフレームワークフレームワークであり、ロールはロールである点に注意したい。 スクラムというフレームワークを使うことは目的ではない。 POというロールを演じることが正解とは限らない。

むしろPOとしての良し悪しを語ること自体がナンセンスだという場面の方が多いのではないか。 この記事の内容に振り回されて、手段を目的化するようなことは望ましくないだろう。

トドメのポエム

ただ「限られた資源のなかで投資対効果を最大化する」という志向は、経済の基本原理でもある。

  • 「家族との団欒」というReturnのために「会社の出世コースを外れる」というInvestment
  • 「会社での出世」というReturnのために「家庭でのコミュニケーションが減る」というInvestment
  • 「家庭と仕事の両立」というReturnのために「時間とエネルギーを割いて働き方や日々の生活を見直す」というInvestment

チーム活動やプロダクト開発における優先順位付けだけではない。 1人の人間として幸福を追求するならば、意識的であれ無意識であれ、必然的にROIを心のうちで勘定するだろう。 人は誰もが皆、自分の人生のプロダクトオーナーなのだ。

そういった意味では、ROIの最大化に責務を持つ「PO」というロールの思考法を学ぶことは、あらゆる活動を豊かにする一助となるのかもしれない。

めでたしめでたし。

"1日でWEBサービスを作る"という取り組み

前の週末に"1日でWEBサービスを作る"という取り組みをしました!

f:id:yuzutas0:20171119210350p:plain

ルール

1.スタートは昼食後!

  • イデア出しから始めること。
  • 開始前にあれこれ考えないこと。
  • とにかく無心でリリースに漕ぎ着けること。

2.夕食までに本番環境にリリース!

  • それまでは断食すること。飲み物はOK。
  • 食事をしたければ、さっさとリリースすること。

何が何でも1日でリリースに漕ぎ着けるという強い意志と「やっていき」の精神。

当日の流れ

プランニング

とりあえずホワイトボードにお絵描き。

  • コンセプト(誰のどんな課題を解決するのか)
  • 開発要件(画面遷移、ER)

サービス名は和風な言葉から連想ゲームで決めました。和歌に出て来る「待ち人」です。 クリエイターの未来を決めるような「待ち人」との「マッチ」から「ビート」が生まれるということで、Match Beat(マッチビート)と命名しました。

ちなみに持ち歩いているホワイトボードはこいつです。

CANSAY nu board JABARAN (ヌーボード・ジャバラン) A4判 [MBR] NJA4CMBR08

CANSAY nu board JABARAN (ヌーボード・ジャバラン) A4判 [MBR] NJA4CMBR08

コーディング

システム構成はこんな感じです。

リリース

※誤解を招きそうなので補足すると、カフェは終業時間になっただけです。

ということで何とか無事に達成しました。

できたもの

クリエイターがテストユーザーを募集するWEBサービス「Match Beat」(マッチビート)
https://matchbeat.yuzutas0.com/

突貫工事なので、作り込みは浅いです。 「もっとこうした方がいいよ!」といったアドバイスをいただけると嬉しいです。

翌日以降に修正した内容

  • Bug: コメント投稿者のTwitterリンクが誤っていたのを修正
  • UI: テキスト内のURLをタップすればリンク先に飛べるように修正
  • UI: 投稿者のTwitterリンクをタップしたときに新しいブラウザタブを開くように修正
  • UI: 長文投稿しやすいように入力フォームの幅を縦長に修正
  • UI: 実機iPhoneMacでも入力フォームのスクロールバーを操作しやすいように修正
  • UI: SNSシェア時にデフォルトで企画タイトルを含むように修正
  • Cost: 金銭面の事情によりGCPからVPSにサーバを移管

なぜ作ったか

この取り組みとは別に「声だけでマッチングするアプリ」を作っています。 そのテストユーザーを募集するにあたって、専用サイトがあってもいいんじゃないか、と思ったのがきっかけです。 詳しくは募集ページをぜひご覧ください。

振り返り

よかったこと

1: タイムアタックで時間を意識したこと

時間が限られているので、効率の悪い作業・苦手な分野は、はっきりと可視化されます。 毎日コツコツと作業を行うだけでは気付きにくい1、自分の弱点と向き合うことになります。

逆に言えば、そこを効率化することで、次からはもっと早く作業ができるようになる、ということです。 個々の反省点(=改善余地)は後述します。

2: 1日リリースの実績を得たこと

クリエイターにとって最大の敵は「未完成」(エターナること)だと思うんですよ。 モチベーションが続かないとか、なかなか完成しないとか。

だけど、アイデアを言うだけではなく、実現するからこそのクリエイターです。 スコープを小さくするための方法を考えることもまた「企画」の醍醐味の1つでしょう。

15週間でクソゲーを20本作って得たもの - Qiita

RPGツクールでゲーム作ろうとしたけど30分で飽きてラスボス戦だけ作って放置したんだけど、今思えば「いきなりラスボス」ってタイトルで1作でっち上げても良かったのかもしれん

2017/10/02 16:41

前に拝見したこのコメント、いいなぁと思いました。 「企画力」という言葉はこういう発想のことを言うのだと思っています。

今回、1日でWEBサービスをリリースするという実績ができました。 次からは「ログイン機能も削っちゃっていいじゃん!」と、自分自身に対して強気で言えるようになったわけです。 「モチベーションが落ちる前に1日でリリースしようぜ!」という選択肢ができたのは心強いです。

3: 使ってもらえたこと

@seekgeeks_nyさんがPostterというサービスのテストユーザーを募集なされています。 「何か一言」と画像を合成してシュールな画像を作るサービスだそうです。 話題になっているハッシュタグをお題にして画像で大喜利できるとバズりやすいのではと思ったり。

画像と文字を合成してTwitterに投稿するサービスの改善案募集中! - Match Beat

ユーザーは1人も付かない想定だったのですが、こうして使ってもらえるのは、やっぱり嬉しいですね。 @seekgeeks_nyさんは「1日でWEBサービスを作る」企画を面白がってくださって、あちこちで宣伝いただきました。 せっかくですので、この機に一緒に何かできたらいいなと思いました。

反省点

What

コンセプトの尖り具合が足りなかったです。 例えば「Pythonで彼女を実装しました!」みたいなパワーワードが出て来ないと、この乱世は生き残れないですからね。

ゼロ・トゥ・ワン 君はゼロから何を生み出せるか

ゼロ・トゥ・ワン 君はゼロから何を生み出せるか

www.wantedly.com

これらの書籍や記事で書かれているように、

  • まずは少数に対して尖ったものを叩き込む
  • 熱狂してもらう
  • シェアを確立する
  • その上で、次の尖ったものを叩きつける
  • その繰り返しで非連続的に成長させる

このスタンスを意識できていなかったです。 薬にも毒にもならないものよりも、歓喜乱舞と罵詈雑言が飛び交うくらいの尖ったものにしたい。

Who

具体的に誰がどう使うかのペルソナを描けていなかったです。 リリースしたら「この人とこの人に声を掛けてマッチングさせよう」という企みが足りなかったです。

angel-base.com

上記リンクで言われているように、仮にサービスが伸びなくても「その2人に喜んでもらえた」だけでも成功と呼べるでしょう。 もしかしたら「最初の成功例が早くも生まれました!」とPRすることで、注目や初速が出たかもしれません。

そういった意味で、ユーザーになってくれるであろう自分以外の誰かにきちんと向き合えていなかったのは反省です。

Where

きちんとした作業場を確保すべきでした。

When

昼食〜夕食で試みたのですが、朝からやったほうが良かったのではと思います。 関連して、食事制限は設けずに適度に休憩すべきでした。さすがに身体に悪すぎる。

How

今回の作業ブロッカー・手戻りのリストは以下の通りです。

  • 異常系の動作確認パターン:複雑になるときは紙に書き出して整理すべきでした。
  • before_filterの無理な共通化:最初はベタ書きで進めて、別途リファクタリングの時間を設けるべきでした。
  • Asset Pipelineのエラー:久々で色々テンパりました。1度に多くの変更を加えると問題の切り分けが大変なので、小さく1つずつ動作確認すべきでした。
  • Production環境の設定エラー:本番サーバにいきなり上げたせいで原因特定に苦しみました。先にローカルでProductionビルドすべきでした。
  • GCPの想定外コストに気付いて別サービスのチューニングを始めてしまった。えらく時間を費やした。お陰で安くなりましたが。GAEは難しいですなぁ。

今後: 磨き込みのアイデア

実際に公開してみると、利用を促進するには工夫がいるなぁと思いました。

テストユーザー側のアクションを磨く

このサービスのアキレス腱は「テストユーザー側」の「アクション」だと思うんですよ。 フィードバックを求めるクリエイターはいるはずなので、最初の投稿はお願いできるかもしれない。 だけど、そこから伸びるためにはテストユーザー側の反応が不可欠です。

では、テストユーザーがあえてこのサイトを訪問するのはなぜでしょう。 このサイトで意見を交わすのはなぜでしょう。 そこを抑えることがポイントなのではと思います。

例えば

  • NewsPicksに経営者がコメントするように、デザイナーやエンジニアやQAが「このサービスはここを伸ばすと良さそうだね」「こういう点が難しいだろうな」「使ってみた!可能性を感じたよ!」と語る場
  • StackOverflowでエンジニアがQ&Aをするように、クリエイター同士が知見を共有しあうQ&Aサイト → 回答するとレベルが上がる、知識の整理になる、考える訓練になる
  • マイナーな仮想通貨で支援できるクラウドファンディングのような場(もしかしたら高騰するかもしれないくらいの期待感がインディーズっぽくて私は好きです)
  • Githubのように、エンジニア以外でもIssueを出したり「+1」できたり、ロードマップやコミット(更新履歴)やチケット進捗を追えたり、Wikiで使い方を確認できたり、STARで更新通知を受け取れるプラットフォーム
  • オフラインで「日曜グロースハック会」なるイベントを月次で開く → 参加者は当日までにMatchbeatにグロースのアイデアを書き込んで、当日はケーススタディ&ディスカッションしあう(=このサイトに書き込むことが勉強に繋がる)

こういったアイデアはどうでしょうか。 最後の案(日曜グロースハック会)はシステム改修なしで今すぐ実現できそうなので、試してみる価値はあるかもしれません。

テスター募集側のツールとして磨く

あるいは「テストユーザーを募集する側」の「ツール」として磨き込む作戦もあります。

  • WebAPI,SDK,コピペ用JSを提供してユーザーからのご意見箱を気軽に設置できるツール
  • LINEやFacebookメッセンジャーbotと連携して、ユーザーが好きなインターフェースで感想を送ることができるツール
  • SNSエゴサーチでご意見を自動収集してレポートしてくれるツール
  • いろんなSNSでバラバラに受けた意見を、どんどんInboxに蓄積すると、似たものを自動グルーピングしたり、チケット管理できるツール

このサービスだけではテストユーザーが見つからないかもしれない。 だけど、テストユーザーを探したり、意見を出してもらったり、出てきた意見が管理しやすくなる。 コミュニティとしての活性化ではなく、SaaSとしての実用性を磨き込む。

そういった作戦に切り替えることも考えられます。

最後に

長々と書きましたが。

イケてる(と思い込んでいる)アイデアをいつまでもリリースできない。 そんなイケてない自分とはサヨナラだ!という内容でした。

やろうと思えば初心者であっても、スコープを絞り込んで1日でリリースできるはずです。 ぜひチャレンジしてみてはいかがでしょうか。

あと、せっかくなので、これやりたいですね。

ちなみに

  • 声のマッチングアプリのテストユーザー募集はこちらです!ぜひよろしくお願い致します! → https://matchbeat.yuzutas0.com/plan/3
  • もし良かったら「日曜グロースハック会」(月次で集まって互いのサービスのグロース案を模索する会)を誰か一緒にやりませんか?


  1. WIP制限を1にすれば普段の作業でも同じ恩恵を受けることは可能なはず。参考: なぜWIPの制限が重要なのか | Ryuzee.com