プロジェクトを遂行するためには、工数の見積もりやスケジュール管理が必要になります。正確な見積もりは難しく納期に間に合わなかったり、残業や休日出勤で埋め合わせたりした経験はありませんか？ 今回は、より正確に工数の見積もるための手法や、差し込み作業を考慮したスケジュール手法などについて解説されている記事をまとめました。 マネージャー、エンジニア、デザイナーなどすべての方に参考なる内容だと思います。 開発の見積もりとスケジュール管理 クックパッド株式会社の方が実践している見積もりとスケジュール管理方法について紹介されています。工数を見積もるステップや、スケジュールを立てるときの注意点、スケジュール管理の方法について学びたい方におすすめの記事です。 開発の見積もりとスケジュール管理 不安とストレスから解放される見積りとスケジュール方法 開発をしているとき、納期に間に合わなかったらどうしようと不安に

エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを

一人 CTO Night での発表資料です

少し前にお会いした、元コンサルタントの方の話だ。 彼は、「自分は特に優秀ではない」と悟ってから、一気に成果が出るようになった、という。 だが、優秀ではない、ということと、成果が出る、とは相反するように見える。 「一見、逆説的に聞こえるけど」と問うと、彼は 「いや、重要だよ。」という。 「僕は自信家で、とにかく人に勝ちたかった。出世、給料、有名になることも含めて。」 「野心があるのは悪いことじゃないと思うけど。」 「うん、でも、勝てないんだよね。すごい人ってたくさんいるから。例えば、先輩が作る提案書を見る。出来がいいし、何より発想が突き抜けてる。わかるんだよね。あ、自分の作ったものは十人並だなって。結局、自分にはそれほどの才能がないってこと、嫌ってほどわかった。」 「なるほど」 「でも、なんとかして追いつけるんじゃないかと、本を読んで、セミナー出て、でも、勉強すればするほど、先輩が遠ざかる。

