このプロジェクトマネジメントを続けてはだめだ！！もういい加減に成長しなければいけない。
そんな思いからアート・オブ・プロジェクトマネジメントを読んだ

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

posted with amazlet at 09.11.15

Scott Berkun
オライリー・ジャパン
売り上げランキング: 96079

おすすめ度の平均:

バイブルにしています
プロジェクトマネジメントに関する教科書的な一冊
プロマネ、必読
プロジェクト大災害で大炎上
真のマネジメントがここにある

Amazon.co.jp で詳細を見る

目次

• 計画
  • スケジュールの真実
  • やるべきことを洗い出す
  • すぐれたビジョンを記述する
  • アイデアの源
  • アイデアを得た後にすること
• スキル
  • 優れた仕様書の記述
  • 優れた意思決定の行い方
  • コミュニケーションと人間関係
  • メンバーの邪魔をしない方法
  • 問題発生時に行うこと
• マネジメント
  • リーダーシップが信頼に基づく理由
  • ものごとを成し遂げる方法
  • 中盤の戦略
  • 終盤の戦略
  • 社内の力関係と政治

そもそもなぜソフトウェア業界はこんなにもプロジェクトマネジメントを声高にする必要があるのだろうか。
事業規模で考えれば他業界でもっと大きなプロジェクトはたくさんある。もちろん、それらプロジェクトがすべからく成功を収めているかというとそうとは言い切れない部分はあるが、、、

本書はプロジェクトマネジメント全般にわたって書かれてはいるが、ここではこの頃私を悩ませている仕様書に関しての話題に言及したい

仕様書は必要か？

本書ではプロジェクトに必要となる書類として以下のものを定義している

• 要求仕様
  • プロジェクトに期待される様々な物事を文書化するため、作業によって達成されるべきすべての要求と責任の概要を記述する
• 機能仕様
  • 顧客の視点から見た特定のシナリオやシナリオ群における振る舞いや機能を記述したもの。ソフトウェアの機能をユーザーインターフェースを通じて解説し、なるべく技術的な詳細に踏み込まないようにしつつ、物事の動作方法を解説する。要求の一覧ではなく、それを実現するための機能の一覧。
• 技術仕様
  • 機能仕様を満足するために必要となるエンジニアリングアプローチの解説。もっとも複雑なコンポーネントや、他のプログラマが再利用する可能性のあるコンポーネントを開設したり、機能仕様に必要な作業項目に対して技術的な裏付けを提供できるだけのレベルで十分。
• 作業項目一覧（WBS）
  • 機能仕様を満足するために必要となるプログラミング上のタスクを解説したもの。
• テスト基準とマイルストーン達成基準
  • 各テストケースの優先順位と、各マイルストーンにおける品質目標を満足するためには、コードが該当テストケースにおいてどの程度正しく動作する必要があるのかという目標。

私のこれまで携わったプロジェクトでは、要求仕様や機能仕様を合わせて外部仕様書と読んだり、機能仕様と技術仕様がごちゃっとなって内部仕様書と読んだりしていた。ちなみにWBS、テスト基準等はそれぞれの文書として独立させることになる。
恐らく本書で述べられているこれら内容は別に独立した文書である必要はなく、それらを網羅するべきということなんだろう。

私の場合は転職経験があるわけでも、大学でソフトウェア関連のことを学んだことがあるわけではないので他にどういう形の文書があるのかは知らないのが現実だ。
内部仕様書に記述する技術仕様は、どの程度まで記述するのかが問題となるのではないだろうか。仕様書を書くことが本来達成するべき仕事ではないので、これらの切り分けをどうしていくのか…。内部仕様書に関しては、社内の誰に対して文書を書くか？ってことになるのかもしれないなぁ

仕様書と設計書の違い

設計段階では仕様は固まっていない。未確定な内容が含まれており、それに対する議論や検証を行う必要がある。それらを経て、実際のモノづくりを行う作業の前に仕様書を作るべき。
設計書と仕様書を同時に作成しようとした場合、設計の変更に伴う仕様書の修正工数ばかりが増大していき、仕様書は意味のあるものとして成り立ちづらい。もしくは計画そのものが破たんする。これらは全く別のプロセスとして動かす必要があるだろう。

