2010年07月23日

離職率の高い会社

その会社はシステム開発を専門にする会社で、50人入って50人辞めるという離職率が高かった。

その理由と1つとしては、給与が低いことにある。
残業がしやすい風土もあり、給与の低さをカバーするように月60時間以上が普通だった。

中には残業しなくていい仕事もだらだらとしながら残業し、効率はどんどん悪くなっていた。

また、残業が多いと「あいつはがんばっている」と評価も高くなる。
仕事をさっさと終えても評価につながらないし、給与も低い。

完全な悪循環となっていた。

離職率の高さの影で、転職者のほぼ全員が次の会社でSEを希望していなかった。
そもそもSE向きでない人の集まりだった。
(その会社にいたためにSEがいやになったかもしれない・・・)

自分がその会社をやめるまで、SEを希望していたのは1人しかいない。

IT系の会社限定で、次もSEがしたい人が少なすぎる会社は要注意だ。
posted by momo at 00:18| Comment(2) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年07月07日

効率よくコーディングできない

数十個あるバッチ処理の初期化処理に機能の追加をプログラマにお願いした。

その機能は、DBのあるカラムが更新されるまでリトライする機能で、導入済みのサンプルソースを渡した。

そろそろできたかと聞いてみると、まだとのこと。
ソースを見てみると、サンプルソースと違うコーディングをはじめていて、よく見ると正しく動かない。

サンプルソースのある部分をコピーして、パラメータを変えるだけで済むことだった。
仕組みは変えずにサンプルソースを参考に忠実に修正してほしいとお願いした。

しばらくして聞いてみると1本は完成し、2本目に入っていた。
1本目ができたら、それ以降は完全にコピーでいい。

しかし、2本目を見ると1本目と若干違う修正になっている。

同じ機能の処理を入れていくのに、それぞれ違ったコーディングをするとバグを起こしやすいし、そのあとの修正も面倒になる。

結局、全バッチのソースを確認したところ、コピーしなかったと思われるような修正したため、バグのあるソースが見つかった。

サンプルソースを参考に機能を入れていくのに、1本目は定義やパラメータの調整はいるものの、他は1本目のコピーでいけるようにコーディングする必要がある。

効率よく修正していけば、バグも出にくいはずだ。
posted by momo at 01:34| Comment(1) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年04月22日

くせのあるプログラマ

どんなプログラムでもなんとなく動くシステムができてしまう。

仕様に強いシステムエンジニアを並べても、実際に開発できませんというエンジニアもいる。

この業界ではプログラム自体が軽んじられているが、結局システムはプログラミングがなければ動かない。

プログラミングの生産性は数倍から変わってくるし、システムの安定性や保守性まで入れると数十倍になる場合がる。

単に開発のスピードだけでなく、作り方がシンプルだと仕様変更などの保守のスピードも断然違う。

特にルールなど説明しないとき、プログラマの良心にまかせられるが、ソースを見れば「くせのあるプログラマ」かどうかわかる。

逐一、ソースのレビューができないため、仕様変更やトラブルのときにソースを見ると、とんでもないことになっている場合がある。

ここでシンプルというのは、極限まで短くしたソースという意味ではなく、読みやすくバグの生まれにくいソースのことだ。

プログラミングに正解がないため、作った人それぞれのソースになるのも事実だ。

くせのあるプログラマはソースに個性を出る、統一感がない、読みにくい、などの特徴がある。

例えば、ソースの個性とは、必要のない箇所などでやたらと引数の多い関数を作ることだ。その関数自体の中身がうすいことが多い。

標準化させたい関数をせっかく作ったからと、全くそこまで持つ必要のないデータでその関数にむりやりあわせ、そこがボトルネックになったりする。

統一感という点では、定数をやたら使うが、リテラルで設定値を埋め込んである箇所がある。
また、ある同じ意味を持つような配列で、0からはじまっているものもあれば、1からはじまるものもあったりする。

読みにくいという点では、データ構造を持てるプログラム言語で、次数に特別な意味を持つ似たような配列をたくさん作り、何をどこに入れているのか追いにくいソースを作ったりする。

また「くせのある」というより「下手な」にあてはまるのは、やたらとソースのバックアップを取るプログラマだ。
仕様変更が決まって、自分だけがコーディングするなら、プログラミングの方向性が決まれば、バックアップは1回でよい。

方向性や手法が変わったときにもう一度バックアップすればいいが、リリースするまでに修正箇所を比較するのは、修正前のソースと修正後のソースだ。

その間のバックアップは自分以外がみると煩わしいものになる。


プログラマにお願いする場合で直接伝えられる機会があるなら、プログラミングに最低限必要なコーディング規約のほかに、プログラムレベルでのデータ操作やデータ構造を伝えたいところだ。
posted by momo at 23:55| Comment(2) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年04月18日

情報セキュリティスペシャリストを受験

今日、情報セキュリティスペシャリストを受験した。

