VBAの画面定義もいずれXAMLやMXMLのようになるだろう

このブログ「VBAがテーマじゃないの？」と思われるフシもあるだろう。

いずれVBAでもフォームの作成なんかの画面定義はXAMLやMXMLのように、XMLベースで書かれる事になるだろう、と私が予想しているからだ。

もしかすると、アプリケーションのインターフェース自体がXMLで保存されるかもしれない。

・テキストや図形ならXMLで保存は当たり前に行われているので、Word や PowerPoint といったものは扱えるだろう。

・スプレッドシートのデータ自体をXMLで保存するのはそれほど難しいことではない。

そう書いていて思い出したのだが、Office2007からはzip形式で保存されていた。解凍すればシートの情報はそんなような形式で保存されていたような記憶があった気がする。私の手元には2007がないので、もしお持ちなら試してレポート頂ければと思う。

　※Excelならxlsxが拡張子だが、それをzipに変更して解凍すればいろいろなファイルに分かれる。

・・・などと書いて、既に「そんなの当たり前じゃないの」という指摘があるのかもしれないな、と内心びくびくしながらアップしてみた次第である。

【アメブロネタ】へコんだ時の立ち直り方

ブログネタ：【夜明けのマルシェ×Ameba連動企画ネタ】辛いとき、凹んだときの立ち直り方は？ 参加中

本文はここから

仕事上、プロジェクトのリーダーやマネージャーという職はどうしても嫌な役回りが多く、辛いこをよく経験する。

顧客の場合。日本では「契約」がすべてではなく、まだまだ情緒的な部分が多いからか、たとえ事前に契約内容を決めておいて承認していただいたとしても、後付で顧客に引っ繰り返される。

部下の場合。指示内容を要点も含めて伝えても、いつの間にか勝手な解釈を行って違うことをしてたり、その更にしたの連中に勝手な解釈で説明していたりする。

それでの遅れ、費用の都合など、すべて調整しなくてはならない。

これが続くと、さすがに凹む。あまりに不条理なときは「完全に裏方に回る」ようにしている。

顧客へは根回しを強化、部下へのチェック体制は強化、それも笑顔で。更に「何もしていない」ように見せかける。

そうすることでプロジェクトは好転し、いい終結を迎えることができる。

完遂することで立ち直ることができる。

さて、その続き。うまくいけば大抵「次の仕事の話」が浮上する、その際、何にもしていないように見せかけている私はまんまとそのプロジェクトを抜けられる事が多い。場合によっては「喋っているだけで何もしていなかった」と非難されるケースもあった。何が成功の元になったのか見極められないない連中に、私のノウハウを伝えても聞こうとしないし、教えるつもりもない。それが私の「ささやかな復讐」になる。

さて、ここからだ。

次の仕事としてのプロジェクトが成功したら「成長したな」と、失敗したら「やっぱりな」と、そこで凹みは解消される。ささやかな復讐、と書いたのは今まで「成長したな」というケースが一件もないからだ。残念ながらプロジェクトの成功／失敗から教訓を学んでいないのだろう。

残念な限りであるが、期間延長、費用超過、要件満たさずでの赤字や信頼の失墜、ひどい場合には契約打ち切り、受注側の倒産、ということもあった。

なるだけ私が凹まないプロジェクト作りを心がけているが、たまたまの成功体験が支えになっている人は残念ながら失敗の要因になる傾向が強い。困ったものである。

PMBOKは基礎知識

語弊があるかもしれませんが、実戦経験をロクに積んでいなければPMBOKも「タダの知識」なのです。

プロジェクトで四角四面にPMBOKを適用、なんてことは考えない方がいいでしょう。PMにとって大切なことは「プロジェクトをうまく回していく」ことであり、「PMBOKを厳密に適用する」ことではないのです。

また、PMBOKはコーランやバイブルのように絶対的で変化のないものではありません。CMMIでいう5のレベルの如く、少しずつ最適化が図られているのです。

PMPを未取得で現場を上手く回すPMと、PMPは持っているけれど軋轢を起こすPM、どちらがマネジメントといえるでしょうか？実際、こういうケースは見かけます。企業戦略としてPMPの取得を推奨したりしているがために、更にPMPを「やらされ感」で取得しているがために、「知識だけPM」は増えている気がします。

PMP保持者としてはいささか残念ですが、嘘を伝えても仕方ありません。

もう一つ、これは経験から思う持論ですが、管理される指標が何なのか、管理者は何を欲しがっているのか、管理される側の技術者が理解しておく方がいいのではないかと考えています。つまり、PMBOKの概略はプロジェクトに参画するための基礎知識として知っておくべきではないかと思います。

その基礎をおさえつつプロジェクトに参画していけば、知識と経験を持ったPMが育つのではないかと思います。