月別アーカイブ: 2009年9月

白魔導師はファイアを使えません

最近、久しぶり…半年ぶり…にお客様常駐から社内に戻ってきました。
それで、あるプロジェクトのお手伝い…調査、プログラミングなどを少ししたのですが、その時のお話です。

プログラミングですが、当初はVB6(.NETではなく古い方のです)で作るとのことでした。
仕様自体も難しい感じでもなく、VB6自体の経験も…だいぶ離れてはいますが…あったので「まぁなんとかなるやろう」と考えていました。

ところが、色々あって、VB6では要求されている機能を提供できない!ということが分かり、プロジェクトの判断として「VB6をVCに変更する」となりました。
私はVCは未経験で、Cにしても10年以上前の新人研修で1,2週間ほどさわっただけで…その理解度は推して知るべしで、「ポインタ」が何かは知っていても、実用的に使うなど全然できないレベルでした。

プロジェクトリーダーの方にやんわりと「VCでは(私では)難しいと思いますよ。あまり期間もないですし、VCをできる人をアサインした方が良いと思いますよ」と提案はしたのですが「VCのプロに骨組みを書いてもらえるから大丈夫」という答えでした。
#実際骨組みはもらえましたが、そこから色々と足さないといけないわけです。

で、予想通りというか、VCの文法やお作法を理解しておらず、なかなか進まず、紆余曲折あって私の手から離れていきました。
そんな中で思ったことは…「白魔導師にファイアは無理やで」です。

依頼人:「このパーティ、白魔導師がいないのよ。ケアルが無くて困っているから、だから君(ケアルを使える白魔導師)、手伝ってくれへんかな?」
白魔導師:「いいっすよ」

…という成り行きでパーティに参加してみると…
パーティリーダー:「あぁ、ケアルはこの戦いではいらないから、代わりにファイア唱えて。黒魔法と白魔法の違いはあるけど、同じ【魔法】だから行けるっしょ?」
白魔導師:「えぇ~!?」

…てな感じでした。

まだ…
パーティリーダー:「接近戦要員が足りないんで、(効率悪いのは分かった上で)接近戦してくれる?」
…であれば、「(効率は悪いが)不可能じゃない」ので、何とかできたかもしれません。
適材適所のアサイン…について、色々と考えることがあった経験でした。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Massachusetts Office of Travel & Tourism via Visualhunt / CC BY-ND

ホワイトボード

所属部門にあるホワイトボードの話です。

自分の考えを整理したい時、打合せなどでよくホワイトボードを使います。
決まったことや議論の内容を書くこともあれば、絵や表などを描くこともあります。

むしろホワイトボードを使わない(=内容を「見える化」しない)打合せはこちらに書いたように私の中では「信じられない」ことの1つです。

その内容を共有するため、また後で参照するために、何らかの形で電子化したいことが多くあります。
ところがそのホワイトボードには、そんな機能がありません。

それなりの値段…アスクルで調べると0の数が1つ違う…がしますが、感熱紙プリンタ+USB付きのホワイトボードもありました。

この不況の最中、「そんな予算はない」と言われればそれまでですが、ホワイトボードの内容をせっせとPCに転記するコストもバカにならないと思います。

最近は高画質になった携帯電話のカメラで撮って、メールでPCに転送して…と工夫しています。
#セキュリティ的にNGだとこれもできませんが。

前述したように「(不況だから)予算が無いから、無駄を省く」のも大事ですが、一方で「生産性向上(効率良く働く)のために必要な予算を使う」ことも大事で、その見極め、バランスを取らないと、せっかくの仕事も楽しくできないなぁと改めて思いました。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

rawpixel.com

自分のテンションを維持する方法

コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。
#CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく…。

一方、人間は日によってももちろん、1日という中でも、同じタスクに対する生産性が違う時があります。
このポテンシャルの高低を小さくし、高いポテンシャルを維持する方法で私がしていることを書きます。

