Share Point Server高すぎ

かなり前の話ではあるんだけど…

「WikiがなければMS Share Point Serverを使えばいいじゃない」(超意訳)という意見を見かけたことがある。

じゃあってんで値段を調べてみたのだけど、そのメモが今頃になって出てきた。

ライセンス名 SharePoint Internet 2007 Japanese MVL
価格 \3,147,430

ライセンス名 SharePoint Enterprise CAL 2007 Japanese MVL User CAL
価格 \5,710

たけーよwwwww
いや、自分の勤務しているところはMS Select契約を結んでいるので、ウソのように安い値段でMS製品を購入できるのだけど、それでこの値段か。

その時はサイボーズのガルーンについても調べたようで、

A 50ユーザー ￥600,000/50ユーザー ￥420,000/50ユーザー
B 51〜249ユーザー ￥11,000/1ユーザー ￥7,700/1ユーザー
C 250〜499ユーザー ￥10,000/1ユーザー ￥7,000/1ユーザー
D 500〜999ユーザー ￥9,000/1ユーザー ￥6,300/1ユーザー
E 1000〜2499ユーザー ￥8,000/1ユーザー ￥5,600/1ユーザー
F 2500〜4999ユーザー ￥7,500/1ユーザー ￥5,250/1ユーザー

ということだった。まあ、単にスケジュール調整する程度だったらこっち採用するよなあ。

研修行ってきた #2

ところで、研修があると狙ったように忙しくなるというジンクスを信じているのだけど、今回もあたっている気がする。

まず、機種Wの品質評価テスト期間とぶつかっている。トラブルもいくつかテスタや要求元から報告が上がっている。機種Wについて言えば、そもそもV2.0の機能導入をしなければならない時期だ。また、研修後に弁理士さんに図面を追加で提出しなければならない。さらに、機種Cの開発を始めないとHさんに怒られる。シミュレータも全然進んでない。機能仕様書の標準化も全然手をつけてない…

だんだん気が重くなってきた。が、これは「実際にはいつもどおりの忙しさだが、研修があると心理的にさらに忙しく思えるだけ」なのだろうか…

研修行ってきた

泊まり込みの研修に行ってきた。
対象は今春に昇格した社員で、主催は人事部。
2泊3日で、前泊も入れると4日間にもなるというもの。

一部の会社ではマインドコントロールまがいの研修もあるようだけど、そういうバカバカしいものとは無縁であるのは幸いだ。
ただ、有意義であったかというと・・・ うーん

職種がバラバラなので、刺激があるのはいいんだけど、あまり深い議論までいかないというか。
なんというか「先輩社員としての心構え」的な、抽象的な、当たり障りのない話題で終始してしまったような気がしないでもない。
まあ、いつもはあまり意識しないお金の話を知ることができたのは収穫だったかなと。

開封確認ウザイ

「開封確認が」というよりは「わざわざ開封確認を指定してくるやつが」といったほうがいいだろうか。
まあ、そういうやつは身のまわりには約1名しかいない。しかし、その約1名というのがメーラの自動送信機能を使って「今日の確認リスト」みたいなメールをバンバン送ってくる困った奴なので、迷惑なことこのうえない。

とはいえ、自分自身は開封確認はすべて無視、自動送信はフィルタでひっかけてごみ箱直行なので、「迷惑」というのはあくまで周りの人にとってである。
こちら側でもDisposition-Notification-Toヘッダがついているメールに自動返信してみようかと思うのだが、自動応答は会社の規則でできないことになっているので悩ましいところ。

まあ、こういう問題は技術的にではなく、上司に相談するのが一番いいだけどね。

プロジェクト修羅場中

修羅場と言っても、せいぜい23時程度までではあるのだけど。

ただ、毎日続くとさすがに疲れる。こういうとき体が食べ物を欲するようで、瞬間的に体重が60kgを越えることも。
夕方のおやつにしていた菓子パンがまずかったのかなあ。チョコアイスモナカも良く食べてたしなあ… orz...
そばやキャンディーに変えて減量作戦中。

自分のところのトラブルはひとまずめどは付いた。ただ、他モジュールのトラブル究明が遅れてて確認まではできてないし、次のリリースも迫ってるので、あまり余裕はないかなあ…

