株式会社アンドパッドに入社しました - $shibayu36->blog;
2021/10/01から株式会社アンドパッドに入社しました。初めての転職なので緊張しているけれど、早めに馴染みたい。 andpad.co.jp 転職活動をしている中でいくつかオファーをもらっていたが、以下の理由で株式会社アンドパッドに入社を決めた。 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう 組織規模が急拡大していて、組織マネジメントの経験が深まりそう 採用フローがしっかりしていて、今後も良い人がどんどん入ってきそう 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう これまでのエンジニア経験の中ではインフラ〜フロントまで全体的に触ってきたが、自分の中ではインフラ領域〜バックエンド領域の中間くらいのエンジニアリングに最もモチベーションが湧いていた。またクラウドネイティブな設計をもっとできる機会があればなあと思っていた。 このように考えてい
株式会社はてなを退職しました - $shibayu36->blog;
2021年8月13日の本日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 本当に色々経験できたのだが、自分の中で本当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere
継続的に学習するために効いたやり方3つ - $shibayu36->blog;
育児していて時間があまり取れない状況下で継続的に学習するために色々な方法を取り入れているんだけど、その中で最近めちゃくちゃ効いた3つのやり方を紹介。 やりたいことリストを作っておく 今日のTODOリストを作る 2分間コーディング やりたいことリストを作っておく 自分が学習したいことの一覧があると、優先度を決めやすくなり、またやりたいことが1つ終わった後すぐに次に取り組むこともできる。そこで僕はTrelloでリストを作り、とにかく少しでもやってみたいと思った開発や、読みたいと思った本などがあれば追加している。 今日のTODOリストを作る 時間が空いてから「今日はこれから何をやろうかな？」と考えていると、途端にやる気がなくなってダラダラしてしまう。そこで先に今日のTODOリストを作っておくということをやっておく。ポイントとしては 細かい家事やプライベートでやること、勉強すること全て含めて同じリ
プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する - $shibayu36->blog;
プロジェクトマネジメントにおいて、見積もりをどのように行うかは結構難しい。僕は理想日見積もりの形式も、相対見積もり(ストーリーポイント)の形式も試したことがあるが、どちらも一長一短であった。 最近色々試す中で、プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行するという方式がやりやすいと感じた。今回はその様子を紹介してみる。 理想日見積もりと相対見積もりそれぞれのメリット・デメリット 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察の記事を読むと、理想日見積もりと相対見積もり(ストーリーポイント)それぞれのメリット・デメリットがさっと把握しやすい。自分としては、それぞれ以下のように思っている。 理想日見積もり : 他の割り込みが全くなく、1日中タスクに取り組んだ場合を1理想日とする見積もり方式 メリット: 他に基準となるタスクがなくてもとりあえず雑に出せる。相対見積
タスクの依存関係とリソースの両方を考慮してプロジェクトマネジメントをするCCPM理論を学んだ - $shibayu36->blog;
自分のプロジェクトマネジメントのスキルをもう一つ伸ばしたくて、タスクの依存関係とリソースの両方を考慮してプロジェクトマネジメントをするCCPM（クリティカルチェーンプロジェクトマネジメント）理論を学んだ。この理論を学んだおかげで、よりプロジェクトの計画作りや、プロジェクトの現在の危険度の把握をやりやすくなったと感じる。アジャイルの手法であるベロシティでの管理ともうまく組み合わせられそうだったので、今度試してみたい。 参考にした書籍 クリティカルチェーン 作者:エリヤフ ゴールドラットダイヤモンド社Amazon 進む！助け合える！ＷＡ（和）のプロジェクトマネジメント――プロマネとメンバーのためのＣＣＰＭ理論 作者:宮田 一雄ダイヤモンド社Amazon アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす 作者:宇治川浩一株式会社ビーイングAmaz
読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました - $shibayu36->blog;
「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました Engineering Manager Meetup #5で「エンジニアメンター制度の効果的な運用を目指して」という発表をしてきました。 自分も久々の発表で緊張しましたが、自分の頭をまとめる良い機会になりました。他の発表も学びが多く、とにかく濃いミートアップでした。このような機会を与えてくれた運営の方に感謝です。また機会があったら参加・発表したいです！ 以下は発表内容のまとめです。 発表内容 アジェンダ はてなのチーム横断のエンジニアメンター制度とは 実際にどのような課題があったか どのように改善したか 改善施策により最終的にどうなったか 今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする イントロ 自分がマネージャっぽい仕事をしていると以下
問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん！最悪！ 会社にこういう問題あるじゃん！なんで直らないの！最悪！ みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。
アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない！」「障害対応をもっとうまくやる方法はないのだろうか？」と思う人には参考になる部分が多いと思う。 個人的にこの本の中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
育休で得られるのは育児のサポートだけではない - $shibayu36->blog;
最近子どもが産まれて、しかもありがたいことに2ヶ月間育休を取れることになった。育休を取り始めて今2週間くらいなのだけど、育休で得られるのは育児のサポート(サポートという表現は適切じゃないかもしれないけど...)を行うことだけじゃないなと思ったので考えを書いておく。 自分が育休を取ると、妻と一緒に育児を行うことができ、育児の負担を二人で分担することができる。しかし、それだけじゃなく、育休を取ることで以下のメリットを得られると感じた。 育児の大変さを知ることができる 育児のやり方の認識を一致させ、自分一人で全て出来るようになる 育児の大変さを知ることができる 育休を取ってみて、「一日中」育児をするということは非常に大変であるということが分かった。これは当たり前のことだと思うけど、実際に仕事をしていて夜だけ育児をするだけだとなかなか実感できないことだった。 例えば一日中育児をしていると、子どもを
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
どうやったら発見した問題をうまく放置できるようになるのか - $shibayu36->blog;
仕事をしていると、様々な問題が発見される。問題を発見した時、とにかくすぐに対処しようとしてしまうことが多い。しかし、そうしていると、タスク量が増えてきたときに問題解決に忙殺され、もっと重要なことに取り掛かれないということが起こりがちである。 「イシューからはじめよ」によると、忙殺されないためには、問題の重要度を見極めて、重要なものだけ重点的に取り組むべきであり、そうでない問題は放置すべきと書かれている。 しかし、そんなことは頭では分かっているのである。それでも問題を見るとすぐに解決しようとしてしまうのである。では、どうやったら発見した問題をうまく放置できるようになるのか。 それについて最近1週間ほど考えていたのだけど、とりあえず以下のことをやってみようという気持ちになった。 それが何か問題かと自問する 問題を少し置いておく 問題を書き出してみて、他の問題と比較する それが何か問題かと自問す
「無印良品は、仕組みが９割」を読んだ - $shibayu36->blog;
昨夜なぜか眠れなかったので、積んであった「無印良品は、仕組みが９割」を一気読みした。 [asin:4041104998:detail] この本は無印良品の業績が悪くなっていたときに、「仕組み」をうまく作ることで業績を改善した話について書かれていた。書かれている具体的な仕組みはもちろん無印という会社に合ったもので他の会社に適用できるかは分からなかったが、しかしながら「仕組み」の考え方については非常に汎用的に適用できるもので参考になった。経営とかに興味があれば非常にオススメ。 個人的に印象に残ったのは以下の2点。 マニュアルの全項目に、なぜその作業を行うかを書いている 仕組みに納得して、実行するうちに、人の意識は自動的に変わっていく マニュアルの全項目に、なぜその作業を行うかを書いている 無印良品には、経営から商品開発、売場のディスプレイや接客まで、すべての仕事のノウハウが書かれたMUJIGR
目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog;
最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設
アイスランド旅行記 - $shibayu36->blog;
先日新婚旅行でアイスランドに1週間半ほど行ってきた。どうせならあまり行けないところにということでアイスランドにしたが、行ってみるとこれまで経験したことのない景色が広がっていて、本当に楽しかった。写真をいろいろ撮ったので簡単な旅行記を残しておきたいと思う。 到着〜ブルーラグーン 到着してすぐに全く違う景色が広がっていた。荒野のような雰囲気で、岩場に苔が生えている地帯がずっと続いていた。 最初にアイスランドの有名な観光地であるブルーラグーンに訪れた。ブルーラグーンはアイスランドで一番大きい温泉で、その名の通り非常に青い。 ブルーラグーンも青いが、その周辺ではおそらく鉱物の影響で全ての水が青くなっていた。水の青さによって空が水面に写っていて非常に綺麗だった。 今回泊まったホテルでは、そのホテルに泊まった人だけが入れる温泉であるシークレットラグーンというものがあった。ブルーラグーンよりも自然のまま
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
「師弟登壇2015」ではてなの研修について発表しました - $shibayu36->blog;
pepabo.connpass.com 「師弟登壇2015」ではてなの研修について発表してきました。 speakerdeck.com 今回の発表は 実践で手を動かすのが一番勉強になる 出来るだけ早く知識を身に付け、チーム配属できるように工夫している をテーマに話しました。久々に発表したら緊張して、最初の方全然調子出なかったので、定期的に前に出て発表しないとなあという気持ちになりました。 ちなみにこの発表の後に、@amagitakayosi くんが、新卒研修受けてないという発表をしてて面白いと思いました。まあなんにせよ実践でいろいろやってるのでよし！！！！ speakerdeck.com ちなみに自分の時はどうだったかな―って思ったら、amagiくんに下のような指摘を昨日受けてウケてました。なんで新卒の時から研修について考えているのか！！！！ こんなこと書いてるけど、最近はちゃんと研修やって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
