下町柚子黄昏記 by @yuzutas0

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

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

この記事は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

開発運用チームを立て直した話

SPI Japan 2017というカンファレンスで発表をしました。 グロースフェーズの痛みの中で、いかに開発・運用チームを立て直したかという内容になります。

発表スライド

「Rebuild Team - 急成長プロダクトのDev&Opsで生じる悪循環とその解決策」

ここ最近の発表の集大成です。 急成長フェーズを体験した人は多くないはずなので、有用な知見ではないかと自負しています。

参加した感想

  • 運営が非常に丁寧でした。選考通過時にはレビュアーから「こういう点が素晴らしい」とコメントいただき、また当日には司会者からフォローをいただき、非常に話しやすい場作りがなされていました。
  • 一方で内容面については全体的に違和感を覚えました。もやもやです。
内容 思ったこ 補足事項
「改善施策が現場に受け入れられない」という意見が多かった 改善施策は現場の人が現場のために生み出すものではないか。
現場にメリットのない改善施策に意味はあるのか。
最後のパネルディスカッションで似たようなツッコミが出たので安心しました
1人1人の改善意識をいかに養うか → 打ち手として「教育」「評価」の話になりがち 普段からお互いに「お前はどう思う」を聞きあうだけで解決するのでは
参考:新入社員の自発的な課題発見・解決を促す
パネルディスカッションで似た話が1
「今回の取り組みをもとにXXX導入を社内全体に広げていきます」といった今後の方針 わざわざ広げる必要ないのではと思う内容が多々。
プラクティスには適用範囲があるので。1
文脈は違えどクロージングセッションのSoE/SoRの話が近いのかなと
テストコードやアジャイル手法を「やってみた」が多い WEBに山ほど上がっている各社事例で知見としては十分ではないか。
適用するプラクティスと生じる問題に業界の差は見受けられなかったので。1
単純に私の観測範囲がほかの参加者とズレていたのだと思いますが

個々の取り組みはどれも素晴らしいものだと思います。1つ1つの活動を否定する意図はありません。

ただ、趣旨が趣旨なので仕方ないのかもしれませんが、「改善」自体が目的化しているように感じる場面が多かったです。 どちらかというと「これから改善活動を担う人」向けのイベントだったということでしょうか。

「改善」から卒業しようと決めた

「プロセス改善」や「xx手法」といったものは、名前こそ大仰ですが、実際には高校生でもやっていることです。

  • どうやったら好きな人に喜んでもらえるか、ひとづてにリサーチしてみたり
  • どうやったらケンカした友達とまた一緒に遊べるようになるか悩んでみたり
  • どうやったら試合に勝てるか、スポーツの練習メニューを試行錯誤してみたり
  • どうやったら楽に良い点数が取れるか、効率の良いテスト勉強法を模索してみたり

そのなかで定石(問題と打ち手の組み合わせ)がパターン化されて名前が付けられるわけです。 「部署間のハレーション」と「子供同士のケンカ」の解消方法は、よく似ていると思いませんか。

結局は、目の前の出来事といかに向き合うか、が重要なのだと考えています。 付き合い始めのカップルのほうが、そこらの開発チームよりも高速にPDSサイクルを回しているとは思いませんか。

夜も眠れなくなるくらいの問題意識があれば、諦めたくない目標があれば、本気で熱中できるものがあれば、 「What」への強い関心があれば、必然的にその過程で「How」は磨かれていくでしょう。

今回に限らず、Howや改善に関するイベント・議論に対しては、以前から違和感を覚えていました。 「また同じ話か」と分類できるくらいには、私自身の見識が十分に育ったのだと解釈しています。1

ということで、なるべく「改善」という言葉は使わないようにします。 "こうやって工夫しました"(How)ではなく、"こういうことをやりました"(What)。 「おもしろいでしょ」と世の中に自慢するような、そんな動き方を大切にしたいなぁと思いました。

海からの贈物 (新潮文庫)

