たとえて言うならプロジェクトデザイナー？

プロジェクトをデザインする

この考え方はとても良いと思います。
マネジメント（管理）する前に計画ちゃんとしないとね。

いきあたりばったりなプロジェクトを「マネジメントしてます！」と言われてもそれって本末転倒だよね。

OpenProjとやら

OpenProj：優れたソフトウェアだがドキュメントの欠如が問題

某友人がどうなのよ？ってエントリーをしていたのでためしにインストール。
いちおう、MSPとのファイル互換はできるものの、、、重い！　Undoが1回！？

・取引先が遠慮なくMSPファイルを送りつけてくるが自分はもっていない
・Linux環境

という状況なら使い道ありますな～。

哀・見積

タイトルはどうでもいいんですが。。。

工数(コスト)と価格を何故分離するのか！？

「①お客さまの予算－営業」と「②お客さまのスコープ－開発メンバー」でのやりとりはまったく別物だから。

②はプロジェクト開始前でさんざん変わるけど、微調整レベルまで①に影響を及ぼしていたら仕事なんないし。いちいちやってると遅いし。
②におきた変更を受けて、①も変えるべきかどうかは分離がきちんとできていないとムズイっす。

[Project]もやもや見積もりと命名する！

もやもや～と機能を書き出して、
もやもや～と〆切りに合わせて要員あてこんで
もやもや～とスケジュールをひいて、、、
コストが不明で。。。

誠に勝手ですが「もやもや見積もり」と命名する！

工数(コスト)と価格は分離！　絶対分離！　分離しないと実行予算管理でおかしなことおこるし。
あと見積もった人じゃないとプロジェクト管理できないとかね。

「なんかタスク増えたけど、、、ま、いっか。利益がちょっと減るだけだし」

あああーーーーー！！！！！！
すげーもやもや！！！
なにそれ！？　気持ち悪いわっ！

[Project]アジャイル(笑)

アジャイル型の開発プロセスを採用すれば全てが解決、さよならデスマーチ、こんにちは働きやすい環境とすばらしい品質のソフトウエア…、そんなわけないですよね。
アジャイル型の開発プロセスにも「作法」のようなものがあるし、それらがプラクティスと呼ばれたりしていて、先人の知恵を上手く取り入れないといけないわけです。

前述のような幻想は誤った認識で広まった非可逆のウォータフォール型の開発プロセスのせいかと思います。多くの人にとって〆切りに追われるのは気持ちが良いものではないですし。

アジャイル型も非可逆のウォーターフォールもそれぞれに長所はあるわけです。

結局、短期の計画、中期の計画、長期の計画をつくり、その計画をメンテナンスしながらプロジェクトを進めることが大事なわけで、無計画にやればいいってもんじゃないはず。

出たとこ勝負、行き当たりばったり　＝　アジャイル(笑)

ちょっと人伝で聞いた話でちょっと「むむむ？」思ったので書きました。

[Project][memo]受託開発の極意

「受託開発の極意(岡島幸男[著]　技術評論社)」を読みました。

思ったことをメモ。
でもメモ意味ないかも。
手元に置いてふとしたときに手にとって読む。
自分やチームの仕事の仕方を振り返ってみる。
自分と役割が近い人、仕事で関わることが多い人と読み合わせて語り合ってみる。
それぐらいしたい本でした。
ここであえてふれていないColumnも役立つ情報多かったし！
なので
「購　読　す　る　こ　と　を　オ　ス　ス　メ　し　ま　す」

0章　受託開発を楽しむには
0.2　
「顧客満足の公式」
顧客満足はQCDからなる成果物に対する「結果」と、仕事を進めていく過程にたいする「感情」の両面からなるということ。
私も恩師から「お客さんは感動に対してお金を払う」といわれたことがあるので、この説明はとても納得。
(こまかく話すとちょっと違うんだけどね)

第1部　受託開発の手ほどき
第1章　お客様に関心をもつ
1.1
「7段階にもネストしたif文や～」
ごめん。それオレ(笑)。
正確に言うとExcelの関数でIF文の限界にチャレンジしてた。無知って恐ろしい。
1.2
「要はお客さまと接する機会が少ないため関心が持てないのです。会ってもいない人に関心を持つことはできません」
激しく同意！　ちなみに私はお客さまとお会いしないと仕事できないタイプ。
たまにお客さまの顔見ないで仕事する必要が発生しますが、なんかあってもちゃんと判断できないですよ。
情報が一方的に的になっちゃうから。
1.6
「お客さまの立場でプロジェクトを眺める」
仕事してるとついついこっち都合を優先しちゃったりするのですが、、、いかんですよね。
猛省です。

