スーツの国から(2007年年末)

なんだかギークの国とスーツの国の話が盛り上がっているので便乗して勢いで書いてみるテストです。
GoTheDistanceさんのBlogエントリ「スーツにはスーツの道がある」に触発されています。

個人的には自分はスーツなんだと考えています。少なくともエンジニアではない。設計したりコードを書いたりビルドしてテストするような作業は行いません。ただし、"技術のこと、実装のことを肌で感じることができないし、感じようともしない「スーツなおやぢ」"にはならないようにはしています。プロジェクトチームを動かす為にはチームの中でのマジョリティであるエンジニアさんとコミュニケーションが出来る事が絶対に必要ですし、技術リスク等を理解して見極めて判断をするためにも、最低限の基礎知識や技術知識、最新技術をバランス良く身に付ける必要がある。エンジニアさんのキャリアに関してもアドバイスが出来なければならないし、そうでなければ優秀なエンジニアさんはついて来ないと言うことを強く意識しています。

こんな私がはたしてスーツなのかどうかはよくわかりませんが、むしろ個人的にしっくりくるのはテクノクラートという単語です。Wikipediaから引用すると「高級技術官僚」。高度な科学技術の専門能力だけではなく政策能力を持つ上級職。ITエンジニアリング界隈にとって、コンサルタントやスペシャリストや管理職なんてありきたりで目指したくもないし、キャリアの墓場みたいで嫌だ。じゃあ企業するかというとそんなパッションがあるわけでもない。問題解決とそれによる利益(利便性)向上こそ命。そんなあなたにオススメはテクノクラートへの道。どうなんでしょ。流行らないかな。

以前に書いた、PFP関東ワークショップで聞いた羽生田さんの話を思い出す。ビジネスとエンジニアリングの間でバランスを持つ話。結論としては、ビジネスとエンジニアリングを繋ぐブリッジ能力として「見える化(モデリング力)」と「ファシリテーション力」の二つがあげられていました。この二つがビジネスと技術の四象限を繋ぐキーであり、今後必要とされるという話です。テクノクラート的には当然スーツと非スーツの境界を軽やかに跨ぐ必要があるのでどちらも重要と考えています。モデリングによってステークホルダー間の認識をあわせ、ファシリテーションによって合意形成を行う。そして人を動かす。

あと、何度も読んで参考としている「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」。この本の最後の章「社内の力関係と政治」が思い起こされます。

政治とは汚いことを表す言葉ではない。「政治」という言葉の第一義は、たいていの辞書では以下のようになっています。
政治(名詞)：政府や、統治機関が実施する芸術や科学のこと。特に、国家のような政治的な団体の統制や、その内外における事象の執行および統制を指す。
「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」16章 社内の力関係と政治

非スーツの道、ギークの道もあると思いますが、政治と技術の境界を歩むスーツの道もあっても良いと考えています。というか、私はそこを歩いていきたい。

Blogged with Flock

SlideShareへのアップロードのコツ

要求開発アライアンスの12月定例会に行ってきました。
(といっても、仕事が忙しくて定例会自体は欠席。懇親会になんとかスベりこむことができた程度ですが)
良い発表内容で、たいへん盛り上がったようです。

で、実際には要求開発アライアンスのサイト管理もやっているのですが、この発表資料をサイトにアップするのに、新企画としてSlideShareを利用してみました。最近はいろいろなコミュニティでも活用されているようですが、SlideShareはいわゆるスライドショーを共有できるWebサービスです。

| View | Upload your own

で、まぁなんとか上記のような形に仕上げることができたのですが、けっこういろいろとワビサビがありました。
基本的には海外のサービスなので、まず日本語をきちんとサポートしていません。
普通にPowerPointのファイル(PPT)でアップロードすると、フォントが変化してしまいとても格好悪くなってしまいます。

ネットを検索したら、以下のようなことを紹介しているサイトがあったので参考にしてみましたが、これもうまくいきませんでした。

SlideShareでは、PowerPoint、PDF、OpenOffice (odp) 形式のファイルがアップロードできます。そして、日本語のPowerPointファイルもアップできるのですが、その場合SlideShare側が持って いる日本語ファイルが少ないために、明朝体でしかもサイズ違って画面からはみ出してしまったりしまってしまいます。読めないことはないけどかっこよくな い。フォントを埋め込んでもダメでした。
なので、これを解決するために、文字のアウトラインを埋め込んだPDFをアップロードしています。
おぎろぐはてな：Powerpointの資料をキレイにSlideShareにアップする

結局は、元ファイルの情報量が多すぎて、SlideShare側の変換がエラーとなってしまいます。というわけで発見したのが次の方法。
「OpenOfficeでPowerPointの資料を開いて、PDFに書き出す」
OpenOfficeでは標準でPDFの書き出しをサポートしているので、単純にPPTファイルを読み込ませた後に、PDFで保存をするだけです。どのような仕組みかはわかりませんが、仕上がったPDFファイルは容量も小さく、きれいにSlideShareに読み込ませることができました。

以下は推測ですが、

• PPTファイルを直接アップロードする ･･･ 日本語フォントの問題で、格好が悪くなる
• 汎用のPDFツールでPDF化しアップロードする ･･･ 多数のオブジェクトの処理がうまくなく、SlideShareでエラー
• OpenOfficeでPDF化しアップロードする ･･･ OpenOfficeに読み込ませた時点とPDF出力のタイミングで、Officeの効果やFontの問題が解決され、成功する

というカラクリだと思われます。

というわけで、しばらくはこの方法で利用してみたいと思います。

Blogged with Flock

オフィスの書類を減らせ

個人的には、とにかくもっとオフィスの書類はもっと減らすべきと考えています。というわけで、以下の記事が良かったのでご紹介。

なぜオフィスの書類が減らないのか社員全員にパソコンを与えてLANでつないだのに、書類が減るどころか増えているのはなぜだ──。多くの企業が頭を抱えている問題だが、実はこの疑問の中に答えが潜んでいる。ITは情報の拡大再生産を容易にする道具であるため、全員にパソコンを与えれば取り扱われる情報量は拡大し、それをアウトプットすることにより書類は確実に増える。その原因はどうやら、電子文書も含めた文書の運用管理のルールがなく、すべて社員任せになっている状況にあるようだ。
オフィス文書削減講座：なぜオフィスの書類が減らないのか - ITmedia Biz.ID

詳細はリンク先を読んでいただくとして、要は「文書の私物化」が、書類が減らない原因というお話です。
「文書の私物化」というのは良い言い方だなァと思ったら、これは文書管理におけるキーワードらしい(Google検索結果)。しかし、実際にはこういった取組みを行って、紙書類の削減をおこなうというのはなかなか難しいと思います。内部統制やセキュリティなどで強くプレッシャーをかけられても、「自分の机は自分のもの」的な意識は突き崩せないと思います。じゃあ、自席を無くすフリーアドレス制にすればいいのかというと、それもちょっと難しそう。そもそもシステム開発の現場ではノートPCだと力不足なのでデスクトップPCを使う関係上、フリーアドレスにもしにくい。

ちなみに、個人的には紙資料は嫌いなので、自席にはほとんどありません。

• 配布資料なども、電子ファイルがある場合は基本的に捨ててしまう。大事なメモがあったらそれはメールなどに書き写して自分に送信。
• 電子ファイルが無い資料は、複合機などでスキャンしてPDFファイル化して、やっぱり捨ててしまう。
• 名刺も古くなったものから、複合機でスキャンしてPDF化、廃棄。
• デュアルモニタにする。2画面あると、複数のドキュメントチェックなどでも印刷しなくて済みます。
• 手帳やノート、メモ帳や付箋紙に手書きでメモを取る。簡単なメモ内容をテキストファイルに書いて印刷してしまうことを減らす。(というわけで、絶対に紙を使わなくするのではなく、コピーや印刷物を減らす)
• 100円ショップでホワイトボードを購入してそれを使う

などなどが、個人的に行っている工夫です。

Blogged with Flock

OpenEventの運営メモ

またずいぶんと間が空いてしまいました。

今回は、自分向けのエントリですが、コミュニティ運営やOpenEventの運営に関するTIPSやリンクなどをまとめたいと思います。このエントリはしばらく更新し続けるつもりです。

■個人的なTIPS

1. 1ヶ月前には日程を決める。急な告知だと、参加したい人が参加できなくなってしまいます。やはり、十分に余裕を持って決めてしまうのが良いと思います。決める労力は、直前であってもあまり変りません。
2. リマインドメールを出す。個人的な目安は「申込締め切り前」「開催1週間前」「開催前日」です。仕事で参加できない場合は仕方がないですが、人間ですからウッカリ忘れてしまう場合もあります。リマインドメールなんて、たいした手間でもないので、出しておきたいものです。
3. リスク対策
• 自分が遅刻してしまう場合の考慮をしておく(よく忘れちゃうんですが)。仕事が急がしかったり、電車が事故で遅れたりする場合もあります。
• USBメモリ等のメディアを持っておく。発表者のPCが不調だったり、プロジェクターとうまく繋げない場合の対策です。なお、PC自体は参加者から借りたりすることができるので、意外と持ち込まなくても平気(これはコミュニティにもよる)
• 紙と太目のサインペンなど … 会場でホワイトボードが使えなかったり、ちょっとした議論を整理するときに持っていると便利です。また、名刺が切れた場合にも手書きして渡したりできます。
  
4. 金銭的リスク対策 (2008/1/28追記)
   
• 会費などを徴収する必要がある(懇親会など)場合は、少し窮屈なくらいの人数設定にする(席は予定人数×90%、料理は予定人数×70%とか)。直前のキャンセルなどについて感情的にならず、受け入れる。会場は狭いくらいが盛り上がるし、楽しい。飲食が目的なわけではないので、なんとかなる。
• 初見の参加者が多い場合などは、精算時に名刺などを一緒にもらうと良い。
• 若干多めに徴集して、もしも余ったら次回の開催に残金を申送りする。なお残金が出たら参加者に公表したり、MLにポストするなどして、オープンにしておく。残金が残れば、それを次回開催のモチベーションとして考える。
  

■リンク集

• TIPSなどの情報
  
• 連載：勉強会のススメ｜gihyo.jp
• イベント運営の勘所 | IDEA*IDEA
• パネル限界論 | IDEA*IDEA
• 他のコミュニティのスケジュール
• コミュニティカレンダー － ＠IT自分戦略研究所
• お役立ちツール等
• スケジュール調整
• Pollan : イベント開催支援サービス
• スケジュール調整システム「ちょー助」トップ
• 申込管理
• 無料メールフォームならふぉーむまんのレンタルフォームサービス… 申込内容をCSV化してくれるのが便利
• メーリングリスト
• Yahoo!グループ - 無料でメーリングリストを作成… クローズドMLとした場合に、MLメンバー以外からのポストを受け付けることができない事に注意。つまり、コミュニティ外の人にメールを出す時にCCに入れることができない。Web経由でファイル共有(Yahooブリーフケース)が使えるのはちょっと便利です。
  
• Google Groups … Yahoo!グループの問題(MLメンバー以外からのポスト受付)が出来るので便利です。ただし全機能を使うにはGoogleアカウントが必要。
  
• 情報共有
• Welcome to qwik.jp! - qwik.jp…ML連携Wiki。使いこなすのはちょっと難しい
• Google Docs … 運営メンバーなどで情報を共有するときに便利。ただしGoogleアカウントが必要です。
• 議論
• はぶにっき：プロセスデザインという黒子の美学
  

■参考

• 仕事のための12の基礎力～「キャリア」と「能力」の育て方～…このなかで、「人脈開拓力」を伸ばす方法として、勉強会やイベントの幹事を引き受けて、呼びたい人を講師やゲストに招くという方法が紹介されています。

Blogged with Flock

The Myths of Innovation 『イノベーションの神話』秒で発注

私の中では昨年度の最重要本だった、「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法」の著書、Scott Berkunさんの新作邦訳が出るそうです。(via YAMDAS現更新履歴)

というわけで、秒でAmazon予約注文しました。楽しみ！

イノベーションの神話