ううん、言っていることは分かるが…。
実際のところ、現場では設計書と内部仕様と作業指示がめちゃくちゃになっている。内部仕様書が正しく仕様書としてなりたっておらず、中途半端な設計書になっているだけだった。
だからこそ、”何の文書を書くのか”ということが明確になっておらずに、文書の作成に行き詰ってしまっているのだと思う。
そう考えると、これらを全く別のプロセスとして捉えて取り組むというのは分かる話ではあるのだが…。
ううん、時間がないっていう言い訳をしてはいけないのは分かるが時間がない。時間を捻出する手立てを立てなくてはいけないなぁ

多くのすぐれた仕様書では、設計が階層に分けられた上で記述されている。まず最初に、顧客のエクスペリエンスが顧客の言葉で記述されている。次に、基本オブジェクトの大まかな概要とアーキテクチャが記述されている。そして最後に、エンジニアリングにおける、設計上の複雑かつ詳細な問題が記述されている。

ふむぅ
やはり、仕様書か設計書か。
どうしても私は今自分が見ている”仕様書”が頭に入ってしまっていてここで述べている”仕様書”との間には隔たりがあるようだ。この隔たりを解消するにはどうしたものか…。やはりここでいうところの”優れた仕様書”を見てみるのが一番だと思う。

Joel on Softwareでおなじみのジョエル氏のページには氏が”優れた仕様書”のサンプルを出している

• 仕様書とはどんなものか？(Joel on Software)
  • http://local.joelonsoftware.com/wiki/%E3%82%84%E3%81%95%E3%81%97%E3%81%84%E6%A9%9F%E8%83%BD%E4%BB%95%E6%A7%98_%E3%83%91%E3%83%BC%E3%83%882:_%E4%BB%95%E6%A7%98%E6%9B%B8%E3%81%A8%E3%81%AF%E3%81%A9%E3%82%93%E3%81%AA%E3%82%82%E3%81%AE%E3%81%8B%3F

• 機能仕様書サンプル　(Joel on Software)
  • http://local.joelonsoftware.com/wiki/WhatTimeIsIt_Jp

んー・・これ見たことあるな…。たぶんJoel on Softwareにそのまま載ってるな…。

はい、出直してきます

私の管轄しているプロジェクトではないのだが、別プロジェクトが火を吹いている。
なんでもお客様からの品質に関する要望に対して提出している書類が思うように理解されないというものだった。

最初からプロジェクトがつつがなく進行している場合は問題がないのだが、数度問題が発覚するとお客様側の担当者としても黙ってはおれず、チェックが厳しくなる。
ただ単にチェックが厳しくなっているだけならばそれほど問題ではないのだが、ソフトウェアに対する品質管理を担当したことがないお客様がチェックを厳しくしようとするのが結構問題なのだ。

まず、言葉が通じない。
一通り書類を書いたところで、言葉の定義を一つずつ教えていかないとその文書を読むことが出来ていない。普通なら「こんな感じかな～？」っていうニュアンスで乗り切るのだが、”疑いの目で品質チェックをしようとしている”お客様としてはそうはいかない。
もちろん、書き方の問題もある。一言”モジュールテスト”だとか”ユニットテスト”だとか言っても、ソフトウェア業界ですら会社によって言葉が何を指すのかがバラバラな状態であることをよく聞く。
このあたりは、いわゆる製造業だとかその他産業との歴史の差が出ているのかもしれない。ソフトウェアの品質管理においての業界標準となりえるとすれば、国際的にはISTQB規格。日本ではJSTQBになるのだろうか

JSTQB
http://jstqb.jp/

しかし、”ユニット”の定義に関して明確になっているわけでは無いんじゃないだろうか？正直なところJSTQBとろうと思ったことないから分からないのだが…。
ただ、いわゆる目に見える機械の”部品”と、ソフトウェアのプログラム上の”部品”とでは実際に手にすることが出来ない分、考え方を変えていかないといけない。

もっとも、お客様にそこまで疑問視されるようなところまでいっている時点で問題なんだけどね。
ただ、ソフトウェアの場合は目に見えないものであるがゆえに、別業界の人に説明する時、言葉に関しては最新の注意を払わないと余計なコストをひたすらにかけることになってしまうなぁ、と思った。
ただ…気をつけないとって言ったところで、自分がその矢面に立たされた時に乗り切れるだろうか？ちょっと考えてしまうなぁ

