メテオフォール型開発 - 実践ゲーム製作メモ帳2
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
部下の士気を上げたいリーダーが知っておくべき、「ストローク」とは？
京都大学法学部卒業。米国ダートマス大学タック経営大学院留学（ＭＢＡ）、東京銀行、岡本アソシエイツ、日本福祉サービス （現、セントケア）を経て独立し現職。名古屋大学客員教授（平成26年度後期）。企業規模、業種を超えた「経営の原理原則」を元に、幅広く経営コンサルティング活動を行う一方、年100回以上講演を行う。『ビジネスマンのための「発見力」養成講座』（ディスカヴァー21）など著書は150冊を超え、現在も経済紙等に連載を抱える。 小宮一慶の週末経営塾 経営課題を抱えて日々悩む経営者に向けて、数々の企業経営者に伴走してきた経営コンサルタントの小宮一慶氏が課題解決の「ヒント」を提供。どんな業種にも通じる経営の原理原則をおさえながら、経営者はどうあるべきか、実際の経営現場で何を実行すべきか、を語る。 バックナンバー一覧
SECIモデル（ナレッジ・マネジメント） | Osamu Hasegawa Films
SECIモデル（SECIプロセス）とは、一橋大学の野中郁次郎氏と竹内弘高氏らが提示した広義のナレッジ・マネジメントのコアとなるフレームワークです。のちに、野中氏は紺野登氏とさらにそのモデルを精緻化させています。 SECIモデルでは、知識変換モードを４つのフェーズに分けて考え、それらをぐるぐるとスパイラルさせて組織として戦略的に知識を創造し、マネジメントすることを目指します。 【共同化】Socializaiton 暗黙知から暗黙知へ 共同化とは、経験を共有することによって、メンタルモデル（認知的＝精神的暗黙知）や技能（技術的＝身体的暗黙知）などの暗黙知を創造するプロセスです。暗黙知を共有する鍵は“共体験”です。経験をなんらかの形で共有しないがきり、他人の思考プロセスに入り込むことは難しいとされています。 【表出化】Externalization 暗黙知から形式知へ 表出化とは、暗黙知を明確な
割り込み - hitode909の日記
困ったらなんでも聞いてくださいみたいな感じあるけど、聞かれてる側は聞かれすぎると自分のことできなくなって破綻すると思う。聞かれる側がバブルっぽい部長みたいな感じで一日中リラックスしてゴルフの練習とかしてる感じなら無限に聞いていいと思う。聞かれる側も集中して作業してやっと終わるみたいな感じなら、最速でやれば終わるみたいな感じだから、一日中聞かれ続けてたら困ると思う。こう調べたけどこうでした、こう思うけどどうですか、みたいな感じなら、聞いてることが分からないと止まってしまう、ということにならなくて、質問送って返るまでの間に別のことできると思う。だから、聞かれた側がすぐに返信しなくてもいいような手段で、メールとか、GitHub使ってたらIssueからリプライ送るとかでで済むと思う。別の話で、二人で同じところを触ってるときは密に連絡した方がよくて、作ろうとしてる物が違うとか、二人とも同じ変更をして
割り込み度 - hitode909の日記
割り込みタスクの対応にかかっている時間の割合を計算すると，どれくらいばたばたしているか計測できるのではないか たとえば，1日のうち，その日にやってきたタスクをやるのにかかった割合が1.0なら，完全にその日暮らしをしていて， 朝なにが起きるかまったく予想できない状態で出社していることになる その日にやってきたタスクにかけた時間が0.0なら，前日までに予定したタスクを進められていて，計画に沿って進められている たとえば，1週間みたいな単位で，毎日その日にやってきたタスクをやっているなら，毎日予期せぬことをやっているということで，長期的に計画を立てて動くことは不可能 新たなタスクが，すでに進めているタスクの緊急度を上回ることがないとき，手持ちのタスクを進めることができて，安定した状態．タスクをキューにして扱えるので順番に処理できる 新たなタスクが既存のタスクの優先度を上回るということは予想外のこ
なぜプロジェクトは炎上するのか？vol.1～それはスカウターが故障してるから～ - Qiita
私自身これまで複数の開発案件でプロジェクトマネジメントをしてきました（開発もするプレイングマネージャー的な感じで） ※マネジメント規模は数人～60人規模まで様々（システム開発・ソーシャルゲーム開発が主） これまでプロジェクト炎上案件の立て直しを何件も実施してきました（立て直しは一番やりたくない…） 今回は「なぜ炎上するのか・どうしたら炎上しないのか」に焦点を当てて、炎上案件について共通点や回避策など実際の実例を交えて複数回に分けて纏めておこうと思います（※現職がゲーム開発なので、ゲーム開発を例にして記述します） みなさんの周りに何も解決できない「なんちゃってPM」はいませんか・・・？ ※スカウターの話は後半で出て来ます プロジェクトが炎上する理由 いきなりですが、プロジェクトが炎上する理由は プロジェクトマネジメントしている人間のマネジメントスキルが低いから です。 「そんなの当たり前だろ
プロダクトマネジメントトライアングルと各社の PM の職責と JD
プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「 プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うこと… 記事によれば、プロダクトマネージャーはこれらの領域を健全に機能させることが役割であり、 機能がなければ自分で役割を演じたり、補う方法を見つける （たとえばデザイナーがいなければ、自分でデザインを行ったりデザイナーを雇う）「開発者-ビジネス」「ビジネス-顧客」「顧客-開発者」の融合領域における、各種の複雑さや衝突、トレードオフの統合を行うといったことが PM の職責であると理解しています。 逆に言えば、これらを俯瞰して見ることができる能力が PM には求められています。そうした意味で、PM は様々なことを広く学び、組織やビジネスの変化に柔軟に対応できる必要
ムダだらけの会議 – 海外から見た日本式ミーティングの謎 デザイン会社 ビートラックス: ブログ
「で、このミーティングって意味あったんでしょうか？」 先週の日本出張でのクライアントとの会議の際に思わず言ってしまった。 自己紹介と、会社の説明、その後は、ぼんやりとした仕事の内容を話し「この方向で検討していければ幸いです。細かい内容は担当者同士で。」で終了。次の具体的なアクションプランや期日も決めない状態ではどうしても不安になった。 というのも、アメリカだと会議の後に誰が何をするかとか、次のアクションとかが決まらずに終わるのは”失敗”とされ、商談がうまくいかなかったのと同じである。 いや、日本とアメリカの会議の方式の違いに戸惑ってしまっただけで、どちらが良いとか悪いとかいう事ではない。しかし、久しぶりに日本で大企業との”典型的な”ミーティングに参加し、漠然とした違和感を感じた。 その具体的な要因を考えて行くうちに、今回の出張で偶然フライトが一緒になったRochelle Koppによる動画
バグなどの謎の現象に立ち向かうも闇が濃く、どうしても沼から脱出できない時に見るフローチャート - Thanks Driven Life
ご査収ください (2022年12月8日 追記) フローチャートを書き直しました。内容自体は当時のものと同じです。 補足 パフォーマンスの出し方は人それぞれなので「私はこんな感じです」というものです。 とりあえず「なんかやばいな?」と思ったら休む 体調的にはもちろん、「これ結構やばそうだな?」という勘所は大事 15分以上(長くても30分)悩んだら周りに聞いてみる こういう時はだいたい 視野が狭くなっている(簡単なスペルミスだったり) 暗黙知に触れている(業務だとよくある) とてつもない難問にぶちあたっている といったケースなので、仲間にSOSを出した方がチーム全体の進捗も結果的に良くなる、という経験談です。 ちなみに15分の根拠はなんとなくです。 ちなみに、問題に取り組み始めるその瞬間から「15分やってわからなかったら誰かに聞こう」としている場合は、 フローチャートの「30分動いてなかったら
「ビジョンを守るために、株主総会で売上と利益を下げる宣言した」――有給取得を人事の帳尻合わせにしないためのサイボウズ流処方箋（前編） - リクナビNEXTジャーナル
「ビジョンを守るために、株主総会で売上と利益を下げる宣言した」――有給取得を人事の帳尻合わせにしないためのサイボウズ流処方箋（前編） ある日突然、トップダウンで職場に降りてきた「早く帰れ、有休を取れ」と言う指示。売上だけでなく労働時間にまで数値目標を課せられた社員からは、「残業代削減か」「たまった仕事はどうするんだ」と不平不満の声が聞こえてきて、時短に向けた取り組みは序盤から険悪なムード――。 強引に「時短」に舵を切り、上記のような状況で苦しんでいる企業は多い。「ノー残業デー」や「健康経営」などの聞こえの良い言葉が、経営陣の壮大な独り言となり、社員にはなかなか伝わっていないのが実情でしょう。 一方、今では「多様性のある働き方」の成功事例として頻繁にメディアに取り上げられているサイボウズも、過去には「離職率28％」という時代がありました。同社は、休むことをよしとしない職場風土からどうやって脱
君のチームに「構造」はあるか？ 伊藤直也が語る、学びが蓄積されるマネジメント
2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏が過去の実例から「学習結果が蓄積されるマネジメント」について語りました。 「CTO」と「VP of Engineering」 伊藤直也氏（以下、伊藤）：「1人CTO Night」というちょっとキャッチーな名前のイベントですが（笑）、さっそく始めさせていただきます。一休の伊藤です。 今日は「一休の伊藤」というかたちで出ていますが、あまり自社の宣伝をしてもしょうがないので、過去に技術顧問をやってきた時の経験などを含めて「いろいろな会社でこう
マネジメントを経験してようやくわかってきた、半年で部下を１人前にするコツ - トイアンナのぐだぐだ
試行錯誤しながら手に入れた部下や後輩を半年で１人前にするコツをまとめました。 嫌な先輩から、まあまあの上司になるまで まずは私の経歴を少し。昨年独立するまで外資で働いていました。新卒で入ったのは少数精鋭にしたって、いくらなんでも少なすぎない？ と人事の肩を揺さぶりたくなる部署でした。 入社2年目には「もう１年いるんだからシニアだね！後輩指導よろしく」と宣告され、必死で３人指導してのち転職。その後はプロジェクトごとに部下を持っていました。独立した現在は外注マーケターとしてトレーニング業務も担当することもあります。合計で指導した部下・後輩は約10名前後。 最初は最悪の上司だったと思います。詳しくは「いつの間に自分が「細かいことにウルサイ嫌な先輩」になっていた 」に書きましたが、もうタイトルだけでお察しください案件。自分でもこれはいけないと思い四苦八苦した今、半年くらいで「いいね、それで行こうか
GitHub+SlackでIssue駆動開発
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
「PDCA」って言葉は正しいの？―全く回らない「PDC」とその対策。 - プロジェクトマネジメントの話とか
全ての社会人に必要不可欠な「PDCA」の考え方。でも、この「PDCA」って言葉・考え方に違和感を感じたことはありませんか？「PDCAとは」一体何なのか？ 世間では当たり前のように使われているこの概念ですが、今回はこの考え方の妥当性と、「PDC」の回し方について考えてみたいと思います。 スポンサーリンク PDCAとは？世間一般の「PDCA」サイクルの定義を確認 まず、PDCAとは何かをおさらいしましょう。みなさんが日頃使ってる「PDCA」というのは、下記のようなものですかね？ １．Plan：計画して ↓ ２．Do：実行して ↓ ３．Check：実行結果をチェックして ↓ ４．Action：対策を講じる ↓ １．Plan… 「４．Action」は「解決策を考え、対策を行う」ということのようですが、まず「解決策を考える」ってのは「３．Check」や「１．Plan」に包含されるし、「対策を行う」と
『総花的な解決策を提示しない』
今週の大学院での問題解決の講義は、現在進行形で自分が使える、使うべき内容だったのでとても「勉強になった」を通り越して「救われた」思いだった。 ■総花的に解決しようとしない あれこれ課題を整理すると、総花的に解決案を提示したくなるけど、課題が山積みの場合はどこか一点突破をしないといけない。なぜなら課題が山積みの組織は、何らかの原因で課題が放置されている構造的な問題を抱えているから、あれもこれも一気に改善するような組織力は持っていない。 例えば過去成功したやり方を時代が変わっていても続けていたり、逆に組織体制の変更により上手くいっていないパターンだ。 ■成功体験を作る それでも最終的には全部解決したい。ではどうするか。一番成果が出やすいところに手を入れる。経営層から見た成果というのは多くの場合売上なので、売上に直結する部分をテコ入れする。 そうしてそこが成功すると、経営層も、現場も、周囲にいる
デベロッパからマネージャへの転向 | POSTD
デベロッパなら誰しも、自分の将来を決断すべき時が来ます。このままデベロッパ、またはシニアデベロッパのキャリアに留まってコードに専念するか、チームの管理を担うリードデベロッパや開発マネージャといった管理職の世界に飛び込むかの選択です。 ディルバート：プログラマからスーパーバイザへ 私自身も2011年に同じような決断をしました。ある大手インターネット銀行のシニアデベロッパだった私は、直属の部下はいなかったものの、数人をメンタリングしていました。当時私は、大学生に職場を世話して1年間のトレーニングを提供するアカデミーのプログラムに携わっていました。最初はメンターを担っていたのですが、最終的には、通常のシニアデベロッパの職と並行しつつ、そのアカデミーの管理を任されるようになりました。厳密な意味で、私が複数の人たちを直接管理したのは、この時が初めてで、私はその仕事を心から楽しみました。その後、私は消
行き過ぎたマネジメントが、チームとプロジェクトを破壊する
常に文書による指示を要求せよ。 誤解を招きやすい指示を出せ。意思統一のために長時間議論せよ。さらに出来る限り不備を指摘せよ。 準備を十分行い完全に準備ができているまで実行に移すな。 高性能の道具を要求せよ。道具が悪ければ良い結果が得られないと警告せよ。 常に些細な仕事からとりかかれ。重要な仕事は後回しにせよ。 些細なことにも高い完成度を要求せよ。わずかな間違いも繰り返し修正させ小さな間違いも見つけ出せ。 重要な決定を行う際には会議を開け。 もっともらしくペーパーワークを増大させよ。 通達書類の発行や支払いなどに関係する決済手続きを多重化せよ。すべての決裁者が承認するまで、仕事を進めるな。 すべての規則を隅々まで厳格に適用せよ。 何事をするにも「通常のルート」を通して行うように主張せよ。決断を早めるためのショートカットを認めるな。 「スピーチ」を行え。できる限り頻繁に長い話をすること。長い逸
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
「Webディレクター」という肩書とその役割 | F's Garage
先日、WebSigの10周年イベントの検討会議の場で、Webディレクターとは？というの話になった。 昔よく言われたのは、「Webディレクター」は「デザインできない」「開発できない」人がなる職業というネガティブな表現があった。特に「Webの仕事」と言えば「Webの受託制作」だったころは、そういう人たちが沢山集まってきていた。 そういう中で、「工程管理しかできないディレクター」とか「気が効かないディレクター」とか、「言われたことしかやらないディレクター」とか、確かに、いろいろいたように思える。 またネガティブな意味で、「Webディレクターとは何でも屋なんだよ」と言われることもある。これはある意味真理だと思っている。 個人的に思っているディレクターの重要な役割とは、 「バネのように、状況（案件）に応じて自在に伸び縮みして、お客さんと制作との穴を埋める仕事」 だと思っている。 PMが全体を見ている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HackMD - Collaborative Markdown Knowledge Base