@IT 「すごい技術者はすごいマネージャになれるか？」

http://www.atmarkit.co.jp/im/cpm/serial/team04/team04a.html

「ITプロジェクトの運営・遂行の上で非常に重要なのは？」という質問に対し、
「プロセス」を挙げたのが8.82%、「メンバーのスキル」を挙げたのが33.82%という結果。ちょっと意外。
…ていうか「根性」の10.29%よりも少ないのかwwww

昇格審査結果

前半休を取ってお昼に出勤したら、上司が昇格審査の結果を通知してくれた。
まあ、合格だったんだけど。

なんだか徒労感だけが残って、達成感とかぜんぜん出てこなかったなあ。
具体的に何がどう変わるってわけでもない(しょせん下っ端なので)し、給料は元のままでも生活には困らないし。

偉くなったら昼夜逆転の勤務時間にしていい、とかだったらすごくがんばるんだけど。

Wikiで課題管理

仕事で、モジュール間の設計課題をPukiWikiで管理している。

もともとは親分が「設計過程も記録に残しておくことはできないのか? 新しい機種の設計を行なう毎に似たような検討を繰り返しているのはうんぬん」と言い出してきて、それを受けた中ボスが自分の使っていたPukiWikiを試してみましょうかと応じた次第。

アイデアは仲間と一緒に考える【解決編】(ITmedia Biz.ID)
実践！ 一人で思い浮かばないアイデアは同志を募って集める【解決編】(ITmedia Biz.ID)
Wikiを使ってプロジェクトの進捗管理【解決編】(ITmedia Biz.ID)
企業内でWiki活用の効果はどの程度? (/.j)

今のところ、trackerプラグインをカスタマイズして検討課題を管理してる。
1ページ中に複数の細かい項目が出てくるようになったのでこの方法も試してみるのもいいかも。

人の名前でページを作っておいて、各ページのTODO項目からリンク張っておくと、その人のTODO項目が一度に分かって便利なのに気が付いた(PukiWiki公式でやってた)。

課題のステータスはこれにならってToDo, Doing, Doneの3つに設定。
やはりカンバン方式にならって赤・黄・緑で分かりやすく表示してる。

あと、リアルタイムに進捗が分かるのが親分に受けが良い。
ただ、2時間おきに「緑が増えたね」などとプレッシャーをかけられるようになるとは予想外の事態wwww

モチベーション復活?

昇格審査の準備という非生産的なシバリがようやっと終わり、今週から通常業務に復帰。

ゲンキンなもので、もともとたいして仕事熱心だったわけでもないのに
開発に戻ったことでモチベーションが復活してしまった模様。
偉いったらないねwww

とはいえ、非生産的なことにかまけていたせいで、スケジュールがすごいことに。
2つある担当のうち、片方はほとんど手がついてない。

まあ、勢いでコードだけは8割ほど作ってしまったのだけど
…あわわわわわ、もちろんこんなインチキは設計が難しくないところだけに限ってますよ?

昇格審査終わった

ようやく昇格審査が終わった。疲れた疲れたw

1月末頃に人事部からの案内が届き、2月中旬に論文提出、下旬に面接。
まあ、実際には冬休み前に部門内の推薦があることがわかってて、出来レースもいいところ。
さらに言うと、推薦が近づくと査定が不自然に上がったりするwwww
これで割りを喰ってる人もいるわけで、なんだかとっても申し訳ない。

面接の時は久しぶりにスーツ着て六本木の本社まで出向いた。
聞かれた内容は、論文中の用語の定義の説明、目標数値の算出根拠、今後の取り組みなど。

面接官は開発系の偉い人2人、よくわからない人1人、人事部の人1人の合計4人。被面接者も4人。
いっしょに受けた人の中に役員の秘書をやってる人がいて、なかなか面白い話が聞けた。偉い人を前にしてもあまり動じない(ように聞こえる)のはさすが。

逆に、人事部の人が助け船を出さなければならないほどしどろもどろになってしまう人もいて、練習不足なのか、性格なのか、ちょっと気の毒なほどだった。
自分も何秒か絶句してしまったので、あまり人のことは言えないのだけど。

