進捗管理は下っ端がやる仕事、あるいはファシリテーターとしてのPMO：プロジェクトマジック：オルタナティブ・ブログ
プロジェクト内に「PMO」という部署を設けるケースがある。 大規模プロジェクトではPM（プロジェクトマネージャー）のタスクがあまりにたくさんあり、とうてい1人PMではやりきれない。だから何人かで分業するためのチームを作る。それをPMO（プロジェクトマネジメントオフィス）と呼ぶ。 で、もちろんプロジェクトの成功にとって大事なのは、PMOを作ることではなく、PMOが何をやるかだ。 他社の人とこの話をしていて、全然咬み合わないことが多い。僕らの考えるPMOの仕事よりも、彼らの考えるPMOタスクはかなり狭いのだ。 もっとはっきり言うと、普通の人が考えるPMOのタスクって、僕らが考えるPMOタスクのうち、一番簡単で、普通は下っ端（PMOチーム内で一番経験が浅い人）にやってもらう仕事だけのことが多い。 「いや、違うんです。プロジェクトの成否を分けるのは、その先なんです」と言いたくなる。 僕らは、この狭
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
「素人まがいのシステム開発」を見分ける方法
自分のプロダクトだっていう意識が皆無なのかテストしないやつ多いよね 最近転職したんだけど、テストしてもリリース後にバグが見つかるからテストは意味がないとかぬかすし 新卒から数年のクソガキが、なぜかプログラマを単純作業労働者かと何か勘違いして下に見ているし テストをしないプランナーとかディレクター プログラマーが単純労働者だったとしてもテストは必要。 単純労働ってことは、工業製品なんですよ。で、工業製品はテストと称する品質チェックをしてますけどね。 素人まがいなところで、単純労働者扱いされて働くのは、正直メンタル的にかなりつらいと思う。マトモなプログラマーほどそう。 給料がそこそこあっても、そういうところで働くは、ストレスがたまると思う。 一度もプロ的な仕事をしたことがない人たちは、そういうのは全然気にならないから、平気。 ということで、素人まがいの人たちが、量産されていく。 素人まがいな開
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） - やまもといちろうBLOG（ブログ）
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論
Photo from Kıvanç Niş ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。 1. ネーミングの重要性 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソー
スクラムがうまくいっている兆候
みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開発チームが必要なときにはいつでもプロダクトオーナーにコンタクトできるプロダクトオーナーが開発チームのそばにいるプロダクトオーナーと開発チームが敵対関係でなく会話しているプロダクト
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance
403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした＆ありがとうございましたー！ SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Private Site
Efficient data transfer through zero copy