海からの贈物 (新潮文庫)


  1. 作業のリードタイムが短く、試行錯誤のサイクルを回しやすいソフトウェア担当者のほうが、ハードウェア担当者と比較したときに、現場発の改善活動に取り組みやすいように感じる、という某社の方の意見。つまるところ「いかに普段からPDSサイクルを回しているか」「いかに普段から自分の考えを言葉・行動に出せているか」「そういった空気を醸成できているか」だと解釈しています。

  2. この手の拡大議論は、既に1度なされているという認識でした。XPに端を発した2000年代のアジャイルブームの時の講演資料を漁ると、共通ルール化や組織内普及の事例が出てくるので。

  3. 何か新しい視点が得られたら良かったのですが。社内でtwadaさんやi2keyさんの取り組み・知見が展開されることもあり「うーん」というのが正直な感想。

  4. ここでは極めて個人的・主観的な物の見方をしています。

新入社員を現場で受け入れるプラクティス

私のところでは新入社員の受け入れ時期になりました。 思考の整理を兼ねて、過去に現場リーダーとしてやったことをまとめます。

スコープ

本稿では「新卒社員」かつ「現場での受け入れ」をスコープとします。

  • 新規参画者向けのTODOやフォロー体制は別途存在する。中途入社や異動があるので共通。
  • 会社横断でのTODOやフォロー体制は別途存在する。新人研修など。

なお「こいつは新入社員として扱かったらダメだろ」みたいな即戦力人材は対象外。

関係者の期待を確認する

関係者に期待事項をヒアリングするところから始めます。

  • 本人(変わりうるので都度確認する)
  • メンター
  • 研修時の上長・講師
  • 配属後の上長

配属意図、関心事項、伸ばしたいポイントについての認識を揃えます。 本来はメンターや上長が推進すべきですが、手が回っていないことが多いので、現場で巻き取るスタンスで。

関係者ごとに意見が異なる場合は、なるべく本人の意思を尊重します。

  • 人は「自分のやりたいことしかやらない」「自分の聞きたいことしか聞かない」ものだと割り切る。
  • 人は誰かが育てるものではなく、自ら育つものである点に注意する。
  • どんな相手であれ、ある側面では自分以上の介在価値を発揮する人材であることを念頭に置いて接する。

コテコテの新人育成メニューを押し付けるようなことは絶対にしないと決めています。 機を見て「こういう点を伸ばすと良いかもね」メッセージを織り込むくらいに留めます。

依頼する業務について

本人と話して案件を選んでもらいます。

制約条件は色々あるので配慮が必要となります。

  • 本人のケイパビリティに合致するもの
  • 推定工期が長すぎないもの
  • 緊急度は低いが重要度は高いもの
    • 緊急の仕事を押し付けるな
    • 重要でない仕事を押し付けるな → 「なぜ重要なのか」の背景を踏まえて依頼する
  • トラブルが起きること前提で、フォローできる範囲内に留める

主な方針は以下のどちらかになるはず。

  • 簡単な作業から徐々にステップアップするチュートリアルモード(人材育成の書籍や社内制度はこちらを前提としたものが多い)
  • 最初から高い目標を叩きつけるハードモード(急成長・表彰狙い)

最終的には同じところに着地するので、まぁどっちでもいいかと。

  • チュートリアルモードでもそのうち全工程を自ら推進してもらうようになる。
  • ハードモードでもやることは同じ:目的・制約の整理→作業分解→TODOリストを捌く→頻繁に軌道修正。

配属直後の登り方やコミュニケーションの取り方が若干変わるくらいですかね。 私はチュートリアルを突っぱねた派なので、同じような性格の人だと辛かろうということで方針を聞くようにしています。

「自走スキル」を身につけてもらう

一連のPDSサイクルを主体的に回すように促します。

  1. 自ら問題を見つける
  2. 自ら解決策を考える
  3. 自ら解決策を実行する
  4. 自ら実行結果をもとに振り返って次の手を打つ

自走さえできれば他のスキルは後から身につくので、この1つだけに絞ります。