で、今のところ結果待ちだけど… どうなりますことやら。

モチベーション喪失

ここんとこ昇格論文(とプロダクトWの開発)でずっと忙しかった orz...
3連休あったけど、結局休日出勤だったし orz...
しかも自己啓発扱いで出勤扱いにはなってないしなあ orz...
で、役に立つことだったらまだガマンもできるけど orz...
前もって準備を進めておいたのに、土壇場でとんでもない難癖つけて台無しにしてくれるし orz...

人事部への推薦枠が限られているらしく、その貴重な資源を割りふってもらった以上は一応きばってみようかとも最初は思ったけど、そんな殊勝な気分はまるきりなくしました。むこう10年分くらいのモチベーションを使ってしまった2週間ですた。

まだ面接があるので多少準備はしないと orz...

新しいお仕事

機種Tの仕事は3月までに引き継ぎを終えることになっていて、それまではゆっくり過ごせると思っていたのだけど…
機種Wがちょっとまずい状況になっていて、1月からモジュールの手伝いにいくことに。また、人を取られてしまったのでさらに最近になってモジュール間I/Fの検討もやらされることになった。理不尽だ…

トラブルトラブルトラブル

ああ、今週は忙しかった…
QAテストが始まる直前にあるトラブルが発覚し、自分のせいじゃないってのを証明し、最適パラメータを見つけるための評価用プログラムを作った。
バスがなくなって久しぶりに駅まで歩いていったり、その電車すらなくなってタクシーで帰宅したり。
んで、上司と弁理士さんとシミュレータの業者さんと面談があって… いやはや、なんでこの時期に集中するかなあ。

ただ、会社の勤怠管理システムが"25:30"などという時刻を受け付けてくれるのには感動したw

CppUnit/cppunit-xのPukiWikiプラグイン

例えば

* ファイル操作/File
ファイルに関する操作をまとめたクラスです。

** オープン/open
ファイルを開く
** クローズ/close
ファイルを閉じる

とPukiWikiに書いたら、

/// ファイルに関する操作をまとめたクラスです。
class File {
    /// ファイルを開く
    open();
    /// ファイルを閉じる
    close();
};

や

class FileTest: public Test {
    /// File::openのテスト
    void test_open();
    /// File::closeのテスト
    void test_close();

    static Test *suite() {
        TestSuite *ts = new TestSuite();
        ts->addTest(new TEST_CALLER(FileTest, test_open));
        ts->addTest(new TEST_CALLER(FileTest, test_close));
        return ts;
    }
};

を出力するプラグイン作った。実戦投入して、便利だったら上流に投げてみようかなあ…

テキスト届いた

情報処理技術者試験(TE(ES))のテキストがamazonから届いた。

む、難しい… orz

なんか1ページ目からいきなりアナログ/ロジック混在回路の問題ですか。
一応電気電子工学科卒だけど、ピュアな論理回路くらいしかやらなかったから、かなりキビシイ。まあ、早めにテキスト買ってよかったと思うことにしよう。

ただ、紙が薄いから意外とページあるんだろうな。しくしく…

コードコンプリート 続き

で、この「コードコンプリート」、今は会社に持っていってしまっているので、家で読めない(泣)。

ことの発端は、今年度の部の方針。
各機種ごとにバラバラで作っていたソフトウェアを標準化しろという話で、これ自体はよくある話なんだけど、下期になってかなり具体的な戦略を出さないといけないことになった。

で、偉い人が打ち出した方針がコンポーネント化による標準部品化。ここまではいいんだけど、何を部品にすればいいのかでまったく方向性が見いだせない状況。こういう時のために上流行程ってのがあるべきなんだけど、「下流行程ができなくなったので上流行程をやってます(やってることになってます)」的なノリの人たちが考え付くはずもなし。

# こういう人たちが「上流行程」と呼んでいるものっていったい何なんだろうね、というイヤミはさておき…

なぜか自分も参考人として召喚されてしまい、意見を述べるはめになったのだけど、「コンポーネント化と言ってみても、ソフトウェアの構成上は単なるモジュールでしかないよね」というわけでくだんの「コードコンプリート」を持っていき、モジュール分割の方法を講釈してあげたという次第。

