ProjectManagementに関するYaSuYuKiのブックマーク (16)
-
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、﹁あるある﹂な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう! スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる﹁スクラム﹂。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
-
﹁カイゼン・ジャーニー たった1人からはじめて、﹁越境﹂するチームをつくるまで﹂の著者、市谷聡啓さんが2019年6月に出版した﹁正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について﹂を拝読しました。 本書をおすすめしたい人 プロダクト開発において、アジャイル開発での進めかたを知りたい人 アジャイル開発チームのプロダクトオーナー(ビジネスサイド、企画者︶ プロダクト開発チームが所属している会社の経営者 アジャイル開発を新たに学びたい人 アジャイル開発をひととおり知っているが、あらためて学びたい人 ﹁正しいものを正しくつくる﹂という中心理念 本書のAmazonレビューを見ていたところ、星1つのレビューを見つけました。 エンジニアの傲慢さが詰まった本 ﹁正しい﹂という言葉を使うエンジニア、同じエンジニアとして非常に恥ずかしい思いです。 ﹁正しいも
-
Backlog開発チームの藤田です。皆さんは子どもの頃、夏休みの宿題にどんなふうに取り組んでいたでしょうか? 夏休みの初めに一気に終わらせてしまう 毎日こつこつ進める 夏休みの終わり近くになって必死でやる 終わらせない などいろんなタイプがありますね。 私は﹁初めに一気に終わらせる﹂タイプでした。毎日こつこつ進めるとかは無理と自分でわかっていたので、先にやってしまって安心したかったのだと思います。﹁終わらせない﹂を選択できるほど肝が据わってもいませんでした。 本記事は、普段私たちが業務で使っているプロジェクト管理の手法を夏休みの宿題に応用したお話です。小学2年生になった娘と一緒に﹁夏休みの宿題完遂﹂を目的に、バーンダウンチャートなどを活用して、プロジェクトをどのように進めたのかお届けします。 夏休みの宿題をマネジメントする事の発端 うちの子にかぎって 私には小学校6年生と2年生の娘がいます
-
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム﹁トーラス﹂開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ︵ロンドン金融街︶全体の投下コストは、総額5億ポンドに上っていた。証券取引所のP・ローリンズ理事長は、責任をとって辞任する。 ﹁トーラス﹂は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト﹁ヴィスタ﹂をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
-
スマホアプリを新規作成したらいくらかかる?モバイル見積もり勉強会 #モバイル見積 http://www.zusaar.com/event/3147004 カレー屋チェーン店﹁ペッパー警部﹂の公式アプリを作ってほしい、という仮想案件に対して見積もりをしてみる勉強会を2014.01.24 19:00-21:30で開催しました。会場は渋谷の21cafeをお借りしましたが、無料で借りていいの?というぐらいにはプロジェクタ・WiFi完備でキレイなとこでした、同業︵?︶の皆様にはオススメしておきます。WordBench神戸勉強会さんの WordPressサイトを構築するといくらかかる? 見積り勉強会で価格を出してみた http://wordbench.org/2014/01/14/wordbench-kobe/ が、面白かったので、そのスマホアプリ版をやってみた、という話です。 モバイル見積もり勉強
-
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、﹁よい製品はよいプロセスから生まれる﹂ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
-
組織パターン (Object Oriented SELECTION) 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂出版社/メーカー: 翔泳社発売日: 2013/08/06メディア: 大型本この商品を含むブログ (15件) を見る 2013-10-30、コプリエンの研修にレポータ枠として参加しました。がんばってレポートします。 本来は組織パターン (Object Oriented SELECTION)を読んだ人、組織パターンやScrumの好きな人、そしてコプリエンファンの人が参加する研修だと思いますが、どれにも該当しないままでの参加となりました。 会場入り 9:45。6Fにつくと喫煙所に角谷さん(id:kakutani)を発見。朝からついてる感じです。会場に入ると裸足のコプリエンと三人の通訳、TAの皆さんが準備し
-
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 --だとすると、日本のSI業界というのは将来性があるのでしょうか? わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 ﹁情
-
政府システム調達における失敗の典型例が、特許庁の基幹系システム刷新プロジェクトだ。5年がかりで臨んだが、結局は55億円を無駄にしただけ。新システムは完成しなかった。失敗の最大の要因は、発注者である特許庁にあった︵図1︶。関係者の証言から、失敗に至る経過を改めてひもとく。 特許庁は2004年、政府が打ち出した﹁業務・システム最適化計画﹂に沿って、特許審査や原本保管といった業務を支援する基幹系システムの全面刷新を計画した。システムアーキテクチャーに詳しい情報システム部門のある職員︵以下A職員︶と、刷新の﹁可能性調査﹂を担ったIBMビジネスコンサルティングサービス︵現・日本IBM︶を中心に、調達仕様書を作成した。 業務プロセスを大幅に見直し、2年かかっていた特許審査を半分の1年で完了することを目指した。度重なる改修によって複雑に入り組んだ記録原本データベース︵DB︶の一元化に加え、検索や格納など
-
巨象も踊る 作者: ルイス・V・ガースナー,山岡洋一,高遠裕子出版社/メーカー: 日本経済新聞社発売日: 2002/12/02メディア: 単行本購入: 22人 クリック: 313回この商品を含むブログ (94件) を見る1.はじめに ITクラスタに多大な衝撃を与えた、IBM対スルガ銀行事件判決。判決直後の﹁4月1日﹂に、その時点で明らかになっていた情報から憶測して、以下のネタ記事を書いたことは記憶に新しい。 判例評釈速報‥IBM/スルガ銀行システム開発事件〜東京地判平成24年3月29日判例集未登載︵控訴︶ - アニメキャラが行列を作る法律相談所withアホヲタ元法学部生の日常 判決直後には、IBM側の申立てにより開示されなかった*1判決本文が、平成24年5月16日、第一法規判例体系に掲載された。同業他社のデータベースを確認したところ、現時点の掲載はないとのことであるので、第一法規の﹁スク
-
■1 ︻急募︼"The Agile Samurai"の翻訳レビュワーを募集します (2011/04/27 18:30追記: 募集は締め切りました。多数の御応募に感謝します。ほんとうにありがとうございました!!! 採用されなくても泣かない!!) いろいろ書かないといけないエントリが少なくとも3つあるんだけど、あとで書きますごめんなさい。 以前に﹁アジャイル開発のディケイドと"The Agile Samurai"﹂というエントリを書いたあとに﹁JFPUGでアジャイルな見積りと計画づくりについて講演しました﹂でカミングアウトして、Agile Japan 2011の北海道サテライトでの講演でも言及した、Jonathan Rasmussonの"The Agile Samurai"をid:nawotoや同僚たちと翻訳してます。 そろそろ訳文のレビューを始めないといけない(のだけれどまだ始めてないという
-
2011/04/14 オープンソースのプログラミング言語﹁Ruby﹂の開発コミュニティで、いま注目されている人がいる。福森匠大︵Shota Fukumori、sora_h︶さん、14歳だ。国籍、性別、年齢などは無関係というオープンソースの世界だが、これほど年若い参加者が﹁コミッタ﹂と呼ばれる開発のコアメンバーに迎え入れられることは珍しい。Ruby開発に加わった時点では中学2年生。﹁最年少記録﹂を塗り替えた。 欧米を中心にビジネスの世界でも迎え入れられつつあり、先日、JIS規格化もされたRuby言語。そのRubyの生みの親で、現在も開発をリードしているまつもとゆきひろさんに島根県から動画チャットで加わってもらい、福森さんに話を聞いた。 無料海外ドメインも使う﹁デジタルネイティブ世代﹂ 記者への挨拶もそこそこに、最新のAndroid端末とMacBook AirをWiFiルータでネットに接続する
-
Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。 デブサミ2011では、[デブサミ]速報‥2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。﹁チケット管理システム大決戦﹂というセッションは、デブサミ史上最大の観客数となったと聞いています。 なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか? 開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、﹁作業を適切なサイズに分割する﹂﹁優先順位をつける﹂﹁人をアサインする﹂という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
-
Debian GNU/LinuxのRuby関連パッケージのメンテナだったフランス人のLucas Nussbaumさんが、Rubyパッケージの作成・管理に関わるのをやめると宣言しました。その理由を、やや感情的にブログに列挙したことをキッカケに、日本語・英語のコミュニケーションギャップの問題、OS︵ディストリビューション︶とRubyなどの言語処理系のパッケージシステムの不調和の問題、コミュニティ運営の成熟度など、さまざまな議論が巻き起こっています。 多くの論点を含みつつ議論が展開 念のために先に指摘しますが、Debian上︵Ubuntuでも同様︶のRubyパッケージの今後については、Lucasさんのほかに、まだ2人、やまだあきらさんと、森脇大悟さんが関わっているので︵リンク︶、今回の騒動によってRubyパッケージがDebian上でメンテナンスされなくなったり、将来が不安だということはないと思い
-
︻ドングリ化について︼ チャンスを逃さないためには、ぼんやりと考えていることを明確化し、まとめておくことが大切だ。5分から10分ぐらいの短い時間で小さなメモに書き出してみる。 これを﹁ドングリ化﹂と呼ぶ︵第1回﹁30秒ごとのチャンス﹂参照︶。 今回は新しいプロジェクトのための要点をつかむドングリ化を実行する。 ︻同じ目標なのにかみ合わない現場︼ ﹁もっとプロジェクト規模を大きくしよう﹂ ﹁いや、そりゃ無理だよ!﹂ と意見が対立している2人の、そのプロジェクト像、同じだろうか。Aさんは、今の構想が70という規模だと考えている。Bさんは100だと考えている。 そこで、Aさんは、せめて100ぐらいの規模はないといけないと思って、大きくしようと提案する。 ところがBさんはすでに100の規模を想定しているので、さらに大きくしようという提案を聞いて、130ぐらいにしようと言われたと感じる。 完成像
-
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、﹁私がどういう考えで仕事を進めていきたいか﹂という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に﹁今までどうやって遠隔地で仕事を進めてきたのか﹂をプレゼンしていました。特に初めて仕事をする場合、﹁今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか﹂を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
-
1