今日から Launchable で働きます。英語の環境でB2BのSaaSと初めてのことばかりだけど、やっていくぞ 💪　https://t.co/xLPxVBaF5M— Satoshi Asano (@ninjinkun) 2020年6月11日 From: 一休.com To: Launchable B2B SaaSスタートアップのLaunchableに転職した。主にフロントエンドエンジニア、時々バックエンドエンジニアとして働く予定である。Launchableはソフトウェアの自動テストに時間がかかる問題を機械学習で提供するスタートアップで、詳しくは以下の記事を見ていただきたい。 xtech.nikkei.com www.publickey1.jp 今回転職した理由としては以下の通りである。 創業者川口さんの熱いブログエントリに感化された 英語の環境で仕事をしてみたかった 同世代の友人たちが

6月中旬に株式会社一休に入社した。一休レストランという飲食店予約サービスを運営するレストラン事業部で、iOSアプリの開発を行っている（やっていることはコーディングとプロダクトマネジメント的な仕事を半々ずつくらい）。 一休はIT系としては比較的歴史が長い会社だが、 アプリの伸びしろの大きさ 経営陣の面白さ 自分で使って楽しいサービス という点で、総合的に見て面白い経験ができそうと感じて入社を決めた。事前に二週間お試しで働いてみて、一緒に働くメンバーとも楽しく仕事ができそうなのがわかっていた点も大きかった。 元々飲みに行ったり外食することは好きだったのだが、一休では自社のサービスを自分で使ってご飯を食べに行き、その体験をまた製品にフィードバックして改善できる。自分の生活をサービスに反映できるところが面白い。 他にも、社長（金融工学、CS、コンサル系のバックグラウンド）が検索のおすすめ順やリコメ

昨年11月に結婚し、2月に勤めていたFablicを退職して京都で暮らしている。 結婚 3年前に上京して、京都に住んでいる彼女と遠距離恋愛をしていたのだが、昨年末に結婚した。現在は京都で一緒に暮らしている。毎晩一緒にお酒を飲めるのが楽しい。 退職 会社を辞めた理由としては、会社が昨年夏に買収され、自分の中でスタートアップ欲求が一段落付いたというのが一つ。もう一つは妻の仕事が3月まで忙しいことがわかっていたので、せっかく結婚したのだし、しばらく一緒に居る時間を作ってサポートするのも良いんじゃないかと思い、このタイミングになった。 Fablicにはスタートアップの黎明期から拡大期に移るタイミングで入社し、フリルのiOSネイティブ移行、AndroidのMaterial Design対応、RIDEの開発など、様々な楽しいプロジェクトに関わらせて頂いた*1。また、自分のわがままを聞いてもらって、プロダ

この記事はProduct Manager Advent Calendar 2日目の記事です。 先日Japan Product Manger Conferenceに参加して、ポケモンGOの開発元であるNianticでPMをされている河合さんのセッションの中で印象的な言葉があったので書き留めておく（セッションの詳細はプロダクトマネージャーに必要な資質って何ですか？ 元グーグルのPM対談 | HRナビ by リクルートで読める）。 会場からの質問で、「開発者に仕事を任せる際に、上からやることをお願いするトップダウン型と、開発者が自発的にアイデアを出してくるボトムアップ型があると思うが、どちらがいいと思うか」（うろ覚えだけど、だいたいこんなニュアンスだったはず）という質問に対し、河合さんは一呼吸置いてから「ボトムアップの見かけはとても重要」と回答されていた。 これはPMの中では既に実現方法（おそら

original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし

Incrementsの知人が社内で輪講していると言っていて、気になっていたので読んでみた。創造的なチームを作るために気をつけることと、そのために必要になるリーダーシップについて書かれている本とのこと。 現代のチームが固定されたメンバー制から専門集団の一時的な集まりになっている（例えば病院、災害救助、スタートアップなど）ことから、チーム構造からチームワーク自体へ注目するという意味で動詞のチーミングが提唱される。 心理的安全 自立的かつ創造的なチームのキーになるのが心理的安全である。 心理的に安全な環境では、何かミスをしても、そのためにほかの人から罰せられたり評価を下げられたりすることはないと思える。手助けや情報を求めても、不快に思われたり恥をかかされたりすることはない、とも思える。そうした信念は、人々が互いに信頼し、尊敬し合っているときに生まれ、それによって、このチームでははっきり意見を言っ

このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。 CROSS2016に出るので、最近の自分の考えを整理しておく。 最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。 アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば ユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U

Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング（実装）」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニアと

プロダクトマネージャーの職能+ユーザー体験設計の本です（と解釈しています）。 最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。 Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。 プロダクトマネージャーとは何か どうやって他の職種と連携して働くか どうやって製品を見つけ出すか どうやってユーザー体験を作っていくか 自分にとっては、

自分が最初に元の誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)（初版はPOETと呼ばれている*1 ）を読んだのは十数年前でした。4月に出たこの改訂版を読み返してみて、改めて感銘を受けました（そして内容をほとんど忘れていたのに気づきました）。 内容としては、エモーショナル・デザイン―微笑を誘うモノたちのために 、複雑さと共に暮らす―デザインの挑戦など後の書籍で検討された内容が盛り込まれて、ノーマン著作の集大成になっています。 自分がこの改訂版で注目しているのは、「6章デザイン思考」の追加です。 6章デザイン思考 正しい問題を発見するのがデザインである として、そのための手段としてデザイン思考が解説されます。 具体的にフレームワークとして取り上げられている人間中心デザインプロセスを見てみると、 観察→アイデア創出→プロトタイピング→テスト→観察… というサイクルになって

日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ

昨年末に株式会社はてなを退職しました。2008年の京都移転直後のインターンに参加し、2009年に新卒入社したので、5年くらいはてなに関わっていたことになります。 このエントリでは、自分がはてなでやったことと、エンジニアとしてのロールモデルを持つことができたこと、コミュニティ活動ついて、そして今後について書きます。 はてなでやったこと 最近ではスマートフォン系の仕事が多かったのですが、入社当初は運用を担当していました。たくさんのサービスを担当しているチームで、ここで様々なコードに触れた経験が今振り返ってみるとすごく良かったと思います。とにかくコードをたくさん読みました。 同期入社には既に実績がある人が何人もいて焦る一方、自分はテストを書いているつもりがDBのデータを消していたり、社内のメールを止めたりとひどいミスを連発していて、今思い出しても冷や汗が出ます。 その後 はてなキーワードフィーチ

一昨年に社内で行ったAbout Face 3輪講の資料を公開します。実は今までずっと公開されていたのですが、存在を知られていなかったので、改めて周知します。 About Face 3はUI/UX設計の教科書で、ユーザーストーリーやペルソナなど、基本的な内容が押さえられています。ディレクター、デザイナー、エンジニア、サポート等、プロダクト制作に関わる全員の共通知識として使える内容だと思います。 About Face 3輪講概要 1. ゴールダイレクテッドデザイン 2. 実装モデルと脳内モデル 3. 初心者、上級者、中級者 5. ユーザーのモデリング : ペルソナとゴール 6. デザインの基礎 : シナリオと要求 8. 優れたデザインの総合 : 原則とパターン 10. オーケストレーションとフロー 11. 間接的な操作を取り除く 12. 良き振る舞いのデザイン 13. メタファ、イディオム、ア

@fladdictさんが監訳されたことで話題の、オライリー本『iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン』、早速会社で購入してもらって読みました。読み終わってまず思ったのは、これはiPhone開発に携わるすべての人に必読の本になるだろうということです。エンジニア、デザイナー、企画者と分担が分かれている場合は、全員が読むといいのではないでしょうか。この本はiPhone開発に必要な共通言語を提供してくれます。それも、コードを使わずに。 本書から得られる内容としては大きくふたつあると思います。ひとつはiPhone開発のプロセスを解説書としての側面。もうひとつはiPhoneのUIカタログとしての側面です。 アプリ開発プロセスの解説書 この本に書かれている開発プロセスは、ベストプラクティスと言えるものになっていると思います。ユーザーニーズを探ること、シンプルさを追求するこ