posted with amazlet on 07.10.19

Scott Berkun 村上 雅章
オライリー・ジャパン (2007/10/29)
売り上げランキング: 10101

Amazon.co.jp で詳細を見る

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

posted with amazlet on 07.10.19

Scott Berkun 村上 雅章
オライリー・ジャパン (2006/09/07)
売り上げランキング: 10812

Amazon.co.jp で詳細を見る

システム開発は製造系じゃなくて創造系じゃないか

妄想ですが考えている事を書いてみるエントリです。

システム開発プロジェクトは「設計」や「製造(コーディング)」をし、「テスト」をします。これはモノ作りの現場、例えば自動車メーカーなどの製造業に例えられます。というわけで一般的にはシステム開発はモノ作りの一種と認識され、運用されています。プロジェクトの規模にもよりますが、全体のQCD(コスト、品質、スケジュール)をプロジェクトマネージャが管理し、全体設計をITアーキテクトと呼ばれる設計リーダーが担当する。その下に、設計者や製造者(プログラマ)、テスターがぶら下って一つのチームでシステム開発を行うのが一般的なイメージ。

しかし、モノ作りではこれらの「人」に加えて「材料」や「工具」が必要ですが、システム開発プロジェクトではほとんど「人」だけで作業を行っています。そして最終製品も開発が終了するまでは曖昧であり、途中で最終形を確認することはできませんし、プロジェクトの途中で最終形がまったく違ったものに変化する事もあります。つまり、モノ作りとしては非常にコントロールがしにくい。

このコントロールしにくい、不定形なプロジェクトをモノ作りと同様に管理するのは限界があるのではないかと考えています。

例えば、映画や演劇、オーケストラのような創造系のプロジェクトのようにはマネジメントできないか。
これらのプロジェクトはほとんど「人」主体で進む点と、「結果があいまいで評価しにくい」という意味で、システム開発プロジェクトに似ていないでしょうか。

創造系のプロジェクト体制は例えば次のような形になるでしょう。

■作家／脚本家／音楽家
プロジェクトの骨格となるストーリーを考えます。共感できる背景や思想を持って、プロジェクトが成功するためのストーリーを考える役割です。出来上がるシステムの骨格(使われ方や重要なポイント)などを観客(ユーザ)から見て考える役割です。

■演出家／指揮者
脚本や楽譜を元に、メンバーをひとつにまとめてシステムの肉付けを行います。単なるマネジメントではなく、メンバーの能力を最大限に引き出し、かつ自分なりの解釈でシステムの肉付をしなければいけません。もちろん仕上がりの品質への責任もあります。もちろん全ての作業工程を知っている必要があります(楽譜が読めなかったり、楽器の出来ない指揮者はいませんよね)

■プロデューサー
プロジェクトを外部から守り、維持します。資金を調達したり、メンバーを集めスケジュール調整もします。外部から見てプロジェクトの最高権限者ですが、内部から見ると守護者となります。

■舞台監督
メンバーの能力を最大限に生かし、脚本を活かす為の舞台を作る人です。システム開発で言えばアーキテクトと呼ばれる立場に近いかもしれません。

■メンバー
プロジェクトの主役です。役柄については主演・助演などの序列はあるかもしれませんが、全員が舞台上で活躍するという意味では等しく重要です。自分だけが目立つのではプロジェクトは成功しませんので、お互いの相互関係に強く留意する必要があります。

こういう構成のプロジェクトであれば、素晴らしい成果が出せると思うのですがどうでしょうか？
(ちなみに、書いているうちにIDEOのことを思い出しました)

PFP関東WS#8に行ってきました

10/3にPFP関東WS#8に行ってきました。プロジェクトファシリテーションに関するワークショップです。参加者は20名くらい。メインは「プロジェクトファシリテーション入門　ＰＦＰ関西合宿濃縮還元版」でしたが、それ以外にもいろいろと盛りだくさんで、たくさんの「気づき」を貰える内容でした。というわけで、後で自分で読みかえす目的もありますが、内容をレポートしたいと思います。

■ファシリテーションの重要性

今回はPFP関東としては初めて、豆蔵さんの会議室を借りたということで、最初に豆蔵の羽生田会長にお話いただきました。10分程度ですが、非常に濃い話で個人的には非常に感動。

• これまではエンジニアリングの観点で、S/W技術やPMを中心に活動していた。これは、ProductからPorcessまでの実現に関わる領域である。
• しかし、顧客の要請(関心)は「問題やビジネス課題そのものの解決」に移ってきている。また、多種多様な「ステークホルダの合意プロセス」なども視野に入ってきている。これはS/W技術やPMのような実現技術ではなく、企画の領域である。
• この4象限を繋ぐキーワードが「見える化(モデリング)」と「ファシリテーション」ではないか？

というような内容を、ホワイトボードを使ってサラサラと説明いただきました。この内容は個人的な自分の現在の興味とビシッとハマってしまい、感動です。いろいろと普段から悩みがあるのですが、勇気を持って、ビジネスモデリングとファシリテーションの学習を続けていきたいと考えています。
なお、羽生田さんのプレゼンテーションそのものも、とても参考になりました。内容だけでなく発表の構造も含めて、短時間でためになるセッションでした。

■TOCに興味が出てきた

次は、アジャイルプロセス評議会 TOCワーキンググループにも参加されている進藤さんの事例紹介です。JudeやTRICHORDなどのおなじみツールの紹介もありましたが、やはり興味深いのはTOC関連の思考フレームワークでした。特に興味深かったのはODSCです。

