2008年3月27日木曜日

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

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

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

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

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

2008年3月26日水曜日

[memo]アーキテクチャ

スターロジックのはぶさん(面識はありませんが)のブログより

「アーキテクチャ」
http://d.hatena.ne.jp/habuakihiro/20080317#1205758083

同意。激しく同意。

最近はプロジェクトの計画や契約書にだってあるんではないかと思っています。
プロジェクトの計画も、たとえば作業内容がシンプルになっている方が作業効率は良いと思います。あれもこれも同時に、、、は危険。意外とパフォーマンス悪くなるし。
複雑怪奇でどう解釈していいのか分からない契約書より、記述がシンプルで数値も具体的なものの方がわかりやすいですよね。いやなのはわかるんですが、ステークホルダーで認識を一致するのであればシンプルなものの方がリスクは少ないよなー、と思います。

2008年3月25日火曜日

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

タイトルが秀逸

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

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

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

2008年3月24日月曜日

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

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

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

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

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

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

2008年3月21日金曜日

[Microsoft Office Project]マクロのUndo

MSPですごい簡単なマクロを作って気づいたこと。
MSP→Undoできる
Excle→Undoできない。2008でも。



でっ? て聞こえそうですね。

[memo]納期優先の無理なプロジェクトが失敗を招く

納期優先の無理なプロジェクトが失敗を招く
http://jibun.atmarkit.co.jp/lskill01/rensai/pwhyf05/pwhyf01.html

案件を取ってくる段階でしっかりハンドリングしましょう、
というメッセージかと思います。
過去記事のタイトルとかみると耳が痛いですね。。。

[memo]Webディレクターだけど何か質問ありますか?

「Webディレクターだけど何か質問ありますか? 」
http://wsoku.blog44.fc2.com/blog-entry-299.html

良いこというなー、と思ったのでメモ。

2008年3月19日水曜日

[プロジェクト管理]管理工数をどう見積もるか

小~中規模のシステム開発の場合、管理工数をどのように算出し、合意を得るのかがヒジョーに難しかったりします。

お客さん:人数少ないとプロマネなんていらないよね。
社内のメンバー:実作業とマネジメントなんて同時にできるわけないだろ、常識的に考えて。

両者の見解は異なります。
私自身は実作業と管理は分ける方が望ましいと考えます。

しかし望ましいといっても、その工数ってどのくらいみとけばいいの? となるわけです。
そこで「ソフトウェア見積り 人月の暗黙知を解き明かす」のコミュニケーションパスを参考に仮説をたてました。
以下、1年前に書いた文書。

プロジェクトは同時稼動人数が多ければ多いほど、コミュニケーションパスが

増えその分、管理コストがかさみます。

50人月の仕事を10ヶ月で行うのと、5ヶ月で行うのでは全体コストに変化が

生じます。

※ コミュニケーションパスの数を算出する式

  n×(n-1)÷2 = パスの数

パスの数

3

3

4

6

5

10

6

15

7

21

8

28

9

36

10

45

  3名以下、管理者は兼務で対応可能

  4名、管理者は0.5人月相当の作業量が発生する。

  5~8名、管理者は1人月相当の作業が発生する。実作業はほとんど行えない。

  9名以上、管理者にサポートが必要

  ※ 1日あたり32のパスを処理できると仮定する。

基本的にはこれらの組み合わせ(ピラミッドを積み上げれば)で管理費を計上できる。


意外と妥当そうな数字が出てきたような……。
この時の仮説ではパス1本あたり15分の工数としました。
これはプロジェクトのフェーズや、システムの重要度によっても変化すると思います。
あと顧客内のステークホルダーの数も重要です。仕様の決裁者が複数いて、顧客内の合意に時間かかるとかはざらですよね。
それとメンバー間でどれくらいコミュニケーションがとれているのか、とか。

どこかで聞いた受け売りですが、ビルは高くなればなるほど、エレベーターの占める面積が増えて、フロアあたりの有効な面積が減るそうです。
組織やプロジェクトチームも同様で、人が増えれば管理したりコミュニケーションとったりする工数が増えます。
この仮説で一番伝えたいポイントはそこです。人が増えると大変だぁぁぁぁ、と。

しかしこの仮説の正当性についてはまったく自信がございません。
ご意見いただけると幸いです。

2008年3月6日木曜日

[RIA]RIAについて考えてみた

営業時に技術の話を一切しないでRIAとは何かを説明しようと思ってとりあえず書き出してみた。

推敲はこれから。
「どっかで聞いたような話。。。」もあるので、そこも自分の言葉におきかえる。
でも暇があったらの話。


「RIAの利用について」

1. 導入

1.1 RIAのイメージは?
RIAのイメージについてどのようなイメージをお持ちでしょうか?
Flash等の要素技術を思い出す方、見た目のカッコ良さを想像される方、操作性の優位性を考える方、ユーザビリティやユーザーエクスペリエンスといった言葉を思い出す方もいらっしゃるでしょう。それらは間違いではありません。いずれの言葉もRIAをあらわす特徴の一つと言えます。
そこでRIAは何をしてくれるものなかのか? 従来のWebアプリケーションとはいったい何が違うのか? この記事ではそれらを技術的な単語をなるべく使わずに解説したいと思います。

