2008年4月23日水曜日

[memo]勝てる見積もり

仕事柄、何度となく見積もりを書いていますが、やっぱり仕事とれないとどんなに「美しい」見積もり書いても意味ねーと思うんですよ。
というわけで「勝てる見積もり」についてアイディアをメモ。これからブラッシュアップ。

・組織として一定のフローを持つこと

・モデルシステム
業種ごとにいくつかのモデルシステムを作る(あくまで見積もりとプロジェクト計画の話)
依頼された見積もりはモデルシステムをベースに差分を数えることで規模間を算出する。
これは営業段階でやっていいプロジェクトかどうかを判断できる

・モデルプロジェクト
モデルシステムに対してどこまでが決定事項なのか判断する。

・モデルシステムとモデルプロジェクトのメンテナンス
日常業務と密接に結びついて、常に最新の状態を保つこと。

・お客さまはコストだけを見ているわけではないこと

・品質
広義の意味で。ユーザビリティといった数値化しづらい付加価値についてもしっかりアピールすること

・コスト
安いに超したことはないが、お客さまがシステムに対して求める条件を満たすために必要十分なコストを
請求すること。

・納期
ほとんどの場合、システムは1日も早くビジネスの現場に投入される必要がある。

・スコープ
スコープ網羅率。QCDと関わる要素だが、お客さまの求めるものを作りきること。場合によっては機能スコープに優先度をつけ、お客さまに対し「過剰な機能」であることを伝えること

・マイルストーン
いつの段階でどういったものがだせるか? 見せられるか? エンジニアの都合だけで進めず、プロジェクトの可視化も含めて宣言をすること

2008年4月16日水曜日

[Project]アジャイル(笑)

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

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

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

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

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

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

2008年4月13日日曜日

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

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

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

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

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

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

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歳にもなったので「若さ故の過ちか…」と言えない感じです。

2008年4月10日木曜日

[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でしょう。よくわからんけど。
それだけスゴイぞ、と伝えたかったのです。