まあ、どういう検討結果を持ってくるかはお手並み拝見といったところ。

コードコンプリート

先日購入した「コードコンプリート」は、評判に違わない良書だった。

上流工程をあまりに重視するあまり、「実際の設計活動」の知見が失われているんじゃないかと思うことがあるんだけど、これがあるなら大丈夫かもしれないw

(実際のところ、要求分析以降の作業について自分の上司やリーダーが指導してくれたことなんてなかったし、その能力があるのかも疑わしい。
まあ、そういう職種の人じゃないんで別にそれはいいんだけど、だからといって現実の問題を解決する能力を開発しなくていいということにはならないんだけど… ぶつぶつ)

ただ、まだ上巻の半分くらいしかまだ読めてない… ボリューム多すぎ orz
しかも会社に持っていってしまったからなあ(続く)

Wikiで仕様書作成

続き。

texiファイルはフィルタで形式を修正して(最近立ち上げた)Wikiに掲示してる。こうした理由はいくつかある。

○新しい手法を導入する際の、心理的な抵抗を減らすため。大部の資料を作成してわけのわからない専門用語で相手を圧倒するのもそれはそれで楽ではあるんだけど、今回はちゃんと布教したかったので、ページ単位にすっきり納め「なければならない」Wikiを採用した。

○文書サーバが分散していて関係者全員がアカウントを持つマシンがなく、だれでもアクセスできる配布手段が必要だった。ウェブならブラウザさえあれば良く、事業所をまたがってもいいし、もしかすると興味をもったお偉方にも読んでもらえるかもしれない。

○完結した資料を作ると、ただケチをつけるためだけにレビューしようと言い出す輩がでてくる。指摘できる俺ってカコイイ、というチンケなメンタリティが透けて見えていやなものだが、Wikiならば「指摘点があればあなた自身が直してこの文書の改良に協力してください」で済んでしまう(相手がよほど偉い人でなければだけど)。

○自分自身もそうなのだけど、レビューアの立場になるとどうしても「何かを指摘しなければいけない」という強迫観念にかられ、どうでもいいようなことを指摘した挙げ句、わけのわからない防御的な記述だけを増やしてしまうという悪いパターンに陥りやすい。しかし、文書作成者とレビューアの立場が同じWikiならば、「レビューアだから何か言わなければ」というしがらみから解放される(もちろん、Wikiだろうと何だろうと他人が読むことをまったく意識しない文章を書く人もいるけど)。

○Wordだと複数人で同時に編集することができない。自動的なマージもできないと思う。

○で、最後の理由。仕様書をいちいち印刷するバカがいるので、強制的に複数ページになるWikiを選んだw はっはっは

texinfoで仕様書作成

仕事でちょいとしたチュートリアルを作る必要があったのだけど、いきなり本格的な資料を作ってもどうせ読んでもらえないと思ったので、少量ずつメルマガ形式で配布している。

で、元のフォーマットはというと、なんとtexinfo。これを複数HTML形式に変換し、数ページずつ「配信」する。1週間経つと完全なチュートリアルができるという、デアゴスティーニ商法も採用した。
HTMLで文書を配布するというのは多分前例がなくて、Word+Excel文化に毒されている職場にあってはなかなか思いきったことをしたぞとちょっと自己満足。

欝欝欝

最近会社が忙しい。
特許にカイゼン活動にコストダウン活動に検査活動に仕様書レビューに検討会にチーム活動検討に…

それでもそれなりにはこなしてはいたんだけど、某マネージャ(元上長)から社内試験の小論文の準備をしておくようにと言われ、一挙に欝に。
文章を書くのもデータをまとめるのも嫌いじゃない、いやむしろ好きなほうではあるんだけど、それもちゃんと理解してくれる人がいてこそなんだよね。
QC活動あたりから派生した「科学的手法」と称する疑似科学的なロジックを使わなければならないというシバリがあるので、やりづらいことこの上ない。ただの技術報告書作成だったらどれだけ楽なことか。

あー、めんどくさ orz...