機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針

昨今のプロジェクトは不確実性が高いものが多く、そのマネジメントも簡単ではありません。私たちソニックガーデンで取り組むプロジェクトにも、うまくいくものもあれば、あやしい雲行きになるものもあります。 成功するための要諦は見つけにくいですが、失敗しそうなプロジェクトには共通項があります。それは「イシュー」のマネジメントをしていないことです。イシューを適切に扱っていないプロジェクトの先行きは不安です。 本稿では、私が不確実性の高いプロジェクトに取り組む際に実践した方がよいことの一つと考えている「イシューのマネジメント」について紹介します。 イシューのないプロジェクトが失敗する理由 プロジェクトを進めていて、どうもうまく成果に繋がっていないとしたら、 やるべき仕事に注力できていないことが原因かもしれません。たとえば新規事業のような不確実性の高いプロジェクトでは、やることが膨大にあります。 そうしたと

アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて

ChatworkのプロダクトマネジメントおよびPM（プロダクトマネージャー）育成のノウハウを、リレー形式で紹介する本連載。第4回となる今回は、プロダクトマネージャーの石田より「小さなカイゼンを継続するための仕組み作り」というテーマで、継続的なプロダクト改善を行うための活動をご紹介させていただきます。Chatworkでは以前、プロダクトの規模が拡大するにつれ、ユーザーからの改善要望に応えられない状態に陥りました。メインのプロダクト開発と日々の改善を両立する仕組みについて、「UX負債」の考え方などを含めて解説します。 第3回：リリースサイクルを高速化する「Quick PRD」とは？ PM以外のメンバーも起案できる仕組み作り Chatworkでの開発プロジェクトの種類 Chatworkのプロダクト開発は、大きく2つのタイプに分類されます。開発期間が1カ月以上かかり、プロダクトマネージャーと複数の

こんにちは。デザイナーのいしかわです。プロジェクト管理ツールマニアです。 理想的なプロジェクトマネジメントに向けて、これまでにプロジェクト・タスク・情報共有・進捗管理などに関するツールを30以上試してきました。その中から特におすすめしたい厳選ツールを7つ紹介したいと思います。 プロジェクト管理ツールを乗り換えるのは大変なので、できるだけ長く使い続けられるものを見つけたい！という気持ちで本気で評価しましたが、あくまでも自分で使ってみた感想になるので、人によっては合う合わないがあると思います。プロジェクト管理ツールの選定の参考になれば嬉しいです。 ※本エントリー更新時点での情報になりますので、機能や価格などの情報は異なる可能性があります。 ※2016/2/21  Asanaを追加しました ※2016/9/4 各ツールの最新情報をチェックし内容を更新しました ※2017/1/13 各ツールの最新

2009年までオートバイの全日本選手権や鈴鹿8時間耐久ロードレースに参戦していた元レーシングライダーです。現在は引退し、会社を経営していますが、企業や大学のプロジェクトチームをマネジメントする立場にあります。チームスポーツのレース業界で13年間培ってきた持論を言語化していければと思っています。 これは『アクティビティ「持論を持とう！」』に参加された日経ビジネスオンライン読者が書いた「参加にあたっての一言」である。 本連載の第1回で、「PM（プロジェクトマネジャー）の持論を作り、磨いていく手順を学び、同時に参加者がお互いの持論を通して啓発し合える活動（アクティビティ）を実施する」と読者に呼びかけた（『あなたの「持論」は文章に書けますか？』参照）。 ここで言う「持論」とは「経験から生まれ、行動を導いている方法論」である。自分が持っている方法論であり、自分の経験から生まれ、自分の行動を導くものを

本連載で言う「持論」とは「経験から生まれ、行動を導いている方法論」を意味する。あなたが「持っている論」であるから、あなたの経験から生まれ、あなたの行動を導くものを指す。自分自身の成長のツールであって、万人に役立つ一般的な方法論のことではない。 前回（『あなたの「持論」は文章に書けますか？』）は、持論の定義、持論が必要な三つの理由などを説明し、「持論を頭の中で考えるのは簡単だが、書いてみると簡単ではない。次回は持論を整理し、文字にする具体的な手順を説明する」と述べた。 今回は、持論を作るためのプロセスを紹介する。具体的な手順を知り、自分で手を動かすことによって、持論とはどのようなものか、確たる認識を持っていただければと思う。 持論を書く基本プロセス まず持論を作るプリミティブ（根源的）なプロセスを説明する。極めて単純だが、持論作りを本格的に進める際にも、以下の4点が基本になる。 領域特定：

