チームでプロダクト開発するための取り組み/cookpadtechconf2017作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
dotsカンファレンス2016で発表した資料です。
「自分でやったほうが早い」でチームは滅ぶ | サイボウズ式
【サイボウズ式編集部より】 この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は、脱社畜ブログの日野瑛太郎さんによる「仕事の任せ方、頼み方」について。 「人に何か仕事を頼む」という行為は、とても面倒くさいものです。 誰かに仕事を頼む以上、最低限どんな仕事をやってほしいのか説明をしなければなりません。「アレやっておいて」で済む相手であればいいですが、相手がまったくその仕事に通じていない場合は、説明だけでかなりの時間が取られてしまいます。仕事を依頼した後も、質問に答えたり、仕事の結果をチェックしたり、やることは意外と多くあります。 このような状況から、人に任せるのではなく「もう自分でやったほうが早い」と思ってしまうのはある意味では当然です。この考え方は、短期的には正しいと言えるでしょう。納期がピンチだという時に、悠長に
【朗報】そんなあなたに - hitode909の日記
コードを書く速度が遅いとお嘆きのあなた！！！ なんか、とにかくコードを書く速度が遅いんだけど、何が一番のボトルネックになってるんだろう ...— Cside (@Cside_) 2014, 5月 27 あなた！！！ > id:Cside コードを書くのがなんとなくお嘆きのあなた！！！オブジェクト指向入門第二版を読めば、大半の些細な悩みは解決することでしょう！！！ 利用者の声 私も愛用しています！！！最高の本です！！！最高過ぎて前歯が折れました 滋賀県在住マリンスポーツ氏 はこべさんも途中まで読んだそうです 滋賀県在住マリンスポーツ氏 ある昼下がり、しばゆーの机に下巻があるのを目撃したんです 滋賀県在住マリンスポーツ氏 お求めはこちらから 今ならAmazonプライムに加入することで24時間無料で発送いたします(Amazonが)。 オブジェクト指向入門 第2版 原則・コンセプト (IT Arc
Re: 開発フローの改善 - hitode909の日記
チームメンバーにとにかくさぼりたい人とかいないんだから、とりあえずやってみて、品質上がったり下がったりしたら、みんな何かしら、上がったとか下がったとか良いとか悪いとかつらいとか死にたいとか言うだろうから、気軽に導入して、観察してみるのが良いと思う。悪の部下を最悪のディレクターが管理するみたいな世界観では、慎重になった方がいいけど、最高のチームメンバーが協調しあって目標を達成する世界では、そんな些細なことでチームの文化が壊れるとは思えないし、朝の走り込み制度とか始めない限りは、全員ぐったりするとも思えない。ので、どんどんやってみるのがよいと思う。僕は管理する側じゃないから気軽なことを言うけど、管理する側とされる側みたいな感じじゃなくて、一緒に最高のソフトウェアを作るという形を目指さないといけないと思う。
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
QiitaやKobitoを作る開発チームの文化 - Qiita Blog
こんにちは，yaottiです． 今日はQiitaやQiita:Team, Kobitoを開発するチームでぼくたちがどういう文化，価値観を大切にしているかをお話したいと思います． HRT, SPOF, LeanIncrements(あまり知られていませんが，Qiitaを作っている会社の社名です)の開発チームが特に大切にしているのは以下の3つです． HRTを大切にしたコミュニケーション属人性を極限まで排除する重要な価値に集中する以降でそれぞれ具体的に見ていきます． HRTを大切にしたコミュニケーションHRTとは HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で(あらゆるチーム開発者に読んでほしい!)，Humility(謙遜), Respect(尊敬), Trust(信頼)の3つを意味しています． 「驕り高ぶらないようにしよう」「相手を尊
ピープルウェアを読んだ - はこべにっき ♨
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2013/12/18メディア: 単行本（ソフトカバー）この商品を含むブログ (6件) を見る この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。 実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。 いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコ
久々にチーム開発したのでメモ - ひげろぐ
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った 久々のチーム開発で。チーム人数は3名。 せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。 実践したこと プルリクベースの開発 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 上記のやり方が面白そうだったので試してみた。 Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。 Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。 コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。 一方でい
Hubot + Idobataでチームのコミュニケーションを加速させる
第36回 長岡IT開発者勉強会(NDS)にて。
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
「Lean UXとは組織文化をデザインすること」監訳者が明かす、UXデザインの本質 - エンジニアtype
「Lean UXとは組織文化をデザインすること」監訳者が明かす、UXデザインの本質 2014/03/13公開 いまや、スタートアップや新規サービス開発のバイブルとなっている、エリック・リース著の『リーン・スタートアップ』。 そのリース氏本人をシリーズ・エディターに迎えて展開している書籍シリーズ『THE LEAN SERIES』の第2弾が、オライリー・ジャパンから発刊され話題になっている。 『Lean UX―リーン思考によるユーザエクスペリエンス・デザイン』と名付けられたその本は、昨今、機能開発以上に重要視されているUI/UXデザインについての手法が多数紹介されている。 3月6日、東京・六本木ヒルズのGREEセミナールームで開催された出版記念イベント『Lean UXが拓く最適なデザイン』に400名を超える聴講者が集まったことからも、この分野へ興味を持つ人が増えているのが窺えた。 このイベント
憤怒と侮蔑の話 - 神社
技術的負債云々の話から、自分の失敗を思い出したので。 ある行動から人に悪意をぶつけるとき、もしくは吐き出してしまった後、ちょっと冷静になると、いつも憤怒と侮蔑を思い出すように心がけている。 つまるところ僕はその人に憤怒しているのか、それともその人を侮蔑しているのか、ということ。とにかく憤怒と侮蔑は明確に分けておかないといけない。大げさな言葉にしているのは、極端にしないと『どっちもかもしれない』なんていう曖昧な考えになるからで、ちゃんと分別するために大げさな言葉を使わないといけない。 憤怒しているというのはつまり怒っているので、それはもう腹を立てている。『こんなクソコード書きやがってちくしょう！あの野郎！』みたいな感じ。僕はよくこういう状態になる。自分にもなる。それはもうよく怒る。大体僕は短気なので、すぐに怒ってしまう。でも、元のコードを書いた人を侮蔑してはいけないので、怒っても怒っても、出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub