placement new2006/06/01 06:36

C++再考

Ruminations on C++『C++再考』を読んでいたら、placement new が紹介されていた。今まで、placement new なんて聞いたことも無かったのでちょっと賢くなった気分。とはいえ、やはり、C++ は奥が深いです。へっぽこの雲にはなかなか全貌が見えないのでお仕事で使うのはちょっと心細いかも。まぁ、もうちょっと自信が付いたら使ってみます。

人材育成2006/06/02 07:20

ソフト開発の現場は、慢性的な人手不足のためなかなか良い人材に巡り会えません。まぁ、新 3K の現場なので仕方ないけど。でも、そのせいで、素人同然の人がプロジェクトに割り当てられることもしばしば。当然、ソフトの依頼人は、そんなことは知らないので人が増えれば、その分だけ成果物の品質が上がると思っている(そりゃそうだ。請求額も増えるからね)。でも、実際には、教育期間を経て初めて使い物になるというのがほとんど。これまで、出来る限り教育に力を入れてきたけど、そろそろ飽きてきた。別に、感謝されなくても良いのだけれど、なにも好き好んで恨まれることもないような。なかなか、チーム運営も大変です。ま、人材育成に成功すれば、後は、ほっとくと成果物が出てくるのでうまくいくとおいしいのだろうが。。。見習いプロジェクトリーダーとしては、その日を夢見て頑張るか?ってかんじ。

ベクトルとスカラー2006/06/09 18:27

ベクトルとスカラーは、高校で代数幾何を選択した人なら覚えていると思いますが、この言葉を東芝の社長から出てくるとは思わなかった。今日、たまたま読んだ雑誌のインタビュー記事で、ベクトルだけあわせてもダメ。個々の社員のスカラー(実力)を上げないと組織としての実力が向上しない。と言うような趣旨で書かれていました。 これ、確かにその通り。最近、CMMだ、品質会計だ、見える化だ、とはやりのプロセス改善に経営層は燃えているようだけど、実際にその作業を行うことになる現場には、ほとんど、これらの施策を実行するための実力向上教育が、さっぱり用意されない。用意されないなら、用意されなくても良いけど、そうすると、導入するプロセス改善の効果は誰が評価するのかがわからない。上司にしても、結局、PIMBOK に書かれていることを言うだけだし、プロジェクトの監査では、機械的に監査シートに○×を付けるだけ。これでは、まじめに、プロセス改善に努力しても全く正当に評価されない(どのような方法が好ましいのか、上司に判断する能力が無ければ、評価できないだろう)。 これでは、好ましいプロセス改善が行われているか誰も評価できないためにプロセス改善をやってますという自己満足しか残らない。

いつから、プロセス改善は目的になったんだ?成果は、監査シートで見るのか?生産性の向上は、実現しなくても良いのか?など、いろいろと疑問が浮かぶ。目的と手段を明確化して、もっと、プロセス改善を道具として活用するために、もっと、トップはよく考えて欲しい。現場から、意見を上げても、なかなか取り上げてもらえないのは、自分のプレゼン能力の問題かもしれないけど、社内的にもプロセス改善がなかなか根付かないのは、やはりプロセス改善を導入するプロセスに課題があるとしか言いようがない。

リーダーシップの条件2006/06/15 05:25

最近、複数人でと仕事をすることが多いけど、その時に、効率よく業務を進めるために必要なことを考えてみました。 自分で思いついたのは以下の2つ。

1 質問力 2 WBS

質問力は、相手に誤りを理解してもらうために磨く必要があると思います。人間、直接に誤りを指摘されると、反射的に反発することが多いですが、自分で気がついた(と思わせれば)意外と、素直に訂正するものです。ただ、これの欠点は、相手が自分で誤りに気がついたと誤解させることにあります。 (要は、こっちの苦労が相手に伝わらない)

WBS は、当然ですね。複数人での作業では業務を如何に切り分けるかが重要で、効率的に進めるためには先を見通した業務分割が鍵を握ります。ソフトの開発では、手戻り工数を無くすために要件管理の精緻化を目指しているのですが、私に言わせれば、WBS の精緻化の方がより効果的。まぁ、WBSの精緻化を目指すと、要件管理の精緻化よりもさらに難易度が上がるので、なかなか、難しいのかも。

いずれにせよ、業務の効率化は、ドキュメントの作成やプロセスの改善というよりも、業務をよく知り、適切にWBS を行うことの方が大事ですね。 ソフト屋さんは、どうしてもコードを書くことに執着しますが、もうちょっと広い視点で見ることも必要かと思います。