_ リーンスタートアップを読んだ。

リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす [ エリック・リース ] 価格：1944円（税込、送料無料) (2018/11/26時点) 楽天で購入

だいぶ前にRUNNING LEAN を読んだのだけど、その時はリーンのことをよくわからずに読んでいたので、全然印象に残っていなかった。インタビューしながらキャンパスを埋めながら、事業とかプロダクトを作っていく方法だと思いこんでたと思う。
ということで、ちゃんと原典（？）を読んでおこうと思ったのが、読む切っ掛け。

この本でのリーンは事業とプロダクトを無駄なく作るための方法として、トヨタのリーン生産方式を参考に考え出されたもの。単に考えただけでなく、著者のエリック・リースが自身で経営してきたスタートアップやコンサルティングとしてサポートした中で考え出されている。
「無駄なく作る方法」というよりも、「無駄であることに早く気づくための方法」の方が正しいかもしれない。前者だと、予め徹底的に考えて無駄を失くそうとするやり方を含んでしまう。この本は、事業やプロダクト開発のために今一番知りたい事実を検証するために必要なことを考えて実践することを最重要視している。作ったものが無駄になることよりも、何の学びもなく無駄に時間を費やす事の方がより無駄という考え方だと思う。

この本が出たのが2012年なので、今はきっともっと知見が出てるのではないかと思う。
その一つが逆説のスタートアップ思考なんだろうな。だいぶ前に読んだ本なので、また読んでみよう。

参考

• RUNNING　LEAN 実践リーンスタートアップ （THE　LEAN　SERIES） [ アッシュ・マウリャ ]
• 逆説のスタートアップ思考 （中公新書ラクレ） [ 馬田隆明 ]

_ Rakuten Hackathon 2018 Pre event に行ってきた。 #rakutentech #rakuten_tech

毎年恒例のお騒がせイベントRakuten Technology Conferenceは今年もあるようです。
今年は実行委員がまるっと入れ替わったようで内容も真新しくなっているらしい。
その一つとして、ハッカソンイベントを併設するそうで、試しに事前イベントに行ってみた。
参加者は、途中から来た人を含めて、20名くらい。だいたいが大学生、スタートアップのCEOと3名ほど楽天社員。日本語話せるのが自分含めて3人くらいという、グローバルな雰囲気だった。

ハッカソンのサイトを見ると、スケジュールとどうやらRakuten RapidAPIを作ってなにかするということくらいしかわからない。
この事前イベントで、詳細の説明があった。

スケジュール

10/20（土）からカンファレンス当日10/27（土）までに以下のようなイベントを実施予定。
どうやら現時点（2018/10/14 20:30）で掲載されている情報は最新版では無いそうで、後日更新してくれるらしい。

• 10/20（土）参加必須
  • 個人で参加した人のための、チーム作りとチームビルディング
  • 各スポンサー企業から提供していただけるサービスや技術についてのワークショップ
  • ハッカソン
• 10/21（日）
  • ハッカソン
• 10/24（水）
  • 18:00 からハッカソン会場を提供
• 10/26（金）
  • 事前審査
  • 懇親会
• 10/27（土）
  • 事前審査を通過したチームによる3分のピッチとデモ

大まかな流れはこんな感じ。

審査及び審査基準

楽天のCIO、RapidAPIの開発リーダーや各スポンサー企業からの代表者により審査。
審査基準については、後日参加者宛に連絡するらしい。
ちらっと審査基準のリストのExcelファイルを見せてくれたけれど、「楽天のサービスを改善するもの」から「Goverment 2.0」などテーマは大きい。

10/26の事前審査で、各スポンサーやコミュニティスポンサーに入っている団体から来ているメンター*1の方々が審査するらしい。

テックカンファ当日にプレゼンできるのは最大15チーム。
おそらく15チーム分のセッションの枠があるから、そこまでしか入れられないってことなのかな。
もし参加チーム数が15チームより少なければ、事前審査しても全部当日のプレゼンはできるそうだ。この説明会の司会に言わせると「そのときの状況に依る」ってことらしい。

賞品

各スポンサー企業、楽天から受賞者に何かしら提供。
各社検討中ということかな？

成果物の扱い

このハッカソンで作成した成果物は、当然だけれど開発したチームのものとして扱われる、と言っていた。
当たり前だけれど、これははっきりしておかないと、作ったものが
Eventbriteで申し込んだ時に実は参加同意書的なチェックボックスがあったのかもしれないが、スルーしてしまったので覚えていない。

という感じだった。久しぶりに英語だけでバーっと話をされたので、抜けてたりするところもあるかもしれないが、たぶんハッカソンの運営から近々何かしら詳細が来るんじゃないかと思う。
今のサイト上の情報じゃ、怖くてエントリーしないし。

対策

ハッカソン自体は1日半くらいしか無いので、今のうちに準備できることはしておかなければいけないと思う。ということで思いついたことを書いてみる。

チーム