スキル習得のために、ひたすら「あなたはどう思いますか?」を問い掛け続けます。

  • その上で、少しでも兆しが見えたら褒める。とにかく褒めまくる。メッセージング目的なので露骨で良い。
  • 内容の成否ではなく姿勢を評価する。成否はアンコントローラブルな部分があれど、姿勢は再現可能なので。
  • 褒めるときは、本人の前だけでなく、本人がいないところ、いろんな人が見ているところで褒める。

基本的にはミスを責めずに、サポートする方向で。

  • STEP1やSTEP2の筋が悪いのは経験や知識が足りないだけ。
  • 着手できないのはSTEP3のリードタイムが長いだけ。
  • アクションが失敗するのはSTEP4の一部。

というか自分自身も毎回スムーズにできるわけじゃないだろと自省しながら対峙する感じです。 逆に毎回スムーズなら、挑戦していないということなので、新入社員以下だという自覚を。

本人とのコミュニケーション

毎日30分の1on1を設ける → 少しずつ頻度を減らす。

  • 最初は個人タスクについて「やったこと」「よかったこと」「困っていること」を聞く。本人の抱える課題を検知する。
  • 徐々に、1on1で話した内容をチーム内にフィードバックするように促す。本人の困りごとは、本人がチーム内で相談して、チームでフォローしてもらう状態に持っていく。
  • チーム単位での動きに慣れてきたら「チームの状況」「何が1番の問題だと思うか」「どうしたらいいと思うか」を聞く。チーム内で介在価値を発揮してもらう。

注意点として「こういうところは良くなかった」の指摘は、他の人がいないところでやります。

  • 最初の方に1回だけ仕事のスタンス面について話すことがあるかないか。通過儀礼なので2度は言わないですが。
  • 去年の実例:影響範囲を考慮せず何となくのプルリク出す → 「これがそのままリリースされて顧客に届いたらどうなると思う?」
  • 軽微なミスはいちいち怒らない。ポカ避けをどう組み込むかが大事。上記の例も本来はシステムで防ぐのが望ましい。

基本方針は他メンバーとのコミュニケーションと同じで、気持ち丁寧に対応します。

関係者とのコミュニケーション

配属チームの他メンバーとも頻繁に会話します。

  • しつこいくらい何度でもフォローを依頼します。「大丈夫そうだった?」「困っていなかった?」を聞きまくる。
  • チームメンバーに対して「実は本人はこう思っているらしいよ」のフィードバックを繰り返す。特に若手メンバーは「全然気づかなかった」と返してくることが多い。
  • 新入社員を気にかけてもらうことでチームとしてフォローしやすくなる。リーダーや後輩指導の経験が少ない若手メンバー自身の成長にもつながる。逆にリーダーと新人の1対1の関係に終始すると、チームの成長機会を損ねてしまうので注意。

新入社員と仲が良いチーム外の先輩に、本人の相談相手になってもらいます。

  • チーム内のメンバーやリーダーでは引き出せない本音もあるだろうということで。同様に、男性ばかりのチームに女性が配属されたら、女性社員に声を掛けてもらう、といった観点もありますね。相性などもあるので色々配慮します。
  • 「相談相手で〜す」というより、それとなく話を聞く存在になってもらいます。内容をフィードバックするかどうかは相手の判断に任せます。私の言動を変える必要がある場合は、本人の代弁者として叱ってもらいます。
  • わざわざ依頼しなくても相談相手になっていることもあるし、余計なお世話だろ感があるが、念には念を。本人にとっては人生で初の仕事なので、最初のほうは多少お節介すぎるくらいでよかろうという思想。これが続くとうざい(というかキモい)ので、ある程度自走できるようになったら基本はノータッチ。

上長との1on1で報連相しておく。

  • 新人の担当業務と状況、私の新人に対するコミュニケーション内容について話します。
  • 進め方やコミュニケーションの取り方についての相談に乗ってもらいます。問題があれば指摘をいただきます。
  • 上長経由でコミュニケーションしたほうがいい場合などは依頼する。特に、偉い人が新入社員の仕事ぶりを直接見れない距離であれば「がんばっているらしいじゃん!いつも話を聞いているよ!」と一声掛けるだけで、心理的安全性が担保されることもあります。