プレゼンテーションはいくつかのポイントを押さえれば、大幅に分かりやすく、説得力があり、オーディエンスの心を掴むものになる。今回はパワーポイント等でのプレゼン資料の作り方のポイントを５つに分けて紹介する。 1. 作り出す前に構成をざっくりと考える 聴く人の腹に落ちるプレゼンテーションをしたければ、まず構成を練ろう。行き当たりばったりで、思い付いたことをスライドにまとめると、最も伝えたいメッセージが薄れてしまったり、論理構造が狂ってしまう可能性があるからだ。一方で、実際に手を動かしてスライドを作っていく中で良い表現は浮かんでくるのも事実。 そこで最低限、あらかじめ次の2つをざっくり書き出すようにする。 最も主張したいメッセージ (結論） プレゼンのどこかしらに盛り込みたいこと 次に、書き出されたものを見ながら、どうやって(1)結論までのストーリーを作るか考える。以下に、そのストーリーの代表的な

2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる

仕事ができる人とできない人の『生産性』の違い 1. 目的について 仕事ができない人は、目的を曖昧にしたまま仕事に取り掛かる。 仕事ができる人は、何かを頼まれたら「なぜその仕事をする意味があるのか」本質的な目的を聞く。 目的が不明確なまま仕事をしていては、頼まれたこと以上のアウトプットはできない。また、本質的な目的が分かっていれば逐一「ここはどうすれば良いですか？」と聞かなくとも自分で考えて仕事が進められる。 2. タスク管理について 仕事ができない人は、タスクを頭で全て覚えようとする。 仕事ができる人は、紙やアプリ、PC、付箋に記憶させる。 無駄なエネルギーを使わず、意思決定・問題解決のために頭をフル回転させる。 3. 集中できる環境づくりについて 仕事ができない人の携帯は、仕事中でもメールやLINEの通知がひっきりなしに鳴る。 仕事ができる人は、集中力を阻害するものを意識的にOFFにする

2016年4月13日に六本木Super Deluxeで開催されたIT/Webエンジニア向けイベント「TechLION vol.25」（http://techlion.jp/vol25）に出演した際の講演スライドです。 持ち時間20分ということで、以前にシェアしたスライド「効果が出る仕事の教え方」を本題の演目と捉えて、そこに入る前のマクラとしてお話をまとめました。 ※直接対面でお話しする前提で作ったスライドなので、スライドだけ見てもいまいち伝わりづらい部分、誤解釈させてしまうリスクもあって、内心こわごわの共有ですが、いくらかでも、つまんでお役立ていただけるところがあれば嬉しいです。 出演後の後書きをブログにまとめましたので、よろしければあわせてご覧ください。 TechLION出演の後書き┃心のうち http://hysmrk.cocolog-nifty.com/blog/2016/04/te

組織にテストを書く文化を根付かせる戦略と戦術 Feb 16, 2016 @ 日本OSS推進フォーラム Read less

今回はオペレーションに関するスライドです。特にフォーカスすること、フォーカスするためにできることについて解説しています。 スタートアップへのアドバイスとして「フォーカスが大事」とよく言われます。それでも実際にフォーカスできているスタートアップは中々いないようです。 なのでこのスライドでは、なぜフォーカスすべきなのか、そして実際にフォーカスするためにどうやってオペレーションを効率化すれば良いのかなど、私がこれまで支援の中で得てきた知識をまとめてます。少しでも効率化して、フォーカスできるようになればいいなと願っています。

こんにちは。@ryuzeeです。 営業でDevOpsの基本の話をしてきましたので資料を公開しておきます。中身自体は昨年11月に楽天テクノロジーカンファレンスで話した内容を日本語化したものです。 DevOpsに関してはいまだに実体がなんなのかという議論がなされていますが、僕自身の現時点での解釈は、ビジネス上の意思決定から実際に顧客に届ける全体の流れの話であると考えています。すなわちいかにリードタイムを短くするかとスループットを大きくするか、ということです。(それってリーンじゃん、と言われればその通り) デプロイの回数が測定基準である、という記述も見かけますが、デプロイの回数は、あくまでバリューストリームの末端の「個別プロセス」の話でしかないので、物理的に一日に10回デプロイボタンが押せても、意思決定から価値化までの時間は長い、ということがありえます。 Build・Measure・Learnの

1. 2016/01/19 - Regional SCRUM GATHERING® Tokyo 2016 あなたのチームの「いい人」は 機能していますか？ 横道 稔（株式会社サイバーエージェント / 株式会社 RightSegment） 2. 自己紹介 • 横道稔 （@ykmc09_dev） • 株式会社サイバーエージェント アドテクスタジオ • 株式会社 RightSegment にて PrivateDMP を開発 • エンジニア、エンジニアチームのマネージャ • CSM / CSPO

新規事業開発や起業において、ビジネスモデルの設計・構築が成功率を下げている可能性があります。一般的には優れたビジネスモデルの設計こそが事業の成功率を向上させると認識されていますが、実際の事業投資シーンにおいては真逆の結果、つまり事業開発はまったく進まず、起業は失敗するという結果が生まれます。本資料では普段あまり語られることのない、ビジネスモデル設計・構築に潜む「デメリット」をご紹介します。Read less

インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。 SREとGoogleのSRE Site Reliability Engineerは日本語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日本ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。中でもSREのパイオニアとしてGoogleのSREチームが有名です。 GoogleのSREチームはGoogleの検索、広告、Gmail、YouTube、App Engin

システム開発でエンジニアとのコミュニケーションで困るのは良くある話。 今まで色々な開発に携わってきましたが、社内SEとのコミュニケーションで困ったことと対策を書いてみました。 私自身が現役エンジニアでもありますが、どちらかというとディレクションの方が経験が多いので、両方の目線で考えてみました。 何を言ってるか分からない 「マスターにマージしたらコンフリクトしてデプロイできません」 とか 「オンプレ環境でデータベース構築したのでクラウド環境からリプレイスします」 とか、聞く人が聞いたら 「パルスのファルシのルシがパージでコクーン」と同じレベルですよね。 意味不明すぎて「日本語でOK」って言いたくなりますがそこは我慢です。本人は普段から当たり前に使っている言葉なので、伝わらないことに気付いていないだけなんです。 ただ、これの対策はあんまりなくて、、、 「可能な限り覚える」しかないと思ってます。

2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。

採用担当者が、応募者の中から誰を採用べきかというような難しい決定をするときには、仕事に関する具体的な能力だけでなく、コミュニケーション能力やチームワークのように、どんな職業の人にも必要な、基本的なスキルを備えているかどうかも採用基準にしています。 仕事に直接関係はないけれど、社会人なら誰にでも必要なスキルのトップ10をご紹介します。 第1位：共感力とEQ（心の知能指数） 「共感」は仕事でも家庭でも、もっとも重要なスキルです。他人に共感することで、周囲の人々を理解でき、顧客の求めることや誰かにモチベーションを与える方法、相互利益に関する理解を深めるのに役立ちます。知識と理解の違いは共感です。本気で他人の言葉に耳を傾けることを学び、他人の視点で物事を見るように訓練すると、共感力を高めることができます。 第2位：チームコミュニケーション能力 採用担当者は、応募者を評価するとき、企業文化にフィット

はじめに こんにちは、投稿推進部の勝間です。 約1年前、「サービス開発エンジニアからマネージャになった話」というエントリを投稿しましたが、現在も試行錯誤しながらマネジメントに取り組みつづけています。 「組織は生きもの」とも言いますが、私の部署もまた生きもののように、日々いろいろな課題が生まれ、それに取り組んでいます。今回は、そのような部署で私が感じた課題と、それに対する具体的な取り組みについて、いくつか事例とあわせてご紹介します。 1. 業務外の問題に目を向ける 私の部署では、毎日約5分間の朝会を開いています。 1人30秒くらいで、「今日取り掛かること」「参加するミーティング」「その他勤怠など含めて共有すべきこと」を共有します。 朝会を行うことでそれぞれの業務的な進捗を確認でき、また、内容について疑問に思ったこともすぐに確認、理解できる状態を作ることができていました。 一方で、業務と直接関

会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを