作業ではなく、仕事をせよ - arclamp
この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 （補足追記：この記事は、一緒に働いている／働くことになる若い後輩たちへのメッセージです） 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア（もうちょっとで四半世紀...）の中で学んできたことも含めて、整理してみます。 心構え：作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実
EC/CRMの自社サービス「prismatix」開発チームのプロジェクトマネージャーになって最初にやったことn連発 | DevelopersIO
この7月からDev PjMにクラスチェンジしました。何もわからない状態から、いかにしてプロジェクトの状態を把握・コントロールしようとしたか、その試行錯誤の記録です。 4ヶ月前に言ってたことダイジェスト Dev PjMになって最初の頃、こんな話を書いていました。 prismatixの開発者から開発チームのプロジェクトマネージャーにクラスチェンジした話 | DevelopersIO マネジメントの姿勢 そこで、私は 指揮者(Conductor) として振るまおうと決意しました。 何をしたいのか Devチームを中心として系が回るようにする ことを実現したいと思っています。 もう少しわかり易い言葉でいうと、「prismatixというサービスの 開発 を通じて、顧客およびチームに 価値を届け続けている 状態を作る」のが目的になります。 どうしていくのか Devチームもハッピー、みんなもハッピー な状
Risk Breakdown Structureとは何か | タイム・コンサルタントの日誌から
米国のアポロ計画は、1961年5月に、ケネディ大統領が演説の中で、「60年代中に人類を月に送る」と宣言して始まった。じつは当時、宇宙技術の点で、米国は仮想敵国ソ連に大幅に遅れをとっていた。ケネディ演説の直前の4月、ソ連のガガーリン飛行士がボストーク1号に乗り、人類初の有人宇宙飛行を実現した。彼のセリフ「地球は青かった」は、名言として今も広く知れ渡っている。 ケネディ大統領が60年代中に（つまり、それから8年7ヶ月以内に）有人月面飛行をする、と宣言したとき、米国の多くの専門家は、「そんなこと不可能」と感じていたらしい。しかし、一見不可能に見える未来像を示して、大勢の人を引っ張るタイプの楽観的リーダーシップは、当時の米国社会ではうまく作用した。1969年7月、アポロ11号は3人の宇宙飛行士を乗せて、月に向かって旅立つ。 アポロ11号というプロジェクトに、費用を全部でいったいいくら使ったのか、正
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
危険予知：プロジェクト・リーダーに必須の能力として（11月16/23日・PMセミナーのお知らせ） | タイム・コンサルタントの日誌から
KYという流行語が、かつてあった。「空気が読めない」とか「空気読めよ」の略で、調べてみると2007年の「新語・流行語大賞」にノミネートされている。 この言葉が流行る前は、じつはKYは労働安全分野の略語だった。『危険予知』の略である。「KY活動」などとも使う。KYが「空気読めない」の意味で流行してしまった後は、あえて「KYK」とよんだりもしているらしい。まあ、地味なおじさん用語では、ネットやJKの影響力に勝てないし。 本サイトの読者で、労働安全に関心のある人は、正直あまり多くないと思う。だから「KY活動」だって、初耳かもしれない。製造業や建設業の現場では、危険を伴う作業を行うので、事故やケガが起きがちだ。いわゆる労災である。そこで雇用者に、労働安全のための監督義務を課している。 労働安全の分野では、「度数率」というモノサシで、安全を測る。これは労働時間100万時間あたりの労働災害の発生件数で
逆転敗訴した野村情シスがIBMに送った悲痛なメール、横暴なユーザーを抑えきれず
委託したシステム開発が頓挫したとして、野村ホールディングス（HD）と野村証券が日本IBMを相手取って計約36億円の損害賠償を求めた裁判。プロジェクト失敗はベンダー側に非があるとした2019年3月の一審判決から一転、2021年4月の控訴審判決はユーザー企業側に責任があるとした。工数削減提案に十分に応じなかったり、プロジェクト途中で追加要件を多発したりした野村側の姿勢を東京高裁は問題視し、逆転敗訴の判決を下した。 関連記事 野村HDが日本IBMに逆転敗訴の深層、裁判所が問題視した「X氏」の横暴な変更要求 野村HDが日本IBMに逆転敗訴のワケ、「工数削減に応じず変更要求を多発」と指摘 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。 当時、投資顧問事業部（判決文では「投資顧問部」）の次長だったX氏は、パッケージソフトに
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
プロジェクトの発想を活性化させる、『チームの思考能力』とは何か？ | タイム・コンサルタントの日誌から
以前も書いたが、これは、わたしがプロジェクト・マネジメントを学生や社会人に教えるときに、最初に出すクイズの一つである（「Structured Approachができる人、できない人」）。「店を探して予約する」「日取りを決める」「参加者を確定する」、等々、いろんな答えが考えうるし、どれも間違いとは言えない。しかし、わたしがあえてPM講義の最初にこの問いを出すのは、「計画を立てる」という、もう一段抽象度の高い答えが欲しいからだ。 時限的で一過性の取り組み、それも複数の人が関わって、失敗のリスクも伴うような事に取り組む際は、「まず計画を立てる」という思考習慣がほしい。言われなくても、当たり前のことである。そう思う人も多いだろう。ただ、その『当たり前』が、ちゃんと意識され言語化されていてほしいのだ。 ちなみに上記の記事を書いたのは、8年前の2012年7月だ。この年、わたしは東大大学院の柏キャンパス
kondo - 不要なプロジェクトファイルを削除
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 様々なシステムや小さなツールを開発していると、いつの間にかディスクスペースがなくなっています。巨大なファイルがある訳ではなく、小さなファイルやディレクトリの集まりがディスクスペースを逼迫していると、整理するのも大変です。 そこで使ってみたいのがkondoです。一般的に不要な（後でも復元できる）情報をリストアップしてストレージの整理を補助してくれます。 kondoの使い方 kondoはディレクトリを指定して実行します。 $ kondo ~/Documents/ 4.1KiB Node /path/to/yargs 4.7KiB Node /path/to/cosmiconfig kondoが対応しているのはCargo/Node/Unity Projects/SBT/Haskell/M
プロジェクトリーダーというお仕事 - Qiita
概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ
プロジェクトの進捗を計る「アーンド・スケジュール法」とは何か 〜 (2)その内容と課題 | タイム・コンサルタントの日誌から
EVMS（Earned value management sysytem）とは、プロジェクトのコストと進捗を、「アーンドバリュー」（出来高）と呼ばれるメトリクスを使って測定し、コントロールする手法であって、モダンPMの技術の三本柱の一つになっていると前回の記事で書いた。ところがEVMSには、ある弱点があった。「アーンド・スケジュール法」は、この問題を克服するために、2003年ごろから考案され発展して、ついにはPMBOK Guide第6版やPMI Practice Standard for Schedulingにも正式に採用されるようになってきた。 それでは、EVMSの進捗管理における問題点とは何なのか？ これを論じるためには、そもそも『進捗管理』（スケジュール・コントロール）という仕事の目的を、きちんと理解する必要がある。
RailsアプリとかをAWSのレガシーシステムからGCPのイケイケシステムに移行した話 - nownab.log
はじめに Railsアプリケーションを中心とするシステムをAWSからGCPに移行しました。本記事ではその過程をできるだけ赤裸々に公開します。 本プロジェクトではインフラ移行と同時にアーキテクチャも刷新しました。AWSがレガシーでGCPがイケイケという意味ではなく、移行対象システムのアーキテクチャがレガシーからイケイケになったという意味です。 技術的な内容については詳細は省いて概要の説明にとどめています。AWS、GCP、Docker、Kubernetesあたりの知識があるとスッと読めると思います。 書きたいこと書いたので長い記事になってますがぜひお付き合いください。 レガシーシステムとイケイケシステム まず、移行前のレガシーシステムと移行後のイケイケシステムについて軽く説明します。 タイトルをキャッチーにするためこうしましたが、特別レガシーでもイケイケでもないのでご了承ください。ちょっと前と
ソフトウェア設計が重要である理由 | POSTD
新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”（出典： Trent Erwin ／ Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存
プロジェクトの成功と、アウトカム | タイム・コンサルタントの日誌から
「自分がチャレンジする予定のプロジェクトでは、ゴール到達から成功失敗の判断まで半年かかることになっていますが、このような目標設定は適当ですか？」 今回は、この質問を取り上げよう。例によって、大学でプロジェクト・マネジメントの講義をしていた時、学生から出てきた問いである。そして、とても良い質問だ。 このときの講義のテーマは、「ミッション・プロファイリング」だった。この用語は、PMBOK Guideには出てこないので、なじみのない読者も多いかとは思う。プロジェクトにおけるミッション、すなわち使命を、その目的・ゴール及び目標（＝成功基準）などの観点から、分析・定義し文章化する作業である。その結果がプロジェクト・チャーターになる。 授業では特に目標設定の大切さを学生に教え、修士論文や就活を題材に、プロジェクトとしての目標を考える、簡単な演習を入れている。さらに、自分がこれから将来関わるであろうプロ
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
仕様の「見える化」と働き方改革 - 設計者の発言
工学の世界広しといえども、複雑膨大な設計情報をExcelで管理しているのはIT業界くらいだろう。ITは現代社会のインフラを成すほど重要なものだが、その有り様がOfficeのような汎用ツールで管理されているとしたら、なんと脆弱なインフラだろうか。Excelで設計情報が管理されている飛行機や高層ビルなど、怖くて誰も利用しないだろう。プロのIT技術者を名乗るなら、プロ用のCAD/CAM（エンジニアリングツール）を使おう。気に入るものがなければ、ITスキルを行使して自作しよう。私は長年そのように主張してきた。 残念ながら、業界でのCAD/CAMの利用は進んでいない。今でも石を投げれば「Excel方眼紙」の峨々たる集積にあえぐプロジェクトに当たる。何回か説明したが、これにはそれなりの理由がある。まず、ExcelやWordやパワポやVisioでの仕様管理を前提とすれば、余分な工数や要員を見積に上乗せで
大規模データ移行の失敗を防ぎたい。計画やプログラム、インフラの注意点と、ありがちなこと - Qiita
仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
Account Suspended
Account Suspended This Account has been suspended. Contact your hosting provider for more information.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://brevis.exblog.jp/28315223/
プロジェクト計画のロジックとは何か 〜 やはりExcelで工程表を書いてはいけない (2) | タイム・コンサルタントの日誌から