連携が多い部署には挨拶しておく。

  • 受けられるサポートが多いに越したことはないので。
  • その業務で少しでも成果を出したら「配属1ヶ月でこんな成果を出せました!」的な感じで一緒に祝う → 「部署は違うけど手伝ってよかった」のポジティブサイクルに巻き込みます。

なお、リーダー(私)の観点から見て、最も大切なことは「私自身の言動が糞だったときに、新入社員が他のひとに相談して、私をぶっ刺せるルートを確保すること」だと思っています。

  • これがないと間違っていたときにフィードバックを受け取れない=改善できない。
  • 逆にこれさえ確保できていれば、多少のミスはどうにかなる。
  • 人と人の話なので正解はない → ノーミスは無理 → ミスを誰かがカバーする方向で備える。

まとめ

色々書いたけど、基本的には「なるべく自分事として受け止める」「1人で背負いこまない」というのを、丁寧に徹底しましょう、というだけの話です。 1人1人やり方は違うので正解はないかもしれませんが、最初のほうでコミュニケーションに手を抜くと、後々面倒になるのかなとは思います。

おわりに

あとあれですね、年度末の新入社員プレゼンで「このリーダーのもとで働けてよかった」的なことを言ってもらえると、結構嬉しかったりしますね。

部下育成の教科書

部下育成の教科書

XP祭りで開発高速化の話をしました #xpjug

概要

XP祭り2017に参加して「新米エンジニアがレガシーシステムを死に物狂いでグロースハックした話」というタイトルで発表しました。

イベントについて

アジャイル分野の方々が参加するイベントだそうです。 他の方々の発表は以下のページにまとまっています。

XP祭り2017

発表スライド

当日の資料は以下になります。

すでに新米ではないのですが、当時を振り返るとアジャイルプラクティスを(結果的に)適用していた!ということで、この機にケーススタディとしてまとめてみました。

CfP内容(一部抜粋)

グロースハックプロジェクトでの試行錯誤を共有します。

10年物のレガシーシステムにおいて、120の開発案件を捌き、 4ヶ月でユーザーアクション数を2.8倍にしました。

1つ1つボトルネックを愚直に解消していくことで、 気付いたらアジャイルのプラクティスが適用されている状態になりました。

http://xpjug.com/xp2017-session-a3-2/

ざっくり概要

  • ステークホルダー
    • 多様なステークホルダーからの五月雨の依頼に対して、結果的にスクラムのような開発プロセスで対応することになりました。
    • 1個流しで案件を捌き、その過程でリードタイムに影響を与える阻害要因(ボトルネック)を特定・排除することで、フロー効率の改善を図っています。
  • スキル
    • 新米状態から素早く一人前になるために、アーキテクト・プロダクトオーナー・リーダーのように振る舞いました。
    • 当然ながら上手くいかない→「何が足りないか」を把握できる→その差を埋める、を繰り返すことで、ハイスピードでスキルを向上させることができました。
  • システム
    • レガシーシステムに対して改善サイクルを回すために、まずはGit/Jenkins/SonarQubeといったツールを導入して、最低限の開発環境を整えました。
    • その上で、過剰な設計書フォーカスからソースコードフォーカスに移行したり、「よい設計」の共通認識を揃えながら徐々にシステムの複雑度を解消していきました。

ビブリオバトル

LT形式で書籍を紹介しあうコーナー。せっかくなので出てみました。

「システムは作って終わりではない」ということで、マラソンに関する科学がメタファー(あるいはアナロジー)として参考になるのではないか!と『マラソンの練習法がわかる本』をお勧めしました。