チームでエントリーすることが可能なので、さっさと周りに声をかけて、チームを作ってしまうのが有利になる。
ハッカソン当日に初対面の人と組むのは、なかなかハードルが高いだろう。というのは普段エンジニアとしてチーム開発したことある人ならすぐわかると思う。
ちなみに、この事前イベントで参加してる人同士でもう勝手にチーム作りが発生していた。

あと、万が一にも賞金を取った場合の取り分も合意しておいた方がいい。これでもめるケースもある。

開発

テーマは後日連絡が来るはずなので、その前に使う技術要素を固めておくといいだろう。
Rakuten RapidAPIは制約の1つなので、いまのうちにアカウントを作成して、サンプルコードを動かすのを試したほうが良さそう。
正直言って、使いやすいサービスとは言えないので、今のうちにハマりどころは解決しておくといいだろう。ちなみに、自分はMicrosoft Computer Vision APIを試しに使おうとしてみたけれど、Subscription に関するエラーが出てきて、それをどう対処したらいいのかで今ハマっている。これはMicrosoftさんに聞いたらいいのか、それともRapidAPIの中の人に聞いたらいいのか、なかなか難しいところである*2。
8,000ほどのAPIがRapidAPIで使えるようになっているので、ざざっとどんなものがあるのかを見ておくといいだろう。
ハッカソンのテーマはまだわからないけど、スポンサー企業からの受賞を狙うとして、ガッツリその企業が提供するAPIを使い倒すという手もあるかもしれない。

あとは開発言語や作るプロダクトをWebサービスにするのかモバイルアプリにするのか、デモのための実行環境等々をチームで決めておくといいのかな。

_ 「きみの友だち」を読んだ。

きみの友だち （新潮文庫） [ 重松清 ] 価格：723円（税込、送料無料) (2018/10/12時点) 楽天で購入

主人公の恵美が小中高校生の生活の中で「友達」にまつわる短編集。
普通の女の子だった恵美が、交通事故により松葉杖を必要とする体になってしまうことから、それまでの周囲の環境が一変し、それまでの「友達」の希薄さを感じ始める。それと同じ時期に、病気がちでほとんど学校に来れない由佳とあるきっかけから友達になる。性格がまるで違うけれど、ずっと二人で過ごしていく中で、本当の「友達」の意味を見つけていく。すべての話が恵美を主人公としたものではなく、同級生や恵美の弟、先輩や転校生などを主人公として、それぞれが持つ「友達」の意味と、恵美と由佳の「友達」の意味との違いが描かれている。それぞれの話は、どれも誰もが過去に少しは感じたことのあるような話だった。ちょっとした喧嘩から素直に謝れない状況や、誰とでも仲良くすることに気を取られて安心できなかったり、後輩に追い抜かれる先輩、など。それぞれの話で、「○○という立場（や人間関係）ならば、□□であるべきだ」といったような思い込みが出てくる。例えば、「友達ならいつも一緒にいるものだ」や「先輩なら後輩よりも優れてなければいけない」といったように。特に友達については、恵美が少しずつ明かしていく友達の意味がすごく印象に残る。
最後は悲しさと嬉しさの混ざった終わり方だけれど、美談っぽさがなくリアルな終わり方に感じた。

_ 「マイクロソフト伝説マネジャーの 世界No.1プレゼン術」を読んだ。

マイクロソフト伝説マネジャーの 世界No.1プレゼン術 [ 澤 円 ]

外で発表する機会がこれまであまり無かったので、これから増やしていきたいと思っている。LTみたいな一方的に言いたいことを言うようなプレゼンテーションはやることは何度かあるのだけれど、勉強会やカンファレンスでの講演のようなプレゼンテーションはほぼやったことがない。そこで、澤さんのプレゼンの本はとても興味があって読んだ*1。

この本はスライド作りのテクニックについては殆ど書かれていない。それより大事なプレゼンテーション全体をどのように作るかについて書かれていた。澤さんにとってプレゼンテーションが目指すべきゴールとして

1. 聴いた人がハッピーになる。
2. 聴いた人から行動を引き出す。
3. 聴いた内容を他人に言いふらしたくなる。

いつも自分はスライドがなかなか納得したものにならなくて難しさを感じるのだけれど、その根本としてこの3つを考えていないことだと感じた。このゴールを忘れて、自分の理解や会社くを簡潔にまとめることに集中しすぎたせいで、難しいと感じていたのかもしれない。つい最近、パブリックスピーキングを研究していた方が、聴衆分析の重要性について話をしていたので、ちょうどそのこととリンクした。スライド作成のテクニックも大事だけれど、作成する上での心構えや、プレゼンテーション自体の目的について意識しながら、次の機会に試してみよう。

スライド作成については、やっぱり長沢さんの本が参考になりそうな気がしてきた。

Keynoteで魅せる「伝わる」プレゼンテーションテクニック [ 長沢智治 ]

_ 8月が終わった。

今週、久しぶりに業務でコード書いたなーって思って、コミットログを見たら8/9以来で何とも言えないヤバみを感じたのでした。その時もだいぶ久しぶりだったはずで、いったい今は何の仕事をしているのだろうか。折角、誕生日プレゼントでいただいたトラックボールやキートップを入れ替えて新品に近くなったHHKBが宝の持ち腐れみたいになっている。

