エンジニアからみた良いプロダクトマネージャとは? 1 on 1 で 何を話すのか? マネージャ/ソフトウェアエンジニアの立場から Tech Lead(TL/テックリード)の役割 マネージャとのつきあいかた 言ったもの勝ち/言わないと伝わらない
ちょうど1ヶ月前。フレンズのディクテーションとフレーズの暗記を毎日やることを決心した。その成果を1か月後にブログに書くというイベントをカレンダーに登録した。なのでこのブログを書いている。 なぜやるのか? 1:1 ではなく大人数での会話の聞き取りについていけないことがよくあるから。特に仕事とは関係のない話題の場合に顕著。これはリスニング能力の問題。 日常のふとした言い回しのストックが足りないと感じていたから。例えば「病院どうだった?」「あ。僕がそっちに行くよ」「もったいないねー」など。 これらのフレーズは聞き取ることは簡単。そして意味も簡単に類推できる。しかし自分の口からは出てこない。なぜなら知らないから。 なぜフレンズか? 英語の先生、英語がネイティブではない外国人の同僚、多くの人がすすめてくれたから。そしてDVD 全巻持っているくらいフレンズが好きだから。 工夫した点 続けられる仕組みづ
Rebuild: Aftershow 126: Everything Except Mayonnaise (higepon)で紹介したプロジェクト。Machine Learning | Coursera で機械学習のクラスを修了した。理解を確認するために小さなプロジェクトを作っていたので紹介。実用性はいまのところない。 まとめ Pebble Time Round(スマートウォッチ)の加速度系データ (x, y, z) を入力にしてヨガのポーズを区別できるようになるか試してみた Supervised Learning なので training/test/validation set データを手動で作成 Hidden layer 1 つのニューラルネットワークで学習させた ヨガ以外の活動(徒歩、スマホをいじってる)、Downward dog ポーズ、Warrior 2 ポーズの 3 つをある程
Tech Lead(TL/テックリード)の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム(最大で10人以上)の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値(プロダクトゴール)を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
1 on 1 (ワンオンワン) とは1対1のミーティングの事。ここでは毎週もしくは隔週で行われるマネージャとその部下(direct reports)であるソフトウェアエンジニアの 1 on 1 に焦点をあてる。よく 1 on 1 で何を話したらよいか分からない。話題がない。と相談されるので僕の思うところをまとめてみる。 僕はマネージャもソフトウェアエンジニアのどちらも経験があるので両側からの視点を提供できると思う。 マネージャ編 マネージャは 1 on 1 を部下のために開催しなければならない。自分のための時間ではないことを肝に銘じよう。部下には話したいことを何でも話してもらう。事前に「1 on 1 は君のための時間だよ」と説明しておこう。 1 on 1 が始まったら「何か話したいこと、気になることある?」と問いかけよう。焦ってはいけない。じっくりと待ってみよう。 たとえマネージャとしてプ
エンジニアからみた良いプロダクトマネージャ(以下PM)とは。rebuildfm #98で id:naoya さん(@naoya_ito)から PM についての話があったので便乗して書いてみる。※プロダクト(製品)マネージャはプロジェクトマネージャとは全然違う職種なので注意。 結論から先に。エンジニアから見た良い PM とは「つねにユーザーのことを考えた上でプロダクトに信念を持っている人」だと思う。それは当たり前じゃないか?と思った人は正しい。でも常にそれをできる PM は多くはない。幸いにも僕は多くの優秀な PM と仕事をさせてもらったのでそこから学んだことをまとめてみよう。 PM の役割 まずは PM の役割から見ていこう。スタートアップの CEO の役割からエンジニア、デザイナーをマイナスした感じと言ったら伝わるだろうか。 もう少し具体的に PM がやっていることを挙げてみよう。 自分
計算機プログラムの構造と解釈posted with amazlet on 06.04.15 Gerald Jay Sussman Julie Sussman Harold Abelson 和田 英一 ピアソンエデュケーション (2000/02) 売り上げランキング: 56,404 Amazon.co.jp で詳細を見る 自分が「計算機プログラムの構造と解釈」という本を勉強していった過程をまとめています。 この本の本質は、翻訳の悪さでも難しい数学でもないです。 なんと伝えたらよいのだろうか。 全部読み終えたときにまとめたいと思います。 →読み終わったのでまとめました。「「計算機プログラムの構造と解釈(SICP)」を読み終えて」 読み終えたら次のステップとしてはOn Lispなどがおすすめです。 目次 関数型言語の勉強にSICPを読もう - (1) SICPを読み始めた理由 関数型言語の勉強に
オンラインで授業を公開している大学とその講義の一覧のまとめです。 もし他にもご存知の方がいらっしゃれば、コメントやトラックバックなどで教えていただけるとうれしいです。 まとめ 英語ができるならば MIT 最強。国内は東大が比較的がんばっています。 (追記)国内ではWIDEのSOIががんばっているとのご指摘をいただきました。確かに素晴らしい講義がたくさんです。(表に追加しました) 講義はすぐそこに開かれているので、あとは「勉強方法」に従い講義を受けるだけだと思いました。 大学名のリンク先が講義公開 URL になっています。([高等教育シリーズ] 大学で勉強する方法) 大学名 公開形式 講義の例 備考 MIT 動画、講義資料 East Asia in the World、Japan in the Age of the Samurai 1800以上の講義が公開。中国語やポルトガル語に翻訳されてい
勝間和代のビジネス頭を創る7つのフレームワーク力 ビジネス思考法の基本と実践を読んだ。 厚めの本だったので2日かかりました。 たくさんページを折りましたよ。 僕らの世界(IT業界?)で言えばフレームワークといえば Ruby on Rails とか Catalyst とかなのですがビジネスの世界にはこんなものがあるのですね。 自分も前々職では SE をやっていたので某コンサルティング会社のコンサルの人がものすごい単価(給料)でプロジェクトに参加しているのは見てきました。 その当時は、自分と彼らが何が違うのか?なぜ重宝されるのかが分かっていませんでしたが、この本を読んでようやくその理由の一端が見えた気がします。 メモ 多くの人が「実行」部分をさぼる 基本的なフレームワーク21選 こりゃ参ったこれらのフレームワークが頭の中にあるのとないのでは全然違うだろう。 - 水平思考の6つの帽子いいね 水平
勉強方法を勉強して分かった僕に足りなかった3つのこと。 それは 時間割 マインドマップ 復習 の3つ。 1.時間割 勉強をコンスタントに長期的に続けるならば時間割は大変有用。 時間割を作り実践してみて分かったが「次に何をやるべきか」に迷う時間は振り返ればとてももったいなかった。 時間割を作ればほぼ迷わない。迷うとすれば超イレギュラーな事が起きたときだけ。 時間も節約できるしペースもつかめる。 また時間割を家族と共有していれば「20:00になったから勉強してくる」と言うだけで理解してもらえるようになる。 ただし時間割は時が経ち「見慣れて目に入らなくなる」「実態に合わなくなる」事があるので注意が必要。 僕は毎週手書きで描き直している。 時間割の有用性についてはレバレッジ勉強法が詳しい。 2.マインドマップ 正直 マインドマップ を馬鹿にしていた。何で皆あのようなものに踊らされているのかと。それ
約半年をかけて計算機プログラムの構造と解釈(SICP)を読み終わりました。 (途中で、練習問題をスキップしたりしましたが・・・) 半年もかけたのでちょっとだけ振り返って見ます。 SICPを読む過程で得たもの まずはSICPを読む過程で得たものからざっと列挙してみよう。 構文解析を理解し自前で実装できるようになった 字句解析を理解し自前で実装できるようになった ストリームを理解した 遅延評価を理解した 手続きが first class objectである言語での考え方を学んだ 型変換の導入の動機とその意味を理解した 手続きの抽象化の導入の動機と過程を学んだ 高階関数を使ったり書けるようになったりした クロージャを理解した Schemeを書けるようになった 再帰処理を自然に書けるようになった フルスクラッチでインタプリタを書けるようになった コンパイラを自前で書くことが出来そうだとの感触を得た
プライベートなことは Notion に書いた。 Kaggle コンペ参加は1回のみ。 バレエを始めた。 週2-3回の筋トレはよく続いた。 8月にコロナに罹った。熱を出して寝込んだ。家族はほぼ無症状。後遺症はなし。 息子は中学生になり、子育ての負荷がぐっと下がった。… ceronman/loxido: Rust implementation of the Lox programming language. How to allocate object let bar = gc.alloc(LoxString::from_string("bar".to_owned())); LoxString::from_string and GcObject implementation. They are staraightforward. pub s…
毎朝5時に起きて出勤前にコードを書くという習慣を始めた。2週間経ったのでまとめてみようと思う。この記録が小さい子持ちの30代パパ・ママエンジニアに役立つとうれしい。多分独身で若い人には役に立たない。 始める前に抱えていた問題 好きなコードを書きたい。勉強したい。そう思っても以下の理由により以前とは比べられないほどに時間がとれなくなってしまった。 子供に可能な限り時間を使いたい。結果的に自分の時間は減る コードを書く自由時間が極端に少ない 1人になれる時間がほとんど無い 家で10分以上集中できない。こどもが遊ぼう!って誘ってくるとか 子供に話かかられたり質問されたら出来る限り応えたい とにかく疲れやすい 以下のような典型的な1日。 朝は 6:30 頃に早起きの息子に起こされる。1人で起きて絵本などを読める歳だが、静かに起きることは稀だ。トイレに行きたいとか。何かが見つからない。何だかんだで同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く