一般的に言うSEやPGの人に

「出世したいですか?」

と聞くとたいていの答えは

「出世は興味ないです。技術レベルを上げたいし、プログラム作るの好きなので」

となることが多いです。


で、

「でも、こんなシステムだめだ~、とか言ってますよね?」

と聞くと

「そうなんですよ。なんでこんな仕様にするんですかね。こうこうこういう風にしたほうがいいと思うんですよね」

と答えがきたりします。


で、

「自分でどういうのを作るか考えて作る方がいいですよね?」

と聞くと

「もちろんそうですね。自分で考えて作りたいです。そんなことなかなかないですけど」

となります。


で、

「それって、決定権がないから自分で決める場にいなかったり、権限がないからですよね?」
「やっぱり自分が決める立場になって、自分で納得いく形で作れるようになる方がよくないですか?」

と聞くと

「そうなんですけど、そういう立場になると打ち合わせが増えて、作る時間なくなるんですよ」
「現場からは離れたくないなぁ」

となるわけです。






気持ちはとってもよくわかります。
私は自分でものつくりをするわけではないので、プログラムの楽しさはわかっていないのですが、感覚的には理解しているつもりです。


大勢のSEの人はこのようなジレンマを持っているのではないかな、と




ここに書いておいて、答えがあるわけではないのですが、なんとかならないもんですかね?
人それぞれ志向があるので、誰でも権限を強くしたいと思っているわけではないと思います。

しかし、自分で決めたいと思っている人は、権限を持たないと自分で決めることもできないわけで。。。
となるとやっぱりある程度の出世というか、立場向上は必要になりますよね?

なんかいいやり方ってあるのでしょうか・・・
難しいところですね




ちなみに私は最終決定はシステム部門が責任を持って決めるべき、と思っているのでなるべく権限を持てるように環境を作るようにしている人です。
いまの会社でも最初はまったくといっていいほど決定権がなかったですが、徐々に影響力を強めており、拒否権は完全に握りました。

「それはやりません」

と言える立場になった感じです。
あ、出世したわけじゃないですよ


あともうちょいでほぼ思い描く環境が作れそうですが、そのもうちょいがなかなか高いハードルなのでどう超えるか考え中です。


WBS(WorkBreakdownStructure)って言葉をご存知の方も多いと思います。

プロジェクト初期(計画時)に、プロジェクトの成果物あるいは仕事(work)を詳細区分(breakdown)して階層構造(structure)化した図表を言います。
あるいはその図表によってプロジェクトのスコープ全体とその中で作られる成果物ないしは作業の関係を体系的に集約・把握する手法のことです。

これといわゆるTODOリスト、タスク表との差がいまいちよくわかりません。
誰か教えてくれませんか?



というのはおいておいて(いやまじで誰か教えて)、プロジェクト計画時に今後どのように進めていき、どのような仕事が発生し、それをいつやるのかはほとんどのプロジェクトで実施していると思います。

基本、これがないと無計画にプロジェクトが進み、抜け漏れが増え、プロジェクトは頓挫します。


では、WBSはどのように作成していくのか?

一般的な手法としては、最終目的・成果物を目指して、それを達成するために必要な要素を分解していきます。その要素を分類わけして記述していくことになります。
この時、分類わけの定義や記述する粒度は揃えておく必要があるので、最初に定義しておくべきです。
そうしないと分類ごとに記述レベルに差ができ、規模が把握できなくなります。

WBSには成果物と仕事を記述することをお勧めします。
そして、それを達成するためには時間とコスト、資源が必要になってきます。
それらを定量的に把握できるのもWBSの利点の1つです。




と、ここまでは一般的な話でマネジメントしたことがある人、そうでない人も自分の業務スケジュールを作る上で実施したことがあると思います。



私の手法はここからもう1手間かけます。
通常だと表の横軸は期間をあらわすと思います。その際、かかる期間と締め切りを線などで書くと思います。

私はこの線を箱で書きます。その中に縦軸に記載している仕事内容を記載します。
そして、その箱と箱の関係性を矢印でつなげます。

つまり、最終目標に向かって、どのような作業が必要で、どの工程が終わっていないと次に移れないのかを明示します。仕事には「これが終わらないと手をつけられない。つけても後戻りが発生する」場合や、「これが終わっていないとこの作業が終わったとは言えない」など関係性があるものです。
通常よく見るWBSではその関係性を表しておらず、単純に並行で進めなければいけないように見えます。
実はその仕事は単純に並行しているわけではなく、関係し合っているのです。
それを意識して進めることで、どの仕事がどこに影響していて、それが最終目標にどう関わってくるのかを視覚的に把握できるようになります。


なかなかどういうものか想像しにくいかもしれませんね。
実際に作ったものをアップするのが一番伝わるとは思うのですが・・・


この表を作成するのは非常に時間と手間がかかります。しかし、きちんと作成するとどれだけ複雑で規模が大きいプロジェクトでも全体感を把握できますし、問題が発生した際の影響範囲とスケジュール変更をすみやかに実施できるようになります。


小規模プロジェクトでは実感しにくいと思いますが、大規模になればなるほど効いてきますので、大型プロジェクトがうまく進められないと悩んでいる人がいらっしゃれば試してみて下さい。

ご参考になれば幸いです。

