よくあるSE失敗ネタかと思っていたが、プロジェクトに全く必要の無い人材が
タイトなプロジェクトにやってきた。
必要なスキルはC++だった。
スキル表では相当な経歴の持ち主だったらしい。
ちなみに女性だがこの際まったく関係ない。
・仕様が読めない
・コードを書くのがとんでもなく遅い
・とにかくサンプルコードはないかと騒ぎ立てる
・自分が知らないから仕様を変えろと言う
・毎日だれかれ構わず意味の分からない質問を投げかけ、
他の人の生産性を著しく落とす。
誰もコミュニケーションを取らなくなってしまった。
今はただのドキュメント書きだ。
その人の書いたコードは全て捨てた。
(共通クラスに共通ではない処理をたくさん
埋め込んでいた。)
おまけにその人が一番単価が高いんだそうだ。
神よ。
仏よ。
短いスパンの仕事で良かった。
しばらくは私の中のワーストエンジニアとして君臨し続けるでしょう。
その調子で様々なプロジェクトを混乱におとしいれて下さい。
2008/08/07
コードを見ろ
そこにその人のスキルが表れている。
スキル表、職歴表、面接だけで判断してはならない。
物事を整理する力の無い人は、同じコードをコピペするのを
悪いとも思わないだろうし、複数人でのプロジェクトを
行ったことが無い人は、癖があるコードを書くかもしれない。
インデントが独特で読みにくい。
意味のないコメントだらけ。
オブジェクト指向どころか構造化すらされていない一本道のようなコード。
本人に説明してもらうと良い。
何故そうしたのかを。
そこで初めてプロジェクトに参加させるべきかどうか判断できる。
これが技術者面接だ。
技術力を見るのに技術の分からない人が面接官になるべきではない。
スキル表、職歴表、面接だけで判断してはならない。
物事を整理する力の無い人は、同じコードをコピペするのを
悪いとも思わないだろうし、複数人でのプロジェクトを
行ったことが無い人は、癖があるコードを書くかもしれない。
インデントが独特で読みにくい。
意味のないコメントだらけ。
オブジェクト指向どころか構造化すらされていない一本道のようなコード。
本人に説明してもらうと良い。
何故そうしたのかを。
そこで初めてプロジェクトに参加させるべきかどうか判断できる。
これが技術者面接だ。
技術力を見るのに技術の分からない人が面接官になるべきではない。
2008/05/21
ストレス続き
なんとプロジェクトから撤退、という方向で落ち着いてしまった。
ど素人がプロジェクトを回している状態で、間違いなく火を噴くプロジェクトになる予定だった。
ど素人が雑誌を見て思いつきで、プロジェクト運営する。
システム構築の経験の浅いコンサルタントが、その場限りの対応をひたすら続ける。
しかもユーザーも質が悪く、かつプロジェクトに対する意欲も見られない。
EA、CRUD、DFD、ER、汎化・・・・
それよりも先に、何が必要でどうすべきかを決めるのが先だろう。
これで正解だったと思う。
サラリーマン時代は、考えられなかった事だが。
ただ、リスクをユーザーに伝えられなかったのが心残りだ。
さーて、次なるあらたなストレスに向き合いますか。
ど素人がプロジェクトを回している状態で、間違いなく火を噴くプロジェクトになる予定だった。
ど素人が雑誌を見て思いつきで、プロジェクト運営する。
システム構築の経験の浅いコンサルタントが、その場限りの対応をひたすら続ける。
しかもユーザーも質が悪く、かつプロジェクトに対する意欲も見られない。
EA、CRUD、DFD、ER、汎化・・・・
それよりも先に、何が必要でどうすべきかを決めるのが先だろう。
これで正解だったと思う。
サラリーマン時代は、考えられなかった事だが。
ただ、リスクをユーザーに伝えられなかったのが心残りだ。
さーて、次なるあらたなストレスに向き合いますか。
2008/05/02
オブジェクト指向が救うのは誰か?
オブジェクト指向が本当に理解できていて、優れたデザイン(設計)が出来る人なら
まずその人が救われるかもしれない。
その人が救われるなら、その人が所属する組織もコスト削減になって
救われるかもしれない。
組織が救われるならもしかするとその周りの人たちも救われるかもしれない。
ユーザーはきっと一番最後。
でも最も救われているのはOO関連の書籍やツールを出してビジネスに結びつけている人たちだ。
間違いない。
まずその人が救われるかもしれない。
その人が救われるなら、その人が所属する組織もコスト削減になって
救われるかもしれない。
組織が救われるならもしかするとその周りの人たちも救われるかもしれない。
ユーザーはきっと一番最後。
でも最も救われているのはOO関連の書籍やツールを出してビジネスに結びつけている人たちだ。
間違いない。
2008/04/16
ストレス
ストレスとうまくつき合う方法があったら知りたいと思う。
色々な性格判断をやってみると、
ストレスには非常に強いという判断が出ることが多い。
しかし、以前の会社を辞める前に体調を崩したことがあった。
現象から判断するにストレス性であることが分かり、自分には意外に思えた。
楽天的であまり過去を振り返らないという、
良い方向にも悪い方向にも出る
習性を持っている自分としてはショックであった。
ストレスを認めてみたら楽になれた。
その先へ進めた気がする。
さて、今はまた別のヤツと戦わなければならない状況に陥っている。
さて、乗り越えられるか、逃げるか。
うーむ、迷っても良いか・・・
色々な性格判断をやってみると、
ストレスには非常に強いという判断が出ることが多い。
しかし、以前の会社を辞める前に体調を崩したことがあった。
現象から判断するにストレス性であることが分かり、自分には意外に思えた。
楽天的であまり過去を振り返らないという、
良い方向にも悪い方向にも出る
習性を持っている自分としてはショックであった。
ストレスを認めてみたら楽になれた。
その先へ進めた気がする。
さて、今はまた別のヤツと戦わなければならない状況に陥っている。
さて、乗り越えられるか、逃げるか。
うーむ、迷っても良いか・・・
2008/02/17
目線
システム開発には多くの立場の人が携わる。
その中には与えられたものをこなすだけをゴールとする人、逆に与える立場の人、
小さな範囲だけを見て働く人、ある程度の規模を見渡して働く人、
様々な人が居る。
書籍、Web等でも
・まずは実装技術が無ければ全体の話も出来ない
・全体を見通さなければスコープも明確にならない
などそれぞれの立場で書かれた文言が見つかる。
どちらも正論である。
上の目線、下の目線という事では無いと考えている。
最終的な目標はソフトウェアを作り上げること。
これに変わりはない。
そしてユーザーがそれを利用して価値を上げる事。
これを忘れてはならない。どの立場の人も。
そうすれば自分に必要なのが実装技術なのか、ヒューマンスキルなのか
見えてくる。
実装技術が伴わない人が偉そうに聞きかじった知識をひけらかす。
人をまとめる力のない人がマネージャをやっている。
そしてそれらは他の人より「目に付く」。
その結果、前述のような言葉が出てくる。
だったらそれが良く見えている人、あなたがやればよい。
簡単だ。
その中には与えられたものをこなすだけをゴールとする人、逆に与える立場の人、
小さな範囲だけを見て働く人、ある程度の規模を見渡して働く人、
様々な人が居る。
書籍、Web等でも
・まずは実装技術が無ければ全体の話も出来ない
・全体を見通さなければスコープも明確にならない
などそれぞれの立場で書かれた文言が見つかる。
どちらも正論である。
上の目線、下の目線という事では無いと考えている。
最終的な目標はソフトウェアを作り上げること。
これに変わりはない。
そしてユーザーがそれを利用して価値を上げる事。
これを忘れてはならない。どの立場の人も。
そうすれば自分に必要なのが実装技術なのか、ヒューマンスキルなのか
見えてくる。
実装技術が伴わない人が偉そうに聞きかじった知識をひけらかす。
人をまとめる力のない人がマネージャをやっている。
そしてそれらは他の人より「目に付く」。
その結果、前述のような言葉が出てくる。
だったらそれが良く見えている人、あなたがやればよい。
簡単だ。
登録:
投稿 (Atom)