┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.105 2005/08/24
■ I N D E X
┃
┣【ＰＦ】価値と原則[9]
┣【ＰＭ】プロジェクトマネジメント入門[25]
┗【アンケート】気になるシステム業界 ホントのところ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＰＦ】価値と原則[9]
さて、これまで「価値(value)」と「原則(principle)」を解説したことで、プ
ロジェクトファシリテーションの目指すところが見えてきたと思います。しか
し、具体的に目的を達成するには、何を行動として起こせばよいでしょうか。
ここでは、プロジェクトファシリテーションの「実践(practice)」を紹介しま
す。具体的な実践として、2つ簡単に紹介しましょう。
・朝会
・ふりかえり
ここに書かれていない他の実践もたくさんあります。例えば、偏愛マップや、
バーンダウン、かんばんによる進捗管理など。また、これらの実践は、「ふり
かえり」によるフィードバックで、日々変化します。ここでは、簡単な紹介に
とどめ、詳しくは、『プロジェクトファシリテーション実践編』で解説するこ
とにします。
●朝会
毎朝、全員で集まって15分間のミーティングを行ないます。目的は、チーム内
の情報共有と、仕事を始めるにあたって、朝のスタートを気持ちよく切ること
です。
チームリーダーが司会を行い、全体的な進捗状況や伝達事項を共有した後、各
人が以下の3つについて話します。各人の話題をこれ以上増やすと、15分では終
了できなくなります。もし、問題点の討議などが必要であれば、司会者は別の
ミーティングをアレンジします。
このミーティングは、立ったままで行なうことが多い[*1]ため、スタンドアッ
プミーティングとも呼ばれます。また、このミーティングは、チーム全体の進
捗が貼り出されている場所で行なうのが良いでしょう。
朝会の行いかたについては、別途『プロジェクトファシリテーション―実践編：
朝会ガイド』に記述します。
朝会の様子(進捗を見ながら)
http://www.ObjectClub.jp/ml-arch/magazine/magazine105/meeting.jpg
●ふりかえり
チームは、一定期間ごとにふりかえり(反省、回顧)を行ないます。繰り返し型
開発を採用していれば、イテレーションの終了時に行なうのが自然です。そう
でない場合でも、1週間〜1ヶ月程度の期間で定期的に行なうのがよいでしょう。
ふりかえりの目的は、その期間で行なったことから「気づき」を得て、よりよ
い仕事ができるように自己改善を行うことです。個人個人が思っていることを、
声に出して言ってみる。個人のなんとなく思っていることが形になり、さらに
チームで共有されて「気づき」になります。単に悪かった点を上げる、という
「反省」のみではなく、その期間のよかった点、次の期間で試してみたい改善
策なども話し合います。
もっともポピュラーなふりかえりのフォーマットは、KPT(Keep/Problem/Try)で
す。この手法では、ホワイトボードや模造紙を3区画に区切って、それぞれの区
画にKeep(良かった点＝継続したいこと)、Problem(問題点)、Try(試してみたい
こと)を書き出します。
KPT(Keep/Problem/Try)の例
http://www.ObjectClub.jp/ml-arch/magazine/magazine105/kpt.jpg
その他にも、時系列に沿って、個々人の感じたことを書き出す「タイムライン」
などの手法があります。
「ふりかえり」のやりかたについては、別途『プロジェクトファシリテーショ
ン―実践編：ふりかえりガイド』に記述します。
●まとめ
この連載では、「プロジェクトファシリテーション」の「価値」と「原則」を
まとめ、2つの「実践」として「朝会」と「ふりかえり」を紹介しました。これ
らの手法を使って、あなたのプロジェクト・現場がより活性化し、プロジェク
トファシリテーションの目的である、「プロジェクトの成功」と「エンジニア
としての時間の質の向上」の両方が得られることを望んでいます。うまくいっ
た、いかない、などのフィードバックをぜひ頂きたいと思います。
実践の詳細については、『プロジェクトファシリテーション―実践編』を参照
ください。また、実践するにあたって必要なツール(小道具)については、『プ
ロジェクトファシリテーション―ツール編』を参照してください。
以上で、PFの価値と原則編はおしまいです。(editors@ObjectClub.jp)まで、
コメントおまちしています！ （平鍋）
[1]:時間を短くする効果がある。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-15&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-15&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-15&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＰＭ】プロジェクトマネジメント入門[25]
プロジェクトマネジメントとは直接関係しないのですが、前回お話しした通り
プロジェクトの成否を決めるひとつの要因として、開発するソフトウェアの規
模を正確に把握することが上げられます。この規模を把握する方法、つまり見
積手法を数回に渡りお話ししたいと思います。
ソフトウェアの見積手法として「ファンクションポイント法(以下、FP法)」が
あります。
繰り返しになりますが、ソフトウェア開発における課題のいくつかについては、
ソフトウェアを定量的な数値として量ることが難しいことに起因します。この
ため、開発を始める時に開発規模が見えず、開発にかかる工数・経費・期間が
読み取れずに、今までの経験や勘ではじき出すことになってしまいます。たま
たま、合っていれば顧客に迷惑をかけずに、また、この開発プロジェクトはビ
ジネス的にも成功することになります。しかし、このようなことは稀ですし、
経験や勘では何ら根拠がありません。
今回お話しするFP法は、外部仕様(データフローダイアグラム、E-R図)から開発
するシステムの機能要件の規模を定量的に見積り、これを工数などに換算する
という手法です。
見積手順としては、大まかに次の通りになります。(細かな手順としては6ステッ
プあります。この6ステップの説明は後々する予定です。)
・外部仕様から「調整項目」を加味し、「ファンクションポイント」を算出
・「ファンクションポイント」から「各種係数」による換算を行い、工数な
どの「見積値」を出す
なぜ、機能要件(ファンクション)に着目するかというと、開発するシステムの
機能要件は、開発環境やプラットホームなどに依存しないからです。開発工数
や期間に影響するのは、これら機能要件を実現するための内部仕様や作り方で
す。まずは、機能要件を定量化するファンクションポイントを算出し、作り方
やシステムの特性などを「各種係数」として表し、算出したファンクションポ
イントをこの係数を加味して「見積値」を出します。
また、機能要件は外部仕様から見積るので、外部仕様が見え始めた開発の早い
段階から使えます。このため、早い時期から開発する規模が想定できます。
著者のところでは、まだ、「各種係数」などの収集が多くなく、試行の段階で
すが、機能要件という顧客にわかりやすい尺度で見積ることが出来るのは営業
的な面から見ても有効と考え、推進しております。将来的には、このファンク
ションポイントによる契約(受注金額)が出来ないかとも考えております。
これは、現在のソフトウェア開発の取引が、開発要員の人月単価が中心となり、
生産技術や効率化などの改善がビジネス的に寄与しない現状になっているため、
これでは、ソフトウェア産業が技術的に衰退しかねません。そこで、ファンク
ションポイント数を顧客と合意し、この数で契約を交わします。私たちソフト
ウェア開発会社は、如何に機能要件を効率よく実現していくかを目指します。
このとき効率はそのまま利益に結び付いて行きます。
これらのことから、現在、筆者の会社ではFP法の教育や現場への導入を進めて
います。
次回は、FP法の「特徴」や「適用分野」に関してお話ししていきます。
（事務局長）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=F001-24&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=F001-24&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=F001-24&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「1日にどのくらい水分を摂っていますか？」のホントのところ。まだま
だ暑い日が続きますが、1日にどのくらい水分を摂っていますか？
1日1〜2リットル飲むのが健康にいいらしいですよ。
ペア・プログラミングをしているときに、大量に水を飲むのがオススメだそう
です。トイレが近くなって、強制的に休憩がとれるようになるからって、こと
らしいですよ。
3リットル以上。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=0
2〜3リットル。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=1
1〜2リットル。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=2
1リットル未満。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=3
ほとんど飲みません。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=4
水分は仕事帰りのアルコールで補給！
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=5
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=71&choice=6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「夏好きですか？」の結果は公開中。是非ご覧下さい。
⇒http://www.objectclub.jp/special/kininaru/vol70/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、代理編集人です。
今回はさとみが体調を崩してしまい、代わりに天野が編集を担当しました。
立秋を過ぎたとはいえ、まだまだ暑い日が続きますね。みなさんも体調には充
分お気をつけください。さとみへのお見舞いメールも受け付けております。こ
のメールに返信いただければ、さとみにも届きますよ。
ついでに宣伝です。天野が連載している雑誌「日経ソフトウエア」が、本日
(24日)発売です。よろしければ、お手にとってご覧ください。
http://software.nikkeibp.co.jp/software/backno/2005/0510indexc.html
今週の強引な一言
*** 艱難汝を玉にす（ことわざ）***
問題の解決を誰かに任せっぱなしにしていませんか。その問題を解決してこそ、
新たな問題に取り組める足腰が鍛えられるのです。人に任せっぱなしにするの
ではなく、仲間と一緒に問題に取り組んでみてはいかがでしょう。
（天野勝）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は
⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2005 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.