• ODSCとは
• Objectives（目的）
• Deliverables (成果物）
• SuccessCriteria （成功要件）
• プロジェクトやタスクを定義する際に、上記ODSCを明記して作業を行う。
• 成功要件を定義するので、作業中の意思決定をするときの判断がしやすい印象があります。また、わかりやすいのですぐにでも使える気がします。

PFP関東WSでは毎回必ず事例発表があるのですが、ホンで読んだ理論や技法も実際に活用されている人の言葉で聞くと、とてもわかりやすく、また実践のヒントになります。

■プロジェクトファシリテーション入門 PFP関西合宿濃縮還元版
最後は串田さんファシリテートによるワークショップです。発表資料はWikiに公開されているので興味のある方はどうぞ。というわけで、ここではワークショップの中身についてレポートします。

今回のお題は「どうすればプロジェクトが成功するか」についてグランドルール(問題vsわたしたち、見える化、カイゼン、笑顔)を守って議論を行うというもの。対象のプロジェクトも自分達で選ぶことができます。

• くじ引き
• まず最初にカラーペンを全員に配り、4分間で1対1の自己紹介を行い、共通のキーワードが見つかったらペンを交換するという方法でアイスブレーク＆シャッフル。
• 「わたしはSIerでPMやってます」「私も組込み系のPMです」⇒成立！交換！
• 「血液型はA型」｢O型」⇒不成立！
• 「結婚して8年目です」「私も1999年に結婚した！」⇒成立！交換！
• 時間が短くて、むしろ燃えました。
• 同じ色のペンを持つ人で１グループ。今回は5人×4グループにわかれます。
• あとは自由(これが難しい)
• 真っ白な模造紙が配られます。あとはペンと付箋。さあ開始！(げげっ)
• ゴール決定
• とりあえず全員で1分間考えて発表し、その中で楽しそうなプロジェクトを選ぶことにしました。私のいたグループで出てきた案は次の通り
• 世界征服
• 定時に帰る
• 1週間休みをとる
• 全ての国に行く ⇒ これを採用！
• 発表をうまくやる
• 検討
• われわれのグループでは、さきほどの事例発表にあったODSCを使ってまずゴールと成果物、成功条件を分析してみました。
• ゴール(O)…全ての国に行く ⇒ さらに明確に「一人で国連加盟国(または何らかの本/Wikipediaに掲載されている)に行く」
• 成果物(D)…パスポートのVISA・スタンプ、日記、写真などのキロク
• 成功条件(SC)…できるだけ短時間で実施し、ギネスブックに申請する
• このODSCを意識しながら、プロセスをブレークダウンしていきます。
• ゴール(終端)からプロセスを追っていく
• あとは皆でアイデアや意見を出していくのですが、TOCの思考プロセスを活用して後工程から順に追っていきました。具体的にはこんな順番です。
• 帰国してギネスブックに申請する
  ↑
  <ループ終端(全ての国を巡るまで)>
  入国する
  ↑
  出発する
  <ループ始端(全ての国を巡るまで)>
  ↑
  準備する

• それぞれのプロセスについてのアイデアや問題を付箋に書き込み、プロセスのまわりに貼っていきます。例えば、
• 資金はどうするか？ → 各地で働いて稼ぐ？(大道芸？) → 成功条件(できるだけ短期に)に違反 → 事前に資金準備が必要！
• 入国できない(トラブル、不許可)時はどうする？ → 途上で計画を変更する必要あり
• ケガや病気の発生には → 国によっては対応困難 → ある程度の医療知識を事前に習得必要
• 特によかった点としては、最初につくったODSCによって、各種課題やアイデアの取捨選択がすぐにできたこと。資金調達などは、短期間で行動する成功条件を満たす為には旅行中に行うべきではなく、事前に十分な資金調達をしておく事が重要、というような判断がつきやすかった
• 発表
• 最後に各チームで発表を行い終了。最後にKPTを参加者全員で考えて終わりました。

ここまででちょうど2時間。非常に密度の濃い時間の過ごし方でした。

■書籍紹介
今回はどのセッションでも書籍紹介がありました。発表時に「お気に入りの本や参考書」を持ってきて、回覧するのは良いアイデアだと思います。これはいつかやってみよう！

羽生田会長ご推薦


進藤さんご推薦




■ファシリテーションの練習のためのPFP WS
個人的には、PFPの場を「ファシリテーション的行動の練習の場」として捉えています。ワークショップには、PF初参加の方もいれば、よくわかっている人もいます。会社でいきなりPFを実践するのは勇気がいりますが、PFPの集まりの中では気兼ねなく実践してみることができます。

今回も、たくさんの「気づき」を持ち帰ることができました。
ぜひまた参加したいと思います。スタッフの皆様に感謝です。

日経SYSTEMS10月号

先月号から、日経SYSTEMSの毎号感想を書いています。
なんと、書き溜めているうちに11月号が家に届いてしまいましたが、10月号の感想です。

記事	感想
特集1 目指せ！残業ゼロの現場 時間を取り戻す4つのポイント	とても大事な事。残業を引き起こしてしまっている原因を「手戻り」「気のゆるみ」「無駄な作業」「偏り」に分けて対策を書いているのが好感度。しかし、事例紹介が中心なので、ただちに適用できるものではないなぁ。
特集2【保存版】ユーザー・マニュアル作成術	テクニカルコミュニケーター協会というのを知りませんでした。でも、「紙のマニュアル」を前提にしているところがちょっと違和感あり。エコ的に考えて、紙のマニュアルを脱する議論をもっとしても良いのではないかと。
特集3 のぞいてみよう「組み込み開発」の現場	ちょっと業務から遠いのでパス。
検証ラボ データセンターのセキュリティ検証実験 IDS/IPS設置して再びチェック、すべての脆弱性はつぶせず	2部構成の後編。前編は防御側(IDC)視点で語られていて面白かったのだけど、今回は攻撃側視点でちょっと楽しめず。しかし、勉強になりました。こういったセキュリティ関連チェックを自力でやるのは非現実的だなぁというのが感想。
プロダクト賢者の選択 構成・変更管理ツール 分散拠点からのつなぎ方に違い、カスタマイズのしやすさを重視	有償のワークフロー付き構成管理ツールの説明。結局IDEと統合されていないと使い物にならない気がします。Subversion+Tracまたは JIRAというのが現実的。あとはASPサービス利用がいいと思ってます。後者はセキュリティ上なかなか取れない選択肢ですが。
絵で見るテクノロジ 文字コード　文字集合と符号化方式の組み、いくつもの規格が乱立	Vistaの問題(http://itpro.nikkeibp.co.jp/99/vista/index.html)と絡めればもっと読める記事になったのに……
事例に見る問題解決の軌跡 CASE24 ネクスト フレームワーク「Maple」を導入、改修案件の工数が従来の半分に	PHPでもDIなのかー。しかしPHPは扱っていないので、響きませんでした。やってみたいんですけどね。
SOAきほんのき［第1回］SOAを取り入れるメリット／柔軟性と再利用性が向上、Webサービスが普及を後押し	SOAのメリットを「ビジネス環境の変化にあわせて、迅速にシステムを開発し、プロセスの変更にも柔軟に対応できること」としているが、SOA以前の方法論ではなぜダメなのかが説明されていない点がちょっともったいない感あり。
教えて！実装&テスト工程［第1回］下流工程の準備／ツールやフレームワークは、選定間違うと「負の資産」に	IDE、Wiki、バグ管理システム以外にモデリングツールやプロファイリングツールの準備を推奨しているんだけど、いまいち活用イメージが湧かなかった。うーむ。
図解でもっと磨くプロマネ技術［第1回］プロジェクト完了報告書／思い出のアルバムからは、ノウハウも教訓も見えてこない	仰るとおり。しかし、まず完了報告を書くこと、読むことがら始めなければいけない世の悲しさよ。
コミュニケーション・スキル再入門プロジェクト編［第1回］初対面の緊張を和らげる／うまくやろうとすると逆効果、沈默を恐れず相手の言葉を待つ	初対面は苦手じゃないので飛ばし読み～
永井昭弘のすごい現場 建築設計事務所で見た巨匠のすごいレビュー	建築設計事務所っていうのは、システム開発の非常にお手本になると思っています。NHKの「プロフェッショナル 仕事の流儀」でも何回か建築家が登場していたけど、かなり刺激をうけました。
濱本常義のここが危ない！ 若手成長の踏台になる喜び 夏の恒例行事で実感	セキュリティキャンプの話ですが、こういうエリート育成活動ってどうなのかなという感覚もあります。ボトムアップのほうが急務なんじゃないかなぁ。
鈴木雄介のITアーキテクトの視点 バグの原因は何か？「環境を見る」と見えてくる	環境は重要。デマルコの本を思い出します。
ココロとカラダの相談室 抜けないだるさは万病のもと 気のせいにせず病院へ	ノーコメント
ITエンジニア現代図鑑 第7回「オレ様SE」実力過信しユーザー軽視 自分勝手にシステムを作る	ヒトゴトではなくて、テクノロジ先行のプロジェクトでは「オレ様SE」だけでなく「オレ様SI」もあるなー
数字で答えるIT現場の疑問 1000人月プロジェクトの工期はどれくらい？	COCOMOの紹介ですね。イマサラ感はありますが、この規模になると誤差の影響も多いのでこういった統計値の確認は重要です。でも、日本型システム開発がその通りに当てはまるか、というと、ちょっと微妙な印象あり。

Waterfallについて

mixiのマイミクさんから別件で、翔泳社さんの「開発の現場 Vol.9」を紹介してもらったのでパラパラと読んでいます。で、ちょっと気になったのが、特集「技術力アップの新常識」のコラムの一つです。というわけでご紹介。

ウォーターフォールは時代遅れ～ウォーターフォールは使い方次第
ウォーターフォールモデルの弊害はさまざまなところで指摘されています。しかし、このモデルが開発の現場でいまだに利用されているのはなぜでしょうか。それは、使い方次第で弊害を克服できるからです。本稿ではそうした、ウォーターフォールモデルを「いけるプロセス」に変身させるためのいくつかの工夫を紹介します。
翔泳社 開発の現場 Vol.9 より text:豆蔵 笠原規男

個人的には一部の分野(基幹系システムや、ミッションクリティカル度の極めて高いシステム開発)を除けばウォーターフォール型のシステム開発は不適切だと考えています。そう考える理由は2つです。
1つは現代に求められる(開発する)ITシステムが高度化し、人間系と密接に絡み合ったものとなったために最初の工程で全てを設計した上で開発する事が非常に高リスクとなった、という仮説です。取扱う問題が広い為に、少人数の担当者(エンドユーザ、システム担当者、開発者)が全てのシステムリスクを短期間につぶすことが困難であるため、段階的に開発せざるをえないと考えています。
もう1つはコストの問題です。ウォーターフォール型のシステム開発プロジェクトは、そのスケジュールの中で必要な要員スキルが大きく変化します。要件定義や設計フェーズでは「設計力」「ヒアリング力」などが要求されますが、開発実装フェーズでは「実装力」「技術力」、テストフェーズでは「テスト力」が要求されます。実際にそれぞれの局面で適切なスキルを持った要員を配置し、局面ごとに切替えていくのは非常に難しい。また、各局面の専門家どうしのコミュニケーションコストを考えただけでも頭がいたくなります。解決のためには要員体制を平準化する必要があるので、単純なウォーターフォール型開発は厳しいのではないかと。

というわけで自分のプロジェクトはだいたいフェーズ分割を行って段階的反復開発にしてしまうのですが、この本で書かれている「アーキテクチャ中心」アプローチは良さそう。ぜひいつか参考にしてみたいと思っています。

開発の現場 Vol.009

posted with amazlet on 07.09.28

SE編集部
翔泳社 (2007/07/12)
売り上げランキング: 46117

Amazon.co.jp で詳細を見る

ところでこのエントリを書くに当たってWeb上でウォーターフォールに関していろいろと検索してみたのですが、面白かったのがこれ。

Waterfall 2006 (日本語)
2006年に行われたWaterfall型開発に関するカンファレンスのようです。って、良く見ると内容が怪しい。セッションテーマがこんな感じなんですが……

• 超巨大プロジェクト: どのように遅らせるか - 決して完成しないだろうということを知られないために by Jutta Eckstein
• コラボレーションの排除: 一人で作業しよう by Jean Tabaka
• パターンからのアンファクタリング: 読みにくいコードで職を守る by Joshua Kerievsky
• テスト: 重要な工程を最後に実施する by Lisa Crispin

良く見ると開催日が2006/4/1、開催地はナイアガラの滝です。つまりエイプリルフールネタのジョークページなんですね。知らなかった。

参考：
はてなブックマーク タグ「ウォーターフォール」を含む注目エントリー

刀を抜かずに相手の心を斬る

イキナリなタイトルですが、ソフトウェアテストの権威である電気通信大学の西康晴先生の言葉です。プロジェクトがテスト局面に入ると、常にこの言葉を反芻しています。というわけで、ちょっとご紹介してみます。

テストの達人は開発の達人である

• 達人は、間合いを掌握する
• 網羅することで、抜けやモレ、思いこみによるバグを無くす
• 品質とは何か、を広く考えてユーザの満足度を向上する
• 達人は、一刀両断にする
• バグの出やすい弱点を把握し、改善する
• 達人は、道具の手入れを欠かさない
• 開発の最初からツールを考慮し、骨の髄まで使いこなす
• 達人は、型に始まり型を崩し型に戻る
• 技法の原理原則を理解し、最大限の効果を発揮させる
• きれいな設計・実装のソフトウェアは、テストも楽である：テスト容易性設計
• 達人は、気配を感じ取る
• バグやリスクが発生する前に予兆を検知し未然防止する
• 達人は、鍛錬を欠かさない
• 現状に満足せず、常に問題点を探し改善するとともに、勉強を欠かさない
• 達人は、達人を知る
• 自分からレビューをしてもらい、良いコードを読み、コミュニティに参加する
• 達人は、刀を抜かずに相手の心を斬る

ソフトウェアテスト技術 経営情報学会第三回情報システム工学研究部会 資料より (c)西康晴

コーディングテクニックや言語知識は、進歩が早い為にキャッチアップし続けるのはかなり難しい。しかし、テスト技術はそれよりももっと普遍的なものであると思っています(自動テストとかの話題は別)。テスト専門家でなくても、システム開発を行うPMやSEはぜひとも押さえて欲しい所。上記リンクの資料はまとまっているので、読んでみてもよいかもしれません。

エンジニアの課題図書

私はシステム開発プロジェクトでは、もう最近はエンジニアというよりプロジェクトマネージャやリーダーといった役割を求められる事が多くプログラミングをすることは少ないです。しかし意思決定のためにも、またチームメンバとのコミュニケーションや指導教育のためにも、システム開発に関連する技術書やビジネス書は継続的に読むように意識しています。

そういう時にけっこう参考にしているのはJoel Spolsky選定のマネージメントトレーニング用課題読書リストです。まだ全て読了していませんが、かなりイイ選択をしているように思います。

それ以外には、世の中で話題の技術書も押さえるようにしています。
最近だと、

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

posted with amazlet on 07.09.21

Scott Berkun 村上 雅章
オライリー・ジャパン (2006/09/07)
売り上げランキング: 19692

Amazon.co.jp で詳細を見る

ソフトウェア見積り―人月の暗黙知を解き明かす

posted with amazlet on 07.09.21

スティーブ マコネル Steve McConnell 田沢 恵 溝口 真理子 久手堅 憲之
日経BPソフトプレス (2006/10)
売り上げランキング: 16075

Amazon.co.jp で詳細を見る

JavaからRubyへ ―マネージャのための実践移行ガイド

posted with amazlet on 07.09.21

Bruce A. Tate 角谷 信太郎
オライリー・ジャパン (2007/04/21)
売り上げランキング: 30599

Amazon.co.jp で詳細を見る

が特に良かった。
ああ、あとはモチロンこれですね。

要求開発~価値ある要求を導き出すプロセスとモデリング

posted with amazlet on 07.09.21

山岸 耕二 安井 昌男 萩本 順三 河野 正幸 野田 伊佐夫 平鍋 健児 細川 努 依田 智夫 ［要求開発アライアンス］
日経BP社 (2006/03/02)
売り上げランキング: 130704

Amazon.co.jp で詳細を見る

米国と日本のシステム開発プロジェクトの違い

GoTheDistanceに書かれた「アメリカにはSIerなんて存在しない」というエントリへの反応です。要は米国では「企業がシステム開発から運用まで自分たちでやっている」という話です。

以前に要求開発アライアンスの合宿勉強会で、アーキテクタスの細川さんにも同じような事を説明していただいたのを思い出しました。「なぜシステム開発プロジェクトは失敗するのか」に関するディスカッションの中での説明です。

ここで説明された米国企業の特徴としては、

• 自社内にCIO、アーキテクト、PMをきちんと要している。
• また、専門技術者も自社内に体制として確保している。
• ベンダーや専門家が、外部から製品提供や技術支援を行い、開発の一部を海外などの技術者にオフショア開発する。

というお話でした。これに比べて複雑な日本の(一般的な)システム開発プロジェクトでは、構造および責任体系が複雑であるために、いろいろな問題が起こるのでは？ というようなお話でした。

今後の流れのひとつとしては、ユーザ企業による(少なくとも設計工程までの)内製化が進んでいくと考えています。協和発酵さんの事例などを見ても、ユーザ企業主導の開発プロジェクトは増えていくように思います。

とはいえ、自分の現在の立ち位置はSIerということもあるので、もっと異なるアプローチはないのか、日々考えています。

バリューアップ手法

日経SYSTEMSを定期購読しているのですが、時折(というかしょっちゅう)様々な広告や小冊子が同梱されてきます。ほとんどは捨ててしまうのですが、たまたま保存していた「ソフトウェア開発のパラダイムシフト～Visual Studio Team Systemで実現するバリューアッププロセス」の冊子を読んだらけっこう面白かった。

冊子と同等の内容の文章は@ITのサイトでも読むことができるようです。

• @IT:相対立するパラダイム ～「Visual Studio Team Systemで実践するソフトウェアエンジニアリング」
• @IT:フローの重視～「Visual Studio Team Systemで実践するソフトウェアエンジニアリング」

ここでは「バリューアッププロセス(またはバリューアップ手法)」と名づけているのですが、このネーミング自体が失敗のような気がします。要は、システム開発において計画ベース(プロジェクト開始時における仕様の実現をゴールとしてタスクを実施する)ではなく、システムの提供する価値ベースで行う反復開発のことを、バリューアッププロセス(バリューアップ手法)と呼びたいようです。

マイクロソフトでは、このバリューアッププロセスをMSF(Microsoft Solutions Framework)にて実現しているということ。MSFには、ライトウェイトのfor Agile Software Developmentと、CMMIレベル3に対応した for CMMI Process Improvementの二種類が用意されているようです。

フレームワークの詳細までは確認していないのですが、フレームワーク自体はMicorosoft製品を利用する前提となっているわけではないようです。もちろん、バリューアッププロセスを最適化するための各種メトリクスなどは、VisualStudioTeamSystemを用いれば取得できるようですが、方法論とツールはきちんと分離されています。

古典的なプロジェクトマネジメント アプローチおよび 「ウォーターフォール」ソリューション提供プロセス モデルは、IT プロジェクトにおいては一般的ではない、他の産業のような水準の予測可能性を前提としています。しばしば、プロジェクトの結果も提供手段もよく理解されておらず、探査がプロジェクトの一部となってしまいます。組織はIT 投資のビジネスへの影響を最大化しようとすればするほど、新しい領域への冒険を行います。この新しい領域は本質的に不確実であり、新しいニーズや方法における探査や実験の結果によって変化します。不確実性が存在するにもかかわらず確実性を要求したり望むことは、少なくとも非現実的であり、
せいぜい機能不全です。
俊敏であり続け、変化を予期する：Microsoft Solutions Framework WhitePaper v3

現在私が担当しているプロジェクトは、.NET開発でもないですし、VisualStudioも利用していないのですが、ちょっとMSFを勉強してみようかなぁ、と思いました。

Visual Studio Team Systemで実践する―成功する開発プロジェクト運営のために

posted with amazlet on 07.09.19

Sam Guckenheimer Juan J.Perez トップスタジオ
日経BPソフトプレス (2007/02)
売り上げランキング: 217632

Amazon.co.jp で詳細を見る

夏休み、断食ならぬ断ネットワーク

またもや更新間隔が空いてしまいました。
じつは先週から、遅ればせながらの夏休みをいただいていました。気がつくと6ヶ月間無欠勤。普段はプロジェクトの緊張感から体調を崩す事があまりないので、風邪で休んだりもありません。というわけで、土日をあわせて8日一気に休んで、かなりリフレッシュしました。

ちょっと意識したのは「オフライン」になる事。プロジェクトの状況にもよりますが、PCを持って行ったり旅先でのメールチェックは極力やめるのが今回のテーマです。というわけで、非常手段の携帯電話は持って行きますが、PCもニンテンドーDSも持って行かない、非デジの夏休みでした。

今回はちょっと業務が混じった催しで行くのですが、それでなくても一年に一回は必ず登山や温泉という形で絶対にネットに触れない連続した日々を持つようにしています。これがもつ効能は実にすばらしいものがあるので、誰にでもお勧めです。今日はそんな「メディア断ちした旅」の話題を。
Lifehacking.jp:メディア断ちの旅：携帯、ネット、テレビ、新聞を禁止して出発

私はここまでは徹底していないので旅先で現地のTVや新聞は少し見ていましたが、ネットには接続しないようにしていました。
(実際には、携帯電話しかデバイスが無いのでしかたないという見方もありますが)

で、行き先はハワイです。米国初上陸でもあります。これが非常に楽しかった。また行きたい！
というわけで、以下雑感です。

• 行き帰りはノースウェスト航空のエアバスA330。エコノミー全席にマルチメディアモニタ装備。オンデマンドで映画や音楽が視聴できるので快適すぎます。映画は日本語吹き替えも選べるのでまったく問題なし。
• 今回は初ハワイということもあるので、ずっとホノルルステイ。ハワイはJTBが強いというのを事前に聞いていたのでJTBツアーで行ったのですが、驚いた。ホノルル市街はJTB専用バス(トロリー)が10分間隔で走っているとですよ。
• ホノルルではビーチが全て公営です。つまり、ホテルのプライベートビーチというものがないのが、ちょっと不思議な感覚でした。これまでに行った事のあるビーチリゾートは、だいたいホテルのビーチを利用するパターンが多かったので。あとビーチは禁酒禁煙なので非常にクリーンでした。
• メシの量はとにかく多い。人によってはハワイの食事は×な事も多いようですが、私は全然平気です。大好きなコーラがどこでも売ってます。
• ノンデジタルな旅を標榜していたのですが、ついApple Storeに行ってiPhoneを触ってしまいました(ちなみにこの時点ではiPod Touchの発売は知らず)
• 数独(パズルの一種)が流行ってます。ビーチでも街中でもみんな数独やってます。試しにホテルサービスの新聞のおまけの問題を解いてみたのですが、これがメチャクチャに難しい。日本の新聞だと誰でも必ず解ける難易度の問題がついているものですが……
• 全般的には大満足。また行きたい！

なお、帰って来たら未読メール500通(SPAMフィルター後)、未読RSS1400件でした。これをなんとかできるといいんですけどねー。

日経SYSTEMSの記事についての感想をたんたんと記録してみる(9月号)

現在私は日経SYSTEMSを個人で定期購読しています。日経SYSTEMSの前身である日経ITプロフェッショナルという雑誌から継続していますが、システム開発全般の話題を取扱っているのでなかなか便利です。

というわけで、今月から、たんたんと最新号の目次と感想を記録してみたいと思います。
自分のための備忘という意味もありますが、以前に所属していたプロジェクトで似た事を行っていた事があり、それは自分にとってもチームにとってもとても良い経験だったのです。この話はまた別の機会に書こうと思います。

■日経SYSTEMS9月号 (青字が感想)

• 特集1 ITエンジニアが取り組む 内部統制
• 自分の現在のプロジェクトは比較的無関係ですが、顧客が内部統制対応した場合のSIer側の影響ということを平易に知ることができて良かったです。
• 特に変更管理の取扱いについては、顧客から指摘(依頼)される前に知っておくのが重要かなぁと。というわけで過去に参加した(影響のうけそうな)プロジェクトの後輩にお知らせしてみたりしました。
• 特集2 プロジェクトの根回し術
• この手のテクニック記事は微妙なので流し読み。そういえば積読になっているデル・カーネギーの「人を動かす」をそろそろ読まないと……
• 検証ラボ データセンターのセキュリティ検証実験 外部から攻撃して脆弱性チェック、1万項目の約1％に問題見つかる
• かなり興味深い記事です。データセンター事業者に対してセキュリティ診断サービスの提供会社が「攻撃チーム」を組成してセキュリティチェックを実施。その顛末が書かれています。「ヤシマ作戦」と呼ばれる擬似攻撃は運用メンバーには知らされず、はたしてメンバーは攻撃に気づくのか。結果として発見された脆弱性についても勉強になります。なお、次号に脆弱性対策の有効性をチェックする「オデッサ作戦」の記事が載るそうです。これはちょっと楽しみ。
• プロダクト賢者の選択 SAN ストレージ 仮想化やiSCSIへの対応進む
• 以前の案件で調査したことがあったので、さらっと流し読み。とはいえ、お客様から質問されることもあるので概論を知っておくのは重要かなぁ～。ハードウェアベンダさんの資料だと、なかなか判り難い事もあるのです。
• 絵で見るテクノロジ マルチコア CPUのアーキテクチャ革命、「周波数向上」から「並列処理」へ
• 最近デュアルコアというような単語もよく耳にしますが、初めてちゃんと理解しました。
• 事例に見る 問題解決の軌跡
• CASE 22 日本コムシス 運用保守がIT業務の7割に達す、アウトソースで2割以下に
• アウトソースをキッカケにSLAを作成、この過程で問題を解決という話。とはいえ、SLAは本気でやると非常に厳しいので、どれくらいコストをかけるかというところが勘どころなような気がします。
  
• CASE 23 シャディ 既存システムと計算結果が違う、1行単位でロジックを追跡
• 要求考古学的な事例ですね。基幹系の細かい仕様が設計書に反映されず、更改で漏れるというパターンは今後も非常にたくさん出てくる問題だと思うので、効果的な対策を考えていかなければいけないと感じています。
  
• 特別レポート X-over Development Conference 2007の見どころ
• 9/7のカンファレンス説明。興味深いセッションも多いのだが、残念ながら夏休みで参加できず。クロスオーバーという視点は好感。ぜひ一発で終わらずに継続してほしい。
  
• 連載講座
• ［技術・製品スキル］
• システム基盤きほんのき 【最終回】 ケーススタディ／要素技術の活用法がカギ、ショッピング・サイトの基盤を作る
• 最後に「システム基盤をうまく構築するための3か条」という項があり、そこに書いてある「第2条 敵を知り己を知ること」が良い。ここでいう敵は業務アプリケーションの事ｗ。
  
• Windowsサーバーなぜこれができない 【最終回】 クライアントの設定管理／Active Directoryは割と煩雑、効率的な設定を押さえよう
• 興味の範囲外。パスです。
  
• ［システム構築スキル］
• 教えて！上流工程 【最終回】 ～ 基本設計編3 ～ データベース設計／コミット間違うと不整合にも、アクセス設計でデータ守る
• 特に目を引くものは無し。手堅い内容です。
  
• 図解で磨くプロマネ技術 【最終回】 品質評価報告書／報告書の表現、数字、項目から、担当者のごまかしを見抜く
• 苦い･･･苦すぎる･･･内容です。ごまかしを見抜くポイントを容赦なく指摘しています。まぁ、顧客に指摘されるよりは良いですが、勉強になります。
  
• ［ビジネススキル］
• コミュニケーション・スキル再入門 【最終回】 チーム内に相乗効果を生み出す／メンバーの個性を知り、自由な発想をチームの強みに
• キーワードは「ブレインストーミング」「TTW」「ソーシャルスタイル」「PCM」です。TTWはちょっとやってみたいと思わせるツール。ソーシャルスタイルとPCMは、以前より知ってはいますが実際の活用はちょっと難しい気がしています。
• 現場で役立つ実践「会議術」 【最終回】 合意を形成する／要求・欲求の掘り下げで、皆が満足する案を探る
• 納得感…会議全体を支配する雰囲気の醸成する方法が興味深い。
  
• コラム
• 永井昭弘のすごい現場 オンラインダウン発生！あの日、何もできなかった
• 濱本常義のここが危ない！ 情報に踊らされるな真贋見極める眼を養おう
• 奥井規晶のエンジニアのコンパス 自らの価値を貪欲に高め幸せをつかみ取ろう
• ココロとカラダの相談室 痛みを共有して仲間の死を乗り越える
• さすがに仲間が死んだことはナイ･･･
  
• ITエンジニア現代図鑑 第6回 「不注意 SE」現場に出ず事情も知らず、ユーザーの要求はねつける
• ありそうな話です。でも、自分も「現場主義」のつもりであっても、いつこういった不注意に陥らないとも限らない、と自戒の念を込めて読みました。
  

勉強ノート

結城浩さんの日記から。

勉強ノートを読み返す。勉強になる。 勉強ノートといっても、実際のノートではなく、 コンピュータのファイルになっている。 それをプリントアウトするのである。 最近は手描きの図をスキャナで取り込むようにもしている。 必要に応じてプリントアウトするのだ。 ちょっと出かけるときなどに勉強ノートをプリントアウトして ポケットに突っ込んでいく。 電車の中や、バスの待ち時間、食事をしている間などに、 その勉強ノートをちらちらと見る。 たいへん面白い。当然である。 参考書を読んで自分がなるほどと思ったことだけを抜粋しているからだ。 面白くないわけがない。濃縮なるほどジュースである。
結城浩の日記■濃縮なるほどジュース 2007年8月21日 21:53

私もここ数年、「勉強ノート」を取るようにしています。しばらくは紙のノートに書き込んでいたのですが、半年前からはGoogle Docsに移行しました。自宅でも職場でも、外出先でも閲覧できるのは便利です。

内容は結城さんと似ていますが、基本的には本や受講したセミナーやその他勉強した事の抜粋です。読書ノートとしては、目次を全て転記した上で、付箋を貼った箇所の内容を書き写しています。読書としてはちょっと効率が悪い(一度読んだ後、書き写しの作業が必要)のですが、ここまでやると、本自体を処分してしまえるのが良い点です。

基本的に本は手元には残しません。そもそも公立図書館で借りてくる事が多いのですが、購入したとしても、読了後はブックオフなどに売却してしまう性格です。まぁ、これは「世の中にはまだまだ未読のスゴイ本がある。よって、すでに読んだ本を読み返している暇はない」と考えているからなんですけど･･････

オープンコミュニティ

中部地方でJava-Edgeというコミュニティを立ち上げるなど、最近大活躍の、ちささんのBlogより。ちなみに私は応援するスタンスです。知人というだけではなく。

What's inspire me ?: 今日はすごく嬉しいことがありました。すごく小さいことかもしれないけど、私にとっては本当に嬉しいできごとでした。人と人、技術と技術、コミュニティとコミュニティがつながるって本当にすばらしい。 最近は、現実と理想のギャップに苦しんで、ほんっと毎日泣いてる（ｗ
大多数の意見
- 現実・現場では役に立たない。
- 理想論だ。
- 説明責任を果たしていない。
ごく少数の意見
- ギャラもらってブログ書いてるんですか？
- ファンです。
- センスがあるよね。

実際にどんなことになっているのかはわからないのですが、批判的なメッセージもあるみたい。負けずにどんどん進んでいってほしいと思っています。

自分の周りを見渡してみると、社内も社外も比較的オープンコミュニティに開かれている感があるのですが、まだまだ世の中的にはそうではないんでしょうかね。

通勤時間の使い方

（これは携帯電話からの投稿テストです）

おはようございます。今日は通勤電車からの投稿です。せっかくなので、私の通勤時間の過ごし方をご紹介してみます。

■定番通勤アイテム
ipod
公立図書館で借りた本
携帯電話
ペンポッド（携帯電話のストラップに付けたミニボールペン）
ロディアのメモ帳

■過ごし方
バス待ち時間に携帯で仕事関係のメールチェック
バスの中で今日の日経新聞のポッドキャストを聞く
昼間にやるべき事を思い出したらメモ帳

電車の混雑がひどくなければ読書
ひどければ音楽を聞くか、ポッドキャスト。最近のお気に入りは日経ビジネスのものと、Listen-IT
スキマ時間には、はてなブックマークの注目エントリーをチェック。仕事に役立ちそうなものはあとで会社で見る。

あとはブログやメールに使うタネ文を入力。これは自分にメールしてPCで再利用。

PFP関東ワークショップ#7に参加してきました

先週の金曜日に、PFP関東ワークショップ#7に参加してきました。PFPは、Project Facilitation Project(プロジェクトファシリテーションを推進する会）という、「プロジェクトファシリテーションとは何か、またそれをどのように実プロジェクトで実践できるかを考え、業界に普及させていくことを目的としている」コミュニティです。今回で通算3回目の参加となりました。ちなみに15分ほどの遅刻です。会議が長引いた……

というわけで、以下参加レポートです。

■「SPES2007」ワークショップ開催報告
ソフトウェアプロセスエンジニアリングシンポジウムに、PS研究会さんと共同で発表を行ったということで、PFPとしての開催報告とふりかえり・考察の発表がありました。PFP Wikiにもレポートがあがっていますが、外部から見たPFPについていろいろと興味深い話がありました。

PFPやオブジェクト倶楽部に代表される、Agileな雰囲気のコミュニティに参加をしたり、Engineer Mindなどの雑誌を読んでいる比較的若手～中堅のエンジニアにとっては、PFPで使われているツールやフレームワークは馴染みのものです。KPT(Keep Problem Try)をグループで考えまとめるという作業も、別に抵抗はありません。
しかし、これはあくまでコミュニティの中の話であって、SPES2007でワークショップを行うにあたっては、いろいろと苦労があったという話でした。PFP Wikiに写真が掲載されていますが、ワークショップ参加者は組織でプロセス改善を担当されている方ということで、平均年齢も高そう。

ついつい使い慣れているからといって、チームへの新しいツールの導入は相当に注意する必要アリ、というのが個人的な感想です。
ちなみにKPTをご存知無い方は、@ITのこの記事をご覧ください。

■「効果的な自己紹介をみんなで体験しましょう」
PFPのメインは参加型のワークショップです。というわけで、今回はあまのりょーさん・ふるふるさんによる「効果的な自己紹介」についてのワークです。

• やったこと
• 知らない人とペアになる(会話禁止)
• 相手の名前やプロフィールを想像して紙に書く(3分)
• 3分間集中して相手に自己紹介をする(質問不可)
• 小まとめ
  
• 白紙の状態から他人の事を考えるのは非常に難しい(時間も長く感じる)
• プロジェクトでは長期間メンバーと過ごす。お互いを知るために「自己紹介」にもっと時間をかけてもいいのでは?
• 偏愛マップを使った自己紹介
  
• テンプレートを使って偏愛マップを書く(15分)
• 偏愛マップを使った自己紹介(10分)
  
• 偏愛マップを使った自己紹介まとめ
  
• カラフルにすると楽しい!
  
• 相手に短時間で共感できる
  
• 知られたくない事は書かなければよい
  
• プロジェクトのwikiなどにアップしておけば後で参加するメンバーにもよい
  
• 良い自己紹介の方法のグループディスカッション(15分)
  
• 発表(15分)

偏愛マップとは、自分について書いたマインドマップの一種です。齊藤孝さんの本が有名なので興味があればどうぞ。わたしは既読でしたが、自分で描くのは初めてでした。今回は初めての人でも偏愛マップを書き易いように、あらかじめ中央部分が書き込み済の用紙が配られ、これに書き加える形式となっていました。
作成時間は限られているので少し不安でしたが、はじめてみると意外に書き進むものです。私の偏愛マップはこんな感じになりました。

偏愛マップを使うと意外に浅く広くの表現になるので、自己紹介では意外な共通点やサプライズの演出ができるので、口頭での自己紹介にくらべてプレゼンテーションしやすいな、というのが感想です。

また、あたりまえですが描かれている、つまり「見える化」されているので、相手に合わせて戻ったり、先に進んだりがしやすい。

あまのさんのプロジェクトでは実際にキックオフで偏愛マップを使った自己紹介を取り入れているそうです。準備や導入は大変そうですが、プロジェクトメンバーは一定期間(下手をすると)家族より長くの時間を過ごすわけで、もっとお互いを知る事に手間と時間を掛けてもよいのかな、と考え初めています。

偏愛マップ―キラいな人がいなくなる コミュニケーション・メソッド

posted with amazlet on 07.08.10

斎藤 孝
NTT出版 (2004/03/27)
売り上げランキング: 18302

Amazon.co.jp で詳細を見る

要求考古学 Part.2

前回に引続き、6月末の要求開発アライアンス 勉強会合宿で見つけたキーワード「要求考古学」に関する考察です。いくぶん妄想(暴走)気味ですのでご注意を。記載内容は私の考えであって、内容は誤っているかもしれません。

■近代的要求考古学

現行システムを「観察する」ことによって得られる情報は、限られています。というわけで、より深く調査をするのであれば、「分解する」する必要があります。というわけで、仮にこれを(前回評した古典的要求考古学に対するものとして)近代的要求考古学アプローチとでも呼ぶことにします。

「分解する」とひとことで言っても、実際のところは設計作業をもういちど行う、つまり「再設計する」事に等しく、ひょっとしたら「分析」「解析」というキーワードが適切かもしれません。

言うまでもなく、現行システムを完全に解体し設計書を全て再作成することは困難なだけではなく、その労力を考えると現実的ではありません。また、次のプログラミングの基本法則により、実際の作業は見かけよりも難しいと言えます。引用元は書籍化もされている、システム開発に関する有名BlogのJoel on Softwareからです。

プログラマがいつでも既存のコードを捨てて最初からやり直したいと思うのには、ちょっとした理由がある。その理由というのは、古いコードがクズだと思っているからだ。そしてここに興味深い観察事実がある。 彼らはたぶん間違っている。 彼らが古いコードがクズだと思うのは、プログラミングの基本法則のためだ。

プログラムというのは書くのより読むほうが難しい。

これがコード再利用がかくも難しい理由だ。あなたのチームのプログラマが、文字列を分割して配列にするための関数に、みんな違うものを使っているのはこのためなのだ。彼らが自分で関数を書いている理由は、古い関数をどうやって使うのか調べるよりも、そのほうが簡単だし、楽しいからだ。

Joel On Software/Joel Spolsky

■分解する方法について

さて、分解の方法としては、いくつかの戦略を取る事ができます。それぞれのメリットやデメリットを整理してみます。

• データ中心アプローチ
• 入力(人間系や外部システムから)から出力(画面や帳票、外部システムまで)まで、データの流れを中心に分解する方法です。一般的にはデータフローダイアグラム(DFD)を作成していく形になります。(要求開発アライアンスの提唱する開発方法論 Openthologyでは、UMLクラス図をカスタマイズしたTFP分割手法を提言していますが、これも一種のデータフローダイアグラムと言えます)
• メリット
• システムの堅牢性、確かさの側面で深く分析がされます。
• 機械的な作業であるため、人海戦術を用いて実行することができます。
• 誤解の入る余地があまりありません
• システム対象業務固有の知識を、あまり意識する必要がありません。
• デメリット
• 対象の規模にもよりますが、コストと期間を要します。
• システムの使いやすさや、特徴は表現されません。
• 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。
• 機能中心アプローチ
• システムの有する機能(メニューや機能名)中心にシステムの構成要素を分解する方法です。結果として、システムユースケース図に近い成果物を作成する事になります。
• メリット
• システムの使いやすさや、特徴が現れます。
• 利用者にもわかりやすい分析アプローチのため、分析作業やレビューに参加してもらうことが容易です。
• デメリット
• データ中心アプローチと異なり、分析に漏れが発生する可能性が高くなります。これは、データと異なり機能は隠されたり、分散されている事があるからです。
• システム対象業務固有の知識が必要です。用語集などを作成しなければ、誤解を生じる可能性があります。
• 構造中心アプローチ
• システムを構成するプログラムの構造を中心にした分析です。一種のリバースエンジニアリングに近く、コードを元に分析を行います。データライフサイクルの観点でプログラムとデータの関係を整理する(CRUD図)、プログラムの構造を図式化する(UMLクラス図等)ことになります。
• メリット
• 作業の機械化が可能です(実際に、このような分析を行うツールは様々なものがあります)
• デメリット
• 既存システムの品質(保守性やコードの可読性、充分な共通化)によっては、結果が使い物にならない可能性があります。スパゲティプログラムを分析しても、わかる事は限られています。
• 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。

ここまで書いて息が切れました。というわけで、次回に戦略面での考察を続けます。

要求考古学

この間の要求開発アライアンス 合宿勉強会のワークショップの中で出てきたキーワード「要求考古学」について考えています。

■要求考古学の定義

考古学は人類が残した痕跡(例えば、遺物、遺構など)の研究を通し、人類の活動とその変化を研究する学問である。

Wikipedia:考古学より

を参考とするならば、要求考古学の定義は次のようになるかと思います。

要求考古学は設計者が残した痕跡(例えば、現行システム、設計書、マニュアルなど)の分析を通し、本来のシステム要求とその変化を研究する学問である。

要求考古学が必要とされるシチュエーションは、次のようなケースをぼんやりと考えています。

• 現行のITシステムに新たな機能(要件)を追加する必要がある。
• 現行のITシステムが何らかの理由で維持困難となり、現行システムの要件を充足した新システムを構築しなければならない。
• ITシステムのデータを再利用する目的で取得し、何らかの処理を行なう必要がある。

こういった作業の際に、システムの当初の要求(要件)が不明である場合(当初の関係者がいない場合を含む)には、作業者は要求考古学を用いて要求発掘を行う必要があります。

■古典的要求考古学

さて、最も簡単なアプローチは何でしょうか。それは「観察する」です。つまり、

• 現存するドキュメントを読む
• 動かしてみる
• プログラムを追いかけてみる

ことにより、なぜそうなっているのかを類推するアプローチです。

実際にITシステムの保守フェーズでは、こういったアプローチは一般的に行われていると思います。ちょっとした機能の追加を小規模に行う場合には、適用可能な方法です。

しかし、このアプローチには、2つの問題があります。

■効率の問題

ITシステム開発では、「仕様の爆発」という現象が発生します。

真実26.仕様定義フェーズから設計フェーズに移るとき、膨大な数の「派生仕様(derived requirements:仕様を具体的な設計方式にブレイクダウンする場合、設計方式に対する要求仕様)」が生じる。これは、問題解決プロセスが複雑なために発生するもので、この設計設計の量は元の仕様の50倍になることもある。

ロバート・L・グラス ソフトウェア開発55の真実と10のウソ より

これはつまり、当初の要件が、最大で50倍の文書等に分散してしまうということを言っています。実際にはここまでの爆発はあまりないと思いますが、それでも、爆発した仕様の破片から、当初の要件を導き出すのは効率的ではないと言えます。

■正しさの問題

もう一つの問題は、現行システムを観察しても「正しい要求」を導き出せない事があるという点です。これには二つの理由があります。一つはソフトウェア開発特有の原因です。

真実27.ソフトウェアの開発において、ベストの解法が１つしかないことは、まずありえない。
真実28.ソフトウェアの設計は、複雑で反復が必要なプロセスである。従って、最初に考えついた設計方式が間違っている可能性は高く、最適解ではない。
ロバート・L・グラス ソフトウェア開発55の真実と10のウソ より

つまり、今見えている仕様が最適解であるとは限らないのです。その仕様を元に当初の要求を考察したとして、本当に正しい要求に立ち戻れるかは大きく疑問があります。

また、もう一つの問題点としては、現行システムが「当初の要求ではなく、要求の代替策を表象している」可能性があることです。現行システムを最初に開発した時には、何らかの理由で要件を満たすことができず(例えば、パフォーマンス等の問題により)、より望ましくない要件(例えば計算を簡略化するなど)が採用されている場合、観察によって当初の要件が得られることはまずありません。

というわけで、改めて書き下してみると、古典的要求考古学は問題点が山積みです。長くなってきたので、次回は別のアプローチを考察してみようと考えています。

ソフトウエア開発 55の真実と10のウソ

posted with amazlet on 07.07.09

ロバート・L・グラス 山浦 恒央
日経BP出版センター (2004/04/08)
売り上げランキング: 113029

Amazon.co.jp で詳細を見る

要求開発アライアンス合宿レポート その２

というわけで、前回に引続き先日行った、要求開発アライアンスの勉強会合宿「要求開発 実践からのフィードバック」のレポートです。個人的なメモも兼ねているので、一部わけわかんなかったらごめんなさい。2日間の合宿の1日目のレポートはこちらです。

さて、前日の講演と宴会(反省会・猛省会)が終わった後ホテルに帰ったのは午前3時orz...。ギリギリまで寝て、翌朝バイキング形式の朝食を済ませた後、さっそくのワークショップです。

■ワークショップ１『要求不在自慢 ～「失敗に学ぶ、要求開発実践のためのポイント」』
要求開発アライアンス理事の細川さんによるプレゼンテーションとラウンドテーブルです。

失敗学のすすめ

posted with amazlet on 07.07.06

畑村 洋太郎
講談社 (2000/11)
売り上げランキング: 34241

Amazon.co.jp で詳細を見る

私はまだ味読なのですが、「失敗学」を参考に、特に上流工程における失敗についての対策を考察するという筋立てで、参加者によるディスカッションをしました。細かい内容は非常にナマナマしいのでご紹介できないのですが、いろいろと興味深いキーワードも沢山出ました。以下メモです。

• 日本のITにおけるユーザ「没」主体と業界構造
• 米国では、ユーザ企業の役割として「CIO」「アーキテクト」「PM」「専門技術者」がいて、これを支援する形で外部のベンダーや専門家・海外技術者が参加するというプロジェクト形態となっている。
• 日本では、ユーザ企業の役割は未分化で、「CIO」もいない場合が多く、また情報システム部門が曖昧に「アーキテクト」「PM」「専門技術者」の役割を担っている。そして、外部のベンダーが対応して二次請けとしてソフトウェアハウスや海外技術者を利用するという、多段構造になっている。
• 日本の「総合的なIT投資意欲」の低さ
• ITへの投資額などは大きいが、CIO設置比率や経営陣のIT重要性理解、攻めのIT投資など総合的に比較すると、海外に比べて非常にランキングが低い。(ガートナー 2007/5)
• 日本人は「失敗を受け入れ難い」(?)
• 本来はデジタルに「成功」「失敗」が決まるわけではない。「失敗」ではなく「10%成功」「30%成功」という状況を受け入れて、より成功するための戦略を。
• うまくいかないパターン
• 要求不在
• ビジネス目的と関係の無いゴールがあらかじめ設定されている
• ステークホルダー不在(肝心な利害関係者がプロジェクトにいない)
• フォーマルな開発方法論の適用やコタツモデルの導入で失敗を防止
• 要求発掘(要求考古学)
• 最近増えて来ているシステム更改では、要求を定義したり開発をするのではなく、考古学的に発掘しなければならない事がある。
• 仕様書がない、とか
• 仕様変更の繰り返しの結果、当初の目的が失われている、とか
• 面倒になって、全てを移植しても、実際には使われない、とか
  
• 非常に困難そして非効率。
• 別のアプローチの検討が必要

約90分のセッションはあっというまに時間切れ。参加者は10名くらいだったのですが、かなり熱いディスカッションとなりました。個人的には「要求発掘」について響く事が多く、もうすこし考察してみたいと考えています。

なお、同じ時間には別の部屋でもセッションが行われています。『布教の時間：～ビジネスモデリングの有効性：価値のある見える化に向けて～』『おまかせ隊長！よだばなし』全部に参加できないのが残念です。

■ワークショップ２『実演ライブ！　要求分析ツリーがみるみるできる』
続いてのセッションは、要求開発アライアンス理事長の山岸さんの実演ライブ。要求分析ツリーの作成を、コンサルタントとユーザ企業担当者の掛け合いロールプレイで実際にやってみるというものです。個人的にはトークの流れや質問の仕方について非常に刺激になりました。また、要求分析ツリーは適当なツールが無いのが悩みで、ExcelやPowerPointを活用していたのですが、ここではJUDEのアクティビティ図を使って作成していました。なるほど！

このセッションもあっという間に時間が尽きてしまいました。別の部屋では『ハッピー！ホッピー！TFP！』『体験！君がオブジェクトだ！』というセッションが行われていましたが、これも超気になります。

ここでだいたい12時です。最後にクロージングミーティングを全員で行って合宿は終了。睡眠不足気味ですが、非常に充実した2日間となりました。

要求開発アライアンスで合宿を行いました

またもや更新間隔が空いてしまいましたが、先日金曜日の夜から翌日の昼まで、都内某所のホテルのカンファレンスルームを利用した合宿形式の勉強会に参加(?)してきました。要求開発アライアンス「要求開発　実践からのフィードバック」というタイトルです。というわけで、記憶が薄れる前にレポートします。

■基調講演「開発上流工程の歩き方」
春から新たに要求開発アライアンスの理事として参加いただいた中山さんの発表です。ユーザ企業のシステム部門の目からみた上流工程に関するお話です。ベンダ企業に勤める私としても、とても参考となるお話がたくさんありました。
なお、着色している部分は私の個人的な感想ですのでご注意ください。

• ほとんどウォーターフォール(WF)は採用していない。
• 開発はRUP風(?)に、「準備」「方向付け」「推敲」「作成」「移行」の5つのフェーズに分けられているとのこと(反復型開発)。
• 確かに、開発ベンダから見ればWFは御しやすく、いろいろと都合の良い(契約や、コスト・仕様変更などの取扱い)のですが、ユーザ企業の観点からすると当然だと思います。その割には世の中的にはWF型のプロジェクトが多いのはなぜなんだろう･･･
• ポリシーとして「プロジェクトサイズ」をコントロールする。
• プロジェクト期間は12ヶ月以内と制限しているそうです。これは、大規模プロジェクト化した場合のリスク対策に加えて、技術進歩や世の中のスピードへの対策としてとのこと。
• 超えてしまう場合は次フェーズに見送るということです。
• 情報システム部門の役割
• ユーザ部門と、ベンダの間のメッセンジャーではない。
• 企画・設計を行う。
• 手段は「モデリング」である。
• 新システムの前提
• 単純コンバージョンのシステム更改を除き、ポリシーを決めている。
• 業務のBPRや組織改革を伴わなければいけない。
• 新たなITを取り入れたものでなければいけない。
• このビジョンは、わかりやすさと明確さでちょっと感動した。
• テスト駆動
• 情報システム部門としては、コードや設計レビューの実施は現実的では無い。その代わりにプロジェクト初期からテストデータ作成に参加し、実業務に近いINデータとOUTデータによってシステム検証に参加する。
• スケジュール管理
• 遅れが2週間を超えた時点で再スケジューリングを実施。
• 再スケジュールは科学的根拠に基づく次工程移行の短縮による。
• あたりまえなのですが、それをやっているということ、およびユーザ企業の方から聞けるということにクラッとしてしまった･･･。

他にもいろいろな気づきやヒントをいただける講演でした。内容そのものもそうですが、全体的にはシステム部門としてのポリシーやビジョンがハッキリとしている事に感動を覚えました。あたりまえですが、ユーザ企業は「システムを導入すること」が目的ではなく、「システムを使ってビジネスで成功すること」が目的です。しかし、プロジェクトが開始されると参加者の目標が「システムを導入すること」に摩り替わってしまい、結果として使えないシステムや使いにくいシステムが生まれる原因になりがちです。これに対する対策として、まずポリシーとビジョンをしっかりと定めるというのが、とても効果的だというのが感想です。

■その後
1日目は基調講演後、ホテルのパーティルームでの反省会、居酒屋に移動しての猛省会、そして……という感じでした。私は普段は自宅が遠い為に途中で失礼することが多いのですが、この日はホテル泊なので時間を気にする必要が無い！ というわけで、とてもリラックスして参加できたのが良かった……

長くなりそうなので、合宿2日目のレポートは次回にまわします。翌日は9時からワークショップを2セッションです。

Googleアプリでネット上に書斎を

Lifehacking.jpさんののエントリ「Google アプリだけの生活 (Day7)」が興味深かったので関連ポストです。別に真似をしているわけではありませんが、私もかなりGoogleアプリが知的活動の中心となりつつあります(さすがに仕事にまでは利用できていませんが)。個人的にはネット上の書斎として、非常に便利に利用しています。具体的には、個人メールは全てGmailに一本化、これに加えて個人的な学習などのノートをほぼ全てGoogle Docsに集約、ブックマークと簡易なToDoなどは、iGoogleで管理しています。

逆に、Google以外で使っているサービスはRSSリーダー(livedoor Reader)とソーシャルブックマーク(del.isio.us)くらいです。del.isio.usに登録したブックマークはiGoogle上に表示しているので半分くらいは統合済みですが・・・。

個人的に気に入っているのは、いろいろなノートをGoogle Docsに集約している点です。技術書やビジネス書はあまり購入せず、図書館や古書店で入手し、読み終わったらすぐに返却や処分をしてしまう性格で、その代わりにかなりしっかりとノートを書くことにしています。今までは紙だったり、PC上のローカルファイルなどに分散してしまっていたのですが、Google Docsに登録しておけば、会社でも自宅でもアクセスや検索が可能ですし、さらに追記をすることもできます。例えばこんな感じです。
他にも、例えばコミュニティ運営で共有すべきちょっとしたドキュメント(例えばサイトの更新方法など)についても、Google Docs上で共有しておけば相互に更新できたりと非常に便利に使ってます。

電子メールはGMailに移行して2年以上経ちますが、件数がかなり蓄積されてきたので、GMailの特徴である検索と、2.8Gの容量が生かされてきたように感じています。

というわけで、現時点では、仕事でOffice文書を作成する以外の個人的な書き物のほぼ全てはGoogleアプリを利用するようになっています。これは良く考えてみるとスゴい。だって、7年前には、ネット接続というと自宅からはダイアルアップでプロバイダに接続していたわけです(常時接続と言えば、大学と会社だけでした)。

しかし、ここまでGoogleに依存してしまうのもちょっと恐ろしい気がして、そういう意味ではそろそろバックアップも考えなければいけないなぁ、と考える今日この頃です。

現在購読しているフィードの数

久しぶりに、RSSリーダーのフィードを整理してみました。

ちなみにRSSリーダはいろいろ試してみましたが、現在はlivedoor Readerに落ち着いています。動きがキビキビしている点と、各種ショートカットが充実している点、あとはモバイル対応しているというところが気に入っているポイントです。
あとは、ご存知の人も多いと思いますが、このサービスを開発しているのが最速インターフェース研究会のma.laさんだというのも理由です。別に面識があるわけではないのですが、注目すべきGeekの一人だと考えています。

話がそれましたがフィードの整理の話に戻すと、とりあえず過去6ヶ月以上更新されていないフィードを削除して、残った数は143個でした。個人的にはもう少し多いと思っていたので意外。

私はほとんど能動的にネットサーフィンをしないので、基本的に追いかける情報はこの143フィードと、あとは、はてなブックマークの人気エントリだけです。はてなブックマークの人気エントリはPCで参照することはほとんど無く、もっぱら携帯から気分転換やちょっとした移動時間に参照する程度です。

ネットワーク上の膨大な情報は、すでに検索困難な量まで増加しています。Googleなどの検索サービスによって、インデキシングは進んでいますが、そもそも検索すべき情報の存在を知っていなければ、検索することすらできません。
というわけで、私のこの143のフィードは、一種の私の身代りエージェントという感覚で、それぞれの得意分野と検索方法で、世界を探検して結果を私に報告してくれるという感覚で利用しています（もちろん、実際にはBloggerのみなさんが記事を書いていらっしゃるわけですが。多謝）。

将来的には、技術が進歩してAIなどに「私の興味がある分野のリサーチを実施してまとめ、私向けのBlog風のものを作成してくれる」ようになったらいいな、と思いますが、この実現にはもう少し時間が必要でしょうか。plaggerやyahoo pipesなど気になるテクノロジは出現し始めています。

楽しみだなぁ。未来が楽しみな、今日このごろです。

ソフトウェア開発見積もり

またもや更新間隔が空いてしまいました。けっこうプロジェクトで苦しんでいます。うーむ。
現在直面している問題は「ソフトウェア開発見積もり」です。うげげ。
というわけで、改めて色々と整理をしてみるエントリになります。興味の無い人はスルーして下さい。

まずは、「ソフトウェア開発見積もり」の大前提。セントラルドグマかもしれないけど。

「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」

• コストは人数と歳月の積に比例するが、仕事の進み方は必ずしもこれとは一致しない
• 人数と時間には互換性は無い(9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない)
  

フレデリック・ブルックス「人月の神話」

「プロジェクトを大失敗させる原因は二つある。ひとつは、見積もりミスだ」

• 楽観的な見積もり：見積もり根拠があいまいで、必要な要素をきちんと見積もっていない
• 顧客側による(一方的な)コスト削減要求
• ムリなプロジェクト
  

ロバート・L・グラス「ソフトウェア開発55の真実と10のウソ」

あと、個人的に重要だけど忘れられがちなのは次の定理(?)

「コストやスケジュールを予測する場合、まずソースコードの行数を見積もる・・・というのはウソ」

• コストやスケジュールより、LOC予測する方が難しい(1980年代に証明済み)

ロバート・L・グラス「ソフトウェア開発55の真実と10のウソ」

現実の見積もり方法に関してですが、とりあえずWebで概要をつかむには日経ITProさんの上流工程AtoZというサイトが良い感じです。

さて、ソフトウェア開発見積もりですが、個人的な理解は以下の通りです。
Step1. まず、開発しようとしているソフトウェアの規模を見積もる。
Step2. 見積もったソフトウェアの規模を実現するための、作業を見積もる。
これをごっちゃにすると、かなり神頼みの見積もりになってしまうというのが個人的な意見です。

■ソフトウェアの規模見積もり
これも個人的な知識のまとめですので、間違っているかもしれませんが、ソフトウェアの規模見積もり方法は以下の3つが代表的です。

• 勘と経験と度胸法(通称KKD法)
  基本的に見積もった人がどれくらい信用できるかに依存しますが、かなり的確な見積もり手法です。そもそも、作ってもいないソフトウェアの規模なんて想像し難いワケですから。ただし、個人的には以下に注意しています。
  「見積もった人が冥界にお住まいの場合」→1日が20時間くらいの計算になっている可能性あり。
  「見積もった人が勉強不足で、今回のアーキテクチャをよく分かっていない」→論外。しかし、ありがち。
  

• LOC見積もり(開発コードの行数を予測する)
  まったく新規に開発するソフトウェアを見積もる場合には利用してはいけない見積もり方法です。(なぜなら、LOC自体を予測することが非常に困難だからです)
  とはいえ、個人的にはコーディング工程の見積もりのチェックには使っています。
  

• 　ファンクションポイント法
  大変手間がかかる上に、所属組織で過去のプロジェクトも同様に見積もっていないと厳しいですが、精度はかなり高い(と一般的には認識されている)手法です。
  すっげー大変なので、かなりガッツリと作業時間を取らないと出来ません。
  

• ユースケース法
  システムの使われ方(ユースケース)に着目した見積もり方法。わかりやすいのですが、精度は微妙な気が。ある意味、将来作るマニュアルのページ数から見積もりを類推するようなものです。
  

うーん、最近マトモに見積もりの勉強をしていないので、3年くらい前の知識で時間が止まっている感じ。というわけで、再勉強することを決意。

■参考となりそうな資料

ソフトウェア開発見積りガイドブック―ITユーザとベンダにおける定量的見積りの実現

posted with amazlet on 07.05.27

情報処理推進機構ソフトウェアエンジニアリングセンター
オーム社 (2006/05)
売り上げランキング: 85647

Amazon.co.jp で詳細を見る

→なか見検索に対応しているので、立ち読みができます。

ソフトウェア見積りのすべて―規模・品質・工数・工期の予測法

posted with amazlet on 07.05.27

Capers Jones 富野 寿
構造計画研究所 (2001/03)
売り上げランキング: 245837

Amazon.co.jp で詳細を見る

→値段高すぎ！個人じゃちょっと買えません。とはいえ、ロバート・L・グラス「ソフトウェア開発55の真実と10のウソ」でも引用されていたので、重要だとは思うのですが・・・会社のどこかに死蔵されてそう。

ソフトウェア見積り―人月の暗黙知を解き明かす

posted with amazlet on 07.05.27

スティーブ マコネル Steve McConnell 田沢 恵 溝口 真理子 久手堅 憲之
日経BPソフトプレス (2006/10)
売り上げランキング: 36480

Amazon.co.jp で詳細を見る

→というわけで、こちらをAmazonでポチッと購入してみました。本当はこの勉強会に出たかったんですが、知った頃には終わってしまっていた・・・

IT業界の人はITを知っているのか

更新をサボリ気味でごめんなさい。いろいろと忙しくて、万事滞ってます。
というわけで、本のご紹介ですが、すいませんワタシはこの本を読んでいません！という、ヒドい展開です。

デジタル・ワークスタイル―小さなことから革命を起こす仕事術

posted with amazlet on 07.05.14

徳力 基彦
二見書房 (2007/04)
売り上げランキング: 149

Amazon.co.jp で詳細を見る

本の著者の徳力さん(一度セミナーでお話を聞いた事がありますが素敵な方です)が、Modern Syntax Radio Show Podcastで喋っていたのを今朝の通勤時で聞いたのですが、この本は「Blogなどを読んだりしない、ネットを使っていないビジネスマン向けの本」ということです。Blogなどで情報収集をできている人には知っている話ばっかりだそうなので、ちょっと私は購入は見送っています。

これもPodcastで話題になっていましたが、IT企業やその周辺で、いわゆるシステム開発を行う人々は、意外というか驚くほど最近のネット事情を知らなくて、ビックリします。

この間は、「情報収集の秘訣を教えて下さい」と若い子に聞かれたりして、びっくりしました。
普通にRSS-Readerで気になる人と有名な人と知人のBlogをチェックして、SNSを読んで、del.isio.usかはてブの人気エントリーを暇つぶしにたまに見て、あとは人に会って話を聞けばいいんだよというような話をして、タスク管理はGTDだねというような話をしましたが、実際問題こういったキーワードについても、ほとんどの人がひっかかりません。書いてて悲しくなってきた！

というわけで、まだまだネットを活用していない人にはお勧めな気がします。
私の知り合いの人は、ぜひ読んだら感想を教えて下さい :-)

PFP関東ワークショップ#5に行ってきました

ポストが少し遅れてしまいましたが、4/24にPFP関東ワークショップに参加してきました。
PFPとはProject Facilitation Projectの略で、プロジェクトファシリテーションを推進する会という意味だそうです。

ファシリテーションに興味を持っている今日この頃、What's ispire me? のちささんにお願いして参加させていただいた次第です。
全体としては、やはりPFに興味を持っているメンバーが仕事の後に集まっているということもあり、アイスブレーク、発表、ワークショップ全てにわたって、ポジティブフィードバックに溢れる集まりということで、いろいろなヒントだけでなく、元気も手に入れることができるワークショップであったというのが感想です。

というわけで、以下レポートになります。

■会場は、ATLシステムズさんのオープンスペース。他のイベント等でも何回か利用させていただいたことがありますが、素敵なスペースです。また、喫煙所が素敵なのは、喫煙者にしかわからない秘密・・・・・・。

■プレゼンテーションの切替えをしている間に、簡単なアイスブレークのためのエクササイズを。こういった技を身につけておくのはとても重要ですね。

■最初は、古家さんによる事例紹介。プロジェクトへのPFの導入に関する発表ですが、とても参考になりました。全体的にPFに前向きではない状況の中での、PF利用ということで、いろいろヒントをいただきました。特に良かったのが「二次会」というキーワード。
ドライブ感のないプロジェクトへの朝会の導入はわたしもよく行うのですが、やっぱり所要時間が長くなってしまいがちです。というわけで、この事例では、気になる話題が出た瞬間に「二次会！」と声を上げて、「朝会の二次会」を別途やるという・・・・・・これは良いアイデアだと思いました。

■というわけで、事例紹介の後はワークショップです。今回のテーマは「プロジェクトにおいて良い雰囲気とは」についてのグループディスカッション。５人ずつにわかれて着席し、最初は『平鍋メソッド』で自己紹介を行います(この手法、WEB上で公開されていないようなので、とりあえず詳しく書かないでおきます)。その後は、

1. 「プロジェクトにおいて良い雰囲気ってどんなとき？」をポストイットに書いたあと、皆で発表してまとめる。
2. まとめた「プロジェクトにおいて良い雰囲気ってどんなとき？」について、実際に皆が「出来ているか」「出来ていないか」を集計
3. ひとつだけ「プロジェクトにおいて良い雰囲気ってどんなとき？」を選んで、「なぜできていないのか」「どうすればできるようになるか」「できたらどうなるか」をディスカッション
4. 最後に、個々人が今後やることを、自分のカードに書いて持ち帰る

という流れでした。写真は、わたしの着席していたテーブルのディスカッション時に使ったワークシートです。なかなか盛り上がり、話は二転三転しましたが、楽しく時間を過ごすことができました。

■PFPの集まりの良いところは、非常に前向きであるということです。今回のワークショップのテーマもそうですが、「プロジェクトの○○を良くする」ということについては、なかなか普段集中して考えたりディスカッションする機会がありません。今回のテーマ「プロジェクトにおいて良い雰囲気とは」についても、皆で議論を行い「うんうん、そうだよね」「エーッ、それすごい！」という会話をしていく中で、わたし自身がとてもポジティブな気分になれたことが、とても良い体験でした。

システム監査技術者試験 振り返り

さて、既に数週間が経過してしまいまいしたが、情報処理技術者試験を受けてきました。賛否両論ある資格試験ということもありますが、個人的にはスキルの棚卸しと、学習姿勢を維持するための筋トレの一種として受験しています。

受験したのは「システム監査技術者」です。この区分は、通常のエンジニアとは少し異なる視点で、システム開発を論じており、試験の合否は無視するとしても、かなり興味深い学習だった、というのが感想です。

システム監査技術者とは

被監査部門から独立した立場で、トップマネジメントの視点で、情報システムが経営に貢献しているかどうかを、安全性、効率性、信頼性、可用性、機密性、保全性、有用性、戦略性など幅広い側面から総合的に調査し、あるべき姿を描くことによって自ら形成した判断基準に照らして評価し、問題点について説得力のある改善勧告を行う者
JITECのWEBサイトより

という定義というわけで、プロジェクトマネージャや、エンジニアとは立場が異なり、ユーザ側、もしくは経営側の人間として描かれています。

通常システム開発プロジェクトに参加していると、見える範囲はスポンサー(お客様の責任者)、ユーザー(お客様の担当者)、そしてプロジェクトメンバーや自社の管理部門などに限られてきます。もちろん提案時にはトップマネジメント(経営者)に会うことはありますが、それ以降のプロジェクト実施中に、あまり意識することはありません。まぁプロジェクトによるかもしれないけど。

こういったプロジェクトやシステムを、独立した視点でチェックし、問題点や改善方法を直接トップマネジメントに報告するのが、システム監査技術者の位置づけです。

Wikipediaなどを見ると「受験生は他の情報処理技術者試験とは違い、技術者と言うよりも経営者側に立つ人が多い。また、本来監査業務を独占業務としている公認会計士にも受験者・資格所持者が多い。」とありますが、私の意見としては、プロジェクトを外部から見る目を手に入れるという意味で、むしろエンジニア側も勉強する価値のある試験区分であると考えています。

私も参加している要求開発アライアンスでもおなじみですが、我々が意識しなければいけないのはビジネスに役立つシステムを、どうやって作るかということです。この時に忘れてはいけないのは、単にユーザの要求を満たし安価であればよいということではなく、管理の始点からも適切なシステムを作る必要があるということ。

システム監査技術者では、この管理の視点を得ることができるような気がしています。

さて、堅い話はこのへんにして、受験をふりかえってみたいと思います。
＜良かった事＞

• 学習期間は4ヶ月。受験申込直後から、午後の試験対策を中心に参考書と過去問をコンスタントにこなしていきました。これまでは過去問題中心の問題集で勉強することが多かったのですが、午後に小論文を書かなければいけないことから、試験よりも説明中心の「情報処理教科書 システム監査技術者(翔泳社)」を選択。結果、午後の試験はあまり苦しむことはありませんでした(得点がどうかはわかりませんが)。
• 私は普段はボールペン類しか使わないのですが、試験は鉛筆かシャーペンを使わなければいけません。今回は、シャープペンシルに加えて、太めに削った鉛筆を何本か持ち込み、問題文のマーキングや考えをまとめる時には、鉛筆を活用してみました。シャープペンシルだと、折れたり紙が破れたりがあるので、これは良かった。
  

＜悪かった事＞

• 今回の最大の失敗は、午前対策をうっちゃっていたことです。一応10年くらいこの業界で働いているので、大丈夫だろうと思っていたら、意外と新し目の問題が解けません。油断大敵。
• 会場の座席がキツイ。試験会場は池袋の某大学だったのですが、机とイスの間隔が狭い、動かすことのできない木製のイスがひどかった。クッションとか持ち込んだほうがいいかも・・・最近オフィスのイスが良くなってきているので、落とし穴でした。
  

ちなみに、自己採点は怖くてやってません。
忘れた頃に、合格通知が来ると嬉しいなぁ。

Input+Output and Community

偶然発見したCSS Niteというコミュニティの発表資料が素晴らしすぎて、感動したのでご紹介します。本質的にはWebデザインそしてCSSに関する内容なのですが、その末尾の「コミュニティについて」のくだりが、とても心に響いたのです。
Webデザイナー関連のコミュニティということもあり、資料もとっても洒落ています。















最近でこそ、日経SYSTEMSなどで「社外コミュニティで自分をのばす」という特集が組まれたりしてコミュニティ力の認知度は上がってきていますが、それでも自分の周りを見渡すとまだまだ浸透していません。これが本当に残念でならないのですが、何か良い手はないものでしょうか？

ネットを日本語化する

Firefoxのアドオンでこんなものを見つけました。
ネットを日本語化する：Japanize
これはすごい！
知らなかったのは私だけ？

最近海外のWebサービスを普通に使うのがあたりまえになってきました。
例えばソーシャルブックマークのdel.isio.usとか。
もちろん類似の国産日本語ツールも良いですが、海外のサービスも単にインターフェースが英語というだけで、メニューの英語も慣れれば気にせずに使えます。
とはいえ、普段と異なる操作をしようと思うと、英語のメニューやヘルプを解読するのは、ちょっとストレスです。

ネットを日本語化する：Japanizeをインストールすると、なんと代表的な(話題の)海外Webサービスを日本語化してくれます。
さっそくインストールしてdel.isio.usにアクセスしてみると・・・
おぉー、日本語です。

ちょっとした事なのですが、やはり自国語で表示されると安心感があるものですね。
というわけで、Firefoxユーザにはお勧めです。
他にもYouTubeやTwitterなど、いろいろなサイトに対応しているみたいです。

というわけで、ちょっと感動したエントリーでした。

質問を活用する

以下のBlogエントリを読んで思い出した事があるので、徒然と書いてみます。
TECH-moratorium：テクモラトリアムさん経由で発見した記事です。

先日米国で幾つかの技術系セッションに参加したのだが、その折に感じたことを書いてみる。
日本で技術系のセッションに参加すると、聴衆は結構皆行儀が良いというか、大人しくきちんと話を聴いている。ただし余り反応もなく、話に関心があるのかないのか、賛同しているのかどうかが、比較的分かりづらい (他人のことは言えないのだが)。
反応なくじっと聴いているので、うけなかったのかと思うと、事後のアンケート結果が割と良かったりする。
それに対して、米国のセッションでは、(中略)聴衆の方にもセッション自体の価値を上げる責任がある、と考えているようなのだ。
翔ソフトウェア (Sho's) Fujiwo の日記:質問を受ける態度

リクルートワークス研究所の所長である大久保幸夫さんの著書「仕事のための12の基礎力」では、職業人が20代までに身につけるべき力の一つとして「反応力(リアクション力)」というものを定義しています。



日本人は、(という書き出しは非常に抵抗があるのですが)国民性というか、学生時代までにリアクション力を学ぶ場面が非常に少ないためだと思うのですが、やはり反応力は少ないと思います。最近アジア圏のエンジニアさんと仕事をしているのですが、言葉の問題はあるものの、反応力が十分あれば、むしろ良好なコミュニケーションができるように思います。

ちなみに私は大学生時代にインプロのトレーニングを行う事によって、反応力がついたように思っています。

さて、「仕事のための12の基礎力」の「反応力」の章には、「講演会や勉強会で適切に質問するためのポイント」が書かれています。本自体は手放してしまったため手元にないのですが、ノートがあったのでそこからご紹介します。

大前提「質問するつもりで聞く」

1. あらかじめ講師がわかっている時には、その人の書籍や発言している内容などについて目を通しておき、講演では「ここが知りたい」というテーマを持って参加する
2. 講師の言うことを鵜呑みにせず、「本当にそうだろうか？」という疑問を持って聞く
3. 質問は大抵「反論」「確認」「展開」の３種類に分かれる。内容のどこかに疑問を持ったら素直にぶつけて講師の考えを聞く「反論」、私はこう理解したが、それでいいかと言う「確認」、「ではこういうケースはどうか」あるいは「具体的にはどういう事例があるか」等を聞く「展開」である。どの種類の質問をするかを、講演を聞きながら絞り込んで行く
4. できるだけ最初に質問する。始めは遠慮して手を挙げる人が少ないので指名されやすく、他の人に同様の質問をされてしまう心配もない
5. マナーとして始めに講演のお礼を言い、名前を名乗り、それから質問をする。一人で２つも３つも質問せずに、１つに絞ってするのがベター
6. 誰からも質問が出ない時は、講師が持ち時間の中で話しきれずに省略したところを質問してあげる
7. 全体の質問時間の中で質問ができなかったときは、講演終了後に演台に行って直接諮問してもよい。個別性の高い質問の場合はこのほうがいいときもある。

大久保幸夫「仕事のための12の基礎力」より

個人的には赤字のところが、覚えておくと良いテクニックだと考えています。

『ワークスタイル×ブログ』カンファレンスに行ってきました

あすなろBLOGさんの一周年記念イベント『ワークスタイル×ブログ』カンファレンスに行ってきました。懇親会は諸般の事情でパスしましたが、WEBだけでは触れられない生の声をライブで聞けたという意味で素晴らしいイベントでした。

以下感想メモです。

• 場所〜開場まで
• 大手町で散髪してから移動したのですが、時間の読みが甘くけっこうギリギリの到着に。もうちょっと余裕を持って行動したかった。
• 場所は大手町野村ビル。中に入ったのは初めてでしたが、1F にはパソナテックさんのキャリアに関する展示ブースがあって、面白そうです。余裕が有ればもうちょっと観察できたのに……
• 開場は大ホールです。SIX APARTさんのステッカーを入手できたのがちょっと嬉しい。しかし、すごい参加者数です。
• 基調講演：Blueshift Global Partners 渡辺千賀さん
• 言わずと知れたアルファブロガー、On Off and Beyond の渡辺さんです。シリコンバレーネタで会場は沸きまくり。また、著書「ヒューマン2.0」やブログどおりの方で感動しました。「イノベーションのロングテール」「質も量も大切・量が質を生む」「オードリーヘップバーン攻撃」「(ブログによる)バーチャル飲み会効果」などの金言多数。
  発表内容もさることながら、聞いているだけで元気になるプレゼンテーションでした。

• CTOセッション
• 近江商人JINBLOGの上原さん司会で、ブログネ申平田さん、GREE藤本さん、ウノウ尾藤さんによるセッション。CTOセッションということでしたが、CTOという枠にとらわれないトーク展開が素敵です。「社員のモチベーション管理」については、CTOとしてでなくとも「楽しくなかったら楽しくする」というような姿勢が人を惹き付けるのではないかな、と。また、CTOの仕事の一つとして人材の確保があるそうですが、この人たちと仕事をするのは(大変だろうけど)楽しそうだなーと思わせてしまうところがすごい。

• ライフハックセッション
• シゴタノ！大橋さん、アリエルネットワークの徳力さん、渡辺千賀さんという豪華メンバーのライフハック語りです。徳力さんのトークが、大企業のIR担当などの経歴もふまえたものであったので印象に残りました。
• 徳力さんのブログに対する「個人名で情報発信するのは考えられない。個人が縁の下で努力をした結果、会社の名前が上がるという感覚だった」というのは確かにそうだなとうなずく事しきりです。(逆にこれに対して渡辺千賀さんが「最初は匿名の情報発信の意味がわからなかった」というコメントも面白かったです。業界の違いということなのかなと)

何度もカンファレンス中で触れられたのは、ブログのコミュニケーションを促進する力でした。Eメールとは異なる、不特定多数への自己の発信。徳力さんは、これを「コピーロボット」と表現していました。つまり、自分が他の事を行っている間、または眠っているあいだにも、ブログは自分自身の代わりにコミュニケーションしてくれているのだということです。確かにそうだなぁと思うところはあります。このブログや、mixiなどに書いた日記はすでにコミュニケーションツールの一種になっています。私に興味を持っている人の一部はすでに読んでいて、私の昨日まで考えている事は理解した上で、関係をせまってくる。これでかなりのコミュニケーション労力が短縮できます(自分の最近の興味や背景をいちいち説明しなくても済むわけですから)。

というわけで、引き続きブログ発信をがんばらなければなぁ、と思う今日この頃です。