★スタバの話 氷で薄くなってしまうのがイヤなので、スタバでアイスコーヒーを頼む時は氷すくなめにしてもらう。すると60%くらいの確率で「その分、コーヒーを増やしますか？」と聞いてくれる。知ってました？むちゃお得な感じしません？ もし増やしてくれないときは、その分だけ自分で牛乳を足す。もちろんタダ。 ★吉野屋の話 安部社長がインタビュー記事で語っていた吉野屋のポリシー。 「牛丼の具をご飯に盛る際、キッチリ決められた分量だけ一発ですくえるのがプロ。もし決められた量より1g多くよそってしまったら、その分だけ会社にとっては損失だ」 社長は元々、アルバイトとして牛丼をよそっていた方。光景が想像できる。 ★さて、どっちに共感します？ どちらの話も 「チェーンストアオペレーションの中で、提供する商品の分量を守るべきか守らざるべきか」 というテーマなのだが、結論が正反対なのが面白いと思う。 ・「ちょっと足す

当初の計画通りに作業が進んでいることを確認する見える化は大切だ。しかしそれだけでは、現場で問題が発生したことを早期にはつかめない。現場で起こっている問題を浮かび上がらせる工夫が必要になる。 数字による報告だけでは、プロジェクトの状況は見えてこない──。シーイーシーの栗原誠氏（第一システム事業本部 第二システム開発事業部 第三システム開発部 グループマネジャー）は、PM（プロジェクトマネジャー）として参画したあるプロジェクトで、こう痛感した。 それは、プログラミング/単体テスト工程の終盤でのことだった。栗原氏はそのプロジェクトで、「プログラム20本のうち10本のプログラミング作業が終わったので進捗率は50％。単体テストまで完了したのは5本なので進捗率25％」といった数字を基にした報告を、週次ミーティングでメンバーから受けるようにしていた。 報告を聞く限りプロジェクトは順調に進んでいるように見

Rustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...

プロジェクトに成功する企業と失敗する企業の二極化が進んでいる─―。 日経コンピュータが5年ぶりに実施したシステム開発プロジェクトの実態調査から、 こうした現状が浮かび上がってきた。 全体の成功率は31.1％で5年前より4.4ポイント上昇。 しかし、率以上に変化したのはその内容だ。 成功企業と失敗企業の明暗を大きく分けたのは「測る」ことだった。 最新の分析結果を報告する。

「システム開発プロジェクトで、進捗をきちんと守ることなんて到底無理ですよ。いいシステムを作ろうと思うほど、進捗が遅れるんですから。雑誌作りだって同じでしょう？」。 日経SYSTEMS 2010年8月号で「進捗遅れをなくそう」という特集を担当するにあたり、懇意にしているITエンジニアのAさんに相談したところ、特集の意義を真っ向から否定された。 記者は言葉に窮した。自分で言うのも何だが、記者は進捗（締め切り）遅れの常習犯である。自分のことを棚に上げて、システム開発プロジェクトの進捗遅れに意見する資格はない。 それでも、一点思うところがあったので指摘した。経験的に言って、進捗を遅らせたほうがいい記事になるとは限らない、ということだ。むしろ進捗通りに進んだときのほうが、記事の出来はよいように思う。 記者の指摘に対し、Aさんは「システム開発でも同じかもしれない」と答えた。単純な話、進捗を守ると余裕期

EnterpriseZine（エンタープライズジン）編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

「これまでのシステム開発経験の中で一度も不具合を出したことがない」と言い切れる人は、まずいないでしょう。かくいうわたしも、大小さまざまな不具合を出した経験があります。今回は「システム開発における不具合とテストの重要性」について考えてみたいと思います。 膨れ続けるシステムに立ち向かうために ある程度の規模を持ち、他システムとの連携が必要なシステムでは、その特性に応じて違いはあるものの、その規模に相応する「システムの複雑さ」を有することになります。また「業務システムが新規開発時の状態のままで運用が継続される」ことはあまり考えられません。度重なるシステム拡張や機能追加を繰り返すことで、多くのシステムが複雑化し、肥大化していきます。例えば、長期間稼働し続けている既存システムに対して機能追加や仕様変更を行う場合には「開発当時のメンバーがいない」「仕様書や資料が古すぎる」という問題が起こることもあるで

誰が誰に何のために報告するのか。これを意識することが報告書の内容を考えるうえで重要である。 完了報告書を作成する役割は，プロジェクト・マネージャが担うケースが一般的である。システム開発プロジェクトでは発注側であるユーザー企業と受託側であるベンダーの双方にプロジェクト・マネージャが存在するが，どちらのプロジェクト・マネージャが誰に対して報告するのかによって完了報告書を書く目的は少々異なってくる。その報告者と報告先は下記の三つのパターンに分けることができる（図1）。 A.ユーザー企業のプロジェクト・マネージャが経営者や上長に報告する B.ベンダーのプロジェクト・マネージャがユーザー企業に報告する C.ベンダーのプロジェクト・マネージャが自社の経営者や上長に報告する Aの場合の完了報告書の主な目的は，経営者や上長が決断したシステム投資に対して，担当者として説明責任を果たすということである。システ