#今日の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アプリ。 仕事中、ゴールを忘れて暴走したり、議論でヒートアップしやすいのでその防止用に開発中。 公開予定は今の所なし。

#今日の30分 ログ

ツイート

#今日の30分 リーンスタートアップ1-4。実験についての詳細。例を多く出してる。仮説を立て、その仮説を検証するために必要な最小限の製品を出し、得られた結果を仮説と比較し、その差分を元に戦略を見直す。うん、このあたりはフィードバックループの話っぽいな。

— ざっきー dev (@zakky_dev) 2018年5月14日

#今日の30分 リーンスタートアップ2-5。構築、計測、学びのループを実際に行うときの概要かな。「何故から始めよ」という感じの内容も出てきて、自分の知識と結びつくような感じ。そして「リーン」というだけあって、トヨタの話が出てくる。

— ざっきー dev (@zakky_dev) 2018年5月15日

#今日の30分 +5分。リーンスタートアップ2-6まで。MVPの話。プロダクトが実現されたときどうなるかを検証することが重要なので、実際のプロダクトではなく、動画や人力で試す方法もある、というのは目から鱗という感じ。言われてみればその通りだなー。重要なのは仮説の検証……この場合価値仮説かな？

— ざっきー dev (@zakky_dev) 2018年5月16日

#今日の30分 +8分。リーンスタートアップ170ページまで。実験の結果から得られた定量的な数値をベースとして、理想に近づけていく活動の話。最小から始め、仮説を立て、検証し、その結果をベースに次の仮説を立て……今までと言っている事自体は同じような感じっぽい？

— ざっきー dev (@zakky_dev) 2018年5月17日

#今日の30分 +11分。リーンスタートアップ2-7章読了まで。評価基準の策定について。一見正しく思える評価方法ではなく、次の行動に繋げることができる評価方法を考えること。その方法論として、コホート分析やスプリットテストが説明されている。そして評価基準の3つの「しやすさ」の話。

— ざっきー dev (@zakky_dev) 2018年5月18日

#今日の30分 -8分。リーンスタートアップ219ページまで。ちょっと眠すぎて集中できない。読んでもダメっぽいのでここまで。内容はピボットについて。革新会計を採用した場合のピボットのを考えるべきタイミングや、ピボットする上でどのような方法や方向があるかの提示。

— ざっきー dev (@zakky_dev) 2018年5月19日

#今日の30分 +2分。リーンスタートアップ2-8まで。方向転換の検討時に参加すべき人、注意すべきこと。そして方向転換の種類について。んー、価値捕捉型の方向転換がちょいとイマイチ理解できなかったな……。

— ざっきー dev (@zakky_dev) 2018年5月20日

レトロスペクティブ