#今日の30分 ログ

ツイート

#今日の30分 -4分。Running Lean8章。課題インタビューで取り組むことにした課題の解決方法の検証。簡易的なデモを作り、それがその課題をどのように解決するかを見せ、もっと良い解決方法や、不要な部分を削除して調整していく。

— ざっきー dev (@zakky_dev) July 2, 2018

#今日の30分 +11分。Running Lean 9,10章。最初のバージョンをリリースするタイミングで重視すべきことと、定量的データの計測について。何を作るか、どのように体験してもらうか。

— ざっきー dev (@zakky_dev) July 3, 2018

#今日の30分 Running Lean11,12章。作ったMVPが正しいか。顧客のライフサイクルを観察し、何を見るべきか。課題、ソリューションについて聞き、MVPを作ったら、次はその検証。そして、MVPを投入したことで、顧客がどう反応するかの観察。

— ざっきー dev (@zakky_dev) July 4, 2018

#今日の30分 -3分。Running Lean13章。機能追加、というか製品の修正について。機能を追加するときに考慮すべき事項、追加判断をするワークフロー。顧客の要求をそのまま実装するのは控えたほうがいい、という話。

— ざっきー dev (@zakky_dev) July 5, 2018

#今日の30分 +12分。Running Lean14章、15章。事業を拡大していく上で考慮すべきことの話。製品がなくなったときに4割の人が「非常に残念」と回答する状態になれば、ある程度成功が見込める。また、サービスの種類によってはアクティベーション率、定着率が4割でもいい。

— ざっきー dev (@zakky_dev) July 6, 2018

#今日の30分 Running Lean207ページまで。情報量が多い。スタートアップ開始時に考慮すべきこと。資金調達が早いとムダを生む話と、SaaS製品を売るときの話。SaaSのフリーミアムについての考察が面白かった。フリーミアムはマーケティング。なるほど。

— ざっきー dev (@zakky_dev) July 7, 2018

#今日の30分 +5分。Running Lean読了。リーン・スタートアップを読んだ前提で話が進むので、そっちを先に読むべきな印象。内容としては、リーン・スタートアップを実際にやってみた人の実践例と、その人がうまくやるために作り出したツールや思考方法の紹介、かな。

— ざっきー dev (@zakky_dev) July 8, 2018

レトロスペクティブ

前回の結果

• カンバンにないタスクはやらない
  • 85%。増加傾向。
• 1日あたり最低3つ以上の技術関係記事を読む
  • 13。来週の様子を見て、数を減らすか検討。
• 今日の30分 とは別枠で「カイゼン・ジャーニー」を読み直す。
  • 1部読了。

今回の実験

• 1日ごとにTryの達成状況を確認する。
  • 目的: Try達成率と、その日にあったことの関係性の確認のため。
  • 計測方法: Twitter投稿回数。
• カンバンにないタスクはやらない
  • 目的: タスクの見える化による進捗状況の意識のため。
  • 計測方法: カンバンのタスクに使った総時間を追記して、その総計を調べる
• 1日あたり最低3つ以上の技術関係記事を読む。
  • 目的: 新しい知識の入荷のため。また、小さな成功体験の積み重ねのため。
  • 計測方法: 読んだ技術関係記事の数を記録。
• 「今日の30分」とは別枠で「カイゼン・ジャーニー」を読み直す。
  • 目的: 現場をカイゼンしていく上で参考にするため。
  • 計測方法: 読んだページ数。

#今日の30分 ログ

ツイート

#今日の30分 -7分。Running Lean目次まで。リーンについて別方面から見てみるつもりで手を出してみる。リーン・スタートアップと同じ系統で、スタートアップについての本。顧客開発についての話もあるらしい。たまに単語を見かけるので気になってはいたし、ちょうどいいかも。

— ざっきー dev (@zakky_dev) 2018年6月25日

#今日の30分 -2分。Running Leanの1章。Running Leanの手順と概要の話。常々思うけど、このあたりの話好きだな自分……。それはさておき、個人的にはリーン・スタートアップの復習みたいな感じになっている。リーンキャンバスは初めて見たけど面白いなー。

— ざっきー dev (@zakky_dev) 2018年6月26日

#今日の30分 -10分。ちょっと眠気が限界……。書籍執筆を実例にした、Running Leanの概要説明。やはり「誰が何故」それを求めているのかや「どのようにすればその【何故】を達成」何故できるのか。その課題は解決に値するか。

