PJの基本動作を押さえる～課題リストのお作法～：榊巻亮の『ブレイクスルー備忘録』：オルタナティブ・ブログ
変革プロジェクトに携わるなら、「課題リスト」は必ず必要になると思う。 プロジェクトを始める前に、広く現場から課題を集めることもあるだろう。 プロジェクトが始まってから解決しないといけない問題を課題としてトラックしておくこともある。 ところがその書き方、お作法はあまり共有化されていない。各自が思い思いの書きっぷりで書くのが常だ。 お茶や武道の世界にお作法があるように、プロジェクトの世界にも一定のお作法がある。慣れてくれば型を破っても構わないが、基本のお作法は知っておかなければならない。 お作法を無視した課題リスト 例えば、 「現在のシステムの問題・改善点を挙げて下さい。情報システム部で課題リストとして取りまとめます」という話はしょっちゅうある。 僕らがプロジェクトを手伝い始める前に、社内でこうした意見収集をしてることもよくある。 ところが、お作法を意識せずにやると、集まるのはこんな内容のもの
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック (1/3)：プロジェクト成功確率向上の近道とは？（2） - ＠IT
サンプル例に見る機能仕様書の基本的な書き方＆読みやすくする7つのテクニック：プロジェクト成功確率向上の近道とは？（2）（1/3 ページ） ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日本人向けにカスタマイズされたものを例に、機能仕様書の基本的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説
データサイエンスを加速させる「TDSP」とは何か？
マイクロソフトが、データサイエンスの方法論などをまとめた「Team Data Science Process（TDSP）」を発表。データサイエンスのためのガイドラインやツールをGitHubで公開した。 米マイクロソフトは2016年10月11日（米国時間）、データサイエンスにチームで協力して取り組むための方法論／事例集「Team Data Science Process（TDSP）」を発表。TDSPのガイドライン、プロジェクト構造、ツールをGitHubで公開した。 TDSPは、データサイエンスにおけるコラボレーションやチーム学習を改善する「アジャイルで反復的な方法論」。以下の要素で構成される。 データサイエンスライフサイクルの定義 標準プロジェクト構造 分散共有型の分析インフラ データサイエンティスト用のツール／ユーティリティー データサイエンスライフサイクル データサイエンスライフサイクル
進捗管理は下っ端がやる仕事、あるいはファシリテーターとしてのPMO：プロジェクトマジック：オルタナティブ・ブログ
プロジェクト内に「PMO」という部署を設けるケースがある。 大規模プロジェクトではPM（プロジェクトマネージャー）のタスクがあまりにたくさんあり、とうてい1人PMではやりきれない。だから何人かで分業するためのチームを作る。それをPMO（プロジェクトマネジメントオフィス）と呼ぶ。 で、もちろんプロジェクトの成功にとって大事なのは、PMOを作ることではなく、PMOが何をやるかだ。 他社の人とこの話をしていて、全然咬み合わないことが多い。僕らの考えるPMOの仕事よりも、彼らの考えるPMOタスクはかなり狭いのだ。 もっとはっきり言うと、普通の人が考えるPMOのタスクって、僕らが考えるPMOタスクのうち、一番簡単で、普通は下っ端（PMOチーム内で一番経験が浅い人）にやってもらう仕事だけのことが多い。 「いや、違うんです。プロジェクトの成否を分けるのは、その先なんです」と言いたくなる。 僕らは、この狭
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