第2章
「サービスは見積りから始まっている」
スティーブ・マコネルの『ソフトウェア見積り』が引き合いに出されています。
タケも読みました！
マコネル最高ｗ　この本に書かれている見積もりに関する話は非常に奥が深い！

2.2
「お客さまは金額だけで発注先を決めるのではありません。見積もり期間におけるサービスの質も重視しましょう。」
うっすらわかっているようでいてちゃんとわかっていなかったこと。
言い換えると安易な価格勝負すんな！　と。
もし価格勝負をするために意図的にテスト期間を短くして品質を下げるようなことがあるなら、いかんですよね。
システムに関わるもののモラルの問題も含めて、見積もりはしっかりやらないと。
また「プラスα」はいままでまったくできてなかった。スキル不足と時間不足のせいにして。これもなんとかしたいなぁ。
2.4
「見積もり手法を身につける」
「オブジェクト倶楽部」のワークシートが紹介されていました(http://www.objectclub.jp/download/)。
今度、試してみよう♪
タケはそんなに見積もり手法を勉強した訳じゃないですけど、いろいろな手法を知ったり勉強したりすると見積もりに対する考え方に厚みがでる気がします。
日々勉強ですな。

第3章
3.1
「実質、要件は変わったのではなく、間違って定義されてしまっていることが多いのです。」
そうっすよね！
あとプロジェクトがキックオフするときに営業から開発へ情報伝達が上手く言ってない場合！
これもある意味、間違った要件定義。
話変わりますけど、RIA開発に関わっていると「デザイナとデベロッパの協業」についてよく議題にあがりますが、それ以上に営業と技術者の協業の方が問題な気がします。
炎上する原因てだいたいそれだよね。
3.2
手段ばかりに着目するのではなく何を何故作るのか！?　を考えなさいと。なんかもう御礼言いたいです。
3.4
「表3-1　システム要件で定義する内容」
これもきっちり認識する必要あり。
3.7
「丸投げドキュメントの読み方」
これは丸投げドキュメントに限らない気がするのですが、それってタケがいつも丸投げされている証拠？

第4章　保守性にこだわった設計・実装・テスト
4.4
単体テストが重要だというのは重々承知していたつもりですが、サンプルとして数値でだされるとその重要さをより認識することができます。
4.5
テスト計画の重要性、各フェーズで何を気をつけるべきかが書いてあります。品質をどこまで保証する、つまりどれくらいテストをしっかりやるか、どういった分担で行うのか、どういったアプローチをとるのかはプロジェクトを始める前にしっかり決めておかないといけないはずです。
またテストは私の知る限りでは必ずと言っていいほどクリティカルパスになります。
テストちょー重要！

第5章　運用が最上流
5.2
「お客さまとの信頼関係も保守する」
なんて良いことを言うんだろう。。。
5.3
「テスト資産を活かす」
なんだかんだ言って、同じテストを何度も何度もやることになることがあります。
そう考えたらテスト計画やテスト仕様書、結果はしっかり書かなきゃいけないし、ツールを使って自動化できるんだったらやっておいた方がいいかもしれません。

第6章　計画とスケジュールの管理
「計画がないプロジェクトはありえませんし、計画が頻繁に変わるからといって、まったく無秩序ではいけません。計画は管理・メンテナンスするものです。」
私の作るMSPがプロジェクト開始2週間でぐっちゃぐちゃになるのはMSPがダメなツールだからではなくて、プロジェクトの計画と実行と管理というのはそんなもんだからです。全然変わらない場合は「わーい♪」と喜んでないで潜在リスクがないか考えないと。
6.1
「3つのスケジュールを使い分ける」
これは目から鱗。。。
プロジェクトを進めていく内にだんだんブレイクダウンしていくことはありますが、明確に3つに分ける(違うものだと認識する)のは考えてなかった。。。
きっと当たり前なんだろうな。自分の無知がおそろすぃ。
6.3
「見積もりが外れる原因と対策」
私は個人的には下記のように考えています。ちなみにKKD法(笑)ね。
・経験
　→タスク洗い出し、アプリーチやプロセスの選択、プロジェクト基盤作成に必要なことや技術知識などなど。
・勘
　→潜在するリスクをあげること。ここは○○日じゃないだろう…とか、ここで詰まるだろう…とか。
・度胸
　→工数を「削る」のは度胸！　ここは○○日もいらないだろう…とか。超安全見積もりで仕事がとれるほど世の中そんなに甘くない！
　6.5
「プレッシャーを感じたままスケジュールや計画を立てると、手段の目的化が起きます。」
私はプロジェクトの計画を立てるのと見積もりを書くのは限りなく近い作業であると認識しているので、それを前提に話すと、見積もりを書くときに入ってくる情報が「参考値」なのか「制約条件」なのかはちゃんと切り分ける必要があります。
特に予算はね。書こうと思えば書けるんですよ。予算内で。やべーな、と思ってても。。。
ましてや見積もりを書く人間より、その情報をもってくる人が年長者だったり経験が豊富だったり組織内で権力もってたりすると、余計にやっかいです。そういうもんだって思っちゃうからね。

第7章　チームで成功を目指す
7.3
「表7-1　リーダーのカラー別の特徴」
これわ。。。「ボケボケ」型ってないんですか？　タケはボケボケ型だと思います。
7.4
「お客さまに対する陰口を止めてみる」
コラッ！
7.5
「交渉力」
勝ち過ぎない、っていうのはわりと意識してやってますね。
でもそれでつけ込まれて不利になることが多い気もします。。。さじ加減が難しい。

第2部　人と組織を変えること
8.5
「問題なのは相対評価を気にするあまり自信をなくし、自分が何を目指したいのかわからなくなってしまうことです。」
うーむ。確かにわからなくなっている気がしますなー
Column
「アムロとブライトさんのセリフ」
岡島さんとは美味い酒がのめそう(笑)。
タケはもう子供がいて30歳にもなったので「若さ故の過ちか…」と言えない感じです。

[Project]PMOってなーに？

社内のメンバーに私なりのPMOが何かを伝えたくて書きました。
以下、本文。


はじめに

PMBOKのPMOの定義を確認

******PMBOK3版より******
1.6.4　プロジェクトマネジメント・オフィス

プロジェクトマネジメント・オフィス(PMO)は、その管轄下にある複数のプロジェクトのマネジメントを一元化し、調整を行う組織の一部門である。PMOは、「プロジェクトマネジメント・オフィス」、「プロジェクト・オフィス」、または「プログラム・オフィス」と呼ばれることもある。PMOは、プロジェクト、プログラム、またはその両方を監視する。PMOによって支援または管理されるプロジェクト群は、一緒にマネジメントされるということ意外に相互の関係はない場合もある。もちろん、関係のある複数のプロジェクトの調整およびマネジメントをPMOが行う場合もある。多くの組織において、PMOがプロジェクトを調整し、マネジメントする方法に従って、複数のプロジェクトは実際にグループ化されるか、または、関係付けられる。PMOの主たる関心事は、親組織またはクライアントの全体的なビジネス目標に関連するプロジェクトおよびサブプロジェクトに対する計画調整、優先順位設定、および実行ということである。

PMOは、トレーニング、ソフトウェア、標準化された方針および手続きという形態でのプロジェクトマネジメント支援機能の提供を始めとし、実際の直接マネジメントやプロジェクト目標の達成責任に至るまでの連続的な範囲全体の中で、種々の機能を果たすことができる。ある種のPMOは、権限の委譲を受けて、中心的なステークホルダーとして行動し、また、各プロジェクトの初期段階時の重要な意志決定を行うことがある。このPMOは、提案の権限を持ち、ビジネス目標の一貫性を保つためにプロジェクトを中止することもできる。さらに、このPMOは、必要に応じて、複数プロジェクトを兼任する要員や、プロジェクト専従要員(可能な場合)の選択、マネジメント、再配置に関与することができる。

******ここまで******

分解

■前半部分
読む人によって解釈が大きく異なることはないと思うので放置

■後半部分
ここからが濃い

> PMOは、トレーニング、ソフトウェア、標準化された方針およ
> び手続きという形態でのプロジェクトマネジメント支援機能の
> 提供を始めとし、実際の直接マネジメントやプロジェクト目標
> の達成責任に至るまでの連続的な範囲全体の中で、種々の機能
> を果たすことができる。

これはPMO管轄下ある全てのプロジェクトの成功に対して責任をもち、あらゆる手段で実施や支援をしろ、ということです。
「連続的な範囲全体の中」という表現がミソ。プロジェクトは様々な要因が集合しているので、何か一つの課題を解決したら即、プロジェクト成功というのは難しい。
「制約条件の理論(ボトルネックがなんちゃらいうやつ)」を参考にすると、一つのボトルネックを解決すると別の場所がボトルネックになると説明しています。言い換えれば改善活動に終わりはない、ということです。極端な話、短所と思われる箇所を全て改善したら、いままで長所と思っていた箇所が短所に変わることもありえます。

> ある種の
> PMOは、権限の委譲を受けて、中心的なステークホルダーとし
> て行動し、また、各プロジェクトの初期段階時の重要な意志
> 決定を行うことがある。このPMOは、提案の権限を持ち、ビジネ
> ス目標の一貫性を保つためにプロジェクトを中止することもで
> きる。さらに、このPMOは、必要に応じて、複数プロジェクト
> を兼任する要員や、プロジェクト専従要員(可能な場合)の選択、
> マネジメント、再配置に関与することができる。

私の個人的な解釈は「組織とそれに関わる全ての人を守れ」という意味合いととらえています。
だいぶ端折った見方ですが、こう言うと重いですよね。。。
これを行うには、IT業界においてはテクニカルスキルも重要ですし、プロジェクトをまとめるマネジメントスキルも必要です。また正しいものがいつでも成功するとは限りません。
一方的な見解による無理難題は政治的なスキルで解決することも必要です。

ここで「タケの働く会社」のこれまでを振り返ってみます。

先月PMOの活動が止まった理由は何だったでしょうか？
みんなで時間をつくって集まった課外活動が半ば空中分解し、参加メンバーにそのアウトプットを提示できなかったのは何ででしょう？
かつては行われていたという月1飲み会をやっていないのは？
勉強会は業務という形で○○さんが実施するようになりましたが、かつてのように有志が講師の役をかって行うことは減りました。

極論、みんな目の前の仕事が忙しくて時間がとれないせいです。
(メンバーが増えたこともそうですが、あえて置いておく)

新しい取り組み、新しい技術の習得、それらに対するメンテナンス活動、何をやるにしても時間が必要です。モチベーションを上げるための施策、コミュニケーションを深めるための行事だって時間が必要です。

当たり前だけど、これらの時間をとるための試みが二の次になっていました。
だいたいが厳しいプロジェクトをやっていたがために、そういった状態になっていたのだと思います。

じゃ厳しいプロジェクトって何であるの？　と。

これは内的要因、外的要因が複雑に絡むので答えを単純に言うことは無理です。
とは言うものの、私、個人的な意見としてクラスメソッドの場合は無計画なプロジェクトのキックオフが原因のほとんどであると思います。
また営業サイド、情シスサイドの連携ミスや齟齬もあるでしょう。

よく言うように炎上する案件は炎上するべくして炎上する。
デスマーチプロジェクトはプロジェクト始まる前から決まっているんです。

難しい課題ですが情シスメンバーの稼働率を下げ、新しい施策のための時間を作り出し、効果的な取り組みを行って、会社とそれに関わる人達の成長と幸せを促す。
それを目指すのがPMOの存在意義だと思っています。

でも難しい。
ちょー難しい。
解決する課題は一つじゃありません。前述したように「連続的な
範囲全体」なのでやることいっぱいあります。
営業と上手く連携することも必要です。
メンバーのスキルをどういった方向にのばしていくのか、これはテクニカルな課題もありつつマーケティング的な分野にも関わってきます。
「タケの働く会社」の生産性を考慮して他社に勝てる見積もりをだして、その上でみんなまともな時間で帰ってもプロジェクト成功、というのは本当にいろんなことを改善しないとたどり着けないと思います。
まじでマーケティングも必要ですね。
PMOじゃなくてPMMOにしたいくらい。

とは言うものの「タケの働く会社」にとってPMOは心臓であり脳でもあると思います。
JavaにたとえたらきっとJVMでしょう。よくわからんけど。
それだけスゴイぞ、と伝えたかったのです。

[Project]見積もりのときのインプット

「予算は○○円らしい。」

それ参考値？　制約条件？
それによって全然違いますよね。

インプットは重要です。その情報の重みは？　精度は？　誰の発言？

怖いのはいい加減なインプット情報で、コストが独り歩きしてしまうことです。

[Project]計画通りに進まなくて当然

タイトルが秀逸

「プロジェクトは、計画通りに進まなくて当然」
http://www.atmarkit.co.jp/im/cpm/serial/9target/03/01.html

契約形態に関しても言及されていますね。
準委任契約と請負契約はその状況によって発注者、受注者双方に不利益を生じないように締結されるべきです。
文中で書かれているように要件定義フェーズなどでは準委任契約が望ましいですし、製造工程に入っているのなら社内での作業割り振りが自由な請負契約の方が動きやすくなります。
また契約形態を含めて仕事の定義はシンプルな方が良いです。
下手な考えで一方的にリスクをヘッジしようとするとかえってリスクまみれの契約になることもありえます。
例）準委任なのに成果物しばり、期日縛り

さてこの参照した記事のタイトルですが、私が尊敬している他社のPMの方にまんま同じことを言われました(笑)。スケジュール表がぐっちゃぐちゃになることを相談した時のことです。
記事にも書いてありますがプロジェクト管理は非常にシンプルな作業ですが、手間暇は結構かかります。社内外でこの苦労を認めてもらうことが最も難しい気もします。

[Project]見積もりは誰のもの？

・見積ってなによ？
まず見積もりって人や役割によって意味が違います。
私は営業みたいな役割になることが多いから見積もりの「コスト」についてフォーカスするし、エンジニアだったら実現手段やかかる工数、プロジェクトマネジャーとかならスケジュールにフォーカスすると思います。
なので「見積もり」じゃなくて「プロジェクト計画」ですね。コスト、スケジュール、リソース、品質、などなどを統合して計画になるはずです。まずこれ前置き。

・プロジェクトに計画が必要なわけ
PMBOKにはプロジェクトの特性として下記の三つが記述されています。
１．有期性
２．独自性
３．段階的詳細化
大ナタ振って言い換えると「二つとして同じものはない」です。定常業務じゃありません。
定常業務でない以上、プロジェクトをどのように始めて、どのように進めて、何をもって終了とするのか？　期間はいつか？　実現手段はどうするか？　などなどをステークホルダーで合意をとる必要があります。とれなくても宣言くらいする必要があります。
にも関わらず予算だけ決めて「あとよろしく」は愚の骨頂です。
人月見積もりについて話題になることがありますが、人月のコスト見積もりが間違っているんじゃなくて計画性のなさが問題なはずです。
補足しますが計画が全てといっているわけではありません。計画は思った以上に簡単に壊れます。しかしそれをメンテナンスしながら、調整しながらプロジェクト完遂に向けてやりくりしていくことが大事なはずです。

・見積もりって…
何気なやりとりをしてる見積もりですが、ソフトウェア開発会社にとって開発プロジェクトは主業務であることはもちろんですし、その企業のありとあらゆる能力が如実に表現されます。それはプロジェクトの計画をしっかり作成した上で出てくるものであるべきだし、その重要性を認識するべきです。
「とりあえず見積もり書いて」とか
「すぐに見積もり書いてもってきます」とかは責任感が希薄だと思います。そんなノリだから人月ベースのいい加減な見積もりが横行するのではないでしょうか。

・見積もりは誰のもの？
開発会社として、そのプロジェクトをどのような計画をもって進めていくのか、という問題は営業担当者が決められるものではありませんし、エンジニアが一人で決めていいものではありません。会社のナレッジから得られるものは重要ですし、利益率をおろそかにしてはそもそも会社の経営自体が危うくなります。これは組織内に技術、経営、マーケティングを把握し、これまでのプロジェクト計画と実績をしっかり管理している担当部署を作る必要があるということではないでしょうか。
一般的にはPMOといった担当部署を設けてプロジェクト計画の統合を行うことになるはずです。

見積もりはとても重要なものですし、各担当者が個人でどうにかして良いものではありません。
だからといって、各担当者がまったくかかわらなくていいものではなく、むしろ積極的にかかわっていくべきだと思いますし、集合知のようなものがプロジェクトの計画の妥当性と見積もりの正しさを向上させていくのかと思います。