属人化を避ける - Qiita
属人化の理由 個人の問題 手抜きやバグを隠す たとえば、仕様書外の動作を実装し、それをプロジェクトで利用する 解雇されないための保険的行動 チームの問題 マニュアルを作る文化の欠如 他人のタスクに対する無関心 他人の監査なしにプロジェクトを更新可能 どうやって属人化を避けるのか 間違った対策 ○○さん以外にもマニュアルなしで操作できる人間を育成 育成した人が全滅すればやっぱり同じ状況 全員がすべてのプロジェクトに精通するとかはムリ 正しい対策 モジュールごとに仕様書を用意 間違って使うことが難しい仕様とする 即ち、仕様書を読まなくてもある程度正確に使える お互いにコードレビューさせる 具体的にはどうすれば良い？ テスト・仕様書・利用例 テストは仕様書のベースとなる 仕様書を見れば、深い動作がわかるようになる 仕様書を読まなくても、利用例を見れば使える 全員がテストできる環境を作る 前提条件
【オマケ記事】超短期型タスク管理をカバーする！ステキな中長期計画法 - Qiita
前回までのあらすじ 先日、プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開するという記事で、私的に上手く行ったタスク管理手法を紹介した。幸いな事に概ね好評だったようだが、「中長期管理はどうしてるの？」という意見を多数見かけたので、オマケとしてちょこっと書いてみる次第。 ※前記事の流れを踏まえるので、予め読んで頂いた方が理解がスムーズかも？ ちなみに、中長期計画は案件状況によって管理手法を大きく変えた方が良いと思っているので、あくまで「手法の一つ」と捉えて貰えると嬉しい。なお、期間の単位は2〜3ヶ月程度を想定する。（なので、どちらかといえば「中期」に該当する考え方がメインとなる） タスク管理と中長期管理の守備範囲について RPG的っぽい雑な例えを持ち出すと、「突発的にエンカウントするモンスターの対処」が前記事の領域で、「ストーリー、イベント進行の段取り」が当記事の領域と区別し
プロジェクトの残業を50%削減したタスク管理手法を惜しみなく公開する - Qiita
おしながき メンバーは3〜5名、協力企業は1〜2名の小規模チーム メインは某小売店の大規模ECサイト案件統括（開発は外部委託） サブで基幹連携等を担う周辺業務システム開発・運用 マネジメントが上手く回らず高残業が常態化。PM前任者異動に伴い、部下だった私にお鉢が回る 上長指示により残業削減へ そんな2〜3年前のお話です。 改善"前"のタスク運用 ※あくまで改善"前"の話です。 基本はRedmine + Kanbanプラグインでタスク（チケット）運用。 ナレッジ可視化の意識付けも目的の一つだったので、以下を徹底した。 作業に伴うタスク発行の徹底 進捗状況の逐次反映 そして、運用ルールの入念な教育（五十六メソッドを採用した） 当時はITSベースのタスク管理自体が社内で先進的な試みだったので、当時部下だった私もPMと協力して「できるだけ丁寧な運用」を心がけた。心がけた、のだが… おかしいな だれ
エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた５つのこと - Qiita
（追記 2017/5/10） だいぶ放置していた形になってしまい申し訳御座いません。 僕自身ここまでの反響が（炎上が？笑）起こったことに驚いております。 賛同してくださった方・批判してくださった方、どちらも最後まで記事を読んでいただき、コメントまでしていただいたことに感謝でいっぱいです！ 自身の考え方としても勉強になりますし、何よりみなさんがこれだけ真剣になっていることが僕自身はとても嬉しい限りです。本当にありがとうございます。 前書き エンジニアとして1年経ち、振り返ってみると、業務中にわからないことがあるたびに調べ、 Qiita (記事投稿者の皆様方) には大変お世話になりました。ありがとうございます。（今頃になって自分は登録しましたが笑） 社会人1年目って人生１回きりしかありません。自分も2年目となり指導する側になる身として、 1年目で抱いていた心をいつまでも忘れないために、これを残
「飲みニケーション」を一切拒否する部下と、どう付き合えばいい？【シゴト悩み相談室】 - リクナビNEXTジャーナル
キャリアの構築過程においては体力的にもメンタル的にもタフな場面が多く、悩みや不安を一人で抱えてしまう人も多いようです。そんな若手ビジネスパーソンのお悩み相談を、人事歴20年、心理学にも明るい曽和利光さんが、温かくも厳しく受け止めます！ 曽和利光さん 株式会社人材研究所・代表取締役社長。1995年、京都大学教育学部教育心理学科卒業後、リクルートで人事コンサルタント、採用グループのゼネラルマネージャー等を経験。その後、ライフネット生命、オープンハウスで人事部門責任者を務める。2011年に人事・採用コンサルティングや教育研修などを手掛ける人材研究所を設立。 CASE8：「部下が会社の飲み会に参加しません」（35歳男性） ＜相談内容＞ 部下の一人が、部やチーム単位の打ち上げなどといった飲み会に一切参加しません。 その部下は、現在新卒採用などを担当してくれている入社3年目の男性です。仕事には真面目に
あなたの開発、Hype(誇大宣伝) Driven Development になっていませんか？ - Qiita
去年ですがmediumで話題になっていた記事にHype(誇大宣伝) Driven Development(HDD)というものがあります。 国内でもこれで失敗している例をよくみかけますし、とても共感したので紹介できればと思います。 翻訳ではなく、自分なりに噛み砕いて個人的な考えなども入れています。 概要 HDDとは一言でいえば、技術選定という重要なプロセスを他人任せにしてはならないという啓蒙です。 誰かが良いと言っているという理由で技術選定をしてはいけません。 例えば以下を理由に技術選定するのは Hype Driven Development(HDD)です。 ・すごく偉い人がおすすめしていた ・カンファレンスですばらしい技術だと紹介されていた ・新しい技術だ ・人気が急上昇している ・超有名企業のA社が導入した その技術は自分たちのどんな問題を解決してくれるのか。 開発の規模に、自分たちのス
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
社員7人の町工場、残業ゼロで年収600万円超！ヒントはラーメン屋に （ニュースイッチ） - Yahoo!ニュース
違法な長時間労働が問題視される中、社員わずか7人という中小企業が残業ゼロに成功している。ワイヤカット加工機で金属を切り出す受託加工を手がける吉原精工（神奈川県綾瀬市、吉原順二社長、0467・78・1181）がそれだ。経営者がトップダウンで作業工程や就業形態を見直し、残業代を基本給に組み込んだ結果、社員の年収は600万円を超え、優秀な人材の定着につながっている。 22時までの残業は当たり前だった 吉原精工は創業36年の町工場。基本労働時間は8時半―17時で、1日7・5時間。週休2日制で、年末年始やゴールデンウイークは連続10日間を休む。さらに賞与は2013年から継続して社員全員に夏・冬とも100万円を支給する。 約20年前までは残業が常態化していた。22時までの残業は当たり前で、吉原博会長は「たくさん機械を動かすことが収益を確保する方法だと信じていた」と振り返る。 ＜拒否された残業＞
初めて上司になって１年が経った
３０歳の若造なのに部署のトップになってしまい、今まで下っ端営業マンだった自分が数人の部下を持ってからもうすぐ１年。有給とはいえ特にやることがないので、この１年でやったことを書いていく。 ・細かいところまでとことん効率化 １０年前のやり方が化石のように現存していた部署だったので、毎日のように徹底的に効率化に励んだ。アナログで書いたり打ったりしていた書類を、せめてエクエルでと関数やマクロを組んでその人が理解するまで家庭教師みたいに一緒にやった。パソコン関係ではなく、細かい手順やルールまで「そもそもコレなんのために必要？」を毎回やって、徹底的に無駄を省いた。 ・定時退社おばけになった 定時がくると「定時ですよ～定時ですよ～」とフラフラと部署を歩き回るおばけになった。残って仕事をしている人には簡単に何をやってるのか説明してもらって、明日でも大丈夫そうだと自分が判断したものは「明日！明日！」と言いな
経営者に、良い管理職となることを求めてはいけない | 自分の心を殺してはいけない| Gallup認定ストレングスコーチしずかみちこブログ
良い経営者と良い管理職の両立は難しい 経理という仕事柄、会社では経営陣の近くで仕事をしてきたし、社外の方でも経営層の方とお会いする機会が多い。 この経験から、私は、良い経営者と良い管理職は両立できないと考えるようになった。 まず良い経営者、良い管理職とは何だろう？ 良い経営者 ・夢、理想を明確に描ける。他の人の心にも描くことが出来る。 ・その夢、理想に達するために、常人にはついていけないスピードで考え動くことが出来る 良い管理職 ・経営陣のやろうとしていることを汲み取り、実際の行動に変換し、部下に伝えることが出来る ・部下の特性を活かす成長に導くことができる なぜ両立が難しいのか ざっくり言うと、夢や理想を描くことが出来るのが経営者で、そこに向かって皆が走れるようにサポートするのが管理職、というイメージだ。 私の知っている良い経営者達は、皆、頭の回転が速く、行動力も伴っている。 ある意味そ
部下が全員働くママになったら、私の残業時間が減ったという話 | 自分の心を殺してはいけない| Gallup認定ストレングスコーチしずかみちこブログ
出勤の不安定さとその対策 働くママと一緒に仕事をする際に、まず頭に入れて置くべき点がある。 それは、出勤が不安定ということだ。 子供は常に体調を崩すと覚悟した 私自身には子供がいない。 なので、子供があんなにも熱を出すとは知らなかった。 子供が体調を崩す理由は山ほどある。 インフルエンザに食中毒。季節の変わり目。 溶連菌という言葉はこの時初めて聞いた。 メンバー2人ともが突然休み、一人でぽつんと呆然と始業時間を迎えたこともある。 対策は、スマホで この問題には対応方法があった。 メンバーが私たち3人のLINEのグループを作ってくれたのだ。 子供の具合が悪くなると、休日でも夜でもその段階で「長男、発熱中」などとLINEに書き込んでくれた。 朝になって突然子供の具合が悪くなったときは、朝の5時や6時の早い時点でそのことを知らせてくれた。 出社の状況が早い段階で分かると、仕事の調整が余裕を持って
地方は儲からない｢イベント地獄｣で疲弊する
2017年も読者の皆さんは、自治体や商工会議所など、さまざまな会議の場で「今年は新たに何をするか」「4月からの新年度は何をするか」ということをテーマにしているかもしれません。しかし、実は「何をするか」ばかりが議題に上がっている段階で、ヤバイのです。それは事業が失敗する｢予兆｣といっても、いいかもしれません。 どういうことでしょうか。そもそも衰退している地域ではヒト・モノ・カネが慢性的に不足しています。その中でも、一番の問題は、「人手」です。モノやカネは国などが支援したとしても、結局地元で真剣に事業に取り組む｢人｣は、簡単に補えません。 そうした状況にもかかわらず、自治体や商店街などのトップ層は「活性化のためだ」という名目で、新たに事業をプラスすることばかり考えがちです。｢過去にやってきたことを減らす」という発想がないのです。 その結果、午前と午後で、違う組織の違う会議なのに、参加しているメ
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
日本を｢1人あたり｣で最低にした犯人は誰か | 国内経済 | 東洋経済オンライン | 経済ニュースの新基準
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 ✕
イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候 - Qiita
はじめに この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1 やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。 我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だ
Agile Metrics入門
Agile Metrics入門 1. 1 Agile Metrics入門 株式会社SHIFT 太田健一郎 2. 2 • アジャイル開発のQCD+S • アジャイル開発におけるメトリクス取得の目的 • メトリクスのやってはいけない • メトリクスの入力元 • アジャイルメトリクス • メトリクス組合せ例 • 他社案件事例 • メトリクスツール • 参考情報 アジェンダ 3. 3 アジャイル開発のQCD+S 4. 4 • Quality – 品質→価値 • Cost – ポイント毎の実時間 x 総ストーリーポイント • Delivery – Agileでは通常固定 • Scope – スプリント毎に提供するストーリーの総量 – Agileでは開発するストーリーは交渉できる要素 QCD + S 5. 5 アジャイル開発におけるメトリクス取得の 目的 6. 6 • Measure – チームとプロ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
「組織的負債」を貯めないための、プログラマの哲学によるチームのマネジメント術 | Social Change!
プログラマの世界には「技術的負債」という言葉がある。ソフトウェアを開発していく中で、時間がなくて妥協したり、技術力が足りなかったりして、適当に作ってしまった部分が、後々になって不具合を引き起こしたり、改修にかかるコストをあげたりすることを言う。 後になればなるほど、悪影響が大きくなることから負債と喩えられる。そんな技術的負債と同じように、組織やチームのマネジメントでも、後になればなるほど悪影響が出てくるような「組織的負債」とも言えるような現象が起きてしまうことがある。 本記事では、私たちソニックガーデンで「組織的負債」を貯めないようにチーム経営してきた経験をもとに、プログラマの哲学を応用したマネジメント術について書いた。（今回の記事では「である」調にしてみた） 技術的負債と組織的負債の生まれる背景 技術的負債が生まれるのは、スタートアップの初期段階に多い。その時期は得てして、経験豊富な技術
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログミーBiz
技術的負債だらけのチームで技術マネージメントしてみた Kichijoji.pm7[talk2]![技術的負債だらけのチームで技術マネージメントしてみた Kichijoji.pm7[talk2]](https://cdn-ak-scissors.b.st-hatena.com/image/square/1d801c5d6e762bdd91810a87b39e211ac8516680/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fkichijojipm7-160502042041-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
