マネージメントに必要なことは全てゲームから学んだ
この投稿は毎年恒例、pyspa Advent Calendar 2020の1日目の投稿になります。 どうもご無沙汰しております、akisuteです。すっかり年に1回アドベントカレンダーのときにだけ顔を見せる人になっておりますが、おかげさまで無事平穏に過ごしております。 さて突然ですが私はプログラマーを引退しました。 なぜなら今年で36歳だからです。プログラマーは35歳になったら定年ですね。 実際のところ、このぐらいの年になると、よほど何らかの意志が働かない限り、技術に対する情熱みたいなものが失われてくると思います。もちろん本当に技術とプログラミングが好きな人は間違いなく35歳なんかで情熱を失ったりはしないと断言しますが、残念ながら私はそうではなく、もはやiPhoneには大した興味が湧いておりませんし、最近はJavaだのGoだのTypescriptだのVue.jsだのといったものを必要に応じ
5年分の店舗経験をゲームで――サイゼリヤに聞く，ボードゲームを活用した社員教育。「オリジナル店舗運営ゲーム」の顛末を制作陣に聞いた
5年分の店舗経験をゲームで――サイゼリヤに聞く，ボードゲームを活用した社員教育。「オリジナル店舗運営ゲーム」の顛末を制作陣に聞いた ライター：瀬尾亜沙子 レストランチェーン「サイゼリヤ」のことは，皆さんもご存じだろう。そのサイゼリヤが，ボードゲームを使った社員教育を始めたという。 企業におけるゲーミフィケーションの1つとして，研修用のボードゲームというものはときおり耳にするものの，実際に見たり遊んだりできるチャンスは限られている。企業向け研修用ゲームはたくさん作られているというが，企業側にメリットがないため，「こういうものを社員向けに作りました」とアピールされることがないからだ。 先日掲載した「サイゼリヤがボードゲームで店舗マネジャー（店長）の研修をしている」というニュースは，そのためか話題を呼び，多くの人の興味を惹いたようだ。そこでこの度，サイゼリヤに取材を申し入れたところ，快諾いただい
「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
放置プロジェクトをなくすために「色つき星取表」を使ってみよう｜結城浩
※全文を公開している「投げ銭」スタイルのノートです。 こんにちは、結城浩です。 いろんな作業（プロジェクト）を並行して走らせていると、ついついおもしろいプロジェクトばかりやってしまいがちです。 そうすると、とても長い期間放置する「放置プロジェクト」ができてしまいます。いったん放置プロジェクトになってしまうと、おっくうになってしまい、さらに放置が進んでしまいますよね。 そこで、放置プロジェクトをなくすために「色つき星取表」を使ってみましょう。 特別なソフトや準備は何もいりません。いつも自分が使っている「表計算ソフト」を利用すればすぐにできます。ExcelやNumbersですね。Googleのスプレッドシートの人もいますかね。 以下では順を追ってお話しします。 ■まず、こんなシートを作りましょう。 ■このシートの左には日付と１行日記を書きます。つまり時間は上から下に流れます。 ■上にはプロジェ
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
【勉強会メモ】"個人のタスクマネジメント"のコツや悩みを話す場 - radioc@?
devlove-kansai.doorkeeper.jp 日時：2018-04-06（金）19:30 - 21:30 場所：電通国際情報サービス関西支社 予定の都合で参加を見合わせていましたが当日になってやっぱり参加できそうだったのでキャンセルで空いた1枠に滑り込んで参加してきました。個人のタスクマネジメントはみんな同じような課題感はあるものの、やりかたはその人の仕事のしかたや生活に合わせて人それぞれなので色々議論の捗るテーマな気がしました。会社の勉強会でもテーマとして扱ってみんなでLTしてみたいです。 みんなだいすきTrello セッション後のダイアログでも周囲の人にどうやってタスクマネジメントしているかを聞きましたが全体的に圧倒的なTrello人気でした。ツールに固定されないタスクマネジメントの話ではありますが、細かなTipsはTrelloに最適化されている印象です。確かにレーンを分け
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
プロジェクト・マネジメントの教育について | タイム・コンサルタントの日誌から
先日、わたし自身が主査を務める研究部会で『プロジェクト・マネジメントの教育について』という講演をさせていただいた。過去何年間かにわたり、 大学・大学院・自社・他企業などで試行してきたPM教育カリキュラムの内容と課題について、ディスカッションしたいと考えたからだ。当日は普段の倍以上の方が来場され、この問題への関心の高さがあらためてうかがえた。遠くは岩手から参加された方もいたが、都合の合わなかった読者もおられると思い、ここにその一部をご紹介しよう。ちなみに、会の名称は「プロジェクト＆プログラム・アナリシス研究部会」といい、スケジューリング学会の下部組織だが、とくに学会員でなくても自由に参加できるオープンな組織である。 当日の発表内容は、前半が「大学におけるPM教育の実践例から」ということで、主にカリキュラムの内容の話、後半が「PM教育のあるべき仕組みを考える」で、わたしの今の考えを述べたもので
人材の流動化か囲い込みか
最近、日本のSI企業と仕事をする機会あった。 久々に衝撃的な体験だった。 とあるシステム案件の下請け的開発依頼だったのだが、 1.アーキテクチャがおかしい ビジネス系の人が直接実装担当のエンジニアに指示を出している。丸投げである。よってアーキテクチャが根本的におかしいのだが修正できない。 アーキテクト不在。 2.ドキュメントが無茶苦茶 基本なぜかエクセルで書いている。読みにくいことこの上ない。さらにバージョン管理が無茶苦茶である。ほとんど読んでも意味の無い古いドキュメントだらけで解読が非常に難しい。アプリのバージョン、開発環境などもドキュメント毎に違っている。ビルドするとドキュメントが自動生成されるなんてことは一切ない。 ドキュメント担当不在。 3.プロダクトのソース管理が無茶苦茶 ソース管理ソフトはつかっているものの、理解不能なブランチに分かれていて同等製品が複数派生している。修正に手間
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
山本一郎氏が語る「プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論」。ゲーム開発はなぜ炎上するのか
山本一郎氏が語る「プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論」。ゲーム開発はなぜ炎上するのか ライター：徳岡正肇 プロジェクト炎上のメカニズムと早期発見， 行うべき処理の概論 山本一郎氏 2013年4月15日，Unity開発者のためのイベント「Unite Japan」が都内で開催され，「プロジェクト炎上のメカニズムと早期発見，行うべき処理の概論」と題する講演が行われた。登壇したのは，炎上といえばこの人，ブロガーの“やまもといちろう”こと山本一郎氏だ。 「炎上」と聞くと，我々は「うっかり発言で，ネット大炎上」などといったフレーズを思い浮かべるが，ここで語られる「炎上」というのは，ゲームの開発がにっちもさっちもいかなくなってしまう状況のことで，山本氏は，そういった案件に対する火消しのプロなのである。 Unityに限らず，ゲームエンジンの普及によってゲーム開発は飛躍的に効率化して
データの鬼、Googleが解析した「よい上司を製造する8つの条件」
検索結果によって人の流れを自由に操る力をもつGoogle。その中で「よい上司」としてチームをまとめ結果を出すには何が必要なのでしょうか。人事チームによる解析計画「Project Oxygen」によって実に驚くべき結論が現れました。 Google流マネジメントの限界 Googleが採用するのは一言でいえば「天才」。豊富な知識と高い技術力をもち、しかも自分で考えて動ける人々が厳しい倍率を潜り抜けてやってきます。そういう人材に自由にさせておけばそれなりに結果が出る……これがGoogle流マネジメントだ、というのが共通の見解でした。 しかし実際には「デキる」チームとそうでないチームが生まれてしまうという現象が起こっていました。しかも「デキる」チームは何をやってもよい結果を出してしまうのです。ならば「高い能力を持った管理職」が大事なのではないか、そういう人物は何を備えているのか。これを探るべく人事チ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
俺とTrelloと終わらんタスク (DevLOVE関西 "個人のタスクマネジメント"のコツや悩みを話す場 資料) #devkan
https://qiita.com/shin_semiya/items/a2c0339d2a5e32eaf7db