この手の…精神的、内面的なことは、人それぞれで、「自分に合う方法」を見つけることが大事かと思います。
この「自分に合う方法」を見つけ、それを定期的に見直し、実施していくことも大事かと思います。

自分と勝負する。

「このタスクなら2時間で出来る」という見積もりを目標として、勝負感覚(タイムアタック)でタスクに取り組みます。
(自分で決めた目標であれ)負けず嫌いな性格なので、集中して取り組むことになります。
時間を気にしてタスクに集中できないのは、本末転倒ですが…。

集中力を高くする効果もありますし、そのやり方に対しても「少しでも効率化できる方法はないか?」と工夫する意識も高まります。

Todoリストを工夫する。

Todoリストにタスクが溜まると「うわ、こんなにもある…」とドンヨリした気持ちになりがちだと思います。

そこを、少しでも進んでいると(少なくとも自分に)思い込むために、タスクの【□】に斜線を1本入れることで着手を示し、完了したらもう1本を入れる運用にして、着手と完了で2段階とします。
これで「少しでもタスクが進んでいるんだよ~」とリズムを作るようにしています。
また、大きなタスクだと腰が重くなりがちなので、すぐにできる(15分とか)タスクに分割したりします。

朝早く出社する。

私はだいたい1時間~1時間半程、早く出社しています。
周囲も静かですし、電話なんかの雑音もありません。結果、集中力が高くなり、生産性が高くなります。

ちなみに、プロジェクトでの立場やタスク状況にもよりますが、その早出で集中力が高くなり、高い生産性を維持し、そのままの勢いで午前中のうちに、その日の予定タスクを完了できたこともあります。

最初に書いたように自分に合う方法を見つけるためにも、「あの人、仕事が早いな」という人の方法や考え方なんかを参考にしてみると良いかもしれません。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: “Stròlic Furlàn” – Davide Gabino via VisualHunt / CC BY-ND

仕様変更における納得感の大事さ

システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。

その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプットの質まで左右することがあります。
#「モチベーションが下がる」ってやつです。

仕様の検討/決定をSIer(自分達)とお客様情報システム部と行っているとします。
この情報システム部はお客様エンドユーザから要望をヒアリングし、(SIerと一緒に)仕様に落とし込むのが主なタスクとします。

その仕様確定後に「エンドユーザからこういう要望が出たので変えてください」と、あっさりと仕様変更を出されるとゲンナリしてしまいます。
#これがモチベーションが下がる原因です。

最初に書いたように仕様変更自体が悪いわけではなく、その過程がポイントです。

(SIerと情報システム部が)決めた仕様も(サイコロを振って決めた適当なモンでなく)、いくつもの案のメリット/デメリットや、プロジェクトの目的に沿っているか?等、様々な側面を少なくない工数、期間を使って検討して決定したわけです。
#もちろんエンドユーザへのヒアリングも含んでいます。

ですので、その仕様変更を要求してきたエンドユーザに対し、現状の仕様となった背景や理由を説明して…

1:「それでもするのか?」という問いかけ
2:「(いったん決めた)自分の判断を覆してまでする意味があるのか?」をジャッジ

…をした上で、答えて欲しいものです。

そこまで考えていない…ひどい時には、思いつきで言っている…エンドユーザに限って、自分達((SIerと情報システム部)がその仕様変更に対して、QCDに対する影響、メリット/デメリット、他の仕様との整合性等を検討し、少しでもネガティブな要素が含まれる回答…例えば「OKですが、工数が1人日増加します」…をすると理不尽に怒り出したりします。

こういうことが繰り返されると「何いうても、すぐに根拠のない仕様変更されるし…」という気持ちになり、アウトプットの質が下がっていくと思います。

逆に「なぜその仕様変更が必要なのか?」をキチッと関係者で共有でき、落とし込むことができると「それなら、こちらの仕様もこうなるのでは?」「(その理由であれば)こちらの仕様がより良いのでは?」と自分達も積極的な提案、フィードバックを行い、プロジェクトの目的をより高いレベルで達成するアクションを取ると思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo credit: Eric Fischer via Visualhunt.com / CC BY