iPhoneを手にしたことで、より気軽にWebを見ることができるようになりました。
もちろん、PCと違って画面が小さかったり、入力スピードが遅かったりと難点はあるものの、それはモバイル端末なのである意味どうしようもないこと。割りきって使っています。
ただ・・FLASHを使ったサイトを見ることができないんですよね。

アドビ、「Flash Player 10.1」を発表–スマートフォンやネットブックに対応
http://japan.zdnet.com/news/software/story/0,2000056195,20401073,00.htm

現時点では、Flashは『iPhone』上で使用できない。これまでのところ、われわれは必要なサポートをAppleから受けていない

これはどういうことなんだろうか…。Appleが出し惜しみをしているのか、それともAppleとしてはFlashに対してまだまだ問題があると認識されているのだろうか。
いずれにしてもフルブラウザを搭載している以上、Flashを使用しているサイトは必然的に訪れるわけなので、何らかの対策は取ってほしいですね。

Silverlightはどうだろう？

少なくともSafariには無理だろうなぁ～って検索していたらこんなものを見つけた

Deep Zoom style on iPhone – Seadragon for Mobile
http://timheuer.com/blog/archive/2008/12/15/deep-zoom-and-photosynth-on-iphone.aspx

おぉ？
Seadragonと言えば、SilverlightでいうところのDeepZoom機能を実装しているやつ。ってことは、これで使えるのか？？ってことで早速インストールしてみた。

AppStoreで「Seadragon Mobile」で見つけることができる。

起動していくつかのギャラリーの中から高解像度の画像を見ることができる。。。。って、これじゃブラウザとは関係ないじゃないか！！

結局のところ、Silverlightも当然のようにSafariでは使用することができない。他のブラウザではどうなのか？もう少しプラグインであれこれできるものがあってもいいものだが…Appleがそれを許さないんだろうな。
このあたり、もう少し融通が利いてもいいと思ってしまう私はWindowsになれすぎているのだろうか。

2003年ごろに出版された本に、Tomcatを単独でWebサーバー/JSPコンテナとして使用するよりも、IISをWebサーバーとして使い、Tomcatをサーブレット/JSPコンテナとして使うほうが性能が向上すると書いてあった。ここで言う”性能”が何を意味するのかは気になるところではあるけど、ネット上を見てみると、そう言った事例はいくつか見受けられる。
今回の要求内容としては、同一サーバーにてServletによるサイトとASP.NETによるサイトを共存させたいという事。「別にServlet側は8080使えばいーじゃん」って言ってしまうとそれまでなのだがそうもいかないらしい。
あちこちに情報は載っているのだが、情報が分散してしまっているのか”この設定は当たり前だよね”という事なのか、実際にやろうとして手間取ってしまったのでここをチラシの裏としてメモする。
ここではTomcatのバージョンは6.0.18。WindowsはVista（32Bit）でIIS7.0。使用したisapi_redirect.dllは1.2.28になる。

isapi_redirect.dllの配置

http://apache.justdn.org/tomcat/tomcat-connectors/jk/binaries/win32/
から最新版のisapi_redirect.dllを入手する（isapi_redirect-1.2.28.dllをダウンロードしてファイル名を変更）。
任意のディレクトリへコピーする。ここでは「C:\Tomcat6\bin\isapi」へコピーしたとする。

ここでは32BitのOSでの話なので64Bitでは別なファイル（http://apache.justdn.org/tomcat/tomcat-connectors/jk/binaries/win64/）になる。

isapi_redirect.propertiesファイル作成

isapi_redirect.dllをコピーした場所で「isapi_redirect.properties」ファイルを作成する。中身は以下の通り

extension_uri=/jakarta/isapi_redirect.dll
log_file=C:\Tomcat6\logs\isapi_redirect.log
log_level=debug
worker_file=C:\Tomcat6\conf\workers.properties
worker_mount_file=C:\Tomcat6\conf\uriworkermap.properties
uri_select=unparsed

この内容はレジストリでも代用できる。その場合は「HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi Redirector\1.0」に対して同様の内容を設定することになるが、ここでは割愛する。レジストリを使うべきなのかもしれないが、代替案があるのであれば、極力触りたくはないものだ。

workers.propertiesファイル作成

isapi_redirect.properiesファイルで指定した場所（ここでは”C:\Tomcat6\conf\”）に「workers.properties」ファイルを作成。
ファイルの中身は以下の通り

ps=\
worker.list=jakarta
worker.jakarta.port=8009
worker.jakarta.host=localhost
worker.jakarta.type=ajp13

uriworkermap.propertiesファイル作成

isapi_redirect.properiesファイルで指定した場所（ここでは”C:\Tomcat6\conf\”）に「uriworkermap.properties」ファイルを作成。
ファイルの中身は以下の通り。ここでは、”examples”サイトへのリダイレクト設定を行う

examples/*=jakarta

IISに対する全てのアクセスをTomcatに対してリダイレクトする場合には「uriworkermap.properties」ファイルに対して
/*=jakarta
のように書く形で設定する。「uriworkermap.properties」ファイルの記述方式としては
[URL]=[WORKER_NAME]
になっている。

例えば、JSPとServletに対してはTomcatで処理するけどそのほかはIISで処理したい時には

examples/*.jsp=jakarta
examples/servlet/*=jakarta

のように記述することになる。ASPとJSPの同一サイト内での共存が可能に！需要あるのか？

IISに対する設定

1. IISマネージャにてサーバーホームより「ISAPIおよびCGIの制限」を開き”isapi_redirect.dll”を追加する。説明は適当で。
2. IISマネージャにてサイト配下の”Default Web Site”を選択。”ISAPIフィルタ”を開き同様に”isapi_redirect.dll”を追加する。名前はなんでもいい
3. IISマネージャにて、”Default Web Site”に対して”仮想ディレクトリ”の追加を行う。エイリアスには”jakarta” 。物理パスは”C:\Tomcat6\bin\isapi”を入力する。
4. 追加した仮想ディレクトリを開き、”ハンドラマッピング”を開く。”スクリプトマップの追加”を実行し、下記内容を設定する。

要求パス：*
実行可能ファイル：C:\Tomcat6\bin\isapi\isapi_redirect.dll
名前：jakarta

1. IIS再起動

上記手順によって、”http://localhost/examples/“に対してのアクセスがTomcat側にredirectされる形になった。TomcatがWebサーバーとして動作する”http://localhost:8080/examples/index.jsp“は当然としてIIS側からもちゃんと動作するって言う事ね。

この話を聞いた私の最初の理解だと、仮想ディレクトリ”jakarta”に対してアクセスを行った場合にTomcatに対してリダイレクトするのだと思っていた。だが実際は違って、IISのサイトに対してアクセスがあった場合に拡張設定された仮想ディレクトリ”jakarta”を利用してisapi_redirect.dllが起動。uriworkermap.propertiesに記述されたサイトでフィルタがかかりTomcatにリダイレクトされるって言う事かな？このあたりの理解はまだ足りないかもしれない。

C#を勉強したいっ！っていう個人的思いとは裏腹に、会社の思惑は別のところにあって、今携わっているプロジェクトではJavaを使用しています。
実際のところ、マネージメント業務が多すぎて自分でソースをいじる機会が少なくなってきてはいるのですが、部下をうまいこと使いながら少しずつ私自身も身につけていけるよう試みています。
それにしても、これまで扱っていたのがIISやC++。次に使うのがTomcat＋Javaという、まったく異なる環境なのでそれはそれで面白そう。
あぁぁぁぁぁああああ。だれか代わりにマネージャやってくんないかなー
なんて思ったり思わなかったり。

ソフトウェアとセキュリティの組み合わせだと、真っ先に思いつくのはウィルスや不正侵入を防ぐ話だ。ウィルスや不正侵入によってもたらされる被害は増えているんだろうけど、今日は違う話。不正コピーの話だ。

ソフトウェアのコピー

ソフトウェアの不正コピーを防ぐ方法として私がぱっと思いつくのは

• 指紋認証
• USBキー
• ワンタイムパスワード

実際に私が使ったことのあるのはUSBキーによるプロテクト。プログラムの中から指定のUSBキーがPCに刺さっていないとプログラムが動作しないという、比較的ポピュラーな方法（だと思う）。
ネットを介して認証を行うプログラムや、PC固有の環境変数を利用したものも使ったことはある。
こういう認証技術とそれをクラックする技術ってのはいたちごっこなんだろうなぁと思っている。まぁ、いたちごっこといっても、苦労して新方式の認証技術を取り入れたとしてもそれを打ち破るのは早くて数時間なのだろうから勝負になっていないのかもしれない

今ではコピーだけとは限らないらしい

ちょっとしたことで、そういうセキュリティ関連を手掛ける企業の方と話をする機会があった。そこで聞いた内容は私にとってはちょっと驚きだった

• プロテクトを破るというよりはプロテクトを使う側を狙う。つまり実行ファイルを書き換えてしまう
• プロテクトを無効にするだけじゃなくて、別なキーで起動できるように書き換えることもできる
• 解析してソースコードを取得。それを別な形で作り変えて再販する
• CADデータや設計情報は速攻で流出して売買される
• ロボット等に搭載されているプログラムにも同様のことが言える
• 改変されたプログラムで、あっさりと取られて相手に理論武装され、結果裁判でも負けてしまうこともある

等々。まぁ、技術の詰まったプロテクトキーをがんばって攻略するよりは実行ファイルの内容を書き換えてしまったほうがよっぽど早いだろうってのは言われてみればその通り。ただ、私が抱いていたイメージでは
お金を払わなくてもシェアウェアが使用できる
ってのが不正コピーなわけだったので、それを自らの収入源に変えてしまおうというのは、なるほどって思ってしまった。さすがにかの国はやることがすごいな、と。そりゃ強制開示を求めてきたりもするわな。
ま、今となってはかの国に特定される内容ではないのだろうけど。

どうするのか

実行ファイルが弱いのであれば、実行ファイルそのものを暗号化してしまおうというのが、今回お話を聞いた内容であった。
実際のところどうなんだろうなぁ…。結局のところいたちごっこなのではないだろうかと思ってしまったのが本音である。どれだけ暗号化を施そうとしてもPC上で動作する以上は動かす方法があるわけで…うーん。どうなんだろう。こればっかりはわからないな。
空き巣の被害じゃないけど、「がんばれば破られるけど、容易に破られるのを防ぐ」ことができれば空き巣の多くは回避できるらしい。ソフトウェアのプロテクトに関してもある程度のところまではそういう妥協をするしかないのだろうか。
プログラムに対する知的財産の保護って難しいものだなって今更ながらしみじみと思ってしまった。

解析魔法少女美咲ちゃん マジカル・オープン!

posted with amazlet at 09.07.03

やねう解析チーム
秀和システム
売り上げランキング: 16229

Amazon.co.jp で詳細を見る

あれこれと試行錯誤しながら、IEのツールバーを作成して、そこからIHTMLDocumentClass等を駆使してページの操作が行えることは何とかできた。ActiveXコントロールに対する捜査はまだ試してはいないけど、できないことはないだろうと思う。ただ・・・
考えてみると、Webアプリケーションの場合機能が分かれた時に別ウィンドウを立ち上げることがよくある。。。と思う。少なくとも私がテストしたいアプリケーションはそうだ。
この場合、IE8では特に別のIEインスタンスが起動してしまうためにそちらに対しての操作がうまくいかない。うーん、これはちょっとハードルが高そうだ。

ウィンドウをオープンさせるイベントをフックさせて新規のウィンドウではなく、フレームわけした場所にそのウィンドウをオープンさせることができれば何とかできるかもしれないが、そこからもウィンドウを開くといくつフレームを用意するんだー！って話になってしまう
結局、IEとは別の場所から制御するしかないのか。。。しかし、そうすると操作できることに限界が来てしまいそうだ。。。
あああああ

もう寝る

以前ご紹介した（id:krote:20090212）ソフトウェア開発未来会議へ話を聞きに行ってきた。会議の形式としてはパネルディスカッション。登場したのは

・東証コンピューターシステムの松倉氏
・イーストの下川氏
・アプレッソの小野氏
・アークウェイの森屋氏
・ジャーナリストの新野氏
・デジタルアドバンテージの小川氏
http://www.developerscafe.jp/future/offline/index.html

の面々。最近よく見かける方々がいる。
アークウェイの森屋氏は最近よくこういう場で見かけるようになった。最近見かけるようになったのはただ単に私がそういう場に行くようになっただけなのかもしれないけど。イーストの下川氏はWindowsAzureを使用したサイト（TORIPOTO（トリポト）を作成したという事でTechDaysで紹介されていたので知っていた。アプレッソの小野氏はブログ（http://blog.livedoor.jp/lalha/）も有名だしね。
というわけでどんな話が飛び出るか楽しみで行った

話題の中心は

今回、パネルディスカッションで話される内容として事前に予定されていたのは

1. 世界不況に対して
2. クラウドコンピューティング
3. これからのソフトウェア開発は

という3つのテーマが挙げられていたわけだが、2時間半（30分延長）の時間の大半はクラウドコンピューティングに対して向けられた。
時流というかなんというか、しょうがないといえばしょうがないのかもしれないが3番目のテーマに関してこの面々が経営者の視点からどう考えているのか。今後、どういう風にしていこうと考えているのかを楽しみにしていただけに少々期待はずれだった。
まぁ、軽食ありの休憩を含んだ時間という設定で、この3つすべてに対して2時間では全然足りないということだろう。クラウドコンピューティングに対しての議論がそれだけ白熱したという事もあるのかもしれない。ただ、それぞれの見解や立場の相違から議論そのものは随分と変な方向性を向いてしまっていたのではないだろうか。
確かにクラウドに対しての不安や危惧は尽きないものだけど、それを論じるために集まった訳ではないのではないだろうか。可能性を語る上で危険性に目を向けなければいけないのはその通りなのだけど、限られた時間の中で本来の目的である”幅広い視野に立った将来設計へのヒント”を達成する方向で論じてほしかった。

個人から見たクラウド。組織から見たクラウド

今日一番の収穫だったのは個人から見たクラウドに対する視点だったように思う。
これは、いわゆるiPhoneのAppStoreのように、個人が提供するソフトウェアの一つの形態として成り立たせることを容易にするのかもしれない。
これまで、アイデアはありながらも公開サーバー等を自前で所有・維持する事が出来ないゆえに埋もれていったソフトウェアの提供。これが、たとえばWindowsAzureのような環境を利用する事によって随分と敷居を下げることができるのではないだろうか？企業に勤めていながら、起業というリスクを負わなくても実行できるのではないだろうか？
ちょっとぐらっときた。
なるほど、この視点でAzureを見てはいなかった。まだWindowsAzureの価格設定が出てきていないので実際のところはわからないが、正直”企業向け”という位置づけでしか見ていなかった。もしそういう見方が可能ならば色々とこの界隈は面白い事になるのかもしれない。レンタルサーバーとの違いって奴を見せてほしいものだ。

一方で、組織。つまり企業がクラウドに対してソフトウェアを提供する事に関しては意見は別れた。
クラウド上にこれまでオンプレミスの環境で構築していたサービスを乗せるとなると、対象とするシステムによってその容易さや考慮する内容というものは変わってくるはず。
コンシューマ向けのサービスに関して言ってしまうと、比較的容易であると思う。さらに、サービスの提供期間が短かったりする場合には初期コストを考慮するとクラウドを使用したほうがコストの削減になりそうだ。ほら、芸人のサイトなんていいんじゃないだろうか。2年くらい持てば人気が…。
ただ、企業内のサービス。特にミッションクリティカルな内容になると、“少なくとも今は”難しいように思う。クラウド上のサービスはインターネットありきなので、何らかの回線不具合があった瞬間にどうしようもなくなってしまうのだからだ。手元にデータも何もないので手の打ちようもなくなってしまう。
結局のところ、これらの技術動向に対して、法整備や環境が整っていないのだと思う。ミッションクリティカルな内容になれば必ず日本の企業は”誰が保障するの？どこに訴えればいいの？”ってなるし、個人情報を扱うとなると”プライバシーマークやISMS取ってくれてるの？”となる。もちろん、それらはいろいろな問題を考慮して作られたものであるので否定はしないけどね。しまいには”データは日本にないと駄目だよ”とか言い出しそうだ。
まだまだこれからこれから。どう考えていくのかを考えていかなければいけませんね。

これからの会議

ソフトウェア開発未来会議が、今後どういう話の方向性をたどっていくのか。2回目のオフライン会議があるのかはわからないが、クラウドに限らず話を進めていってほしいと思っている。”ソフトウェア開発者”は別にWebやっている人ばかりではなく、組み込みの開発者もいればローカルのアプリケーションの開発者もいるわけだし。
これだけ目まぐるしく技術内容が変化し続けている業界において、この会議に参加されている経営者の方々がどう考えているのかは気になるところだ。
自分を含め、考えていかなければいけないだろう。

あぁ、また長々と書いてしまった。。。

Microsoft社が提供している資格、MCTSの「WindowsVistaのクライアントの構成（070-620）」を受けてきた。結果としては無事に合格。実は以前、なめてかかって失敗しただけに少し安心。今回は半分意地になって受けてしまった。
Windows7が今年に出てくるかもしれないことを考えるとちょっと微妙かもしれないが、Windows7はVistaの流れを汲んでいるので無駄にはならないと判断した。
このあと、2008トラックにあたる資格を取り続け、上位資格であるMCITPへ進むことができればと考えている。いつも面倒臭がって途中でやめてしまうので今年はしっかりと気を引き締めていこう。

MCPプログラムとは
http://www.microsoft.com/japan/learning/mcp/mcp_program.mspx

資格の価値は

MCP資格はMicrosoft社が提供しているので対象範囲はMicrosoft社製品に限られる。つまりMacやLinuxにその知識を適用することはできない内容になる。そして、いわゆる”名称独占資格”なのではっきり言ってしまうと持っていようが持っていまいが、できることは変わらない。Microsoft社が掲げている特典も

1. マイクロソフト製品と技術に関する高い評価が受けられる。
2. MCP メンバー サイトにて、いち早くマイクロソフトの技術と製品情報にアクセスすることが可能になる。
3. 技術トレーニング/セミナー、特別イベントなどへの招待または、割引受講招待が受けられる。
4. TechNet サブスクリプションの会費が初年度割引となる。（対象資格を取得済みの方）
5. マイクロソフトプレス書籍の優待販売版。

くらい。高い評価が受けられると言っても、その評価を下す相手がMCPプログラムに対しての理解を持っていないと意味がない。それを考えると、本が安くなる（10％割引）程度ではないだろうか。
MCPに限った話ではなく、OracleマスターやCCNA。その他ベンダーが提供している資格は、ベンダーの製品に依存している。しかも製品のバージョンアップに合わせて資格もバージョンアップさせないと、持っている意味が微妙になってしまう。その知名度こそ違うものの、これらの価値というものは結局のところ自分で見出していく必要があると思う。

そういう意味で考えると、IPAが提供している情報処理技術者試験であれば”一応”国家資格であるし、特定のベンダー製品に左右される内容ではないので応用は効くのかもしれない。逆に言ってしまうと、応用するための”基礎・基本”なので取ったからと言って何かができるようになるわけではない。”実践力”という意味ではベンダー提供の資格のほうが有利だと思う。

取得の動機と企業にとっての価値は

これらベンダー資格を取る人の理由や、どこに価値を見出すのかは人それぞれだ。取得する動機としては

1. 業務命令
2. 会社からの報奨金（一時金・給料UP）
3. 転職・就職を有利にするため
4. 知識の習得・整理・確認

みたいな理由があるみたいだ（http://jibun.atmarkit.co.jp/lcareer01/rensai/career24/data24.html）。情報処理技術者試験のような国家資格であれば報奨金制度が整っている会社も多いが、ベンダー資格に関しては整備はまだまだ。各ベンダーとパートナーにある会社であればメリットはあるかもしれないけど、それ以外の会社にとっては今のところ魅力は少ないと言えるのかもしれない。逆に、それら資格の有効性を認識して評価してくれる会社への転職に動く人もいるみたい。
私の勤めている会社に関して言及してしまうと、これら資格に多少の理解はあったのだが、昨今の不況でこれら資格に対する助成制度は凍結されてしまった。まぁ、これまでMCPやソフトウェア開発技術者試験等は自費で撮ってきた私にとってはそれほど気持ち的に変わりはないんだけど、これからの取得を考えていた若手に関してはちょっと精神的な壁が上がってしまったかもしれない。ちなみに私は「会社に取らせてもらったわけじゃない」と言う、なんとも根性のねじ曲がった理由で当時取得している。B型はどんだけツンデレなんだ。
助成制度をやめたところでそんなに大きくお金が動くとも思えないのだが…。それより、技術力が低下していくことのほうが、よっぽど問題になるのではないかと考えている私は心配性なだけであろうか（実際のところ制度の有無にかかわらず受ける人は受けていくだろうが）。

どう向き合っていくか

結局のところ価値を自分で見つけていくしかないのであれば、それ相応の動きを見せていくしかない。取得した時点で終わりではなくて、そこで習得・整理・確認された知識・技術をどう日常の業務へ適用するのかを考え、実践していかなければ意味がない。
もちろん、これから通常の業務を行っていく中で勉強した内容が生かされる場面が出てくるかもしれないが、自分から出来ることを探していかなければせっかく習得したスキルを発揮できないのではないだろうか。
具体的に何ができるのか。Windowsに関することであれば社内の各端末設定や新規端末の展開に対しての業務に合わせて行動ができるかもしれない。社内に勝手にサポートチームを作ってしまうのも面白そうだ。そのような部署があるのであればそことのパイプ役や、移籍も考えてみてもいいかもしれない。
MCP資格の問題は、企業規模や場面は特定されるもののケーススタディ的な試験問題が多いので、稀にそのまま適用できるケースもあるだろうし。
MCPやOracleマスター取得を部下に紹介・薦めている以上、業務としては非公式だが、そういう組織を結成してしまって、あとから認めさせ、さらにはこれら資格に対する認識を改めさせる方向へ持って行けないだろうか。このあたりを自身の資格取得と合わせて考えていかなければいけない。

余談

それにしてもMCPの問題文。あれはもう少し何とかならないものだろうか。おそらく、原文は英語でそれを訳して作られているのだろうけど、厳密に言うと答えがないような問題がたまにある。日本語的におかしいものだとか。問題に関してはNDA（機密保持契約）があるのでそのものズバリを書くことはできないが…

AさんはBさんと会うときは赤い服を着ることにしている。Cさんと会うときは黒い服を着ることにしている。
今日は何の服を着ているでしょう

お前、だれと会ってるんだよ！！と、突っ込みを入れたくなる。何となく、答えの一覧の中から問題が本当は何を問うているのかは想像がついたので選んだ。これはまだ序の口で日本語としておかしい場合もある。ちゃんと問題作ってくれ・・・

ZDNetに変な記事が上がっていた

晩飯づくりをプロセスしてみよう！–プロセス志向のキホンのキ
http://japan.zdnet.com/sp/feature/09bpm/story/0,3800092652,20388219,00.htm?ref=rss

何をやり始めているんだ・・・ZDNet。
プロセス志向を鍛えるための題材として夕食の作り方を例にしているみたいだが・・・

1. 一人暮らしで手元にある材料で作るが鶏肉とかある
2. 米を研いだりするプロセスはあるが材料はあらかじめ切ってある
3. 炊飯器がない
4. でも鍋は3つある

等々、中々前提条件が特殊な気がする。
まぁ、ソフトウェア開発における要求仕様も毎回毎回これでもかというくらい特殊なのでそのあたりは気にしなくてもいいのかもしれない。

意外と使える開発現場のスキル

最近思うのは、ソフトウェア開発の現場で用いられている開発スタイルや考え方というのは色々な場面で適用することができるのではないか？ということだ。
テスト駆動開発を適用して常に味見をしながら料理をするのも一つ。
ペアプログラミングのようにそれぞれの切り方や味付け、次工程を確認しながら料理をするのも一つ。
リファクタリングは・・・。なんだろう。今回のように工程の最適化を考えることがそれにあたるのかもしれないなぁ
適当にエクストリームプログラミングの中から抜粋してみた。
多少強引ではあるけど、考えとしてはそんなに変な考えでもないと思う。つまり、ものづくりという観点から考えてみれば仕組みとしては共通した考え方を持つことができるということだと思う。
つまるところは

って事は

日本が世界に誇っている製造業。そのものづくりの現場で培われた工程というのを少し見方を変えればソフトウェアの開発現場にも適用できるのではないだろうか？また、もっと別な現場からの適用もできるのではないだろうか？
でも考えてみると、日本の製造業の場合はかなりプロセス毎に細分化されて個別の最適化がされているんじゃないかな。ソフトウェアの場合、同じ部品をひたすら作る製造業とは違うので簡単には共通点は見つからないかなぁ
もっと、基本的なことがありそうな木もするけど、実際に現場で働いたことがあるわけじゃないのでイマイチ分からない。仕事上、それらの内容を知っておくのはプラスになると思うので勉強するのも一つかもしれない。
ふむぅ