— ざっきー dev (@zakky_dev) 2018年6月27日

#今日の30分 +10分。Running Lean3章まで。リーンキャンバスの書き方と書く順番。最初から課金させることと、損益分岐点を考えるあたりが面白い。自分にはどうにもこのあたりが欠けている。いくら稼げればいいのか、というあたりの視点というか。

— ざっきー dev (@zakky_dev) 2018年6月28日

#今日の30分 +16分。Running Lean5章まで。ビジネスモデルの優先順位付けの方法の紹介と、ビジネスモデルの実験の準備の話。リーンキャンバスを複数作る、か。あー、このあたりってリーンソフトウェア開発にあったオプション思考とかそっちの話なのかなあ……。

— ざっきー dev (@zakky_dev) 2018年6月29日

#今日の30分 +3分。Running Lean6章。顧客インタビューについての話。著者が「俺も内向的だよ！」と言い切っていて「だから知り合いからやろう！」とつないでいるあたり説得力ある。うん、見知らぬ誰かにインタビューとか怖いよね……。

— ざっきー dev (@zakky_dev) 2018年6月30日

#今日の30分 -7分。Running Lean7章。解決しようとしている問題が本当に解決すべきなのか、対象としている顧客が本当に存在しているのか、作ろうとしている製品がない状態ではどう解決しているのか。どうなって欲しい、ではなく、何に困っている、に着目すること。

— ざっきー dev (@zakky_dev) 2018年7月1日

レトロスペクティブ

前回の結果

• カンバンにないタスクはやらない
  • 6割程度。ただし週の終わりになるにつれて増加傾向。来週も様子見。
• 1日あたり最低3つ以上の技術関係記事を読む
  • 約120%。持続できそう。このましばらく継続してみる。

今回の実験

• カンバンにないタスクはやらない
  • 計測方法: カンバンのタスクに使った総時間を追記して、その総計を調べる
• 1日あたり最低3つ以上の技術関係記事を読む
  • 計測方法: 読んだ技術関係記事の数を記録
• 今日の30分 とは別枠で「カイゼン・ジャーニー」を読み直す。
  • 計測方法: 読んだページ数

#今日の30分 ログ

ツイート

#今日の30分 +13分。リーンソフトウェア開発204ページまで。統一性の定義と、認知統一性の話。このあたりのモデルの話好きだな。概観モデルを用意しておくのも感覚とあってる。明日はコンセプト統一性のあたりを読むことになる。これは楽しみだ。

— ざっきー dev (@zakky_dev) June 18, 2018

#今日の30分 +2分。リーンソフトウェア開発218ページまで。コンセプト統一性とリファクタリングについて。統合的問題解決はフィードバックの高速化がメインかな。イメージしやすいのはペア作業かもしれない。問題の発生と解決が最高速に行われるのはペア作業やモブ作業と思うんだ。

— ざっきー dev (@zakky_dev) June 19, 2018

#今日の30分 -7分。リーンソフトウェア開発6章終わり。テストの話。頻繁にテストを実施すること、テストを自動化すること、受け入れテスト(顧客テスト)を作りデモで使うこと。役割としてどう動くべきか、正しく動いているか、現状がどうなっているのかを示す。

— ざっきー dev (@zakky_dev) June 20, 2018

#今日の30分 +2分。リーンソフトウェア開発241ページまで。どうにも読みづらい……。大まかには全体最適の話。組織が何故局所最適に陥りがちなのかの解説と、いくつかの解決方法の提示。局所最適になりやすい理由の一つとして、成果の計測方法が挙げられている。やはり会計周りを知るべきか。

— ざっきー dev (@zakky_dev) June 21, 2018

#今日の30分 リーンソフトウェア開発253ページまで。企業間契約の話。読めた部分は一括請負契約と作業請負契約の2つ。顧客側、ベンダー側それぞれにとってのメリットデメリットを解説している。このあたり難しい。何しろ今までまったくやったことなかったからな……。

— ざっきー dev (@zakky_dev) June 22, 2018

#今日の30分 -2分。リーンソフトウェア開発261ページまで。進捗が悪い。契約周りは整理に時間がかかる。どうにもピンとこないんだよな……。

— ざっきー dev (@zakky_dev) June 23, 2018

