子供が小学校に行き渋った時におこなったこと - $shibayu36->blog;
小1の子供が夏休み明けに週1くらいの頻度で「学校に行きたくない」と言い始めた。そういう日はどれだけ行かせようとしてもひたすら泣いて怒って行かない。 話を聞いてみると、本人にとっていろんな不安がある時に行きたくない気持ちになるらしい。たとえば必要な持ち物があると聞いたけどそれが何か分からない、鍵盤ハーモニカのテストがうまくできるか分からないなど。 行きたくないなら最悪行かなくてもいいかと思っていた一方で、学校へ行かないと親はまったく仕事はできなくてイライラしてしまうし、学校の手軽に多様な学習をしてもらえる環境を活用できないし、と可能なら学校に行ってほしいなと感じていた。 なんとか学校に行ってもらうには親の最初の行動が重要そうだなと考え、色々調べながら対策していった。今回は何をしていたかメモを残しておく。 行き渋りや不登校についての知識を得る まずは知識が大切だということで、行き渋りや不登校に
サービス開発の施策に納得できない時にエンジニアができるアクション - $shibayu36->blog;
サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが
価値が出るポイントまで一気に進めてから次のタスクに取り組む - $shibayu36->blog;
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
開発生産性カンファレンス 2024を堪能してきました - $shibayu36->blog;
dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め
本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理
文化による知覚・認識・行動への影響を知る - 異文化理解力を読んだ - $shibayu36->blog;
異文化理解力という本がおもしろいと聞いたことがあり、興味があったので読んだ。想像以上に面白く夢中になって一気に読んでしまった。 異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養 作者:エリン・メイヤー,田岡恵英治出版Amazon この本は、国ごとの文化が、そこに属する人々の知覚・認識・行動へどれほど影響を与えているかを教えてくれる。指標として8つを提示し、それぞれの中で各国がどのような位置にいるかを相対的に示してくれる。8つの指標とは次のようなものだ。 コミュニケーション：ローコンテキストvsハイコンテキスト 評価：直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック 説得：原理優先vs応用優先 リード：平等主義vs階層主義 決断：合意志向vsトップダウン式 信頼：タスクベースvs関係ベース 見解の相違：対立型vs対立回避型 スケジューリング：直線
良いテストケースの作成手法を学ぶ - 「はじめて学ぶソフトウェアのテスト技法」を読んだ - $shibayu36->blog;
ソフトウェアテストに関する知識をもう少し言語化したいなと思い、「はじめて学ぶソフトウェアのテスト技法」を読んだ。 はじめて学ぶソフトウェアのテスト技法 作者:リー コープランド日経BPAmazon この本では主に良いテストケースの作成手法について学べた。良いテストケースとは「最小の時間と労力でほとんどのエラーを検出する可能性がもっとも高くなるようなテストケース」のこと。これにできる限り近づけられるようにテストケースを工夫する。 良いテストケースを作るためにどういう技法があるかをこの本はいくつも教えてくれる。自分がこれまでテストを書いていると「こういうテストの方がなんとなくベターだよな...?」みたいに感覚的に考えていたところを、言葉として定義してくれることで構造化できるのはありがたかった。たとえば 同値クラステスト 同じグループのテストが、以下を満たせば同値クラスを形成する 同じ機能をテス
MySQL即効クエリチューニング読んだ - $shibayu36->blog;
MySQL即効クエリチューニング ThinkIT Books 作者:yoku0825インプレスAmazon 最近クエリチューニングの仕事があったので、少し深めに知ろうと読んだ。 MySQLの内部構造がどうなっているかは置いておいて、どうすればクエリの問題を把握できるかが素早く知れる良い本だった。90ページくらいですぐ読めるのも良い。個人的にはHandler_%変数を使った調査、innotopによる状況可視化、sys.innodb_lock_waitsによるロック状況の可視化あたりが非常に参考になった。 ちなみにさらに内部構造に踏み込んで理解しようとするなら、以下の記事がおすすめ。 雑なMySQLパフォーマンスチューニング MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ Rails Developers Meetup 2018 で
優先度付きキューにも使われる二分ヒープ構造をRubyで実装してみる - $shibayu36->blog;
アルゴリズム図鑑 絵で見てわかる26のアルゴリズム 作者:石田保輝,宮崎修一翔泳社Amazon アルゴリズム図鑑を眺めていて、二分ヒープ構造は優先度付きキューに使われることを知った。面白いなーと思うと同時に、そういえば二分ヒープ構造の実装をしたことがなく、あまり理解できていないことに気づいた。そこで簡単にRubyで実装をしてみたのでメモ。簡単なテストケースを作ったので多分合ってると思うけど、もしかしたらバグっているかも... 二分ヒープの詳細は二分ヒープ - Wikipediaも参考。 【2023/01/03 14:01追記】要素数が1の時に要素が空にならないバグがあったので修正しました。コメントありがとうございます。https://github.com/shibayu36/algorithms/commit/6c2ce588f7bc7fb890c6a560c7ab062c6f531a9a
株式会社はてなを退職しました - $shibayu36->blog;
2021年8月13日の本日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 本当に色々経験できたのだが、自分の中で本当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere
「プロフェッショナルSSL/TLS」を読んだ - $shibayu36->blog;
[asin:4908686009:detail] 最近ふとSSL/TLSの仕組みについて知りたくなったので、「プロフェッショナルSSL/TLS」を読んだ。 かなりいろんな話題を網羅していて、かつ具体的な設定例なども書かれていて良かった。TLSに関する仕事をするときや、SSL/TLSやHTTPS周りで何回かハマったことがあるなら非常にお勧めできる。 仕組みを理解したいなら1章 SSL/TLSと暗号技術・2章 プロトコル・3章 公開鍵基盤が参考になった。実運用なら8章 デプロイ・9章 パフォーマンス最適化・16章 Nginxの設定あたりが参考になりそう。またTLS周りでハマった時のトラブルシューティングには12章のOpenSSLによるテストが使えるだろう。 ただ最新のTLS 1.3に関してはそこまで多く言及はなかった（電子書籍版の巻末の付録のみ）ので、これについては別書籍や別資料で学ぶ必要があ
タスクの依存関係とリソースの両方を考慮してプロジェクトマネジメントをするCCPM理論を学んだ - $shibayu36->blog;
自分のプロジェクトマネジメントのスキルをもう一つ伸ばしたくて、タスクの依存関係とリソースの両方を考慮してプロジェクトマネジメントをするCCPM（クリティカルチェーンプロジェクトマネジメント）理論を学んだ。この理論を学んだおかげで、よりプロジェクトの計画作りや、プロジェクトの現在の危険度の把握をやりやすくなったと感じる。アジャイルの手法であるベロシティでの管理ともうまく組み合わせられそうだったので、今度試してみたい。 参考にした書籍 クリティカルチェーン 作者:エリヤフ ゴールドラットダイヤモンド社Amazon 進む！助け合える！ＷＡ（和）のプロジェクトマネジメント――プロマネとメンバーのためのＣＣＰＭ理論 作者:宮田 一雄ダイヤモンド社Amazon アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす 作者:宇治川浩一株式会社ビーイングAmaz
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
TypeScriptの型を手に馴染ませるためにやっていること - $shibayu36->blog;
最近TypeScriptが好きで勉強していっている。しかしなかなか型定義周りが手に馴染まず、少し複雑な型定義を読んだり、自分でユーティリティ型を定義したりすることが難しかった。 そこで型を手に馴染ませるために色々学習をしてみたので、やっていることをメモしておく。 まずざっとTypeScriptの型概要を学ぶ まずTypeScriptでの型を簡単に学ぶには以下の2つの資料がわかりやすかった。 TypeScriptの型入門 - Qiita TypeScriptの型初級 - Qiita ひたすら型演習をする 資料を読むだけでは全く手に馴染まないと思ったので、その後ひたすら型演習をしている。 まずは TypeScriptの型演習 - Qiita 。これは先程の型初級、型入門の記事を書いた人が演習問題を作っているため同じ流れで学習でき、さらに解説編も充実しているので、手を動かしながら学ぶのに最適であ
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