今月から研修のお手伝いで、自席を離れて、ずっと研修会場に常駐してる。研修のサポートをしつつも、その傍らで、もともとやっているプロダクトの開発やお客さんとの打ち合わせなど通常の業務をやっていた。研修というのは難しいもので、場当たり的では何も伝わらない。相手の意図と反応を予想しながら対応しなければならない難しさがある。どうやればいいかを直接渡すのでもいけないし、やり方を自分たちで考えてもらいたいので、考えさせることを考えなければならない難しさがある。普段コミュ障の自分にはなかなかハードな仕事だ。
けれど、それを忘れるくらい良いこともある。彼ら自身で考えた新しいプロダクトが生まれようとしている。しかも、眼の前で生き生きとコードを書き、真剣に価値について議論し、それを検証するために情報を足で探し回る。その姿を見ると、なんだかわからない興奮みたいなものや、羨ましさとか、自分自身の至らなさとか色々感じて、自分自身の学びの方が大きい。

ということで、自分もエンジニアとして今後もやっていくために、色々と頑張らないといけないと感じた次第で、頑張っていこうと思った。

_ 『組織にいながら、自由に働く。 仕事の不安が「夢中」に変わる「加減乗除（+-×÷）の法則」』を読んだ。

組織にいながら、自由に働く。 仕事の不安が「夢中」に変わる「加減乗除（+-×÷）の法則」 [ 仲山 進也 ]

著者の仲山さんは、勝手に僕がツチノコ社員と読んでいるのだけど、それくらい会社で見ない。それは働き方が自由な人だからで、特殊な契約（？）をしているという話は聞いたことがあり、それが気になって、この本を買ってみた。

この本での自由は、「好き勝手」という意味ではない。お客さまへの価値を提供しながらも、会社に依存しない働き方のことを指している。そこに行き着くまでに経る4つのステージを、下限剰余に喩えていて、それが非常にわかりやすかった。読む前は、この本は「キャリアパスの話だろう」とか「著者は自分とは違う分野だから、参考程度に」と思って読んでたのだけれど、考え方が俯瞰的で、今の自分がどのステージにいるのだろうと考えながら読んでいた。途中の仲山さんのエピソードも面白かった。

仲山さんの仕事に対する考え方は、とても好感が持てたし、自分もなるべくそういう風に考えようとしているところがいくつかあった。「仕事に対して自分から理由を付けられるようにする」や「ライフとワークを分けない」といったことに共感できた。本を通して、いかに他者とのつながりを大切にすることが重要なのかも考えさせられた。加減剰余のどのステージにおいても、1人でできる仕事なんてのは無く、チームやお客さまあっての仕事ということだろう。そういった考え方がリーンっぽいというか近しいものを感じた。

読んでない人には「なんのこっちゃ」だろうけど、今の自分は「加減」をふらついているのかと思った。乗から先につなげるための突き抜けた軸がまだ無い*1。なので、そこを見つけられるように自分の幅を広げたり、ある特定のものに集中させたりとしていきたいと思った。定期的に読んで、自分が今どこのステージにいるのか、次のステージに行くために何が必要そうか、といったことを考えるのが良さそう。

_ 「Adaptive Code 〜 C#実践開発手法」を読んだ。

Adaptive Code　〜　C#実践開発手法　第2版 （マイクロソフト関連書） [ Gary McLean Hall ]

作ったソフトウェアのコードに、リリース後に変更が入らないなんてことは、まずありえないだろう。自分の経験上、運用なんかで1回限りの実行しか無いものでも、それをベースにして作り変えたりしなが再利用することがあったり、書いたコードの寿命が意外と長かったりする。せっかくなら、変更が起きるなら変更が起きやすいようにコードを書きたい。

そんなことを今年の始めに考えていた時に、この本をいただいた。
まさに変化に対応するためのコード設計について書かれていた。
前半は、変化が生まれるのはなぜか、そのためのチームのプロセスとしてScrumが紹介されている。チームとして柔軟に対応できるためには、コードベースもそれに合わせて柔軟でなければならない、というコンテキスト。

その方法として、SOLID原則に基づいて設計することが大切と書いている。各原則の紹介を、C#で書かれたサンプルコードも掲載されているので、とても読みやすかった。自分はC# はほんの少ししか書いたことが無いのだけれど、公式のドキュメントを片手に読めた*1。個人的には、終盤になると、UnityやASP.NETなど、ある程度はC#をベースとした開発経験があると、なお読みやすそうに感じた。

この本を頂いたのが出版直前くらいだったので、およそ6ヶ月ほどかかった…
一応、スクラムでの開発経験があったので前半はサクサクと読めたのだけれど、後半のSOLID原則が長かった。読んでみて、デザインパターンやオブジェクト指向について、ある程度は学んでいることを前提にしているようなので、再度勉強してから読み返したい。

関連書籍

カンバンによるアジャイルプロジェクトマネジメント 今すぐ実践！ [ エリック・ブレックナー ]