#今日の30分 +1分。リーンソフトウェア開発読了。昨日までに引き続き、契約の種類の話と、紹介されたツールの使用について。全体を通してみると、五割も理解できていたら良いほうだな、これ……あと2,3回は読み返すか、別の本を読まないと自分のモノにならない。

— ざっきー dev (@zakky_dev) June 24, 2018

レトロスペクティブ

前回の結果

• カンバンにないタスクはやらない
  • 状況により実施できず。今回も続行する。

今回の実験

• カンバンにないタスクはやらない
  • 計測方法: カンバンのタスクに使った総時間を追記して、その総計を調べる
• 1日あたり最低3つ以上の技術関係記事を読む
  • 計測方法: 読んだ技術関係記事の数を記録

#今日の30分 ログ

ツイート

#今日の30分 +8分。リーンソフトウェア開発3章。決定をできるだけ遅らせる上で、決定するときに考慮すべきことと、決定するときに使えるツールの話。最終責任時点、これ、そのタイミングを見極めるの難しそうだなー。慣れが必要になりそう。

— ざっきー dev (@zakky_dev) June 11, 2018

#今日の30分 +3分。リーンソフトウェア開発122ページまで。迅速に提供することのメリットと、そのために有用なツールとしてのプルシステムの話。これまで読んできた本の話にも繋がることが多いな。「何故」から始めよ、という言葉に置き換えできる。余計なものを作らず、必要なものを最低限作る。

— ざっきー dev (@zakky_dev) June 12, 2018

#今日の30分 +3分。リーンソフトウェア開発134ページまで。待ち行列理論と遅れのコストの話をちょっとだけ。待ち行列理論、ORの話だったんか。よく聞く頻繁なリリースもこのあたりから来てるのね。そっちのほうが効率がいい、とORで決着ついてるなら、それを理由に説得材料として使えそう。

— ざっきー dev (@zakky_dev) June 13, 2018

#今日の30分 +3分。リーンソフトウェア開発151ページまで。速度がビジネス価値に与える影響の計測のために、単純な損益モデルを作り、トレードオフを導く話。あとトップダウン方式の開発改善プログラムの例の説明。

— ざっきー dev (@zakky_dev) June 14, 2018

#今日の30分 +10分。リーンソフトウェア開発169ページまで。プロセス改善はボトムアップ的にやると効果的である話と、メンバーのモチベーションの話。
プロセス改善の話、ボトムアップ的にやるのはいいのだけれど、これ局所最適とかになったりしないのかな。気になる。

— ざっきー dev (@zakky_dev) June 15, 2018

#今日の30分 +4分。リーンソフトウェア開発178ページまで。チーム開発で必要、あるいは生じていくリーダー的なロールの話。アプリケーションドメインとソリューションドメインの両方に精通した人や、チームが円滑に開発できる状況を整える人。なんとなくPOとSMを思い出す間感じ。

— ざっきー dev (@zakky_dev) June 16, 2018

#今日の30分 -10分。5章読了。専門知識を共有したり、使う方法の話。文書では伝えきれないことがあるので、口頭で伝えなければならない。このあたりは感覚と一致する。自分の場合、ちょっと口頭に寄りすぎているけれど。

— ざっきー dev (@zakky_dev) June 17, 2018

レトロスペクティブ

前回の結果

• 特定日までにやるべきことをはっきりさせ、必要なタスクを洗い出す。
  • 0回。これはひどい……。

今回の実験

• カンバンにないタスクはやらない
  • 計測方法: カンバンのタスクに使った総時間を追記して、その総計を調べる

#今日の30分 ログ

ツイート

リーンソフトウェア開発

「リーン開発の本質」を読み進める上で、事前知識が不足していると感じたため、一旦中断して「リーンソフトウェア開発」を読むことにした。

#今日の30分 +4分。リーンソフトウェア開発イントロダクションまで。リーン開発の本質を一旦中断してこっちを読むことにした。ちょっと事前知識不足が酷すぎた。今日の箇所を読む限り、こっちを先に読んだほうが身につきそう。リーン開発の本質はこの本の後にする。

— ざっきー dev (@zakky_dev) June 4, 2018