1.2 「おもてなし」について
私が妄想する高級レストランでは、訪れたお客さんは下記のようなサービスを受けられることと思います。

・身なりがきちんとした「ギャルソン」と呼ばれるスタッフがあなたを席まで案内するでしょう。
・もちろんさわやかな笑顔つきです。
・あなたがメニューの中からどういった料理を選ぶのか助けてくれるでしょう。
・その際、あなたがフランス語が読めなかったり発音ができなかったりしても小馬鹿にした態度はとりません。
・(フランス語を読めない)あなたがメニュー選びに迷っているようなら、シェフのおすすめなどを提案して、あなたのメニュー選びを助けてくれるはずです。
・場合によっては嫌いなものや、アレルギー反応を起こしてしまう食材を避けるようアドバイスしてくれるかもしれません。
・その際、発生する気難しい職人肌のシェフとの面倒くさい交渉も引き受けてくれるはずです。
・メニューを注文し終えるとギャルソンとは別に「ソムリエ」と呼ばれるスタッフがあなたにワインや飲み物を進めてくれるはずです。
・もちろんソムリエはあなたが主要なワイン銘柄をちっともしらなくても、あなたの懐具合を察してその場に適当と思われるワインを提供してくれます。
・そしてより食事を美味しく、楽しくするためにメニューにまつわるトリビアも教えてくれます。

これら高級レストランのイメージを記述しました。さて、ここでWebアプリを思い出してください。あなたが良く使うもので構いません。まず見た目。あなたが目的を達するためのメニューはわかりやすく表示・配置されているでしょうか? 作業の順序。使い方を悩んだりしていませんか? 慣れてしまっているかもしれませんが、よく見ると押したことのない謎のボタンも並んでいませんか? たまにキーを間違えて意図しない動作をしたりしませんか?
これは極端な話、あなたの使っているアプリはあなたを「おもてなし」していないかもしれません。食事で例えると、ただ積まれただけのおにぎりなのかも…?(決しておにぎりを馬鹿にしているわけではありません)

1.3 インタラクションの効用
ユーザーが目的を達するためにただしく導くことを「インタラクション」と言います。こう書いちゃうと簡単そうですね。ところがこれが、そうは簡単に片付かないのです。たとえば仕事場において春先によく見かける光景です。業務システムの使い方について会話をしています。

新人さん「○○さん。これ、この先、どう進めていいのかわかりません?」
○○さん「これはメニューからこれを選んで」
新人さん「…」
○○さん「ここでこれとこれを選んで画面を切り替えて」
新人さん「…」
○○さん「切り替えた先のサブシステムのメニューを選んで、さっき何が表示されていたのかを忘れないでね」
新人さん「…」
○○さん「ここでショートカットでCtrl+*で、、、」
新人さん「…」
○○さん「それでデスクトップ上に保管してあるExcelファイルの中身をコピペすれば完成。わかった?」
新人さん「もういっかい、最初からお願いします」

※ 業務においてExcelの使用率は限りなく100%に近いだろう。だけど忘れてはいけないことがある。私たちはこの自由度がべらぼうに高いOfficeソフトを自分たちの業務に合わせるためにとてつもないカスタマイズを施すこともあり、さらにファイル管理も煩雑になりがちで、必要な業務を行う前の準備の時間に費やしている。

仕方ないとは言えますが時間の無駄ですね。時間=コストです。こんなやりとりが新人さんが来たとき、新しいアプリが導入されたとき、機能に修正が加わったときに行われているのならうんざりです。


2. 考えて、実行して、確認すること

2.1 多くの事で共通する行動
さて話はまた脱線します。が、ちょっと原則的な話です。
モノゴトを行うときの共通点は

1.考える
2.実行する
3.確認する

です。
いろんなことをこれであてはめて考えることが可能です。多くの場合、このプロセスを経ているはずです。たとえ無意識であっても。例えばゴルフ。(どこに打つのか)考えて、(ショットを)実行し、(ボールの行方を)確認します。お仕事でもそうです。計画して、実行して、成果を確認します。この3つからなるプロセスは目的を「正しく」果たすための最短パスです。どれかが欠けると問題がおこります。

1、行き当たりばったり
2、口ばっかり
3、やりっぱなし

いずれかです。
ではアプリの場合。それもダメなアプリの場合はどうなるでしょうか?

1.考える
2.使い方に悩む
3.実行する
4.不安になったので
5.確認をする

目的を達成することに意識が欠けてしまうかもしれません。人間の集中力は有限です。使い方で悩んで仕事の本質から外れてしまうのはもったいないですよね。より効果的に、効率よく目的を達成するために集中力は使われるべきです。確認の作業も仕事の成果を確認し、次につなげることに使うべきです。操作が正しいか正しくないかに多くの集中力を割かれるのはもったいない。