感想

  • 良い意味で変な人が多かったです。女装率が高い。LTは笑いすぎて腹が痛かった!w
  • 運営者の法被(?)が祭り感あって良いですねー。
  • 初めて来た人や遠くから来た人を優先して書籍プレゼントする、といった配慮が素敵だなぁと思いました。
  • 内容面で新しい発見は特になかったかなぁというのが正直なところです。プラクティスや原理原則はある程度固まっているように見受けられるので、パラフレーズのネタを増やすよりも、「いかにエンジニアの枠を超えたケーススタディを積むのか」が求められているのかもしれないと思いました。私が言えた話ではないのですが。

終わりに

運営者・発表者・参加者の皆様、本当にありがとうございました!

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

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

PyConJPでデータ分析基盤とチーム文化の話をしました #pyconjp

概要

PyCon JP 2017というカンファレンスに参加しました。 Day2の最終セッションにて「SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsした話」というタイトルで発表しました。

f:id:yuzutas0:20170912194610j:plain

イベントについて

実施風景や発表内容

togetterや他の参加者のブログで良い感じにレポートされているので省略。 「こういう観点の感想もあるのかぁ」といった発見があり、読んでみると結構面白いです。

他の方の発表を聞いて

よかったです! 小学生並みの感想ですが!

  • 分析ネタ系・作ってみた系:やっぱり面白い。ニコニコ学会や自由研究に通じるものがある。こういうの大好き。
  • 足りない機能をハックする系・中身を読み解くぜ系:プログラミング言語を触るってこういうことだよなー、みたいな良さ。

あとLT聞いて思いついたんですけどPythonで実装した彼女とマッチングするWEBサービスを(略)

とまぁ、技術カンファレンスは今回が初参加で、最初はどうしたものかという感じでしたが、想像以上に楽しめました。

発表について

スライド

当日の資料は以下になります。

CfP内容(一部抜粋)

多様な部署・職種が関わる大企業において、どのような目的・用途・制約が与えられ、そのためにどのようなシステム・プロセスを採用したのか共有します。

プロダクト開発におけるデータ活用の指針・参考事例を持ち帰っていただきます。少しでも多くの開発現場がPythonという武器を手に、データを最大限に活用し、世の中に良いプロダクトを提供する助けになれたらと思っています。

https://pycon.jp/2017/ja/proposals/vote/159/

アジェンダ

  • 分析基盤をDev&Opsする
    • データ利用のユースケース
    • 分析基盤が必要となった背景
    • 設計ポリシー・技術選定
    • データフロー(収集>蓄積>加工>活用)
    • 構築プロセス
  • データ駆動文化をチームに装着する
    • Measure:効果測定と開発工程
    • Learn:顧客理解とSECIモデル

いただいたコメントなど

ありがたいことに色々とコメントをいただきました。

「タイトルだけ見てスルーしてた」

「文化の話いいね」

言われてみれば。 タイトルから中身を想像できないですね……。 どういうのが良かったんだろうなー。

「Jupyterはバッチ処理を試すのに相性が良い」

なるほど。 明文化できていませんでした。 確かにそういうことですね!

「朝の何時までにデータを疎通しなければいけない!みたいな話を伺いたい」

サービスレベルとオペレーションレベルを設計・運用しています。 詳しくは以下を参照いただければと。

yuzutas0.hatenablog.com

今回の質問であれば、バッチ処理の機能要件に該当するトピックとなりますね。 このあたりはいわゆるSREトピックとして、他のシステムと同じように運用・改善を行なっています。

SREやDev&Opsとタイトルに付けた割には、構築後の運用保守に対する言及が少なかったのはミスでした。 「それっぽいシステムを作るだけなら誰だってできるよ!大変なのはその先だろうが!」と言われたらそりゃそうだ、という感じです。

まさにGood Questionというやつですね。終了直後にわざわざ話し掛けてくださいました。

補足(蛇足?)