同一労働同一単価がワールドビジネスサテライトで特集されていました。


番組のトーンとして、

「同一労働には同一単価で支払われるべき」
「同じ仕事をしているのに待遇(正社員、派遣)によって賃金が異なるのはおかしい」
「オランダでは成功して失業率が12%から3%に落ちた」
「日本も同一労働同一単価の世界を目指すべき」
「賃金は人ではなく、仕事に支払われるべき」

といった内容でした



個人的には、(日本人的なのでしょうか?)完全な同一労働同一単価は賛成できませんね。
待遇も加味して賃金は支払われるべきだと思います。
同じ仕事をしていれば、どんな人でも同じ賃金であるべき、というのは乱暴な話だと思います。


正社員と非正社員に差はあって当然でしょう。
正社員は非正社員が負っていない責任や制約があります。
(転勤や配置転換もありますしね)

それらを無視して、同じ仕事をしているんだから同じ賃金を出せ、というのは違うんじゃないかと

また雇用する側からするといつ辞めるかわからない非正社員と(基本的には)ずっと働いてくれる正社員とで賃金を変えるのは当たり前のように思います。


逆に言えば、非正社員の人は一定の自由と引き換えに賃金が抑えられていると言えますね


海外では仕事に対して賃金が支払われることが多いそうです。
それに対して日本では人に賃金が支払われますね。

一長一短だと思うんですよね。
個人的には人に賃金を支払うが悪いわけではないと思っています。


だいたい完全にルーチンであれば同一労働であると規定することは不可能ではないかもしれませんが、何をもって同一労働を判断するのか?
仕事とは決められた範囲がありますが、そこにどれだけ付加価値を付けるかは人次第です。
範囲を拡大していくのも人次第です。
完全に同じ仕事をしていると判断するのは無理じゃないかと思うんですよね


もちろん、正社員と非正社員の間に非常に大きな差があるのは是正すべきだと思います。
しかし、格差があること自体は問題ではないと思うんですよ。
社会主義じゃあるまいし、格差をなくすことなんて無理ですし、格差があることで生まれる活力もあります。

何でもかんでも平等であるべき、とするのはある種の危険をはらんでいるのではないでしょうか。

前回(2009年2月27日)から随分間が開きましたが、RFPシリーズの続きを


0.はじめに

1.趣旨

2.要求

 2-1.業務要求

 2-2.システム要求

 2-3.運用要求

3.予算

4.期間

5.その他



具体的なシステム要求に書く内容ですが、そんなに難しい内容ではありません。

ちょっとシステムがわかる人なら常識といって良いレベルです。


たとえば・・・


1.ネットワーク

  複数の拠点で利用するために既存インターネット回線を使用する

  ユーザーインターフェースはWEBブラウザを利用したい

  →これでクラサバではなく、WEBシステムにすることが決まります


2.開発言語やDB、OS

  将来のメンテナンス、移行、他システム連携を考慮して汎用性の高いものにしたい

  開発者を確保しやすいものにしたい

  →ダイレクトにOSや言語、DBを指定しても良いかもしれません

   生産性が高くてもマイナーなものを使うと今後のメンテが大変なので、メジャーなものを利用することを指定しています


3.障害対応

  障害対応は重視したい

  ハードウェア障害、停電対応、ウイルス対応は十分考慮して欲しい

  →もちろんもっと具体的に書いても良いですが、ベンダー任せでもOKです

    ホットorコールドスタンバイやミラーリング、ネット回線二重化、無停電電源装置など色々細かいことはありますが、ベンダー任せなら詳細は任せてよいかと

    目安を示せるなら対応レベルを考えやすいので提示できると良いですね


4.情報セキュリティ

  個人情報を扱う箇所は厳密に規定することが必要

  →セキュリティポリシーを策定出来ればなお良いですが、世の中の情勢や対応策もベンダーのがノウハウがある場合が多いので任せても良いかと思います


5.レスポンス

  画面レスポンスなどパフォーマンス要求があれば記載


6.想定ユーザー数

  利用ユーザー総数と同時接続想定ユーザー数などを記載

  →ユーザー数に応じてハードウェア性能が変わってきます。

    多めにしておくのが無難です。



システム要求の概要はこんなところかと思います。

詳細はベンダーから確認が来ると思いますので最低限のところだけど抑えておけばユーザー企業としては良いと思います。


クリスマスキャロルを見てきました。

わざわざ記事にしたのは、初3D映画だったので


特段、3Dで見る必要があるのか?と言われるとなんとも判断が難しいところですが(笑



ただやっぱり遠近感とかが2Dで見るよりリアルに出てて、よかったと思います。
過去・現在・未来と時間を行き来するわけですが、浮遊シーンとかはよかったですね。
2Dより3Dのがより感覚的に見れると思います。

もっと3D効果が効いてくる映画だとさらにいいかもですね。


内容は、まぁ、あんなもんでしう
子供もいたけど、ちょっと難しいんじゃないかなぁ?
大人には若干物足りないかも?
あぁいう作品だし、あれはあれでもちろん最高なんだと思いますが。


ラストはすっきりくる内容なので、この時期にはいいと思います。
心は綺麗になる気がしますね。



ということで、普通に見ても面白いでしょうけど、3Dで見るとまた違った感じを受けるのでまだ見たことない人はお勧めです