恋愛にも効く！Running Lean　実践リーンスタートアップで学ぶエンジニアが明日からパワーアップする10のポイント

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

posted with amazlet at 13.01.05

アッシュ・マウリャ, 渡辺千賀 (解説), エリック・リース (編集), 角征典 (翻訳)
オライリージャパン
売り上げランキング: 7,063

実践リーンスタートアップを読了。これは、タイトルそのものの事業を始める人向けに十分注意すべきことが網羅されていている。

ワタシにとってのリーンスタートアップ
ワタシにとっても、幾つかの新規ソリューションを事業化したときに読めればよかったなーと想い、感じることが多かったが、時すでに遅し。その経験の後に内心でふりかえり、ふつふつとココロに留めていたことがそれで間違いではなかったと確認することができたし、ある部分はもう少し踏み込んでおかなければ同じ過ちを繰り返すことを突き付けられたような気分であることも事実で。

彼女・彼を作るのもリーンスタートアップ
ところで、解説で渡辺千賀さんが書いているように、第6章の

「最初は自分を売り込むのではなく相手の話を聞く」
「対象を絞り込む前に網を広く投げる」
「知り合いからはじめる」
「最初会うには中立的な場所を選ぶ」

というアドバイスが“彼女・彼いない歴＝年齢”の人にとってどれだけ役に立つことだろうか。

恋愛とは、お互いに自分の気持ちを聞いてもらえ、安心できる人を探すことだと思う。その相手はずばり“この人”とは限らないから、知り合いから知人を紹介してもらえたらいいなぁとまだ逢ったことのない人を想い、もし紹介してもらえたら、と知人だけを対象とするような行動を取って自分を縛らない方が将来の自分に良いに違いない。
そして、自らが行動して紹介をしてもらえたら、ニュートラルな自分から知ってもらった方があとあと楽に接することができるから、相手がどう取るかわからない自分のフィールドでない方が良いんだ、と、この実践リーンスタートアップから“恋愛”の方法論を学ぶことができるのだ。
＃すばら！

明日からパワーアップする10のポイント
この実践リーンスタートアップで気になってメモをした箇所は35あったけれど、その中でエンジニアが恋愛の他でも必ず役に立つと見立てた10のポイントを挙げるので明日から生かしたいですね。

01	優れた方法論にはフィードバックループがある　−そこから継続的な改善と学習を行う。	勘と経験と度胸には学びがありません。体系化してこそ。その体系化された方法論(＝しくみ)が優れているなら、そのしくみには“ふりかえり”のプロセスがあるものです。
02	プランAを文書化する　−ビジョンの中に「私」がいる。	エンジニアは顧客の頭の中のイメージを具体化することが仕事なのです。
03	「無駄」とは、実行すると資源を消費するだけで、何も価値を生まない活動のことだ。	価値のないことの作業は止めましょう。誰もうれしくはありません。もし、自分がその片棒を担いでいるなら、消費した分だけ後で自分の首が締まります。
04	顧客はあなたのソリューションに興味はない。興味があるのは、顧客自身の課題だ。	まったくそのとおりですね。顧客自身の課題が業務要件なわけです。ソリューションは実現する側のツールに過ぎません。
05	外部の意見を求める　−ビジネスモデルは最低でも自分以外の誰か1人と共有しなければならない/ 　具体的な話をする/ 　アドバイザーパラドックスに気を付ける	ビジネスモデルを自分の担当する業務のキーワードに置き換えてみましょう。自分一人の意見は単なる一人相撲でしかありません。ただし、共有した人の意見は自分の行動を縛るものではありません。どうするかは自分で決めるのです。
06	学習をはやめにしょっちゅう伝える	ここでの学習は実証で得たことを指します。得た経験は必要な人には頻繁に、早く共有しなければコミュニケーションリスクを引き起こします。
07	課題を理解していますか　−結果を週次でレビューする/ 　課題を洗練する/ 　顧客が使う言葉に注目する	プロジェクトにおいて課題管理は要です。その扱いにより未知のリスクを引き起こしかねません。自らの課題であっても顧客と共有するなら顧客にも理解できる言葉で表現しなければなりません。ましてや顧客の課題はプロジェクトを左右するリスクに発展しかねませんからその言葉や課題の意図を把握できなければなりません。
08	ソリューションのテスト　−デモは実現可能でなければいけません/ 　デモは本物に見えなければいけません/ 　デモは高速に反復する必要があります/ 　デモは無駄を最小化しましょう/ 　デモは本物に見えるデータを使わなければいけません	デモは自分が担当する仕事のアウトプットに置き換えて読みましょう。出来ないものはやるとコミットできないし、要求される品質を備えていなければならないし、不要な金メッキは要りません。そして、数字などのデータは本物である必要があります。
09	MVPの縮小化　−(Minimum Viable Product＝実用最小限の製品)/ 　...夢中になってMVPに不要なものまで取り込んでしまう。ムダを除いて学習を加速するには、製品の本質だけをモックアップにしなければならない。 MVPのスコープを削減するというのは、開発サイクルを短縮するだけではなく、製品のメッセージを希釈する不純物を排除することでもある。	エンジニアのいけないところは、本当は必要のないものまでシステムに実装してしまうところです。自分でシステムを“ハウルの動く城”にしてしまう。顧客にそれは業務要件から要らないものだと伝える労力より、やりますと安易に応え茨の道を選びたがる。←間違い。
10	かんばんボードで機能を追跡する　−目標/　仕掛品の上限/ 　バッファレーン/　機能はいつもで中止可能/ 　継続的デプロイ/　2段階検証/ 　課題を理解する(解決に値する課題か)/ 　ソリューションを決定する/　定性的に検証する/　定量的に検証する	ITエンジニアであるなら自分の作業は常に見える状態にしておかなければなりません。エンジニアリングなのです。実行前にプロセスを明らかにし、そのプロセスを追って今どこまで進んでいるか、なぜ滞留しているのかが見える状態にしなければエンジニアリングとは言えないのです。カンバンはそれ自体をやってみると本当に効果が実感できるしくみです。