システム面

  • 話を聞いた人は「そこまで大したシステムではない」と思ったはずです。自分でもそう思います。ただ、大したシステムは必要ないと考えています。だからこそ簡単に書けて便利なPythonを技術選定しました。
  • 半年後には違う姿になっていると思います。システムは生き物と同じで日々変わるので。特にワークフローエンジンの運用保守については強い課題意識を持っています。むしろぜひ助言が欲しいくらいです。
  • 「大規模データだ」「他と比べて大変だ」と言うつもりはありません。たかだか数年程度の若いサービスなので。
    • 技術制約として「この規模のデータだとN/Wレイテンシがボトルネックになる」という話はしましたが。
    • 本当にヤバいやつは「みんな死ぬしかないじゃない!」状態だったりしますよね。未踏出身の先輩が20年物のシステムを数年掛けて少しずつ直すのを見て「こういう人たちには敵わないなぁ」と尊敬しております。

プロセス面

  • エンジニア向けなので「システムを直す優先順位が1番低い」と伝えました。実際にそう運用しています。ただ、ビジネスサイドには別の伝え方をすることもあるので悪しからず。「ボトルネック発生時は他作業を止めてシステムを直す」(その頻度は少なくない)という但し書きが伝わるかどうかで切り分けています。
  • 終わってから気付いたのですが、1番リードタイムを費やしたのは(着手前の)「工数確保のための根回し・調整・擦り合わせ」で、要するに社内政治でした。さらに泥臭い話になりますなぁ。そこまでやって初めて「業務」になるわけですからねぇ。
  • 改めて振り返ると「言うは易し行うは難し」だと思いました。今回の構想は、システムもプロセスも文化装着も、1時間のホワイトボードミーティングで描いた戦略がベースとなっているのですが、それを実現するのに半年以上を費やしております。

メイキング裏話

ひたすら試行錯誤

  • 100枚超えのスライドを5回丸々作り直した。
    • 伝わる構成にならなくて苦労した。
    • もともと扱うトピックが広すぎたというのはある。
  • 10回リハーサルした。あのザマでしたが。
  • 20人からフィードバックをもらって細部を修正した。
    • 例:「楽して」が「楽しい」に見えるので「ラクして」に書き直す。

準備面での振り返り

  • 【Keep】スライドが真っ白の時から毎日リハーサルしてフィードバックをもらい続けたこと。
  • 【Problem】スライドに全部書き出してから余計な箇所を削る方式で始めたこと。これは無理があった。物量が多いので修正がキツい。単純にバッチサイズの問題。
  • 【Try】結局は「30秒だったら何を話す?」から考え直して今の構成にした。「じゃあ1分だったら?」「3分だったら?」と広げていった。最初からこのやり方を採用すべきだった。

当日の反省など

反省点多し。マイクに声が入っていない、時間はオーバーする、余計なことを言うの三拍子。 そんな中で最後までお付き合いくださった方々、声を掛けてくださった方々には感謝の気持ちでいっぱいです。

最後に

ベストトークアワードで優秀賞という栄えある評価をいただけました。 私自身の拙い発表というよりは、チームの仕事が認めてもらえたのだと解釈しています。

何はともあれ、運営者・発表者・参加者の皆様、本当にありがとうございました!

PythonユーザのためのJupyter[実践]入門

PythonユーザのためのJupyter[実践]入門

スクラム開発チーム立ち上げの失敗談を話しました #GWD_Nulab

概要

Nulab様が主催する Geeks Who Drink in Tokyo - Agile Team という勉強会に参加しました。 なるべく具体的なケーススタディ(特に失敗談)を共有したかったので「スクラム開発チームの立ち上げでアンチパターンを踏みまくった話」という発表をしました。

イベントの様子

イベント風景や発表内容は、以下のブログでレポートされています。

モブプログラミング?アジャイル?自分たちに最適な開発手法を本気で考えてみた「Geeks Who Drink Agile Team Edition」をレポート! | ヌーラボ

会場の合いの手スキルがやたら高くて面白かったです。

発表資料

当日のスライドは以下になります。

PEXELSにラグビーの画像がなく、アメフトでごまかしたことについては、深く反省しております。

内容

かいつまんで説明します。 詳しくはスライドを見てもらえると嬉しいです。