昨年、データベーススペシャリストに合格したので、午前Uからの受験だ。
午前は当日に解答が出ていて、答え合わせをしたところ午前は通過していた。
発表は6月下旬だ。

情報処理試験は国家試験で難易度や専門分野によって試験は12種類ある。
国家試験ではあるが、弁護士などと違い、免許的なものもない認定試験だ。

会社によっては試験に合格すると、一時金や技術手当が出るところもある。
それ以外で、特に会社以外でのメリットが見つけられない。


情報セキュリティスペシャリストの試験内容は、専門レベル的にはそれなりに高いが、実際セキュリティの仕事をしている人にとっては、体系的で一般的な知識を問う問題が多いと感じるだろう。

経験のない人に取っては最低限、必要な知識を問われる。
情報処理試験は必要ないと言い切る人もいるが、そういう人に限って体系的な知識の元で仕事ができていない。

資格はなくても仕事はできるが、あって損はない知識が身に付く試験は他にはないのも事実だ。

また試験に合格しても、いきなりシスコのルータが触れるわけではなく、メーカーの機器の特徴や独自の機能を使うには別の知識が必要になる。


試験会場に行くと、IT系の仕事をしている人がこんなにいたのかと驚かされる。

一時金目当ての人もたくさんいるだろう。

それでも忙しい中でコツコツと勉強してきただろう人たちを見ると、何かうれしいし、自分もがんばっていこうという気持ちになる。
posted by momo at 23:42| Comment(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年04月15日

ひとり言の多いエンジニア

今まで、ひとり言の多いシステムエンジニアやプログラマで、仕事のできる人を見たことがない。

「こういうことか」「ああそーか」「ちっ」「しまった」などのひとり事を言う。

なぜひとり事をいうのだろうか?


1つはまわりに対するアピールだ。
おれは仕事をしているんだというアピールかもしれない。
ある意味、純粋だと思う。

アピールかなと思ったあるエンジニアにまかされた仕事はほとんどすすんでおらず、あのひとり事はなんのアピールだったのか今でも分からない。

もう1つは本当に困っている人だ。
普段から「なんでだ」「うーん」などいう人は、本当に何も解決できてない。

「ああそーか」と聞くと解決したのかと思うが、解決していない。
得てして難しいこともしていない。

複雑なロジックを考えていて、思うように動くと「やった」と思うこともあるが、ひとり事は言わない。
淡々と仕事をこなす人は、心の中で思っても口に出てこない。


どちらであっても、周りの人にとっては迷惑この上ない。
機嫌でどなり散らす人よりはずっとましだが、アピールか困っているのかわからないひとり事には、周りも突っ込まない。

逆に普段言わない人がひとり事を言うと、周りが気になって聞いている場合が多い。

周りに迷惑をかけず、静かに仕事をしたい。
posted by momo at 00:15| Comment(2) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年04月14日

仕様の伝わらないプログラマ

システムエンジニアで最も重要なもの技術だ。
技術があればいいという職場はほとんどない。

最低限のコミュニケーション力は必要だ。
システムエンジニアは顧客のやりたいことを聞き取り、それを実現するための方法を伝えて合意を取ったり、コミュニケーション力はあればあるほどいい。

プログラマも同じことが言える。
ただプログラミングをしていればいいとは言えない。

エンジニアが仕様を伝える場合でも、その意図を汲み取ったり、開発にかかる工数やなぜその工数がかかってしまうのかを確認したり、最低限のコミュニケーションが必要だ。

職場のあるプログラマは、伝えた仕様はほぼ間違って汲み取って、思った以上に工数がかかる。

普段から無口ではあるが、リリース時期が近くにきても状況も報告してこず、コミュニケーションがとれない。

ほっておくと工数が膨らんでしまうため、実現方法や修正箇所を細かく伝えるが、しばらくしてきいてみると伝えた方法と違う方法進めている。

その方法は工数がかかるから、前に言ったこの方法がいいよと伝えると、はじめて聞いたようなことを言ったりする。

この戻りがどんどん納期を遅らせる。
プログラミングも遅いため、よけいに時間がかかる。

1日中、逐一、そのプログラマに状況を聞くわけにもいかず、困っている。

せめて実現方法を伝えているのだからその方法で実現してほしい。

プログラマに限らず、たとえ無口であっても、仕事の進め方や状況の報告をするのは社会人としてのマナーだ。
posted by momo at 23:56| Comment(3) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年04月07日

運用系の仕事に変わって

最近、開発系の仕事から運用系の仕事に変わった。
退職した人の仕事を引き継ぐことになったためだ。

運用系といっても、ユーザの要望を聞き取り、一応仕様は考えるが、そのまま開発ベンダに投げて工数見積もりを取る。
そして修正したモジュールを検証して、導入するという仕事だ。

仕事を引き継いで1ヶ月になるが、どうも今までの仕事からするとシステムの仕事とは言いがたいにと思ってしまう。

仕様は、仕様書は流れが書いてあるのみで、E-R図もなければ、シーケンス図のようなものもない。全体の流れもわかりにくい。

同僚となったメンバーは入社から数年間、この仕事をしていて、満足しているようだ。
もちろんこの仕事以外は知らない。

そして開発経験もないし、開発ベンダに丸投げだから、工数の見積もりもできないらしい。

仕様を覚えておくことがシステムエンジニアの仕事の本質の部分であるが、それだけがシステムエンジニアの仕事とは思えない。
その特別なシステムの仕様というだけで、他では全く使えない。

開発ベンダに丸投げし、検証して導入するということが続けていけそうにない。

ずっと開発で行きたいと思っていただけに、非常に残念だ。
posted by momo at 22:18| Comment(1) | 日記 | このブログの読者になる | 更新情報をチェックする

2010年03月17日

ユーザを考えないプログラマ

あるプログラマの作ったシステムを検証したところ、画面表示だけに数分かかっていた。

集計処理やマージ処理などはあるものの、データ数からして数分もかかるはずもないし、この表示だけに数分かかるものをユーザがokとするわけもない。

ただ動くものを作ればいいというものでもない。

ソースをみると、無駄なループや非効率なマージ集計処理があった。
また、何よりソースが読みにくい。
人のソースは読みにくいものだが、特定箇所を直すと他の箇所にも影響の出る組み方もしていた。

ここはこうしてるから遅くなる、この処理は非効率だと説明したが、自分が組んだプログラムを直すのも遅く、仕方なく半日かかって自分が直した。
ソースは半分以下になり、処理は1分を切った。

「この条件を入れれば早いです」と言っていた。
遅いのが分かっていて完了としたり、プログラムを組むことに夢中でユーザの使う姿が浮かばないのならば、プログラマと言えない。

ソースは短く、読みやすいのがいい。
こういうプログラマはこだわりが強かったり、プログラムに個性を出そうとする。
動くことは最低限必要だが、処理が遅い、ソースも長いだと何もいいこところはない。

ソースが長ければ、今後の保守にも影響してくる。
posted by momo at 23:45| Comment(1) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年09月27日

会社のメールで顔文字を使う

会社のメールで顔文字を使ってくるシステムエンジニアがいます。

例えば、こんな顔文字です。

m(_ _)m
(T_T)

そのエンジニアのメールは100%が質問のメールです。
役職的に私のほうが上で、直接ではありませんが上司にあたります。

普通、会社やビジネスのメールで顔文字は使わないですよね。
常識から考えて、上司や顧客先に使うことはありえないです。

そのうえ、メールでのしゃべり口調も使っています。
「そうだと思って、さっきまで調べてたところなんですよねー」って上司にですよ。私なら考えられません。

顧客へのメールは大丈夫かと心配になります。

それで回答を返信すると、「ありがとうございます。m(_ _)m」と返ってきます。

部下からこんなメールをもらって、残念ながら、気さくなやつだなぁと思えません。
会社がメールのマナーを教えてくれないとはいえ、顔文字を使うのはやめましょう。

上司から部下へ、和ますために顔文字付きのメールをもらったことがあります。
上司からならまだよいのかもしれません。
ただ、10年間システムエンジニアをやってきて、顔文字を使っていた上司は1人だけです・・・。

上司によく思われてないではないかと悩んでいる方へ。
顔文字やしゃべり口調のメールをしていませんか?
posted by momo at 23:05| Comment(2) | 日記 | このブログの読者になる | 更新情報をチェックする

2009年09月25日

優先順位を決めずに走って火を噴くプロジェクト

仕事がいつもいっぱいいっぱいになるシステムエンジニアがいます。

優先順位を決めて、システムの新機能や修正を行うのが普通のことです。

そのシステムエンジニアは顧客の要望の順に開発をすすめていました。
すぐに必要ない機能を開発し、すぐ必要な機能はあとまわしです。

当然、顧客は怒ります。
そして、そのエンジニアは上司に困っていると告げ、上司は私に手伝ってやってくれという、いつもの流れです。

工数も読めないエンジニアですし、質問のメールを私に投げておきながら、その間、忙しいとかで自分で調べることもありません。
質問を投げたら別の仕事に取り掛かる始末です。

また、こちらから回答しても、すぐに確認せず、また後日質問です。

顧客がすぐ必要な機能なのか、代替えはできないか、などで優先順位を決めていきますが、顧客と交渉して妥協案や着地点を決め段階的に導入していくなどの調整を行うのもシステムエンジニアの仕事です。

もちろんソースが読める、組めるのも当然のことです。
そのエンジニアはソースが読めませんし、読みません。

おおよその工数もわからないため、交渉もできません。

こんなシステムエンジニアがプロジェクトマネージャになると思うとぞっとします。

顧客との調整が上手くなくても、工数もわからないと優先順位も決められません。

このプロジェクトはいつも火を噴いています。
今日も火消しです。
ラベル:仕事
posted by momo at 23:48| Comment(1) | 日記 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。