この三ヶ月ではてなブックマークiPhoneアプリの新バージョンとAndroidアプリを開発してきました。 両方共担当はエンジニアid:ninjinkunとデザイナーid:kudakurage、総合ディレクションid:nagayamaです。同じ開発者がiPhoneアプリとAndroidアプリ両方を作った事例として、なかなか面白いのではないかと思います。開発期間はちょうどそれぞれ一ヵ月半ずつでした。 自分にとってもブクマチームに移動してから初めての大きな仕事だったので、両方共思い入れがあるプロダクトです。開発話と一緒に、スマートフォンアプリを作る際の流れや、気を付けていることなどをまとめようと思います。（長いです） 開発プロセス iPhoneもAndoirdも開発の流れは基本的に一緒で、以下のような流れになります。 機能の検討 UIの検討 実装 ざっくり並べただけではWebサービス開発と変わり

アップルを創った怪物―もうひとりの創業者、ウォズニアック自伝 作者: スティーブ・ウォズニアック,井口耕二出版社/メーカー: ダイヤモンド社発売日: 2008/11/29メディア: 単行本購入: 14人 クリック: 200回この商品を含むブログ (82件) を見る タイトルと裏の写真は酷いが、それ以外は大満足。ウォズの生い立ちから大学までの話に半分以上が割かれており、ジョブズはときどきしか出てこない。しかしその生い立ちが面白い。エンジニアだった父親の影響で、小さい頃から様々な科学的な知識に精通していたこと、6歳で鉱石ラジオを組み立てた話、中学二年生で加減算器を設計した話・・・ウォズ少年のエピソードはどれも煌めいている。多少輝きすぎている気もするが、そこはまあ、自伝なので。 友達の誰も持っていない物を作ることができたんだ。小さな電子機器。友達にはできないことを僕はやったんだ。「鉱石ラジオを作

original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,

先日リリースした個人アプリBlogFeedbackを開発した動機と、開発の時系列、開発してみての感想（ネイティブ開発者から見たPWAとか）を書いていきます。リリースエントリにも書きましたが、このアプリはiOSネイティブアプリからWebアプリへの移植です。 TL;DR BlogFeedbackのケースではWebでもネイティブアプリとほぼ同等の体験を作ることができた ネイティブ歴が長くHTML/CSSに明るくなかったので、まずReact Native for WebでUIを組んでいって、自力でHTML/CSSが書けるようになってから脱React Native for Webした React / TypeScript / create-react-app / styled-components / storybook おすすめ ブログを書いている人はBlogFeedbackを使ってみて欲しい！

仕事でMacBook Pro (Intel 16-inch, 2019)を使っているのだが、この数ヶ月やたら遅くなってきて困っていた。試しにHotを入れて監視してみたところ、ビデオ会議中にサーマルスロットリングが働いてCPUのクロックが40%くらいまで下がっていたので、これは何か対策しないといけないと思い始めた。M1マシンに変えられればベストだが、購入した同僚が環境構築にハマりまくっていたのを見ているので、買い替えは躊躇する。このマシンも購入直後は問題なく使えていたはずなので、何かしらの変化があったのだろうと思い、内部の冷却に問題があることを疑い始めた。 早速どのご家庭にもある星形ドライバー1.2mmを引っ張り出し、裏蓋を外す。案の定埃が溜まっていたのでエアダスターで吹き飛ばしたところ、MBPは完全に復活した。今は快適な使い心地で、サーマルスロットリングも滅多に効かなくなった。 サーマルス

ランニングを始めて14年ほどになる。そんなに大したランナーではない。だいたい週に2、3回、5km〜10kmを走っている。フルマラソンには一度出たきり、タイムは5時間。全く走らない月もあったし、やたら走る月もあった。先日140. ninjinkunさんと財テクの話 | Ossan.fmに出て自分のランニングの話をしたのがきっかけで、どうして走っているのかをきちんと思い出して書き留めておきたくなった。 走り始めた経緯 自分は村上春樹が好きで、彼がランナーなので同じようにランニングを習慣にできたらいいなとぼんやり思っていた。 実際に走り始めたのは大学院に通っている時だった。当時自分は研究がうまくいっておらず（今から思うと真面目にコツコツやっていなかっただけ）、就職活動にばかり時間を割いていた。そんな中でも中間発表やら学会発表やらは容赦なくやってくるので、それなりにストレスがかかっている状況だった