プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
オープンソースにコントリビュートする方法
オープンソースにコントリビュートする方法 オープンソースにコントリビュートしたいですか？このガイドではオープンソースへのコントリビュートの方法を、初めての人だけでなく熟練の方にも紹介します。
海外企業との共同プロジェクトにおけるフォーメーション・デザインは、どうあるべきか | タイム・コンサルタントの日誌から
前回の記事の末尾にも書いたが、「マネジメント・テクノロジー」という言葉を発案して、わたしに教えてくれたのは、今秋惜しくも亡くなられた勤務先の同僚、故・秋山聡氏である。秋山さんは、この語を《マネテク》と縮めて、『まねてくニュース』なるメールマガジンとデータベースを、社内に発信し続け、多くの愛読者を持っておられた。 秋山さんは高専を卒業後、大学の工学部に編入して修士号を得た、バリバリの理系教育を受けた人だった。日揮に入社後、海外プロジェクト・マネジメント部門で活躍されたが、ある時期より、ライン業務から一切手を引き、PM業務の標準化を中心としたスタッフ的役割に専念するようになった。プロマネ経験者こそが最大の出世コース、と思われているエンジニアリング業界にあって、これは随分と勇気のある処世だったと思う。 日揮においては「プロジェクト・マネジメント技術部」という部門が、一種のPMO的な機能を担ってき
プロダクトマネジメント はWhat、プロジェクトマネジメントはHowに責任を持つところに違いがある
プロダクトマネジメントとプロジェクトマネジメントは、関連する役割で、かつ似た単語を使っているため、混同してしまう人も多いでしょう。プロダクトマネジメントは、「What」何の機能を作るのか、「Why」なぜその機能を作るのかを明らかにします。一方、プロジェクトマネジメントは「How」どのように「When」いつ作るのかに責任を持ちます。その責任範囲の違いから、役割は区別されます。 プロダクトマネジメントは、ユーザー・開発者・ビジネスの満足を追求するプロダクトは、何らかの問題を解決し、ユーザーのニーズを満たすものです。プロダクトは初めに市場へリリースされてから、バージョンアップを繰り返し、製品提供をやめるまで、そのライフサイクルは続きます。プロダクトマネジメントは、ある製品についてDesirability（望ましさ。ユーザーのニーズ）、Feasibility（技術的な実現可能性）、Viabilit
とあるAIプロジェクトの失敗とそこから得た鬼十則 - Qiita
私自身もこういったアンチパターンに遭遇し失敗した経験がある。 冒頭にあげた鬼十則はその反省から生まれたものであるが、ここからそれぞれの項目を解説していきたい。 1. データは自ら集めるべきで、与えられるべきではない 主人公の「データがないから開発できない」の発言は間違ってはいない。しかしデータがないと嘆くのではなく、そのデータを取りに行く努力が必要である。昨年データサイエンティスト界隈で話題となった『アルキメデスの大戦』では上のいざこざでデータ（設計図）が手に入らない時、自らデータを集めて突破口を開くエピソードが綴られている5。この姿はまさに理想のデータサイエンティスト像といえるだろう。データ収集の壁は数多く挙げられるが6、その壁を乗り越える努力を怠ってはいけない。自らが安心して開発を進めるためにも、データ取りには十分に入り込んでいくべきである。 2. 目標とは、先手先手と働き掛けていくこ
変わり続けるプロジェクトの優先順位に終止符を
私が出会う内製のデジタルチームの多くはプロジェクトの優先順位をコロコロと変えることで、まるでいつも消火活動に当たっているかのように忙しくしています。こんな状態ではいけませんので、その解決法をお教えしたいと思います。 このような問題は誰もが経験したことがあると思います。チームが急遽今週やらねばならなくなった仕事や、プロジェクト以外の仕事はすべて放っておけと主張するようなシニアマネージャーなど…。 プロジェクトの優先順位は、いちばん声が大きい人の意見か、早い者勝ちで決まってしまいます。そうなるとビジネスにとってなにが最適かということはほとんど考慮されないので、チームがどのようなプロジェクトに取り組んでいるとしても、成功の見込みすら立たないでしょう。 もちろん、デジタルチームに必要な仕事をすべてこなせる十分な人数がいれば問題にはならないでしょうが、そんなことはまずありません。やらなければならない
プロジェクト・マネジャーが知るべき97のこと
プロジェクト・マネジャーが知るべき97のこと大人気の書籍『プロジェクト・マネジャーが知るべき97のこと』のエッセイを無料で公開中！すべてのプロジェクト・マネジャーにおすすめの本がウェブで読めるようになりました。 エッセイ一覧できるだけ早期にユーザーを巻き込むモグラたたき開発を避けようローカライゼーションのせいで締め切りに遅れるプロジェクト・オーナーは強力なプロジェクトサポーター複雑よりもシンプルな方がいい負債を支払うスキルでなく素質のある人を加えようシンプルにいこうあなたは特別ではないスクロールから学んだこと問題にかかるコストを削減するすぐれた開発者を見つけるには熟練と並の開発者の生産性大きさが重要手順を文書化して、守られているか確かめようさあ、プラクティスを投げ捨てよう要求と仕様成功はビジネス価値で評価される休暇をキャンセルしない集中する時間を取るプロジェクトマネジメントはプロブレムマネ
日経xTECH記事『デジタル活用を阻む「PoC貧乏」〜』について - bonotakeの日記
日経xTECHに、次のような記事が載っています*1。 tech.nikkeibp.co.jp この記事、冒頭から PoC（ポック）貧乏──。講演者の1人が使った言葉が聴衆の笑いを誘った。あるAI（人工知能）関連イベントでの出来事だ。 という一文で始まっています。 で、読み進めていただくとわかるんですが……この「AI関連イベント」、明らかに、私が関わっている 日本ソフトウェア科学会 機械学習工学研究会（MLSE）が5月に開催した、研究会発足記念のキックオフシンポジウムのことで、「講演者の1人」は、アクセンチュアUSAの工藤卓哉さんです。 下記アーカイブ動画の16:44あたりからご覧になれば、記事になっている話がそのまま講演で語られていることがわかります。その辺りで出てくる「丸山先生」は、MLSE運営委員の一人である丸山宏さん（現：Preferred Networks フェロー）です。 基調講
プロジェクトマネジメントは仕組み化が9割
今回はオペレーションに関するスライドです。特にフォーカスすること、フォーカスするためにできることについて解説しています。 スタートアップへのアドバイスとして「フォーカスが大事」とよく言われます。それでも実際にフォーカスできているスタートアップは中々いないようです。 なのでこのスライドでは、なぜフォーカスすべきなのか、そして実際にフォーカスするためにどうやってオペレーションを効率化すれば良いのかなど、私がこれまで支援の中で得てきた知識をまとめてます。少しでも効率化して、フォーカスできるようになればいいなと願っています。
計画する技術 - kakakakakku blog
今日は社内勉強会で「計画する技術」というタイトルで発表をした． 前から少し「計画」のところに課題感があって，そのあたりの知識を組織に広めて欲しいというオーダーもあったため，僕が日々考えていることを言語化して，発表することにした．僕は今までに様々な「計画」の経験があり，実際に今の組織でも難易度の高いプロジェクトを何度も計画し，遂行してきたため，「計画」に対する信頼残高は増えているのではないかと思う． 発表資料 意識したこと 今回，発表資料を作るときに意識したことが2個あった．他にも話したいことはたくさんあったけど，組織マネジメントの話はまた別でしようと思って，あくまで「計画」に特化した話にした． 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や，難しい法則の話は控えるようにした．そういう話をしてしまうと，その場では「おー，
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
「PoC」の進め方──メンバー選定、環境構築、データ収集と活用、評価まで
「ビッグデータプロジェクトを始めることになった」ら、何をすればいいのか──。本連載は、「ビッグデータプロジェクトの“進め方”」を業務視点／ビジネス視点の両面から具体的に理解し、実践していくための導入指南です。 前回は、ビッグデータおよびビッグデータ基盤の概要について、そしてその第一歩として「小さくても、確実な成功を収めることが重要である」と説明しました。今回はこの第一歩を踏み出すに当たって必要となる、「PoC」（Proof of Concept：導入前実機検証）を、具体的にどう進めていくかを説明します。なお前回も触れましたが、本連載におけるビッグデータ基盤の説明には、業界標準であるオープンソースの分散処理基盤「Apache Hadoop（以下、Hadoop）」を用いることとします。 PoCとは、新規システムの本番導入に先駆けて、小規模なシステムを試験的に導入し、ビジネスにおける有効性を調査
デスマーチは続くよどこまでも。発注サイドからみた開発プロジェクトのこぼれ話。 - 親子ボードゲームで楽しく学ぶ。
私は仕事でシステム開発プロジェクトに発注者側として関わることがあります。 ソフトウェア開発と建設工事はよく似ているといわれますが、両方みてきた経験からしても確かに似ているかも。 長期にわたるプロジェクト体制が組まれ、そこには多くの関係者が関わります。 受注するのは大手企業でも、1次請、2次請は当たり前。最末端では「何を作っているかも分からない」ことも多いプログラマたち。かなり過酷な労働環境で働いています。最近では日本語がわからない外国人がオフショアでコーディングしていることも多いですね。 ただ建設業とソフト開発で決定的に違うのは、進捗が目で見えないところ。建設工事なら「もう3Fまで出来上がったな」と、素人目でもわかりますが、ソフトウェアはそうはいきません。 そのため、ソフトウェア開発の進捗管理は、コンサルティングファームなどからくるマネジメントのプロでも至難を極めます。 開発プロジェクトと
工数見積もりやスケジュール管理で参考になる記事10選
プロジェクトを遂行するためには、工数の見積もりやスケジュール管理が必要になります。正確な見積もりは難しく納期に間に合わなかったり、残業や休日出勤で埋め合わせたりした経験はありませんか？ 今回は、より正確に工数の見積もるための手法や、差し込み作業を考慮したスケジュール手法などについて解説されている記事をまとめました。 マネージャー、エンジニア、デザイナーなどすべての方に参考なる内容だと思います。 開発の見積もりとスケジュール管理 クックパッド株式会社の方が実践している見積もりとスケジュール管理方法について紹介されています。工数を見積もるステップや、スケジュールを立てるときの注意点、スケジュール管理の方法について学びたい方におすすめの記事です。 開発の見積もりとスケジュール管理 不安とストレスから解放される見積りとスケジュール方法 開発をしているとき、納期に間に合わなかったらどうしようと不安に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最速でAI機能をリリースする技術 Repro tech meetup4 - Speaker Deck