#今日の30分 +4分。リーンソフトウェア開発24ページまで。ムダの認識の話と、種類の話。7種のムダの話は本質のほうでも触れてたな。そしていくつかのムダはイメージしやすい。というか「この作業/ドキュメント、必要なんですか？」って聞いたこと何度か記憶にあるわ……。

— ざっきー dev (@zakky_dev) June 5, 2018

#今日の30分 +7分。リーンソフトウェア開発44ページまで。1章部分はVSM、2章部分はソフトウェア開発の性質と、それにともうなう問題の話。VSMの作業時間、待ち時間の話はなんとなく知ってたけど、これ、いざやろうとするとどっちなのかわからない時間があるんだよね……。

— ざっきー dev (@zakky_dev) June 6, 2018

#今日の30分 +10分。リーンソフトウェア開発56ページまで。フィードバックループの話。フィードバックを増やす方法として、イテレーションの話を持ち出している。あと、開発チームにはどのようなメンバーが必要かの話も若干。規模を小さくはするが、問題の解決ができるメンバーを揃えること。

— ざっきー dev (@zakky_dev) June 7, 2018

#今日の30分 +8分。リーンソフトウェア開発2章。イテレーションと同期、そして集合ベース開発について。集合ベース開発が印象深い。ちょっとこれは再読する。解決策の決定を遅らせ、複数の選択肢を試し、最良の解決策を考える。うーん、難しいよなあ……。

— ざっきー dev (@zakky_dev) June 8, 2018

#今日の30分 -15分。リーンソフトウェア開発82ページまで。眠気が酷すぎて頭に入らないので中断。無理。内容としてはコンカレント開発の概要。シーケンシャルな工程ではなく、どの工程も並列でやっていくこと、かな。ちょっと理解怪しい……メモもまともに取れてない。明日読み返すことにしよう……。

— ざっきー dev (@zakky_dev) June 9, 2018

#今日の30分 -6分。リーンソフトウェア開発94ページ。決定を遅らせる話。どうにもこのあたりは苦手らしく、進捗が悪い。事前にあらゆることを想定して決定しようとしてもムダなので、学習した成果をもとに判断したほうが効率的だ、ということだろうか。学習がベースになっているなー。

— ざっきー dev (@zakky_dev) June 10, 2018

レトロスペクティブ

前回の結果

• タスク開始時にゴールを具体的な文章に落とし込む
  • 65%程度。意識し始めたあたりからは書いていた。

今回の実験

• 特定日までにやるべきことをはっきりさせ、必要なタスクを洗い出す
  • 計測方法: タスクを洗い出した回数

#今日の30分 ログ

ツイート

「リーン開発の本質」を読んでいるものの、どうにも理解度が怪しい感覚がある。 「リーンソフトウェア開発」を先に読むべきかもしれない。

#今日の30分 +9分。リーン開発の本質2章。昨日読んでた箇所に引き続き、リーン開発の原則についての話。んー、ちょっと理解度怪しいぞ……なんとなく感覚としてはわからんでもないけど、言語化できない。つまりわかっていないってことだし、再読したほうがいいな……。

— ざっきー dev (@zakky_dev) May 28, 2018

#今日の30分 +1分。リーン開発の本質65ページまで。どうにも目が滑る……。それはそれとして、価値の話。リーンスタートアップに繋がる話や、狩野モデルの話もちょっとだけ出てきて「あ、これ知ってる！」って感覚が楽しい。

— ざっきー dev (@zakky_dev) May 29, 2018

#今日の30分 +5分。リーン開発の本質3章終わりまで。プロダクトをビジネス的に成功させる上で必要になるリーダーの話。このあたりはユーザーストーリーマッピングにあったトライアドを思い出す。ただ、どうにも目が滑る。この部分は読み返す必要がありそうだ。

— ざっきー dev (@zakky_dev) May 30, 2018

#今日の30分 +3分。リーン開発の本質96ページまで。ムダについての話。このあたりの話はなんとなく理解できるているような気がする。どのムダについても、他の書籍で言われていることの話っぽく感じる。バッチサイズを小さく、YAGNI、プロダクトチームの作成。

— ざっきー dev (@zakky_dev) May 31, 2018

#今日の30分 +19分。リーン開発の本質4章終わりまで。昨日から続いてムダの話。あとVSMの話。ありがちなVSMを例にして、どういったところが問題になっているかを解説していた……と、思う。ちょっと眠気がひどすぎて頭に入っていない。これは再読必須ですね……。

