ペアプログラミング ホントのところXP祭り2017のセッションのスライドになります。 http://xpjug.com/xp2017-session-a5-1/ 元ネタは以下です。 http://i2key.hateblo.jp/entry/2017/05/15/082655 ※CCPMの表記について一部誤解を与える部分がありましたので、表記を削除いたしました。 2017/09/21 0:27
サイボウズで学んだこと - IT戦記
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
nabokov7; rehash : 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム
October 22, 201010:13 カテゴリプログラミング組織とyou 複数人開発チームのマネジメントに必要なもの - git, 個別開発環境, そしてシャッフルアルゴリズム perl 界隈の皆様、YAPC::Asia 2010 おつかれさまでした。 @nipotan のライトニングトークはシャッフルに関する話でした。で、ここで、なぜそもそもシャッフルが出てきたのかについて、チームマネジメント的な観点から補足したいと思います。 (元の発表はこちら: 動画 / スライド ) ■相互チェック体制の運用 ライブドアのプログラマは、だいたい一人でひとつのサービスを受け持っています。一人が複数のサービスを受け持つのは普通ですが、一つのサービスに複数のプログラマがフルコミットするという贅沢な状況はあまりありません。 担当が一人ずつしかいないと、担当の人が休むと何も進まない。やりたいことが色々あ
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
良いエンジニアの育て方 - ひがやすを技術ブログ
人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え
チームワークとは「いい敵」の共有 - レジデント初期研修用資料
チームワークは大切だけれど、リーダーがチームに対して、「チームワークを大事にしましょう」と諭してしまうと、誰もが「チーム」に遠慮する。結果としてたぶん、チームの能力は集まった人数を下回る。 チームには「敵」が必要 チームワークとは、チームが「共通の敵を持つこと」で生み出される。「チームをまとめるためには敵を探そう」が、リーダーが身につけるべき方法論でもある。 「敵」という存在は、対立や排除の対象であって、概念を共有した上で、それを「敵」と名指しすることで、チームには「何をやらないのか」、「誰に嫌われるのか」が共有される。 「敵」を名指しすることは、だからリーダーが戦略を策定するのと同じ意味を持つ。 目的の共有には意味が無い 目的とは単なる到達点で、どれだけそれを熱心に説いたところで、そこに到達するための道程は共有できない。メンバーの思い描いた道筋はバラけてしまうから、チームは結局まとまれな
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
カリスマ性よりも大事な「いいリーダーの条件」とは | ライフハッカー・ジャパン
リーダーとは、多くの人が考えているような群衆がこぞって付いていくような人ではありません。リーダーとは、周りを気にせず我が道を行く人です。他の人が自分に付いてきているかどうかさえも気にしません。 リーダーシップとは、人々を魅了して自分に付いて来させる能力ではありません。そういう能力のあるリーダーもいますが、その能力はなくてもいいのです。それより少なくとも、勇気があり、根気があり、忍耐強く、ユーモアがあり、柔軟で、機知に富んでおり、決断力があり、現実感覚が鋭く、どんなに悪い状況でも常に冷静明晰な頭脳でいられる能力のある人のことです。いわゆる「カリスマ」とは対極にある人です。 ジョン・ホルト リーダーというのは、単純に管理能力がある人や教育者というより、魅力で人を惹き付けている人のように考える人も多いでしょう。しかしジョン・ホルト氏は、それとは異なるリーダーに関する多くの重要な能力を挙げています
上司力とはどのようなチカラなのか？ 3つの要素を紹介する
上司力とはどのようなチカラなのか？ 3つの要素を紹介する：若手社員のうちに学びたい、「上司力」入門（1/4 ページ） 上司の指示通りに動いていればいい……という時代は終わった。これからの時代に求められるのは自らが管理し、自らが成長していくことだ。そのためにはどのようなことをすればいいのか。3つの要素を紹介する。 若手社員のうちに学びたい、「上司力」入門： 著しい労働環境の変化に振り回される昨今、上司がマネジメントに徹することは難しく、実務をこなしながら部下育成やチーム作りを行うことは、もはや当然のことになりつつある。しかし働き方が多用化する中で、影響力を発揮できる「上司力」を持つ人材は少ない。そこで本連載では「上司力入門」と題し、20～30代前半の若手社員のうちから「上司力」を鍛える方法を、人材育成の専門家が解説する。 著者プロフィール： 吉田実（よしだ・みのる） 株式会社シェイクの代表。
ITmedia Biz.ID：Getting Things Done（GTD）まとめ
Getting Things Done（GTD）まとめ ストレスフリーの仕事術、GTD（Getting Things Done）。海外のナレッジワーカーには常識になりつつあるこの仕事術、あなたはもう試してみましたか？ Biz.IDでは、GTDを活用して仕事の生産性を上げるビジネスパーソンを応援します。 今ならできるGTD 「将来の目標」は「日々の仕事」の中にあり デビッド・アレンさんは「日々の仕事を片付けられないと、将来の目標など見えてこない」と言います。日々仕事に追われていたりストレスにさらされていると将来のビジョンは描きにくくなります。(2008/12/31) GTDでつまずきやすい「プロジェクト」って？ GTDで分かりにくい概念のひとつに「プロジェクト」があります。6つのレベルでやるべきことを見直す「Horizontal Model」で考えると、プロジェクトの活用法が見えてきます。(
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
今世紀最高のアイディア術の本「考具」がすごい！ : まめストリート・ジャーナル 〜無料で情報が買える唯一の新聞〜
2013年01月30日15:25 by tkfire85 今世紀最高のアイディア術の本「考具」がすごい！ カテゴリ管理人 雑談 tkfire85 考具 ―考えるための道具、持っていますか?posted with amazlet at 13.01.30加藤 昌治 阪急コミュニケーションズ 売り上げランキング: 1,260 Amazon.co.jpで詳細を見る 「考具」はかなりの名著なので知っている人も多いと思います。個人的にずっとアイディア術に関する本は、ジェームス W.ヤングの「アイデアのつくり方」が最高だと思ってました。たぶん、20世紀という意味では最高の本だと思います。しかし、21世紀に入ってからの最高のアイディア術本は何か？、と聞かれたら、まっさきに「考具」を挙げると思います。古今東西、様々なアイディア術が紹介されていて、これ1冊を読めばたぶん相当なアイディア体質になれます。簡単です
【仕事術】『入社3年目までに知っておきたい プロフェッショナルの教科書』俣野成敏 : マインドマップ的読書感想文
入社3年目までに知っておきたい プロフェッショナルの教科書 【本の概要】◆今日ご紹介するのは、デビュー作の『プロフェッショナルサラリーマン』がスマッシュヒットした俣野成敏さんの新刊。 対象は25歳のビジネスパーソン……って、私は全然お呼びじゃないんですけど、「こまけーこたー（AA略）」。 アマゾンの内容紹介から一部引用。リストラ予備軍から最年少役員、そして起業した男が教える「キャリアの心構え」。今日からでも自分自身は大きく変えられる。 若手向けとはいえ、グサっと刺さる部分が多々ありました！ いつも応援ありがとうございます！ 【ポイント】■1.アウトプットするつもりでインプットする Teaching the youngster to feed / foxypar4 あなたが本を読むときも、人から話を聞くときも、それを誰かに伝えるということを前提に吸収すると受け止め方が変わります。 「この人に
株式会社ドワンゴを退職しました - こたにき
この度、一身上の都合により株式会社ドワンゴを退職いたしました。 退職にあたり、様々な方にご迷惑、ご心配をおかけし、大変申し訳ございませんでした。 思い起こせば、2007年4月に入社してから約5年間、私の人生はニコニコ動画と共にありました。 2007年当時、半ニートのような生活を送っていた私は、「2ちゃんねる求人」という奇妙でユーモラスな採用活動に惹かれ、その第一期生として株式会社ドワンゴに入社しました。面接の場で、「好きな2ちゃんねるの板は？」と聞かれたのは、今でも印象に残っています。 入社して早々、まだ生まれたての動画共有サイトの開発チームに配属されました。当時はまだ（β）から（γ）に変わった頃の時期で、開発チームも数人とごくごく小規模。私は、初めての社会人経験で、目の前の事を片付けるのに精一杯でしたが、先輩方と同僚に恵まれ、日に日にWebサイト開発にのめり込みました。 当時の様子を思い
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
PF ふりかえりガイド
Copyright (c) 2006-2022 ESM, Inc. Oblove, AMANO Masaru 1/60 プロジェクトファシリテーション 実践編 ふりかえりガイド (株)永和システムマネジメント オブラブ 天野勝 第 1 版 2006 年 6 月 7 日 第 30 版 2015 年 8 月 23 日 第 31 版 2015 年 8 月 30 日 第 32 版 2015 年 11 月 24 日 第 33 版 2016 年 4 月 25 日 第 34 版 2018 年 1 月 27 日 第 35 版 2021 年 5 月 13 日 第 36 版 2022 年 10 月 30 日 オリジナル：http://ObjectClub.jp/community/pf/#material このドキュメントは、クリエイティブ・コモンズ・ライセンス（帰属 2.0）の下 で提供しています。このライ
KPT 法でプロジェクトを振り返ろう！ | バシャログ。
梅雨も明けて夏本番。明日から夏休みをいただく予定の kimoto です。 ちなみに国はおろか、県や市からも出ない予定です！ さて先日、チームでとあるプロジェクトの振り返りを KPT 法にて行いました。 この KPT 法、もちろん有名な振り返り法ですが、知らない方のために簡単な解説をしようと思います。 簡単にできるので、みなさん試してみてください。 KPT 法とは KPT 法とは、Keep、Problem、Try の頭文字をとったものです。 Keep は「やって良かったから次もやりたい事」、 Problem は「問題があったので辞めたい、もしくは改善したい事」、 Try は「次にやってみたい事」という意味です。 これをチーム全員で出す事で、そのプロジェクトの良かった点や問題点などを可視化しつつ洗い出す事ができます。 また、この会議に参加しなかったメンバーにも伝えやすいというのも特徴ですね。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/busnews/20101208/6.html?rss
GTDでお仕事カイゼン！ 記事一覧 | gihyo.jp
