Agile 2016の基調講演: モダンアジャイルSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
良いマネジャーは部下に説教せず、ツールを与える。
私が出会ってきた良いマネジャーは、殆どの人が 「もっとヤル気出せよ」 「成長しないとダメだぞ」 といった「説教」をしなかった人ばかりだ。 説教自体が悪いのではない。 だが、おそらく皆、説教にほとんど意味がないことを知っていたのではないかと思う。 例えばあるwebサービス運営会社のマネジャーは、「説教したって、人は変わらないですよ。」と言った。 またある商社のマネジャーは「こちらが言っただけで考え方を変える人なんて、見たことないです」と言った。 コンサルティング会社の30歳そこそこのマネジャーは「説教でなんとかしようっていうのは、要するに手抜きか頭が悪いだけですよ。」と言った。 彼ら有能なマネジャーは説教をしない。 ではどうやって人に対して影響を与えるのか。行動と考え方を示すのか。 実は彼らは皆、部下に「ツール」を与えていた。しかも単に与えるだけではない。部下が進んで使いたくなるように工夫を
memoryless sources
よくドイツ人は几帳面できっちりしてるとか言われるけど、実際にしばらく生活してみると、日本人の方がよっぽどマシだと思うことがよくある。でもその一方で、仕事の面ではドイツの方がはるかに楽でしかも成果をだしやすいようにも思う。 しばらくフランクフルトで働いてみて、なんとなくドイツ人と日本人の仕事のやり方の違いがつかめてきたような気がするので絵に描いてみた。一言で言うとドイツ人の仕事は雑だ。でも、まわりの人はそれを補ったりあるいは受け入れたりする。決してモラルが低いわけではないけど、ただ自分がいい加減な分他人にもそこまで求めないし、困ったら助け合えばいいと普通に思っている。 逆に日本人は、人に迷惑をかけたり失敗を明るみに出すのをものすごく嫌がる。なので、絵に描いたみたいに、きっちりしてるけど完成しない。 完成しない理由は丁寧にゆっくりやっているからだけでもない。日本で仕事をしていると「鶴の一声」「
新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ
以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの
マネジメントを経験してようやくわかってきた、半年で部下を１人前にするコツ - トイアンナのぐだぐだ
試行錯誤しながら手に入れた部下や後輩を半年で１人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない？ と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう１年いるんだからシニアだね！後輩指導よろしく」と宣告され、必死で３人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか
Scrumはじめるまえの本質的な部分の話 #agile #scrum - @i2key のBlog
チームをスクラムにしたいのですが とあるアプリの責任者に相談を受けた。 彼は自分のチームが改善フェーズにはいり一定のリズムでサービス改善したいためWF型からスクラム化したいらしい。 そこで、いきなり彼は「プランニングポーカーどうやるんですか」と聞いてきた。これは危ないと思った。 PO、SM、エンジニアの相互の信頼が一番大事。 信頼がポイント。それがない状態で始まると意味のない何かになりやすい。 最初にやるべき儀式は、プラクティスの勉強ではなく、 最終責任を取れるビジネス側ポジションの人が、「お互い80%くらいの確度でコミュニケーションしましょう」ということ。 お互いのガードを下げること。一蓮托生になること。 そして、「これの意味は、仮にPOが確度100%の画面ワイヤー等のドキュメントをエンジニアに渡せるのであればエンジニアも確度100%の見積もりを出せるけど、僕（PO）はそんな天才でもない
新人にイラついてしまった時の備忘 - Konifar's WIP
組織にとって新人は期待の風です。しかしその期待の振り幅が大きい分、逆にイラついてしまうこともあります。 「何回も同じこと注意するの嫌だなぁ」とか「もっと考えてきてほしいなぁ」というのがよくある話ですが、ふとした時につい強く言ってしまうことがあるんですね。で、あとでいつも後悔するわけです。イラつきというのはそれ自体で何かがよくなるわけではないし、無駄に疲れるし、自分にとっては害でしかないです。 あとで自分で見返せるように、新人にイラついてしまった後に後悔しながら考えていることをまとめておこうと思います。先に言っておくと、ほとんどマインドセットの話なので万人に共通するような話ではないです。 期待を共有する 「なんでこんな完成度で出してきたんだ。。全然ダメじゃん」とイラついた時は、アウトプットに対する期待が相手の考えるレベルと食い違っているのかもしれません。その場合、「ちゃんとやれよ」という注意
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
dotsカンファレンス2016で発表した資料です。
書評: Site Reliability Engineering
英語だけどぜひ読んでほしい Site Reliability Engineering: How Google Runs Production Systems 参考になったのでご紹介。Googleのインフラ/Ops系技術チームの働き方や考え方を題材にした本です。GoogleのSREについては断片的に知っていたのですが、まとめて読むと違いますね。背景やストーリーがあって、理解しやすいです。 共感できるネタがどんどん繰り出されるので、一気読みしました。読み込みが浅いところもあったので、改めて読む予定。 以下、印象に残ったこと。 Site Reliability Engineering teamは、インフラ/Ops担当であるが、Unix内部やネットワークなどインフラの知見を持つソフトウェアエンジニアの集団。自分たちのオペレーションを効率的に、迅速に、確実にするために、コードを書く。 インシデント対
DroidKaigi 2016 うらばなし
2/18, 19の2日間で、DroidKaigi 2016の2日間が終わりました。 講演された皆様からも聴講された皆様からも大変にご好評だったようです。立ち上げから関わった者としては嬉しい限りです。 私はDroidKaigi 2016は準備を手伝っただけで、当日は参加していなかったため内容の善し悪しについて何かを言うことはできません。 ここでは裏方の立場からDroidKaigi 2016について感じたことを、簡単に備忘も兼ねて書いておきます。 会場 「平日2日間・終日・数百名」の規模になると、会場が決まらなくては何も始まりません。会場探しを始めたのが8月頃で複数の候補を当たってみたものの、日時や場所など、こちらの希望とマッチングが取れる会場は最終的には1か所しかありませんでした。他の会場候補・日程候補と比較検討を行い、会場と日時が確定したのは10月後半です。 他の開発者向けイベントなどと可
プロジェクトマネジメントは仕組み化が9割
今回はオペレーションに関するスライドです。特にフォーカスすること、フォーカスするためにできることについて解説しています。 スタートアップへのアドバイスとして「フォーカスが大事」とよく言われます。それでも実際にフォーカスできているスタートアップは中々いないようです。 なのでこのスライドでは、なぜフォーカスすべきなのか、そして実際にフォーカスするためにどうやってオペレーションを効率化すれば良いのかなど、私がこれまで支援の中で得てきた知識をまとめてます。少しでも効率化して、フォーカスできるようになればいいなと願っています。
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
中小Sierの退職理由を分析してみた～一番はお金じゃないんです～ - あいむあらいぶ
かるび（@karub_imalive)です。 寒くなってきましたね。冬のボーナスがもう早い会社だと今週末あたりに出た人もいるかもしれません。 さて、Sier、特にかるびの所属しているような中小Sier（概ね300人以下位）に勤務していると、この時期あたりから翌年3月位まで、エンジニアの退職者が目立つようになります。かるびは採用担当という立場なので、何よりもつらいのが退職者を送り出すことなのです。大手Sierと違い、中小Sierの泣き所は退職率の高さ。 今日は、そんな中小Sierの退職について少し考えてみたいと思います。 中小Sierの平均退職率はどんなものなのか 退職理由は意外にもお金ではない 1番の退職理由はマネジメントの拙さだった 具体的な退職理由としては・・・ 1) プロジェクト現場のマネジメントが悪い 2) 経営的なマネジメントが悪い お金の問題は副次的に発生する まとめ 中小Si
クソゲーを作る組織とそうでない組織 2012 05-12
1. クソゲーを作る組織と そうでない組織 株式会社 Aiming ジェネラルマネージャ / テクニカルディレクター 2012年5月12日 於 ゲームを作る勉強会 小林 俊仁 ( @toshi_k ) 2. About: 小林 俊仁 http://about.me/toshi_k オンラインゲームを作って早10年 基本はゲームも分かる web っ子 @toshi_k Community Engine でオンラインゲーム作って (2001~2003)、中国で子会社作っ てモバゲータウンの中国版（加加城）とか Play Online China とか作って (2003~2007)、子会社を閉じて日本に帰ってきて、その後オンゲの技術ディレク ターとかプロマネとかやってた 最近は、 ONE-UP → Aiming で組織横断的に開発プロセスの改善とかスクラム マスターとか
「指示待ち人間」はなぜ生まれるのか？
shinshinohara @ShinShinohara 「指示待ち人間ばかり、自分の頭で考えて動かない」という嘆きの声をよく聞く。不思議なことに私の研究室には指示待ち人間は一人もいない。パートの女性３名も他の研究室がうらやむほど優秀。９年連続で私のところに来た学生もことごとく自分の頭で考えて行動する。指示待ち、なんのこと？という感じ。 shinshinohara @ShinShinohara たぶん私がテキパキ指示を出せない人間なので、そのうち周囲があきれて、自分の頭で考え出すからだろう。私は自分のことさえ心もとなく、パートの方に「今日、お客さんじゃなかったですか？」と念を押されて思い出すこともしばしば。スケジュール管理まで進んでやってもらっている。実に助かる。
情報共有ができないチームの人間関係は破綻する | サイボウズ式
【サイボウズ式編集部より】「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回は日野瑛太郎さんによる「情報共有ができないチームのもろさ」について。 チームで働く場合、情報共有はとても重要です。仮に情報共有を一切しないのだとしたら、それは一人で働いていることとほとんど何も変わりません。チームで情報が共有されることではじめて、他人を手伝ったり意見を言ったりすることができるようになります。情報共有はチームワークの基本中の基本だと言ってもよいでしょう。 しかし、そんな基本中の基本であるはずの情報共有が、あまりうまくできていないというチームを結構よく見かけます。人数が少ないうちはある程度うまくまわっていても、チームの人数が増えるにつれて情報共有がいい加減になってしまうということも少なくありません。 僕がまだ会社員をしていたころに一
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自然とそうなる開発チームをつくるいとなむ #toteka
ウェブ魚拓
会社が副業を禁止にする理由
