エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
マネジメントの要素を知る - 「マネジメント入門」を読んだ - $shibayu36->blog;
マネジメントの技術全体に興味があるので、その要素にはどういうものがあるかを知っておくために「マネジメント入門」を読んだ。 マネジメント入門---グローバル経営のための理論と実践 作者:スティーブン P. ロビンス,デービッド A. ディチェンゾ,メアリー・コールターダイヤモンド社Amazon この本は、マネジメントにはどういう話題があり、それぞれにはどのような研究や考えがあるかについて、ざっくり概要を教えてくれる本だった。マネジメントの機能を、計画する、組織する、リーダーシップを発揮する、コントロールするの四つに分類して話を進めている。目次は以下のとおり。 イントロダクション: マネジャーとマネジメント・マネジメント環境・マネジメント全般に関わる課題 計画する: 意思決定の基礎・計画策定の基本 組織する: 組織の構造と設計・人材を管理する・変革とイノベーションのマネジメント リーダーシップ
問題の効率的な解決方法を学ぶ - 「世界一やさしい問題解決の授業」読んだ - $shibayu36->blog;
仕事で何かしら課題を見つけた時に、それを効率よく解決する方法にはどういうものが知りたかった。そこで参考になりそうな「世界一やさしい問題解決の授業」を読んだ。 世界一やさしい問題解決の授業―自分で考え、行動する力が身につく 作者:渡辺 健介ダイヤモンド社Amazon この本は非常に良かった。100ページ強と非常に少ないページ数ながら、その中に問題解決のためのエッセンスが詰め込まれていて勉強になった。分解の木や課題分析シートなど問題解決のためのツールもコラムに書かれていて、これらも参考になる。とにかくおすすめ。 「課題を見つけて解決策をとりあえず試してみたけど何かうまくいかなかった」というような経験をしたことがある人は読んでみると良いと思う。薄い本ですぐに読めるので、とりあえず誰でも読んでみると良さそう。 この本の中で自分が印象に残った次の二点をまとめておく。 問題解決とは「現状を正確に理解し
基礎技術の学習のモチベーションをどう保つか - $shibayu36->blog;
最近、コンピュータサイエンスなどの基礎的な知識を学習するように心がけている。できる限り今後も長い期間役に立つ、寿命の長い技術や知識を付けておきたいためである。その一貫で アルゴリズムを学習 してみている。 学習をはじめて感じた課題 しかし、とりあえずアルゴリズムを学習してみると、学習を続けられるか分からないという課題も感じた。 寿命の長い技術であるほど、日々の開発にすぐに利用できないことが多い 例えばアルゴリズムを学んだとしても、それが役立つまでいくにはある程度長い時間が必要 日々の開発に利用できていないと、モチベーションをずっと保ち続けるのが難しい モチベーションが保てないと、結局途中で勉強をやめてしまい、日々の開発に利用できるレベルまでたどり着けない 流行りの技術とかは、すぐに開発に導入してみるとかができるので、とりあえずモチベーションは保ちやすい。しかし、数学とかアルゴリズムとかLi
なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog;
最近以下のようにコーチングや人間の学習モデルの勉強をしている。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; 「リファクタリング・ウェットウェア」を再読した - $shibayu36->blog; 「コーチングのすべて」という本を今読んでいる そこで、自分の考えをまとめるためにも、なぜ最近コーチングや人間の学習モデルの勉強をしているか書いてみようと思う。 最近、株式会社はてなという会社で、シニアエンジニアというポジションに付いた。シニアエンジニアは、数人のエンジニアのメンターとして、目標設定・1on1面談・評価などを行うポジションだ。また、社内のエンジニアの一つのロールモデルとなれるような態度を求められる。 このポジションになった時に、まず初めに考えたことは、このポジションとして求められていることは何なのかということだった。考えた結果、数人のエンジ
目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog;
最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設
チーム内プロジェクトが発足した時に、プロジェクトの朝会を用意すべきか - $shibayu36->blog;
最近チーム内で少し大きめなプロジェクトが発足して取り組んでいたのだが、その時プロジェクトの朝会(デイリースクラム)をするべきなのか悩んだことがあった。自分の中ではプロジェクトごとの朝会を用意すべきという結論に至ったのだが、今回はその結論に至った経緯をメモしておく。 なおこのような開発フローの話は全てのチームに適用できるわけではなく、チームの状況によって最適なものが違うので、一つの参考例としてどうぞ。 前提 7~8人ほどのチームで、3~4人で取り組むプロジェクトが発足したときの話 チーム全体の朝会は行っていて、進捗確認や問題解決はそこそこ上手く行っていた チームの朝会は、一人ずつやったこと・やること・気になりごと・相談を発表するスタイル プロジェクト朝会実施前 最初は全体朝会で話せば良いかと思い、プロジェクトの朝会は用意していなかった。しかし、最初は良かったものの、徐々に問題が起き始めた。例
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
「アドレナリンジャンキー」読んだ - $shibayu36->blog;
アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン 作者:トム デマルコ,ピーター フルシュカ,ティム リスター,スティーブ マクメナミン,ジェームズ ロバートソン,スザンヌ ロバートソン日経BPAmazon 読んだ。 この本はソフトウェアのプロジェクトにおけるパターンについて、いろいろ教えてくれる本。この本を読んで、あーあるあると思いながら読めると良い本なのだろうと思う。あんまり進め方が良いとは言えないプロジェクトに関わっていたり、炎上気味のプロジェクトに関わっている人には面白く読めると思う。逆に僕はそれぞれのパターンを読んでも、なるほどとは思えなかったので、そこまで面白くはなかった。 この本の中で一つ面白かったのは「マニャーナ」というパターン。説明文には以下のように書かれている。 すぐに動き始め動き続けなければ仕事が片付かない。そう認識できる時間枠を超えて期日が設定され
SunriseとTODO管理ツールを組み合わせてスケジュール管理をする - $shibayu36->blog;
最近タスク量がそこそこ多く、かつ自分の記憶力もそこまでないので、できるだけタスクを忘れないようにしながらスケジュール管理をしておきたいと感じていた。その時にカレンダーアプリであるところのSunriseと、TODO管理ツールをうまく組み合わせることで非常に使い勝手の良いTODO管理を行うことが出来たので、まとめておく。 Sunriseについて Sunriseというのは、様々なスケジュール系ツールと連携して、ひとつのカレンダーにまとめてくれるためのカレンダーアプリ。例えばgoogle calendarやfacebook eventsなどと繋げることで、複数のサービスにまたがった予定を一つのカレンダーで管理することが出来るようになる。 https://calendar.sunrise.am/ 詳しくは以下に詳しい。 TODO管理ツールと繋げる Sunriseの良い所は、TODO管理ツールとも繋げ
社内用Docker Registryを立てる - $shibayu36->blog;
Dockerにはimageを登録しておくためのregistryが用意されていて、https://index.docker.io/ にPublicなイメージを登録しておくことが出来ます。また、社内用など、Publicには出したくない時も自分でregistryを立てることが出来ます。そこで、今回は社内用Docker Registryの立て方について書こうと思います。 https://github.com/dotcloud/docker-registry を参考にします。 Docker Registryを立ち上げる 立てるのはすごく簡単で、docker runするだけでした。 $ docker run -p 5000:5000 -d stackbrew/registry これで実行したhostの5000番portにDocker Registryを立てることができます。 ここに対して、pushやp
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
Dockerが利用しているAUFSとLXC - $shibayu36->blog;
最近Dockerをいろいろ触ってみていて以下の様な記事を書いたりしました。 Dockerで立てたコンテナにsshで接続する - $shibayu36->blog; serfとDockerでクラスタを組んでみる - $shibayu36->blog; 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; 社内用Docker Registryを立てる - $shibayu36->blog; docker commitでCMDやENVなどを指定する - $shibayu36->blog; docker inspectでDockerコンテナの情報を取得する - $shibayu36-
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
インフラのOrchestration? - $shibayu36->blog;
Orchestrationやっぱりよく分かってなくて、色々話聞いてた。まだまだ分かってないけど、今のところをまとめるので、ここは違うとか指摘してください。 http://iiirc.org/snippets/321 Orchestrationに二つの意味が混ざっている？ という話になった。一つはmizzyさんも言っていたインフラの動的な部分という意味で、一つはnaoyaさんやstanakaさんが言っていたサーバ同士がうまくコミュニケーションしあって統制するという意味っぽい。 それぞれの役割やツールへの対応としては インフラの動的な部分 あるサーバの状態に合わせて、実行する内容を動的に変える capistrano, fabric, MCollectiveなどが該当 サーバ同士が相互的にコミュニケーションして統制する serfなどが該当 インフラの動的な部分としてのOrchestration
ペパボとカヤックに遊びに行ってきました & Cinnamonの検証について発表しました - $shibayu36->blog;
金曜日にペパボとカヤックに遊びに行って来ました。 ペパボ 昼ごろにペパボに遊びに行ってantipopさんに案内してもらいました。食堂みたいなのがあってそこで昼食を食べた後、オフィスに少しだけお邪魔しました。ちょうど開発の方々がお話をしていたので、少しだけお話して来ました。 あとペパボの入ったところの黒板に絵が書いてあってかっこ良かった。 すごいぶれてた。。。 カヤック そのあとカヤックに3時くらいに行ったら、社内isuconが開催されていました。実際には7時前にお邪魔するつもりがすごく早くに着いてしまったのですが、isucon会場でぼーっと作業を眺めていました。 見てるとすごく楽しそうで、DBIがとかRedisがとかいろいろ話しててとにかくやりたすぎるけど参加できなくてもどかしい感じでした。そのあと今回のisuconの解説があったのですが、それが面白くて参考になりました。社内isucon非
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
