タグ

ブックマーク / blog.shibayu36.org (41)

  • 「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;

    最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」というが出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon このは、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ当に良いであった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番

    「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
    kirine
    kirine 2018/03/28
  • Mackerelの思想や出来ることを知る - Mackerelサーバ監視実践入門を読んだ - $shibayu36->blog;

    最近Mackerelを触ることが多く、Mackerelで何が出来るのかを知りたいと思い、Mackerelサーバ監視実践入門を読んだ。 Mackerel サーバ監視[実践]入門 作者:井上 大輔,粕谷 大輔,杉山 広通,田中 慎司,坪内 佑樹,松木 雅幸技術評論社Amazon このでは、Mackerelにはどのような機能があるのかを広く紹介している。また、実際に使っているユーザの事例もいくつか知ることができる。そのため、Mackerelでサーバを監視したい!と思っている人や、監視をし始めたけどさらにどういうことが出来るのか知りたいと思っている人には非常に参考になりそう。僕も、さらにどういうことが出来るのか知りたいという気持ちだったので、非常に参考になった。 個人的には、このの内容から、Mackerelはサーバ監視サービスとしてだけではなくて、サーバ管理ツールとして使って欲しいという思いが

    Mackerelの思想や出来ることを知る - Mackerelサーバ監視実践入門を読んだ - $shibayu36->blog;
  • マネジメントの要素を知る - 「マネジメント入門」を読んだ - $shibayu36->blog;

    マネジメントの技術全体に興味があるので、その要素にはどういうものがあるかを知っておくために「マネジメント入門」を読んだ。 マネジメント入門---グローバル経営のための理論と実践 作者:スティーブン P. ロビンス,デービッド A. ディチェンゾ,メアリー・コールターダイヤモンド社Amazon このは、マネジメントにはどういう話題があり、それぞれにはどのような研究や考えがあるかについて、ざっくり概要を教えてくれるだった。マネジメントの機能を、計画する、組織する、リーダーシップを発揮する、コントロールするの四つに分類して話を進めている。目次は以下のとおり。 イントロダクション: マネジャーとマネジメント・マネジメント環境・マネジメント全般に関わる課題 計画する: 意思決定の基礎・計画策定の基 組織する: 組織の構造と設計・人材を管理する・変革とイノベーションのマネジメント リーダーシップ

    マネジメントの要素を知る - 「マネジメント入門」を読んだ - $shibayu36->blog;
  • 組織設計を体系的に学ぶ - 「組織デザイン」を読んだ - $shibayu36->blog;

    自分は組織での行動やマネジメントの分野に興味があるのだけど、その一貫でそもそも組織とはどう設計していくのかの基礎的な知識を学びたいと思ったので、評価の高い「組織デザイン」を読んだ。とにかく面白く、読んで非常に良かった。学ぶことが多すぎて、読書ノートが膨大になってしまった。 組織デザイン (日経文庫) 作者:沼上 幹日経済新聞出版Amazon このでは、組織を設計するために必要な「組織」についての基的な知識を体系的に教えてくれる。これを読めば 組織というのは、分業と調整から成り立っていること 組織形態の基形である、機能別組織・事業部制組織・マトリクス組織それぞれの特徴 分業の様々なタイプのメリット・デメリット。垂直分業、水平分業、並行分業、機能別分業など。 分業によって得られた成果を統合する事前の調整手段である標準化という考え方 分業によって得られた成果を統合する時の例外への対応であ

    組織設計を体系的に学ぶ - 「組織デザイン」を読んだ - $shibayu36->blog;
  • 「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;

    最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon このLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる。このを読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの?ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ

    「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;
  • OSSライセンス参考資料 - $shibayu36->blog;

    OSSライセンスについて調べてたのだけど、毎回どこ見たら良いか分からなくなるのでメモ。OSSライセンスまじむずい。 Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室 ざっと把握するための参考 たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ | コリス いろんなライセンスの特徴知るために 自作ソースコードに、MITライセンスを適用する3つのやり方 | オープンソース・ライセンスの談話室 MITライセンスの適用方法 図解:Apache License2.0の特許条項 | オープンソース・ライセンスの談話室 Apacheライセンスについて オープンソース法 詳しくは

    OSSライセンス参考資料 - $shibayu36->blog;
  • 特定のHTML属性を追加するだけでリンククリック計測したい(Google Tag Managerを利用して) - $shibayu36->blog;

    今日はGoogle Tag Managerの設定をすることで、自分が好きなエリアのリンククリック計測を簡単にする方法について書く。 課題 クリック計測は自作で作るのは大変 Google Tag Managerで計測することもできるが、計測対象を増やすためにタグを毎回一つ増やすというのも大変 他の開発メンバーに教えるのもだるい Google Tag Managerを一回設定しておけば、あとはちょっとサイトのHTMLをいじると計測を追加できるようにしたい やりたいこと Google Tag Managerを一回設定しておけば、あとはHTMLにちょっとした属性をいれるだけで、その要素内のリンククリックを計測したい。つまり、Google Tag Managerを一度設定しておくだけで、 <section data-gtm-link-click-action-name="RecommendedBo

    特定のHTML属性を追加するだけでリンククリック計測したい(Google Tag Managerを利用して) - $shibayu36->blog;
  • いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;

    先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう

    いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
  • フロントエンド速度改善でやったこと(Expiresヘッダ、faviconのgzip圧縮、JSの読み込み遅延化) - $shibayu36->blog;

    フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx

    フロントエンド速度改善でやったこと(Expiresヘッダ、faviconのgzip圧縮、JSの読み込み遅延化) - $shibayu36->blog;
  • 学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;

    僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的でを読むか、自分の中で明

    学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;
  • 2014年に読んだ本の中で、年末年始に読みたいおすすめ本を紹介します - $shibayu36->blog;

    年末年始休暇は読書チャンスということで、僕が2014年に読んだの中で年末年始に読みたいおすすめを紹介します。それ以外のは http://blog.shibayu36.org/archive/category/bookにていろいろ紹介しています。 マネジメント編 今年はマネジメント関連のをひたすら読んだので、この辺りのおすすめが多めです。 そうか、君は課長になったのか。 平易な言葉でマネジメントのエッセンスを教えてくれる「そうか、君は課長になったのか。」はマネジャー数ヶ月の人にとっておすすめなです。200ページくらいでさらった読めます。 そうか、君は課長になったのか。 (ポケット・シリーズ) 作者:佐々木 常夫WAVE出版Amazon 紹介記事 : マネジャーの仕事のエッセンスが学べる「そうか、君は課長になったのか。」を読んだ - $shibayu36->blog; 1分間マネジャ

    2014年に読んだ本の中で、年末年始に読みたいおすすめ本を紹介します - $shibayu36->blog;
  • 仕事の価値と責任範囲を伝え、任せる - 「1分間モチベーション」を読んだ - $shibayu36->blog;

    最近はマネジメントにおけるモチベーション管理について学習を深めている。その一環として1分間モチベーションを読んだ。 1分間モチベーション パンローリング株式会社Amazon このはメンバーに良い仕事をしてもらうために、どのようにモチベーションを管理していくかについて書かれている。おおまかに3つのことを説明していて、以下のトピックについて学ぶことができる。 やりがいがある仕事をするにはどうすればよいか メンバーが自己管理をしながら目標を達成するにはどうすればよいか モチベーションを鼓舞するような声援(援助)の方法はなにか このを読むと、なぜ目標設定が必要なのか、仕事をどのようにして任せるほうが良いのかなどのことが分かってくるので、非常に参考になった。新しくマネジャーになり、仕事をメンバーに任せるということを初めてするような人には非常におすすめなだと思う。 今回は次のことが興味深かったの

    仕事の価値と責任範囲を伝え、任せる - 「1分間モチベーション」を読んだ - $shibayu36->blog;
  • 挫折しないための英語勉強 - $shibayu36->blog;

    最近また英語の勉強をしている。僕自身は全く英語の勉強が続いたためしがなくて、毎回はじめてから1~2ヶ月くらいたつと英語の勉強に飽き、挫折してしまう。けれど今回は何とかして続けたいと思って、いつもとは全く違うアプローチで英語の勉強を続けたところ、今のところ6ヶ月くらい英語を続けられている。 今日はどんな感じで英語勉強してきたか軽く書いてみたい。 挫折しないために決めた方針 これまでは毎回英単語を勉強したり、英語を読んだり、英語のニュースを聞いてリスニングの勉強をしたり、といういわゆる英語の勉強をやってきた。でもこれだと自分は挫折するということが分かった。 今回は海外の人と友だちになれればモチベーション維持できるのではと考えて 海外の人と友だちになってチャットしたり会話したりを勉強の中心にする チャットや会話を円滑にするための勉強をする という方向性でやってみた。 効果的だったもの 効果的

    挫折しないための英語勉強 - $shibayu36->blog;
    kirine
    kirine 2014/06/06
  • 開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;

    最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく

    開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
    kirine
    kirine 2014/05/14
  • なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;

    最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良いだった。このを読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと

    なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
    kirine
    kirine 2014/04/04
  • レビュータイムの導入・消滅・再導入 - $shibayu36->blog;

    今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi

    レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
    kirine
    kirine 2014/03/14
  • 「ピープルウェア」を読んだ - $shibayu36->blog;

    この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者:トム デマルコ;ティモシー リスター日経BPAmazon このはソフトウェアのプロジェクトが失敗する時は、原因が単なる技術的問題だけである場合は少なく、その前段階の人とのコミュニケーションレベルにも問題があるときが多いという話をしている。それでプロジェクトを進める上での人に関する問題をテーマにしている。 最近は個人で作業をするというよりも、チームで仕事を進めるということが多くなりつつあるので、非常に参考になる事が多かった。印象に残った点を書いていく。 早くヤレとせかされると 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 耳が痛い。でも自分自身が言われても直感的にはそうなりそうという感じだと思った。 またこのの関連する内容に「

    「ピープルウェア」を読んだ - $shibayu36->blog;
    kirine
    kirine 2014/03/05
  • 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のプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の

    Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
    kirine
    kirine 2013/12/23
  • 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;

    最近Dockerとか、serfとかその辺りのツールが流行ってる。その中でとりあえずDockerはテスト環境やCIでは使えるかもしれないけど、実際にwebサービスが動いているものに使えるかどうかはまだわかんないねーという流れになっていた。 まあでもとりあえず動いているwebサービスDockerでやったらどうなるかというのを知りたいというのがあって、いろいろ機会があったので4人で3日くらいやってプロトタイプ実装というのをしてみて試した。 結局出来たこと 結局以下の様なものが実際に動くところまで行った。 AWSのような環境がなくてもDockerさえ動けばブルーグリーンデプロイ出来る VPSだろうが自宅サーバだろうがなんでも ボタンだけで「番用環境構築」「番前の確認」「番切替」が出来る web n台くらいを一セットとみなした環境をボタンひとつで簡単に作れる Docker imageのビルド

    本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog;
    kirine
    kirine 2013/12/21
  • チームで開発する際に自分が心がけていること - $shibayu36->blog;

    最近結構大きめなチームで開発しているのだけれど、そこで気をつけていることをちょっと書いてみる。 チームを開発していると 自分がメインで開発している機能 自分以外がメインで開発している機能 の二つが必然的にできてくる。チームがある程度大きくなってくると、自分がメインで開発している機能は自分が一番詳しくなるし、自分以外がメインで開発している機能に関しては自分がいちばん詳しいわけではなくなる。 そこでこの二つについて自分が心がけていることを書いてみる。 自分がメインで開発している機能 この時考えているのは、 自分一人だけの知見では見逃すことも多いので、出来るだけ早めに意見を集める 他の人の意見に左右され過ぎない 動くものが必要な場合は最小工数で作る それは全て捨てる気持ちで作る これらを考えて、僕は自身では以下の様なプロセスで機能開発をしていっている。 その開発に関する調査をする その機能に関す

    チームで開発する際に自分が心がけていること - $shibayu36->blog;