部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
Jamboardを使ってオンラインでプラニングポーカーをする - $shibayu36->blog;
Jamboardを使ってオンラインでプラニングポーカーをするお試しをしてみたので知見を共有します。 課題 リモートワークで全員がオンライン前提となり、かつプライベートエリアなのでミーティングではビデオを付けたくないメンバーがいる。もちろんミーティングの円滑化のためにビデオを付けることを強要したくはない。 しかし、プラニングポーカーはこれまで指でフィボナッチ数を出すというモデルでやっていた。ビデオを付けない人がいる場合、このやり方ではプラニングポーカーができない。 こういう状況で、どのようにプラニングポーカーで見積もりを行うかが課題となっていた。 Jamboardを使ってオンラインでプラニングポーカーをする解決案 GoogleのアプリでJamboardというホワイトボードアプリがある。これを使ってプラニングポーカーをしてみた。 やり方 付箋でフィボナッチ数とカーソル置き場を並べたJamboa
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん！最悪！ 会社にこういう問題あるじゃん！なんで直らないの！最悪！ みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。
アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない！」「障害対応をもっとうまくやる方法はないのだろうか？」と思う人には参考になる部分が多いと思う。 個人的にこの本の中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ
PostgreSQLでSQLチューニングや障害状況調査に使ったクエリ達まとめ - $shibayu36->blog;
最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post
「みんなのGo言語」を読んだ - $shibayu36->blog;
Go言語の学習のため、A Tour of Goに引き続き、「みんなのGo言語」を読んだ。 みんなのGo言語[現場で使える実践テクニック] 作者:松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太技術評論社Amazon 「みんなのGo言語」はGo言語を実践的に使うためのTipsがいろいろまとめられていて非常に良かった。Go言語のA Tour of Goをやったけど、次にどうすればよいかわからない、具体的にGoの良い書き方が分からないという人が読むと非常に勉強になりそう。 僕はまだGoをそこまで書いていないので、「第1章Goによるチーム開発のはじめ方とコードを書く上での心得」と「第4章コマンドラインツールを作る」が非常に参考になった。例えば以下のようなものが参考になった(数字はKindleのロケーション番号)。 Goプロジェクトのプロジェクト構成やディレクトリ構成 519, 2389
雑に書いたブログ記事が問題を起こさないようにする工夫 - $shibayu36->blog;
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog; で、ちょっとしたことでも雑にブログに書いておくと良いことが起こるよということを書いた。さらに余談として最低限の雑さについても書いた。 これをきっかけに、公開の場でアウトプットする時の最低限の雑さとはなんだろうという疑問が自分に生まれ、雑さによる問題や、それを引き起こさないようにするための自分の工夫について少し頭がまとまってきたので、自分の考えを書いておく。 過度な雑さから生じる最大の問題 まずあまりにも雑に公開の場に書いてしまった場合の最大の問題について考える。この時、一番起こってほしくない問題は、「読み手が誤った情報を正しい情報と信じてしまう」ことだと考えた。 あまりにも雑な文章は読み手の誤認を引き起こし、正しい情報ではないのに正しいと読み手が解釈してしまう問題がある。正しいと解釈してシ
2016年に買って面白かった漫画 - $shibayu36->blog;
今年は漫画を買うことが多かった。このマンガがすごい！とか、マンガ大賞とか、数巻で完結するおすすめ作品まとめとか、そういうのでいろいろ調べて買って読んでいった。2016年ももう終わるので、買って読んだ本で面白かったものを１つずつ振り返ってみる。 ドロヘドロ ドロヘドロ (21) (BIC COMICS IKKI) 作者:林田 球小学館Amazon ようやく連載が再開してくれた。ドロヘドロはまじで最高。今まで読んだ中で一番面白い。とにかく全てのキャラが立っていて、しかも伏線がむちゃくちゃ散らばっていて、何度読んでも新たな発見がある。もうちょっとで終わりそうだけど、とにかく次の巻が待ち遠しくて仕方がない。 ダンジョン飯 ダンジョン飯 3巻 (HARTA COMIX) 作者:九井 諒子KADOKAWAAmazon ファンタジーの世界観が完全にできあがってて良い。個人的にはミミックと宝虫の話が好き。
AMPについてのコンテンツ消費者としての感想メモ - $shibayu36->blog;
昨日、「AMPが導入された結果、現時点ではモバイルのブラウズ体験が大きく損なわれてるのですが、そう感じるのは僕だけでしょうか」とTwitterでつぶやいたら、いろいろ反応があり、いろんな観点を知ることが出来たのでメモしておく。なお、自分自身はまだAMPのコンテンツを実装したわけではなので、開発者の知識はなく、ただのコンテンツ消費者としての知識しかない。開発している人から見るとまた違った見え方があるかもしれない。 コンテンツ消費者側のメリット・デメリットという観点 AMPによるコンテンツ消費者側のメリットは速度面だが、モバイルを利用していた時に現時点では速度に困っていなかったので、自分はメリットを享受できていない 現時点では、いろんな理由によりユーザ体験が損なわれている部分がある ユーザ体験が損なわれている例としては、プラットフォームの問題とコンテンツ制作側の問題の両方がある プラットフォー
MySQLを使って簡易的にサービスの数値を集計する - $shibayu36->blog;
最近色んな機能を作る時に、簡単に数値を集計してみて様子を見るということがよくあった。そこで今回はその時に使ったクエリの紹介。 【2016/10/18 10:28追記】 社内でHOUR関数とかGROUP BYにalias名を使ったらもっと簡単にできるよと言われたので、それぞれ追記してみます。 日間の作成数の集計 1日このアクションが何回行われたかとかが集計できる。date_columnにはcreatedみたいなカラムを指定し、table_nameには集計したいテーブルを入れる。他にもCOUNTの仕方を工夫したらいろいろ集計できそう。 SELECT DATE(date_column) as date, COUNT(*) as count FROM table_name GROUP BY DATE(date_column); 【改善版】 SELECT DATE(date_column) as d
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
プロジェクト単位でElasticsearchのローカル開発環境を作成する - $shibayu36->blog;
最近Elasticsearchを触っていて、まずはローカル開発環境を作ることになった。ただ、Elasticsearchはバージョンがかなり変わり、別プロジェクトと利用したいバージョンが異なっていたので、プロジェクト単位で使い分けるにはどうすればよいかを考えた。 やりたいこと プロジェクトごとにElasticsearchのバージョンを切り替えられるようにしたい MySQLだったら同じようなものにmysqlenvなどがある また、他の人が一瞬で環境を整えられるようにしておきたい 利用するプラグインなども含めて一瞬で バージョンを上げる時もローカル環境なら簡単にあげたい 作戦 Elasticsearchはここ からダウンロードして、特定のディレクトリに展開するだけでも利用できる そこでプロジェクトルートのelasticsearch/ディレクトリ以下に展開し、ここに展開したバイナリを利用するように
コードレビューを段階的に行ってもらう話 - $shibayu36->blog;
最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog;
最近フロントエンドの速度改善をほんの少しだけやって、いろんな資料を参考にしたので、今後また速度改善をする時に備えて、参考になった資料をまとめておく。今回パフォーマンス改善やった項目としてはExpiresヘッダ付ける、gzip圧縮かける、JSをbodyの一番下にとか基本的なことしかやらなかったので、そのあたりはこの記事ではまとめていません。 今回は「測定する」「ブラウザがどう表示しているか知る」「改善を検討する」の流れで調べていったのでその順にまとめる。 測定する 何はともあれ測定しないと何も始まらないので、まずは測定の仕方について調べた。 PageSpeed Insights( https://developers.google.com/speed/pagespeed/insights/ )と、webpagetest( http://www.webpagetest.org/ ) はとりあえ
「シバソン」という名の何も準備しないイベント - $shibayu36->blog;
最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。 Kyoto.pm 以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。 ただ問題点がいくつかあった。 一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声
ghi便利だった - $shibayu36->blog;
今日いろいろ探してたら、githubのissueをいろいろ扱ってくれるghiというのを発見したので使った。便利だった。 ghi listとかしたら、そのレポジトリのopen issueを出してくれる $ cd prepan $ ghi list # CPAN-API/prepan open issues 51: Allow login with CPAN 1 50: When editing an existing entry, make the button "Save" not "Post" 48: Add permalinks to comments 43: Can't remove entry from web ui 42: Twitter profile image doesn't show bug @ 40: Comment Edit and or Preview option
「エンジニアマネージャー論と学びを抽出する努力を続けること」を読んで - $shibayu36->blog;
http://wazanova.jp/items/1574を読んで、非常に参考になったのでいつも本を読んで感想書いている時と同様、思うところについて書いてみる。 今回は以下の二つのポイントについて非常に感銘を受けた。 やるべきことを毎日洗い直して、絞り込むことが大切 適切な意思決定プロセスとメンバとの良好な関係が築ければ、95%は大丈夫 やるべきことを毎日洗い直して、絞り込むことが大切 上であげたブログに 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 ということが書いてあり、直近の自分の状況もあいまって非常に納得できる言葉だなと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
