コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
たのしくなるコードレビュー - クックパッド開発者ブログ
こんにちは！サービス開発部でAndroidアプリの開発をしているこまたつ（@k0matatsu）です。 みなさんコードレビューしていますか？ 最近ではとりいれているチームも多いと思いますが、良い効果をもたらしてくれる一方で、負荷の高い作業でもあります。 また、コードレビュー自体に馴染みの薄かった人はなにをどうしたらいいのか難しいですよね。 同僚から得たアドバイスと自分なりのノウハウをあわせて、コードレビューの指針を考えていたので公開してみようと思います。 前提として、クックパッドではGitHub Enterpriseとプルリクエストを使った開発プロセスを採用しています。 また、コードレビューの前には自動テストと静的解析ツールによる単純なフォーマット、コードスタイル、頻出バグのチェックは行われているものとします。 静的解析による機械的なチェックはコードレビューよりも低コストで有効な方法ですの
Mackerelチームの若手エンジニアが初めて大物タスク「Azureインテグレーション」を手がけた話 - Hatena Developer Blog
こんにちは、Webアプリケーションエンジニアをやっています、すてにゃん ( id:stefafafan ) と言います。私は16卒のエンジニアで、今回初めて割と大きめなタスクを調査からリリースまで担当したので、その一連の流れを紹介していきたいと思います。 Mackerelとははてなが運営しているサーバ監視サービスです。 mackerel.io Mackerelでは以前AWSインテグレーションという、AWSクラウド製品の管理・監視ができる機能が実装されました。 mackerel.io 今回私はAzureインテグレーションという機能を実装しました。この記事ではこちらの機能のリリースまでのプロセスを紹介します。 mackerel.io 準備 見積もり会 調査 アクセス権限 SDK/API周り 料金周り 再見積もり クローラー 方針相談 実装 デプロイの相談 Mackerel本体 デザイン 動作確
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
『アジャイルサムライ――達人開発者への道』に学ぶ、開発フロー効率化のススメ！ 【今こそ読み解きたい名著】 - エンジニアHub｜Webエンジニアのキャリアを考える！
『アジャイルサムライ――達人開発者への道』に学ぶ、開発フロー効率化のススメ！ 【今こそ読み解きたい名著】 エンジニア向けの名著と呼ばれる本は数多くありますが、今回は『アジャイルサムライ――達人開発者への道』（オーム社、2011年）を取り上げ、著者の経験やアジャイル手法の実践例を挙げていきます。 数多くの開発者から支持を受け、読み継がれてきた名著。そこには読み継がれる理由があります。 名著には、内容・ボリュームともに充実した書籍が多く、概要に目を通しただけで本を読んだつもりになっていたり、腰を据えて読む時間がなく「積ん読」してしまいがち。「エンジニアが絶対読むべき書籍●選」といった記事をブックマークするだけで読んだつもりになっていないでしょうか。 ポイントを押さえつつ内容を深掘りし、名著の根底に流れるエッセンスを開発に活かしましょう。 アプリエンジニアの池田惇と申します。iOS/Androi
サイボウズ kintoneチームの「改善」大公開！ 新人も巻き込んだスクラム導入の成果とは？｜ハイクラス転職・求人情報サイト AMBI（アンビ）
サイボウズ kintoneチームの「改善」大公開！ 新人も巻き込んだスクラム導入の成果とは？ 連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのか、伺いました。 若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。 取材に応じてくれたのは、若手プログラマの前田浩邦（まえた・ひろくに）さんと、メンター役だった天野祐介（あまの・ゆうすけ）さん。2人が属するkintone
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
サイボウズの開発を支えるKAIZEN文化
東京Node学園祭2016での発表資料です。 http://nodefest.jp/2016/ https://www.youtube.com/watch?v=36RwwoYErjALire moins
Qiita 生みの親、海野弘成（@yaotti）が語る！ 良いチームを定義する2つの条件 | キャリアハック（CAREER HACK）
情報共有ツール「Qiita:Team」のプロダクトマネージャー（PM）を務める海野弘成さん。海野さんは「良いチーム＝自律的なチーム」と定義し、構成要素を共有した。 海野弘成が語った、「自律」と「心理的安全性」の重要性 ※2016年10月24日に開催された「Japan Product Manager Conference 2016」よりレポート記事をお届けします。 映し出されたスライドのタイトルは『Product Team Management』。 登壇したIncrements株式会社CEOで、情報共有ツール「Qiita:Team」のPMを務める海野弘成さんは、 自身の経験から「プロダクトマネージャー（PM）の関わるチームビルディング」に絞って発表した。セッションの冒頭で、海野さんは2つの条件を満たしているのが「良いチーム」であると定義する。 まずは「成果が出せるチーム」。プロダクトにおいて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログイン - はてな
技術的負債と向き合う