なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
社内なら謝らなくて良いカルチャー
社内で仕事をしているとき、指摘や指導をすることがあるが、まだうちのカルチャーに慣れていない人は、すぐに「すいません」と謝る。でも、それは良くないよ、と言っている。 仕事の仕方や成果物に対しての指摘というのは、別に悪いことをしたからな訳ではないのだから、謝る必要などない。私に謝って欲しくて指摘している訳ではないのだ。 謝るってことは、私を向いて仕事をしていることになる。それは良くない。仕事はあくまでユーザやお客さまを向いてするものだ。社内の人に向いて仕事をするのではない。 だから指摘に対して謝る必要はない。良い仕事をしてもらいたい、成長してもらいたいから指摘をしているのだ。社長の顔色なんて見なくていい。良い仕事をすればいい。 同じチームにいて、良い仕事をして、成長していきたいというベクトルがあっているなら、謝ることなんてないのだ。そういうカルチャーの会社であり続けたいと思っている。 もちろん
Mackerelチームのリモートワーク体制における日報とデイリースクラム - Hatena Developer Blog
日報を継続する方法があったら教えて欲しい、id:Songmu です。最近はMackerelチームのディレクター兼デベロッパーをやっています。 リモートワークと情報共有 Mackerelは、8名程度で開発しており、開発メンバーは京都・東京・愛知の3拠点に散らばっており、リモート勤務も各自の裁量で行えるようになっています。 リモートワークにおいては細かい情報共有をなるべく労力をかけずに行うことが必要になりますが、そのために以下のようなツールを利用しています。 開発手法としてスクラムを採用 Hatena::Groupによる情報共有 Github/Zenhubを用いたプロジェクト管理 Slackでのチャットコミュニケーション Zoomによるオンラインミーティング Mackerelチームでは、Hatena::Group上で日報を書くことを推奨しており、今回はその話です。 Mackerelチームの一日
より良い組織を作るために - クックパッド開発者ブログ
はじめに こんにちは、投稿推進部部長の勝間です。 突然ですが、皆さんは「組織における課題」について考えたこと、意識したことはあるでしょうか。 「組織における課題」なんて言葉を使うと、たとえば 事業戦略の方向性 人事評価制度 マネジメント層の育成 など、少し高いレイヤーの話が思いつくでしょうか。 ともすれば自分とは無関係な話のように思えるものかもしれません。 一方で、このようなものはどうでしょうか。 なんとなく、最近社内の空気変わった気がする なんとなく、隣の部署が何やってるかよくわからない このような、もやっとした感覚、は普段働いている中で感じたことがある人も少なくないかもしれません。 こういった「具体的な何か」というより「抽象的な違和感」を私たちが抱くことも組織における課題といってもいいかと思います。 このような組織における課題、違和感を認識したとき、私たちはどのように向かい合うべきでし
SEと営業のためのヒアリング講座。モデレータのヒアリングテクニックから学ぶ（前編）
数カ月前のことですが、次のような依頼をいただいたことがありました。「新野さんのモデレータとしてパネリストから発言を引き出す能力を生かして、SEや営業がお客様の要望をうまくヒアリングできる技術が身につくような講座をお願いできないだろうか」と。 SEの仕事としてお客様の要望を聞き出す、いわゆる要求開発の重要さが増してきている一方で、SEやエンジニアの研修は技術中心でヒアリングを上達させるようなものはなく、なんとかそういった研修ができそうな人を探しているとのことでした。 超大手SIerからヒアリング講座の依頼が 僕は仕事としてほとんど毎月のようにパネルディスカッションのモデレータをしています。今年に入っても、インフォテリアの「ASTERIA Cloud Conference 2015」、F5の「F5 Agility Tokyo 2015」でモデレータを行い、今週金曜日にはCloud Days T
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
esa.io と DocBase を比較してみた #esa_io #docbase - Tbpgr Blog
概要 esa.io と DocBase を比較してみました 利用歴 esa.io : 約 1 ヶ月 DocBase : 1日 ご覧のとおりのため、 DocBase については見逃している便利な使い方や私の勘違いなどあるかもしれません また、利用期間が大きく異なるため情報の量が esa.io に偏っていることをご了承ください。 esa.io の特徴について 下記の記事にまとめてあります。 ※ただし、記事作成後に使い易い機能が日々追加されています。 esa.io でゆるふわ情報共有 - Middleman Blog への Export サンプル付き DocBase の特徴について 下記の記事にまとめてあります。 「小さなメモから始めて、チームを育てる 」 DocBase を触って基本機能や特徴をまとめてみた 比較 コンセプトの違い esa.io 規模：小さなチーム向け 暗黙知可視化への工夫：W
質問の型をいくつか持っておくと便利 - 発声練習
はてな匿名ダイアリー：詳細よりもまず大枠をつかみたい、という事をわかってくれない先輩 会社に入って半年、研修を終えて3か月の新人です。配属先で私の教育係に割り当てられた先輩と、どうも相性が悪いみたいです。この先輩は私が質問すると、いきなり詳細な内容を説明してきます。私がわからないと言うと、「わからないのは詳細を説明してないせいだ」と思うのか、説明がどんどん深い方向に進んでしまいます。 例えば専門用語が分からなくて質問すると、こんな感じ。 「先輩、この『パイ』って何ですか？」 「パイ？それは 3.14 のことだよ」 「うーん、よくわからないですね」 「わからない？つまり 3.141592 のことなんだよ」 「うーん、それは食べ物と関係ありますか？」 「関係ないよ。要するに 3.1415926535 のことだよ」 「もしかして、おっぱいのことですか？」 「違うよ。全然違うよ。3.1415926
WebRTCコトハジメ - Qiita
本日から「WebRTC Advent Calendar 2014」始まりました。 初日は入門編ということで、これからWebRTCを利用したアプリを開発したいと思っている方向けに、参考になるスライドやサイトをまとめます。 1. まずは動かしてみる まずは、Googleが公開しているWebRTC Reference Appをご紹介します。開発者の間では通称apprtcと言われる、WebRTCのデモアプリで、プログラミングで言えば「Hello World」のような位置づけです。 WebRTC Reference App - https://apprtc.appspot.com/ アプリを開くとURLの末尾に r=15075904 というようなルームナンバーが発行されます。 このURLを接続したい人にシェアすることでビデオチャットを行うことが出来ます。 2. WebRTCの概要をさっと理解する ざ
サービス業から学んだコミュニケーションのコツ
2014年10月25日 第20回リクリセミナー 「Webディレクターの頭の中」で使用したスライドです。 サービス業での経験をベースに、コミュニケーションを円滑にするために今も日々心がけていることをまとめました。
どれか1つでも効果抜群。コミュニケーション上手になるための5つの習慣 | ライフハッカー・ジャパン
もっと自己主張ができるようになりたい、争いごとへの対処がうまくなりたい、人前で自分の気持ちを言えるようになりたいなど、コミュニケーションスキルを磨きたいという願いは、誰もが持っていることでしょう。 筆者の職業はジョブコーチ。そのため、クライアントとの会話にはほとんど、コミュニケーションの話題が伴います。相談に訪れる動機は人それぞれ大きく異なりますが、これまでの会話を思い返すと、実際に話している内容はそれほど複雑なことではありません。多くの人がコミュニケーションの基礎でつまづいているのです。 そこで、クライアントとの会話から得られたコミュニケーション力向上のコツを、5つお伝えします。1つでも役立ちそうなものがあれば、ぜひ会話のスキルとして取り入れてみてください。 「そうですね、でも～」よりも「そうですね、それに～」 「いいアイデアですね。でも、違うやり方の方がいいと思います」と言ってませんか
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
SkypeやYammerよりも使いやすい！チーム向けコミュニケーションツール、Slackが超便利！
皆さんはSlackをご存知ですか？Slackはチーム向けのコミュニケーションツールで、プレビュー版の段階から人気を集めていたのですが、2014年2月13日（日本時間）ついに正式ローンチされました。私が所属しているGoodpatchは新しいものが大好きなので、最近試しにSlackを使い始めてみたのですが、これが本当に便利！今日はその魅力を皆さんにお伝えしたいと思います。 Slackって何？ Slackは、Tiny Speckという会社からローンチされたチーム用コミュニケーションツール。Tiny Speckは元Flickrの中心的メンバーによって作られ、CEOはFlickrの共同創業者Stewart Butterfieldです。ネットスケープの創業者であるMarc Andreessenなどから投資を集めている彼らが、2013年8月にSlackをローンチし、HipChatやYammer、Skyp
San Francisco 116 日目 - 英語があまりできない人のためのミーティングの話 - higepon blog
文脈 サンフランシスコの外資で働き始めて 116 日目。英語あまり話せない。初外資。留学経験なし。いわゆる受験英語育ち。その後は英語は独学で勉強するも使う機会に一切恵まれず。 社内にそこまで知り合いもいなくて英語もできないので、そこを準備でどう補っているかという話。今後続く同じような境遇の人の役に立てれば幸い。 ミーティングの話 自分が主催するミーティングで何かをお願いしたり、質問したりする場合の会議に心がけていること。 自己紹介後、まず忙しいのに時間をとってくれたことにお礼を言う。 2回目以降の会議の場合は軽い世間話から「How are you doing?」的な。 相手の席の近くの会議室を予約する。広いオフィスなので来やすいように。 ミーティングの Agenda を事前に用意する。相手に質問がある場合はあわせて事前にメールする（相手が答えを用意できるように） Agenda には会議の流
vim-jpがつないだVimプラグイン開発者とVimパッチ職人、もしくはなぜ最近Vimコミュニティが活発になったのか - Humanity
ばよえ〜ん(訳：Vim Advent Calendar 2012への11回目の投稿です) この記事はVim Advent Calendar 2012の115日目の記事になります。 114日目は@rbtnnさんのsetコマンドでエスケープすべき文字でした。 vim-jp以前ってmattnさん以外、Vimパッチ職人*1の人たちはあんまりLingrに寄り付かなかったなー。という事をふと思い出したのでなんとなくちょっと前のことについて書いてみる。 というより、何時の間にか書きあがってた。 取りとめないし、主観が多分に混じってると思う。 ここでいうVimパッチ職人、Vimプラグイン開発者はだいたいこんな感じ... すごい大雑把な分け方なのでちょっとあれだけど... Vimパッチ職人 mattnさん、KoRoNさん、中平さん、h-eastさん、... Vimプラグイン開発者 thincaさん、Shou
「このエンジニアはすごい！」顧客もうなる「質問力」とは
「このエンジニアはすごい！」顧客もうなる「質問力」とは：ITエンジニアの市場価値を高める「営業力」（6）（1/2 ページ） 努力はしたが、褒められることはなかったITエンジニア時代の私 「君は技術があるけど、話が下手だねえ」 ITエンジニア時代、顧客からこう言われて落ち込んだことが何度もありました。 そこで、予行演習（よく“ロープレ”といわれるやつです）などをして次回の訪問に臨むのですが、やっぱり同じことを言われる。「結論から言え」と言われたら、次からそれを心掛けるなど、努力はしました。でも、なかなか褒められない。 話をしていて、途中から顧客の反応が悪くなっていくのが、自分でも分かるのです。仕方なく、適当なところで切り上げて終わる。こんなことを何回繰り返したか分かりません。 それでもITエンジニアのときは、まだ良かった。私はその後、転職して営業を担当しましたが、営業に対する顧客の反応はもっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報共有から始めるチーム開発とキャリア戦略
Tumblr
GitHub - mutualmobile/MMWormhole: Message passing between iOS apps and extensions.
