開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
第二子のための4ヶ月間の半育休生活振り返り - $shibayu36->blog;
6月の第二子の出産に伴い、1歳9ヶ月 + 0歳という子供の構成になった。これは絶対に大変だろうということで、出産と同時に4ヶ月の半育休(僕の場合は育休を取りながら週1日働く)を取ることにした。今回は育休の振り返りを書いてみる。 どんな形態の育休を取ったか 第二子出産翌日から、4ヶ月半程度の育休を取得した(6月後半〜10月いっぱいまで) 毎週火曜だけ、10:00-16:30の勤務をした。16:30に帰っているのは第一子を保育園に迎えに行くため 最初に言いたいこと まず最初にこれだけは言いたいことがある。それは半育休を取るのではなく、可能なら完全育休をとるべきだったということだ。第一子ならまだしも、第二子の出産なら完全育休にするべきであった。 多少仕事を見れたという良い面はあったが、それよりも疲れや焦りを感じる辛さの方が上回った。また疲れなどの理由で、出社はしているけど結局ほぼ仕事は出来ない状
「1人でできる子になるテキトー子育て」読んだ - $shibayu36->blog;
子育てに迷ったときに判断するための一つの情報源として読んだ。 1人でできる子になるテキトー子育て 世界トップ機関の研究と成功率97%の実績からついに見つかった! 作者:はせがわわかSBクリエイティブAmazon この本は研究の内容をベースとして、子育てのときに親がどういう行動を取れば良いか教えてくれる本。自分が思っていた良い行動は、実は子どもにとっては逆効果だった、みたいなことを知れて良かった。例えば以下のような話が面白かった。 人間の脳は否定語を理解するのが難しい そのため、「騒いじゃ駄目」と言うと、「騒ぐ」と言う言葉の印象が強く残り、余計騒いでしまう 肯定語に言い換えて、「ここでは静かにしようね」と言うだけで伝わりやすくなる 一方、この本は良い行動を年齢別にまとめているわけではないので、今自分にとって必要な情報をかいつまんで読むのは大変だった。その点は残念。年齢別にまとまっていないので
良い制度には「カイゼンループ」が組み込まれている - $shibayu36->blog;
最近いろんな制度や仕組みを見ていて、良い制度には「カイゼンループ」が組み込まれているなと感じた。(カイゼンループは、トヨタの「カイゼン」と、繰り返しの「ループ」を組み合わせて、勝手に造語してみた) カイゼンループとは、制度・仕組み・関わる人・チーム・組織などの「カイゼン(改善)」がくり返し行われるようになっている状態のこと。カイゼンループが組み込まれていると、 制度が組織の現状に合わせて改良され、それにより組織にフィットした制度になり、形骸化しない メンバーがどんどん成長し、より高度で柔軟な動きができるようになる などといった効果があるように見える。 抽象的な話をしてもよく分からないと思うので、ここからはそのように感じた具体的な例をいくつか挙げてみたい。 開発フローのスクラム まずいちばん分かりやすい例が開発フローであるスクラム。スクラムにはスプリント期間ごとの振り返りにより、「カイゼンル
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
育休で得られるのは育児のサポートだけではない - $shibayu36->blog;
最近子どもが産まれて、しかもありがたいことに2ヶ月間育休を取れることになった。育休を取り始めて今2週間くらいなのだけど、育休で得られるのは育児のサポート(サポートという表現は適切じゃないかもしれないけど...)を行うことだけじゃないなと思ったので考えを書いておく。 自分が育休を取ると、妻と一緒に育児を行うことができ、育児の負担を二人で分担することができる。しかし、それだけじゃなく、育休を取ることで以下のメリットを得られると感じた。 育児の大変さを知ることができる 育児のやり方の認識を一致させ、自分一人で全て出来るようになる 育児の大変さを知ることができる 育休を取ってみて、「一日中」育児をするということは非常に大変であるということが分かった。これは当たり前のことだと思うけど、実際に仕事をしていて夜だけ育児をするだけだとなかなか実感できないことだった。 例えば一日中育児をしていると、子どもを
育児にバランスボールが便利 - $shibayu36->blog;
育児にバランスボールがまじで便利。 Active Winner バランスボール 65cm シルバー アンチバースト 分厚い 滑り止め加工 フットポンプ付 ヨガ ピラティス 筋トレ ストレッチ オフィスチェア ACTIVEWINNERAmazon 最近息子は布団に寝かせると寝なくて、とにかく抱っこして立つことを強制してくる。そのためこれまでひたすら立ちながら揺らし続けるということをしていて、テレビを見るくらいしか出来ることがなく大変だった。 そういうことをfacebookに書いたらバランスボールがいいらしいということで使ってみた。するとバランスボールで強めにバインバイン揺れておくと、それだけで結構泣き止むようになった。最高。 またバランスボールを使っていると、立っている時と違って手に力がそこまで必要ないし、ある程度落ち着いて座っていられるため、机にiPadを置いて本を読んだり、Switchの
どうやったら発見した問題をうまく放置できるようになるのか - $shibayu36->blog;
仕事をしていると、様々な問題が発見される。問題を発見した時、とにかくすぐに対処しようとしてしまうことが多い。しかし、そうしていると、タスク量が増えてきたときに問題解決に忙殺され、もっと重要なことに取り掛かれないということが起こりがちである。 「イシューからはじめよ」によると、忙殺されないためには、問題の重要度を見極めて、重要なものだけ重点的に取り組むべきであり、そうでない問題は放置すべきと書かれている。 しかし、そんなことは頭では分かっているのである。それでも問題を見るとすぐに解決しようとしてしまうのである。では、どうやったら発見した問題をうまく放置できるようになるのか。 それについて最近1週間ほど考えていたのだけど、とりあえず以下のことをやってみようという気持ちになった。 それが何か問題かと自問する 問題を少し置いておく 問題を書き出してみて、他の問題と比較する それが何か問題かと自問す
ディレクターを経験して良かった - $shibayu36->blog;
この記事は、はてなディレクターアドベントカレンダー2016の19日目です。昨日は id:shimobayashi の「効率的で課題解決的な態度にひそむ罠について」でした。 こんにちは、はてなでアプリケーションエンジニアをやっているid:shiba_yu36です。僕は現在はエンジニアをやっていますが、一度はてなでディレクター(いわゆるプロダクトマネージャー職)を経験しています。ディレクターに挑戦した理由は、マネジメントという分野にも少し興味があったためです。しかし、当時なかなかディレクターという職種を楽しむことが出来ず、結局1年足らずで挫折してエンジニアに戻ったという過去があります。 このような経験でしたが、僕はとにかく一度ディレクターを経験して良かったと思っています。なぜならディレクター経験がエンジニアとしての今の自分に非常に活かされているからです。そこで、今回は自分がディレクターを経験し
Google Mapのオフラインエリアが海外旅行で非常に役立った件 - $shibayu36->blog;
この前海外旅行に行った時に、Google Mapのオフラインエリアという機能が非常に役に立ったので紹介。 オフラインエリア機能とは オフラインエリアという機能は、特定のエリアのマップ情報をインターネットがつながっている時にダウンロードしておくことで、オフラインのときにも利用できるようにするものだ。通常日本にいるときは、このような機能を使いたいことはほとんどないので全く知らなかった。 今回の旅行中は海外でも使えるモバイルWiFiなどを借りてはいかなかったため、紙の地図を使って適当に探索しようと思っていた。しかし、この機能があることに気づいたので試してみると、ネットがなくても現在位置とマップが出るようになり、通常のGoogle Mapとほぼ同様に利用することができた。 簡単な使い方 特定地域を検索し、その地域の情報パネルを出し、ダウンロードボタンを押すだけ。詳しくは ダウンロードしたエリアをオ
アイスランド旅行記 - $shibayu36->blog;
先日新婚旅行でアイスランドに1週間半ほど行ってきた。どうせならあまり行けないところにということでアイスランドにしたが、行ってみるとこれまで経験したことのない景色が広がっていて、本当に楽しかった。写真をいろいろ撮ったので簡単な旅行記を残しておきたいと思う。 到着〜ブルーラグーン 到着してすぐに全く違う景色が広がっていた。荒野のような雰囲気で、岩場に苔が生えている地帯がずっと続いていた。 最初にアイスランドの有名な観光地であるブルーラグーンに訪れた。ブルーラグーンはアイスランドで一番大きい温泉で、その名の通り非常に青い。 ブルーラグーンも青いが、その周辺ではおそらく鉱物の影響で全ての水が青くなっていた。水の青さによって空が水面に写っていて非常に綺麗だった。 今回泊まったホテルでは、そのホテルに泊まった人だけが入れる温泉であるシークレットラグーンというものがあった。ブルーラグーンよりも自然のまま
知識ゼロからElasticsearchを実践で使えるようになろう！ - $shibayu36->blog;
以前少しだけElasticsearchを触った時に、自分流Elasticsearch入門 - $shibayu36->blog; というElasticsearchに入門した時のメモをまとめていた。しかし、その頃はElasticsearchを使って完全に一人で一つの機能を作るというところまではいけなかった。 最近になってまたElasticsearchを一から導入する仕事をすることになった。この時以前自分がまとめた記事を読みながらやっていたのだが、実践で一から導入するためにはこの記事だけでは知識が足りなかった。 そこで、前の記事の知識をベースに、一から導入するために少しずつ学んでいき、自分のブログにまとめるなどのことをしてきたので、今回はその締めくくりとして、知識ゼロからElasticsearchを使えるようになるために学習したことについて書いておきたいと思う。 今回書くこと・書かないこと 今
Elasticsearchのインデックス定義を設計する手順 - $shibayu36->blog;
Elasticsearchを使おうとすると、まずアプリケーションの仕様にしたがってインデックス定義やマッピング定義を設計しなければならない。これはMySQLを使っていてスキーマを考えるフェーズに相当する。 この時、考えることが非常に多く、いろいろなドキュメントを参照し設計したので、今回はその手順について書いていきたいと思う。 インデックスやマッピングが何かという話は、次の記事を参考に。 Elasticsearchチュートリアル - 不可視点 Mapping and Analysis | Elasticsearch: The Definitive Guide [2.x] | Elastic また対象とするElasticsearchのversionは記事執筆時点の安定版の2.3.5とする。 今回サンプルとする例 実際のプロジェクトを参考例にすることは流石にできないので、今回はブログの記事を検索
CSSのブラウザサポート状況を自動でチェックできるdoiuseが便利 - $shibayu36->blog;
最近書いているCSSがそもそも今サービスが推奨しているブラウザでサポートされているのかチェックするのだるいと思っていたら、doiuseという便利なツールを見つけた。 doiuseとは https://www.npmjs.com/package/doiuse CSSのブラウザサポートのチェックをしてくれるモジュール。caniuse のデータベースを利用して、ブラウザと自分が書いているCSSを指定して、サポートされていないCSSの書き方を見つけてくれる。 試す環境を用意する とりあえず試すための環境を用意する。適当なディレクトリを作って、必要なライブラリをインストールする。また、検証するためにbootstrapも入れておく。 $ mkdir try-doiuse $ cd try-doiuse $ npm install --save-dev doiuse $ npm install --sa
Emacsで今編集しているJSのテストのみ実行する(Karma + Mocha環境の場合) - $shibayu36->blog;
blog.shibayu36.org 前回の記事でKarma, Mocha, Chaiを使ったJSのユニットテスト環境を作ることができた。しかしテストを書き続けていると、「手元で全体のテストを再実行するのに時間がかかる」という問題が起こった。そこで今回は「今編集中のテストのみをEmacsから実行する」という作戦で問題を解決しようと考えた。 今回のサンプルコードは https://github.com/shibayu36/typescript-project-sample/tree/9e6baf1ebc9cd60083515918b23b6cb1dc24cea8 にあるので参考に。 課題 JSのテストをずっと書き続けていると全体のテストを実行するのに10〜数十秒程度かかるようになってくる 手元でkarma startを使ってテストをしていると、ファイル変更のたびにテストを実行してくれるがka
Test::Time::AtというCPANモジュールをリリースしました - $shibayu36->blog;
社内でテスト時の時間操作を便利にするTest::Time::At というモジュールがあったので、それをCPAN化してリリースしました。 テスト中の時間を止めて、sleepなどの操作をうまくハンドリングしてくれるモジュールにはTest::Time というモジュールがあります。このモジュールを使っている時に、たまに、ある時間を指定してテストを実行したい時があります。そのような場合は以下のようにすれば実現できます。 use Test::Time; use DateTime; my $target_dt = DateTime->new(year => 2015, month => 7, day => 15); $Test::Time::time = $target_dt->epoch; my $now = time; Test::Time::Atを用いると、このような操作を少し便利にする事ができま
EmacsでTypeScript環境を整える - $shibayu36->blog;
ScalaにつづいてTypeScriptも勉強しようと思ったので、まずはエディタのセットアップをした。 typescript-mode とりあえずtypescript-modeというのがあるので、それを入れる。M-x package-list-packagesしてtypescript-modeをインストールする。その後以下の設定を入れておけば良い。 (require 'typescript-mode) (add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-mode)) flycheck、補完、型情報の表示、定義ジャンプ tss.elとtide.elというのがあった。tide.elは公式が提供しているtsserverのインターフェースに則って補完や定義ジャンプができるので、こちらを利用することにした。まずpackage-list-pa
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
