サービス開発の施策に納得できない時にエンジニアができるアクション - $shibayu36->blog;
サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが
Re: チームのベロシティを上げる vs. 安定させる - $shibayu36->blog;
yigarashi.hatenablog.com これが良い話だなと思ったので感想メモ。 「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象 「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち 何となく、悲観
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
構造が人間の行動を決定する - 「学習する組織」を読んだ - $shibayu36->blog;
組織関連の興味の一貫として、「学習する組織」を読んだ。 学習する組織――システム思考で未来を創造する 作者:ピーター M センゲ英治出版Amazon この本は組織の学習能力に影響を与える五つの重要なコンセプトについて教えてくれる本。特に副題となっている、システム思考という考えを重点的に教えてくれる。600ページ近くある本で読み切るのは結構大変な感じではあった。 読んでみたら、まず最初20%の、なぜチームの学習障害は発生するのかを具体的にビールゲームという話題で教えてくれる部分と、システム思考の話は非常に面白かった。この二つは自分に新しい視点を与えてくれた。この部分を読むのはおすすめ。 一方で、それ以降は結構難解で抽象的なので、自分はいまいち分からないなという感想を抱いた。なので最初20%くらいはちゃんと読んでたけど、流し読みという感じにはなった。後半部分は人を選びそうだった。 この本の中で
OSSライセンス参考資料 - $shibayu36->blog;
OSSライセンスについて調べてたのだけど、毎回どこ見たら良いか分からなくなるのでメモ。OSSライセンスまじむずい。 Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室 ざっと把握するための参考 たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ | コリス いろんなライセンスの特徴知るために 自作ソースコードに、MITライセンスを適用する３つのやり方 | オープンソース・ライセンスの談話室 MITライセンスの適用方法 図解：Apache License2.0の特許条項 | オープンソース・ライセンスの談話室 Apacheライセンスについて オープンソース法 詳しくは
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;
理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者:奥野 幹也技術評論社Amazon 積ん読に入っていたので読んだ。 この本はリレーショナルモデルを理解することによってRDBの知識を深めようというような本。RDBを実践で使っている人がさらに知識を深めるための本という感じ。内容としては重要な理論がRDBと紐付けられて解説されていて面白かった。一方で、専門用語が文章中に多く使われていて、個人的には何か頭に入ってこなかった点は残念だった。 この本を読みながらわからないところを調べていて見つけたのだけど、この本の著者の昔の発表資料である「データベース設計徹底指南！！」がこの本の端的なまとめになっていて、しかも非常に良い資料なので本当におすすめ。本で紹介されているリレーショナルモデルや正規化理論などがわずか15分程度で理解できる
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
自分が入れたEmacs便利拡張・設定集 (2013年版) - $shibayu36->blog;
年末emacs設定大掃除をして、これは捨てられないと思った設定書いてく - $shibayu36->blog; 昨年に引き続き、2013年の自分のemacs.dを振り返るのをやろうと思います。 今年はemacsでいろいろできるようにする、という方向よりも、emacsでの基本操作をどれだけ使いやすく出来るかということを中心にやって来ました。例えば .emacs.dの管理をどうするか コードリーディングや編集を速くするにはどうするか gitとの連携をどうやって簡単にするか この辺りについて１つずつまとめて行きたいと思います。 .emacs.dを管理する .emacs.dの管理って難しいですよね。僕も関西Emacsに参加してから自分が最新のやり方についていけてないなと感じたので、今年はいろいろと見なおしてみました。 基本的なやり方としてはこんなかんじです。 外部elispはpackage.elと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
