フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される
by MATEUS_27:24&25 プロジェクトの計画と実行において総合的な責任を持つ職務をプロジェクトマネージャーと呼びますが、NASAのゴダード宇宙飛行センターの副監督者であるJerry Maddenさんが何年にもわたって出典不詳のソースから集めた「プロジェクトマネージャーとしての心得」とも言える100のルールがPDFファイルで公開されました。プロジェクトマネージャーとしてだけでなはく、仕事やグループを統括する人にとって非常に役立ちそうなルールとなっています。 One Hundred Rules for NASA Project Managers - 100-rules-for-nasa-project-managers.pdf (PDFファイル) https://www.projectsmart.co.uk/white-papers/100-rules-for-nasa-proje
個人のせいにする前にプロセスやシステムを疑え - HOW TO GO
最近いくつかのプロジェクトで同じことが起きてます。 「何か問題があると個人の問題にする」という現象です。 「個人の問題」 例えば品質問題。 ある個人のコードの質が悪かったんです。たまたま結合試験で気づきました。試験担当者がたまたまコードを見ながら試験したから気がついたんです。 「あいつの書くコードはちょっとなぁ…」という意見が複数出ました。 例えば生産性。（生産性って言葉はあまり好きじゃないのですが、プロジェクトではこの言葉を使っていました。技術力と同じような意味なんですが） ある個人のスキルがあまり高くなく、コードを書くのに時間が掛かります。システム開発の経験も少ないのでプログラム言語、業務仕様の理解も他のメンバーより時間が掛かります。 チームとしても顧客の求める計画を達成できていませんでした。 「あいつがチームの生産性を落としてるから計画通り進んでないんだ」とマネージャーは言いました。
部下がホウレンソウをしない理由 - teruyastarはかく語りき
多分、報・連・相の意味は間違って伝えられてるよ | 日系パワハラ http://nikkeiph.com/spinaches/ 私は、会社の"ほうれんそう"が立派に育っているかどうかの一つの目安はイヤな情報、喜ばしくないデータなどが何の粉飾もされずに正しく上に伝えられることだと思っている。 〜中略〜 上の人間が聞いて不快になりそうな情報は、なるべく伝えないようにしようという土壌がいつのまにかできているとしたら、この土壌には"ほうれんそう"は育たない。 そして山崎氏曰く、若い人からの率直な意見は吸い上げ、問題点があるならば改善するなど積極的な反応が大事だといっています。そればかりか、ほうれんそうを腐らせているのは管理職であるとも遠回しに言及しておられます。 この記事に共感したので、 上司と部下の視点で思うところを書いてみます。 ちなみに報連相の定義は、 ホウレンソウとは 〜 exBuzzwo
ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
藤田晋『ポジティブでいいやつの落とし穴』
うちの社員はポジティブでいいやつが 多いと思います。 それは会社の良さであり、ずっと大事に したいところではありますが、 先日、まさにポジティブでいいやつで、 社内で誰からも好かれるタイプの 事業責任者をミーティングで頭ごなしに 叱りました。 「戦略の詰めが甘いんだよ！」 彼を始め、その部署のメンバーは 疑いようもなく一生懸命頑張りますが、 トップの戦略が甘ければ、自分含めて みんなの努力が全て水の泡です。 そのため、戦略を描くトップの立場の 人の責任は重大です。 これでもかというくらい抜け漏れを チェックして、あらゆる可能性を吟味し、 しらみつぶしに問題を洗い出し、 後悔のないよう、最後までしつこく、 しぶとく考え抜かなければなりません。 ところが、ポジティブな性格の人は、 良い戦略アイデアがひとつ見つかると、 「いける！いける！」 「あとはやるしかない！」 とか言って、すぐみんなで飲み
WBS は、作業分解構造ではないのよ。 - haradakiro's blog
ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb
RPGをプレイする感覚でタスクを管理し習慣づけを成功させる「HabitRPG」
「毎日ランニングする」「早起きする」「ジャンクフードを食べない」など、一度決心してもなかなか実現しづらい習慣づけを、RPGっぽいタスク管理サービスを使ってゲームをしている感覚で実現しようというのが「HabitRPG」です。 HabitRPG | Gamify Your Life https://habitrpg.com/splash.html HabitRPG by Tyler Renelle — Kickstarter http://www.kickstarter.com/projects/lefnire/habitrpg-mobile HabitRPGは開発の途上にあってKickstarterで出資を募っているところ。概要は以下のムービーを見るとわかります。 HabitRPG on Vimeo 一言「毎日ランニングする」と言っても、何かを習慣づけるのは想像以上に難しいもの。「1日ぐらい
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
みんなでガント.com
会員登録不要でチームやグループと共有利用が可能なガントチャートを、 簡単に作成できるクラウドサービスです。 各種デバイス（PC、iPhone、Android）でご利用いただけます。 ガントチャートでプロジェクトの計画と進捗を見える化、 TODO管理で問題課題の見える化を実現します。 プロジェクト管理サービスで最もお得 選ばれる理由１ 20ユーザで6ヶ月使った場合、類似サービス中、最も費用を抑えてお使い頂けます。 高価なプロジェクト管理ツールを使えばプロジェクトは上手くいくのか、そんなことはありません。シンプルで扱いやすく、安価なツールがそれを担うこともあります。 「プロジェクトは、お金がかかる！」管理ツールの費用を抑えたいなら『みんなでガント』をお選びください。 どれぐらい安いのか？ 確認する
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
Trac Lightningで始めるチケット式開発「電撃」入門
“泥”開発に対する最終兵器「Trac」とは？ 誰もが必ず1度はイライラしたことがある「情報の囲い込み」問題 情報の共有はプロジェクトを円滑に進めるうえで重要な課題です。極端な例ですが、例えば、図1の例で見てみましょう。 分かりやすいよくある例で示すと、各開発者の作業状況はメールや手帳上に記されています。検討やヒアリングした結果は、メールでほかの人に問い合わせたならメールボックス上にたまっていきます。打ち合わせなどで相手に会ってヒアリングしたなら、手帳やノート上にメモとして残っていきます。こうして、各開発者が自分のタスクの情報をメールやメモ、あるいは頭の中で“囲い込み”ながら開発が進んでいきます。 ここで、開発者がある機能を実装するために、「別の作業の状況や進捗（しんちょく）を把握したい」とします。 「誰が情報を持っているのか分からない」 まず、誰が情報を持っているのか分からないので、ヒアリ
「フロー体験」理論のあまりの凄さに戸惑いを隠せない：YLOGオルタナティブ：オルタナティブ・ブログ
とあるきっかけで読み始めた、ミハエル・チクセントミハイの「フロー体験」という本、あまりに衝撃的であり、日々のものごとに対する観点をガラっと変えてしまったため、その内容の一端を、特にインパクトある部分を中心に簡単に紹介したいと思います。 ■著者「ミハエル・チクセントミハイ」について ミハエル・チクセントミハイは、１９３４年ハンガリー生まれで、主にアメリカで研究生活を行った、２０世紀を代表する心理学者の１人。 １９９０年に出版された本書は、「(欲求の５段階で有名な）アブラハム・マズローの自己実現の概念を超えるもの」（ニューヨーク・タイムズ紙）など様々な新聞・専門家から賞賛され、「日常生活の心理学に関して、今世紀最高の研究者」とも言われています。 その知識は非常に広汎であり、心理学のみならず、文学・社会学・人類学・比較行動学・情報論・進化論・宇宙論・芸術などにまで及んでいます。 ■フロー体験とは
ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
メンテナンスやトラブルの際にディレクターがしておいた方がいい“8”のTips : LINE Corporation ディレクターブログ
ディレクターの渡邉雄介です。担当しているサービスのメンテナンスやトラブルがあったとき、初動が遅れたり、パニックになって判断能力が鈍ってしまったことはないでしょうか？ ディレクターブログでは、すでに何度か障害時の基本的な対応についての記事 (障害対応的ディレクションスキル・サーバ障害と向き合うには) が書かれていますが、今回はもう一歩踏み込んで、メンテナンスやトラブルの際にディレクターがしておいた方がいいTipsをいくつかご紹介します。 Tips1. トラブルの第一報だけは最速で開発メンバーに伝える 責任感の強い人は、まずはディレクターが問題をある程度取りまとめてからエンジニアや関係者に共有……と思いがちですが、たとえその時点で問題をよく把握できていなくても、障害が起きているということだけは最速で伝えるべきです。これは下記の2つの点から重要です。 ◆ひとりよりも複数で問題に取り組んだ方が解決
反復型開発における見積もりの実際：ベースとなるのはユースケース
オブジェクト指向技術の浸透や，反復型開発の広がりなど，システム開発を巡る状況が大きく変化している。見積もり方法も，従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基本的な考え方や，ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い，ソフトウエアを段階的に繰り返して開発していく「反復型開発（イタラティブ開発）」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基本的な考え方やフェーズの分け方が異なるため，従来型の見積もり技法を適合できない面がある。 そこで第4部では，反復型開発における見積もりの基本的な考え方と，現在，一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお，システム開発のプロセスは反復型開発において最も標準的な「統一プロセス（Unified
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DeNA Engineering - DeNAエンジニアのポータルサイト
かんばん！～もし女子高生がRedmineで「スクラム」開発をしたら
ソースコードの品質向上のための効果的で効率的なコードレビュー
10年かけたたどり着いた一つの場所はアジャイル開発の扉だった