この話の位置付け

  • とあるスクラムチームの立ち上げでアンチパターンを踏みまくった話を共有します!
  • 反省を活かして、それ以降のチーム立ち上げ時には、比較的スムーズに話を進められるようになりました!
  • 「失敗談」と「こうすべきだった」を共有することで、同じように困っている方のヒントになれたらと思います!

アジェンダ

  • チーム立ち上げの背景:モバイルアプリ開発チームを立ち上げました!
  • アンチパターン
    1. 改善とビジョン:目指すゴールの共通認識(=Good/Badの基準)がないと改善のやりようがありません!
    2. 課題とフォーカス:解決したい課題を明確にせずに「アジャイルっぽいやり方」をやろうとしても本末転倒です!
    3. 出荷とロール:下手に役割分担するのではなく、全員が優先順位の通りに行動することで、ボトルネックが可視化されます!
    4. 作業とストリーム:1つのチームで1つのプロダクトの1つのゴールに向かって作業しないと、綻びが生じてしまいます!
  • スクラム開発:「What」と「How」を見直す → 継続的な「課題発見」と「課題解決」による進化を支えるフレームワークだと解釈しています!

スライドの一部抜粋

f:id:yuzutas0:20170902200832j:plain

f:id:yuzutas0:20170902200848j:plain

f:id:yuzutas0:20170902200905j:plain

f:id:yuzutas0:20170902200919j:plain

f:id:yuzutas0:20170902200931j:plain

補足

誤解が生じないように補足すると「これがスクラムだ」と断言したり押し付ける意図はありません。 正直なところアジャイルスクラムという言葉を使う必要さえないと思っています。

あくまで位置づけとしては

  • ビジネス価値の最大化が目的である
  • その過程でチームビルディングが必要となる
  • 開発プロセスフレームワークとしてスクラムを採用する
  • 運営の過程で何かしらの問題は起きる(コンテキストによって違いはある → とはいえ類型もある)
  • なのでアンチパターンや失敗談を起点にして知識を整理した

という感じです。

ケーススタディとして含めなかった話

なぜスクラムを採用するのか

中長期のプロジェクト型開発(ウォーターフォール)は必要悪だと思っています。

  • 事前に定めたQCDS目標を達成するために、学習頻度を犠牲にしがちだからです。
  • 半年間のプロジェクトなら、半年もフィードバックを得られない(仮に得ても活かせない)ことになります。

可能な限りイテレーションを回せるプロセス設計が望ましいです。 そうなると、何らかのアジャイルプラクティスを(結果的にであれ意図的にであれ)適用することになるでしょう。

特にスクラムは型が明確で「最初にこれをやりましょう」の会話がしやすいです。 それゆえに意図の解釈や議論があちこちで起きてしまいがちなので、ビジョンの補完やフォーカスの徹底、ロールやストリームの考え方を装着することが必要になります。

また、スクラムデファクトスタンダードゆえの恩恵をもたらしてくれます。 困った時に参照できるリファレンスや知見が世の中に溢れているのです。 新規参画メンバーに話を通しやすい、別の場所に移っても学びを活かせる、といった利点もあります。

チーム立ち上げ時に使う資料

ホワイトボード

下の図を描きながら、スクラムとは「What」「How」の「問題発見」「問題解決」を繰り返すフレームワークだと伝えます。

f:id:yuzutas0:20170902200950j:plain

参考図書

最初に読んでもらう → 必要に応じて輪読会をします。

URL

いちおうチームに共有しておく → 結局自分で見ることが多いですが。

  • Scrum Guide:邪道ですが「スクラムガイドには書いてないので、自分たちでやりやすい方法でやってみたらどうかな!」と言うために参照することがしばしばあります。
  • Ryuzee.com:困ったときによく見ます。

アジャイル博士になることがチームの目的ではないので、提供する情報量は最小限に絞ります。 なるべく余計なことを考えずに、目の前の問題に集中してもらうことが大事だと繰り返します。

感想

自発的に継続進化できるチームの構築は、基本であり奥義でもあると改めて思いました。 顧客価値にコミットできる良いチームを作っていきたいです。

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術