— ざっきー dev (@zakky_dev) June 1, 2018

#今日の30分 +2分。リーン開発の本質127ページまで。顧客へのプロダクト提供速度と、どこで遅延が発生するのかを考える話。VSMの始点から終点までにかかる時間を短くするためにバッチサイズを小さくする、みたいな感じだろうか。待ち行列理論調べたほうがいいかもなー。

— ざっきー dev (@zakky_dev) June 2, 2018

#今日の30分 -1分。リーン開発の本質5章。サイクルタイムの短縮についての話。プルスケジューリングの中で、コンセプトからキャッシュへの変換過程を見える化する話が面白かった。どのような工程があり、その工程ごとにどのような条件でフィルタするのか。

— ざっきー dev (@zakky_dev) June 3, 2018

レトロスペクティブ

• タスク開始時にゴールを具体的な文章に落とし込む
  • 計測方法: ゴールを文章化したタスク数 / 着手したタスク数
• レトロスペクティブで考えたTryは次週のレトロスペクティブで達成できているか確認する

#今日の30分 ログ

ツイート

リーンスタートアップ

#今日の30分 +10分。リーンスタートアップ3-9章。リーン生産方式と、リーンスタートアップにおける応用の話。バッチサイズの話が主で、プル型の話がちょっと。このあたりはアジャイルの話に通じるところもあり、イメージしやすい。

— ざっきー dev (@zakky_dev) May 21, 2018

#今日の30分 -4分。リーンスタートアップ3-10章。成長エンジンの種類と特性の話。粘着型とウイルス型はなんとなく想像つきやすいけれど、支出型がダメだな。もうちょい読み込んだほうがいいっぽい。個人的にはウイルス型が面白い感じ。なんというか、ねずみ算式なイメージを持った。

— ざっきー dev (@zakky_dev) May 22, 2018

#今日の30分 +5分。リーンスタートアップ3-11章。スタートアップが成長していくにつれて発生するスローダウン、というより直面する状況への順応プロセスについての解説。基本的には「5回のなぜ」の説明。この方法、著者も言っているけれど、難しいよねえ。すぐに「5回のだれ」になる。

— ざっきー dev (@zakky_dev) May 23, 2018

#今日の30分 +10分。リーンスタートアップ3-12章。イノベーションを達成する上で必要になる組織的特質と、社内スタートアップの場合に注意すべきことの話、かな。後者の話が難しい……大まかには社内スタートアップを始めることによって発生する障害とその対策、なんだろうけど……。

— ざっきー dev (@zakky_dev) May 24, 2018

#今日の30分 -8分。リーンスタートアップ読了。こりゃ昨日一気に読めばよかったかもしれん。それはそれとして、内容について。ちょっと自分にはまだ早いというか、現時点で必要か微妙な知識だったかな。スタートアップを始める人は読んでおいたほうがいいかも。

— ざっきー dev (@zakky_dev) May 25, 2018

リーンスタートアップ読了。 リーン開発の原則をベースにしたスタートアップ運営論みたいに感じた。

個人的には、検証された学習の話が特に有用。 この部分だけでもこの本を読む意味があった。

リーン開発の本質

#今日の30分 +27分。リーン開発の本質1章まで。リーンの歴史と概要の話。ジャスト・イン・タイムとか、ポカヨケとか、バリューストリームとか割と聞き覚えのある単語が多い。情報量多くて整理しきれていない感。詳細はおそらく3章以降になるので、そのへんが楽しみ。

— ざっきー dev (@zakky_dev) May 26, 2018

#今日の30分 -3分。リーン開発の本質2章36ページまで。リーン開発の核となる原則の話。ソフトウェア開発はその性質上経験論的に開発されるべきだ、という意図のあたりか面白い。あとは機能の作りすぎのムダの話。感覚的に使う機能と実装されている機能の差分は大きいと思っていたけれど、ここまでか。

— ざっきー dev (@zakky_dev) May 27, 2018

レトロスペクティブ

雑になってしまった。

「ツール」と言っているのは、最近趣味プロジェクトとして開発しているツールのこと。 具体的には一定間隔で設定したローカル通知を飛ばすiOSアプリ。 仕事中、ゴールを忘れて暴走したり、議論でヒートアップしやすいのでその防止用に開発中。 公開予定は今の所なし。