2.2 おもてなし
「おもてなし」にもどります。
高級レストランではあなたが食事を楽しむための手助けをしてくれます。
高級なホテルではあなたが心地よく滞在できるよう手助けをしてくれます。
この手助け=おもてなしがアプリケーションに必要なのです。
RIAとはまさにそれを実現するための技術なのです。
もしあなたが「そんなことは使って慣れればどうということはない」と思うかもしれません。しかしそれは、はっきりと「間違い」であるといえます。
自動車のパワーウィンドウを思い出してください。今ではほとんどの車に搭載されています。高級車であろうとリーズナブルな軽自動車であろうとです。私たちはパワーウィンドウを当たり前のものとして認識しています。慣れてしまっています。もし昔懐かしいハンドル型の窓を使ったら、若かったころの自分を思い出して気分が良くなるのは最初の1回か2回だけで、あとは多少のストレスか違和感を感じるはずです。昔当たり前でも今では当たり前ではないからです。
RIAも当たり前になりつつあります。ユーザーはいたるところでその恩恵を享受しているでしょう。自宅のPCで、店舗の端末で、会社で、もしかしたらケータイで。
あなたの会社のアプリだけ古く、ユーザーの慣れを強いるようなものならどうでしょうか? ユーザーは何らかの違和感をもつでしょう。それは仕事の品質に影響するはずです。そして本来やるべきことに集中できなくなるはずです。
その違和感の対象はアプリだけにとどまらないかもしれません。経営にかかわる大事なデータを紙か静的なHTMLで分析していませんか? もしくはお使いのPCのローカルフォルダにxlsデータを大量に保管していませんか? それは情報の共有と管理ができていない状態です。
想像をしてください。様々なデータを1つの画面でチャートを用いて視覚的に分析する業務を。そして他所でおきた変化をリアルタイムで受け取ることができる画面を。あなたはアプリやデータの取り扱いに煩わされることなく、お仕事で必要な決断をタイミングよく行えるようになるのです。
あなたがユーザとして自宅のPCから「何か」を買うとしたら? それが安い買い物でないとしたら? 家族と一緒に画面を見て商品の色や細かい仕様を変更できたら? もしくは遠距離恋愛中の恋人と同じ商品を違うPCから見ることができたら?
もしくはトレーニングなどを受けたり、教える側になったら?
数年前、遠隔地での教育は専用のテレビ電話を使っていました。
RIAならPCの画面でテレビ電話と同様なやりとりに加え、専用のアプリケーションと連携してさらにいろんなことができます。
ピアノの先生と連弾ができるかもしれませんね。音の波形を画面に出力して先生と生徒の演奏を「見た目」で比較するのも面白いですね。

2.2.1 まとめ
ここまで説明をして今更なんですが、これらの話は「RIA」だからあり得ることではありません。
ユーザビリティやインタラクションなどをいかに作りこむか、ユーザに提供をするか、というのは大切なことです。RIAと呼ばれる技術は既存技術に対しそれらを実現しやすい、またはそのような文化をもっているにすぎません。比較的新しく従来の技術よりも表現力に優れているから、そのようなポジションになっているだけです。Adobe Flexで作れば即ちRIAではないのです。仮にそうであったとしてもユーザを置き去りにしたりストレスを与えているアプリであれば価値は低いと考えます。
極端な話、Excel VBAでも使いやすいアプリはつくれるかもしれません。それがRIAの定義から外れるものであったとしてもユーザの要件を満たし使い勝手に優れているのであれば問題はありません。
ユーザの声を真摯に受け止めること。
技術力の高さ、デザインセンスを誇ることが全てではないのです。
RIAとは何か。
真剣に考えれば考えるほど、いきつく結果は当然のものになるのではないのでしょうか。

2008年3月3日月曜日

2月猛省

・データモデリングの本(タイトル忘れた)
・DBの入門本(読み終わってない)
・Adboeの25周年本(パラパラめくっただけで貸してしまった)
・RFPの作り方(調べ物があったのでちょっと舐めた)

以上、仕事に関係がありそうな本
以下、その他の本

・よつばと! ①~⑦ 読み終わった
・BECK! 新しいやつ2冊
・ローマ人の物語 のでてるやつの後半

よつばとローマ人しか記憶に残ってねーっす。ははははは。

でもローマ人の物語はいろいろな思考をする上で役に立ちますね。

「人は見たいと欲する現実しか見ない」
といったのはカエサル。
「みたい現実だけみせて、本質の部分は水面下でこっそり。。。」
なアウグストゥス。

一方の視点から見ると都合の悪い本質を隠ぺいして、全体として都合のいい方に話をもっていく。。。
しかも嘘はつかない。
とても神経すり減って大変なんだというのはよくわかるけど、このセンスは重要。
偉そうなこと言える立場でないですけどね。

とても大事でやらなくてはならないことがあるのであれば、それくらいの演出とかはあってもいいと思うわけです。現実を直視させるのはそれからでも遅くないはず。嘘ついてなければ。

仕事にも必要そうでいて、あんまり必要であっちゃおかしいんだけど、このセンスがあるのとないのじゃ結構違う。
それとこのセンスには「見たくない現実を直視できる」ことが必須。

で、タケはよつばと!ばっかり読んで勉強してない現実を見るべきなんです。
2月は猛省なんです。