CBcloud社に業務委託で参画している山下です。普段はPickGoというプロダクトのバックエンド開発を中心に行っています。
アドベントカレンダー、何を書こうかなとメモを漁っていたらなかなかエモめな奴がワサっと出てきたので、せっかくなのでそれをそのまま乗っけてしまおうかなと思います(棚卸しも兼ねて)。ほぼメモ書きなので、乱雑乱文ご容赦ください。
本当に必要なものだけをリリースしたい
状況からスタートして目的との矛盾を見る
- 状況仮説 > 課題仮説 > 代替手段 > 目的とビジョンの確認 > 実行 > 振り返り が正しいループな気がしている
- 最初に目的を決めすぎると、状況を都合の良い解釈に導いてしまわないか
- または、すでに動いているプロジェクトで振り返りをしながら、目的と状況がずれていないか確認したい
- OODAループにおける「観察」の重要性
ゴールデンサークルと仮説キャンバス
- 仮説の一本筋は通っているか
- WHYは大事。だけど、WHYがエゴだけになっていたらダメな気がする
- For youのWHYになっているか？
More Effective Agileから
- 「完璧とは、付け加えるものがなくなった時ではなく、削るものがなくなったときである（サン=テグジュペリ)」
- Less is More
- OODAループ
- よく「観察」しよう
- 本当に私情は挟んでいないか？
- 「やりたいこと」をやろうとしていないか
- よく「観察」しよう
百食屋の経営哲学に学ぶ
- https://ix-careercompass.jp/article/894/
- 「作りすぎない」ことに重点を置いている
- 「完売したら早く帰れる」がインセンティブ
- 作った機能の7割は使われない我々の業界もここから学びたい
- リリースする量は先に決めて、もし時間が余ったらそれは仮説の検証とか自己研鑽とか休憩に充てるべき
ある視点
組織
「人の関係」があって「チーム」「組織」はワークしていく
- チームワークの7つの段階
- http://www.scholar.co.jp/workcollaboration/level/
- まずは雑談から始める
- 業務として雑談する
- 組織の成功循環モデル
良い組織には良い習慣がある
- 逆に言うと、良い習慣が良い組織を作る
必要以上に稼働率を上げようとしてリソースを使うのは無駄である
- 皿が空いているからといって、満腹なのにさらに料理を盛り付けても脂肪が増えるだけ
- 必要なのは、満足したという価値
- 人がいるからといって並行していくつも開発するのはコンテキストスイッチを増やすだけ
- 人が増えればソフトウェアがリリースできるわけではない
- やることのために人を増やすのではなく、本当にやるべきことを達成するためにやることを減らすのが先
結果ではなくプロセスに着目した評価
- 「トヨタのカタ」に大いにインスパイアされる
- ターゲット状態へどのように近づいているか
リーダーはなぜ必要か
- ホールネスを唱えるだけでは進まなくなる
- 「突破する」という意思を見せる
- 時に強引に
- この辺はJoy,Inc.を改めて読み直したい
マネジメントのアンチパターン「言ってることを真に受ける」
- Aさんが「Bさんは仕事ができないからチーム変えて欲しい」
- 実は全然そんなことはなく、Aさんは「自分が認められていない」と思っていた
- Bさんを異動させてもAさんの感情はおそらく解決されない
- 実は全然そんなことはなく、Aさんは「自分が認められていない」と思っていた
- 一般的なコーチングの領域は、「その人の望みを明確化し実現するように促す」こと
- ただ、個人の望みを知った上で対処すると、信頼される
開発プロセス
きみにグロースハックはいらない
正しいものを正しく作りたい
zoomはなぜ勝利したか（顧客開発と組織の視点）
タイムボックスを切る、その意味
- 細かくイテレーションを切ることで、
- 失敗を早めに検知する
- デプロイ負荷を下げる
- 疎結合を強制する
- 全員の集中力を上げる
- 「細かいサイクルを回すスピードを上げる」方がチームの練度が上がりやすい
- 頻繁なデプロイができている組織はどのように強くなったのか？
- LeanとDevOpsの科学
全ては顧客から始まる
- 我々は、顧客の状況、課題を理解し、それを解決する価値を届けたい
- 顧客が何を望んでいるかをいち早く理解することが必要
- その手段として、
- 仮説自体の正しさを検証する
- ユーザーインタビュー
- 他、各種サーベイ
- プレトタイピング
- プロトタイピング
- デザインスプリント
- ユーザーインタビュー
- 仮説自体の正しさを検証する
- どうしても仮説ではわからない時は、実際にリリースして確かめる(A/Bテストなど)
- どの方法であっても、いち早く理解するためにどうしたら良いか
- いち早くリリースするしかないので、
- スコープを狭める
- 最小機能(MVP)でのリリース
- CI/CDによって、リリースサイクルを早める
- CIが機能しやすくするための、
- クリーンアーキテクチャ
- TDD
- SOLID原則
- CDが機能しやすくするための
- Blue-Green_deploy
- コンテナオーケストレーション
- マネージドサービス
- サーバーレス
- アプリケーションの品質が高いほど早くリリースできる
- CIが機能しやすくするための、
- リソースよりもフロー優先
- とにかく早く、(できる限り)一個ずつ流す
- トヨタ生産方式からのインスパイア
- ペアプロ、モブプロ
- とにかく早く、(できる限り)一個ずつ流す
- スコープを狭める
- いち早くリリースするしかないので、
- そのような開発プロセスを指向するために、組織はどうあるべきか
- バックログへの起票は、カスタマーサクセスから始まる
CX DIVE 2019 AKI
(だいぶたっちゃったけどメモの供養ということで、特に印象に残ったことを書いておきます.CX DIVEは本当にいいイベントだったのでまたいつか復活してほしい)
以下、Keynote Session のまとめ。(登壇: クラシコム青木さん, コエドブルワリー 朝霧さん)
楽しむということにはビジネスとしての合理性がある
- 「やることを楽しむ」のを、ここ２、３年とても意識するようになった
- それ以前の10年は「やるべきこと、やらなければ前に進めないことをやっていく」段階
- その段階が終わって、「楽しんでやれることをやる」にシフトした方がワークすることを発見した
- 現場の熱量が上がる
- 最初は与えられた小さな予算の中で「どれだけ楽しめるか」を大事にやってみる
- 収益は気にしない
- 結果的に収支が合わないと、テンション下がって続けられないけど、そもそも現場がキャッキャしてないと意味な
楽しんだ上で、お客さんの期待値を超えるのが大事
- リリースしたものがちゃんとウケてもらえるようにする
- これができないと自己満足で終わる
- 期待値を超えると、自然に数字がついてくるようになる
- なので、「早くこれを出したい！！」ぐらいのテンションで今作れているか？を大事にしている
- やってる本人たちのモチベーション
- 好きなものを追求してる時のモチベーション
人間起点のものづくりをするべき
- 地ビールは、「ビールを売りたい」が先にあって、そこに地域振興を無理やりくっつけて'流行'にした結果失敗した
- そうじゃなくて、ビールの人と人をつなぐ力が面白そうというのを起点に動かしている
- 価値観、理想が近い企業とコラボする
- ビールが先にあって、一緒に地域を盛り上げる -> 結果、地域が世界にも注目される
- グローカル
やらないことを決めるというのも大事
- COEDOが事業継承した時は無駄なものがたくさんあった
- 全商品終売にして、新商品でリスタート
- 名前だけ残した (小江戸ビール から COEDOビール への変更のみ)
- 5種類同時販売 > その後10年は新しいものを出していない
- 何か出しても「どうせ地ビールでしょ」みたいに言われるので、違う方向に舵を切ると決めた
- どうやったらちゃんとしたものとして認識してもらえるかをとことん考えた
ブランドを立ち上げる時に、「誰に愛されたいか」を考える
- ブランドを作るときに「どうやったら愛されるか？」を考えがちだが、
- ネスカフェアンバサダーは、オフィスの人を愛することを決めた
- 「どう愛するか」ではなく、「誰を愛する（=誰を仲間にするか）」を決める
- 「この人たちが好き」というところから始める