徒然なるままに、社内SEがそこはかとなく書きつくるブログ

一児の父親であり情シスSEの30代男が、何かを書き記す練習をするためのブログ。

品質が良いってどういう状態?

システム業界では、QCDという言葉がよく使われる。クオリティ、コスト、デリバリーのことである。

このうち、特に「クオリティ」を誤って認識している人は多いように思う。

「品質が良い」とは何だろうか?私も社外人になってしばらくプログラマーをやっていた頃は「プログラムのバグが少ない状態」に決まってるだろ。と思ってた。

でもそれは品質の1つであって、すべてではない。

乱暴に言ってしまえば、発注者にとっては、そのシステムを使って(売上UPなどの)目的が達成できるのか、それだけなのだ。(実際には、安心して継続して使えるのか?とか細かい要求はあるわけだが)

これは立場の違いによるもので、ベンダ側としては、契約通りに収めることが求められるため、バグが少ない状態を品質が良いとするのも無理はない。

しかしながら、上流工程を担うSEや情報システム部に所属する人で、もし「ユーザの言った通りになっている。プログラムバグが少ない状態」が高品質と考えていたら、この機会にぜひ考えていただきたい。

 

メールの返信で避けていること

メールのやりとりにおいて、私が必ず気をつけていることがある。

それは、意見が分かれた場合にメールでやりとりをし続けないことだ。そういった予兆が感じられた場合、コミュニケーションの手段をメールから直接の対話に切り替える。

今ならZoomでもTeamsでも何度もよい。

理由は2つ、1つは問題が解決しづらいこと、もう1つは時間がかかること。

納得できないメールに対してさらにメールで返信をした場合、相手が本当に伝えたかったニュアンスを理解せずに返信をしようとしている可能性があること、また、自身のメールもそのニュアンスが伝わるとは限らないこと。その結果、さらに返信をしてきた相手のメールも自分の意に沿わない内容になっている可能性が高く、負のスパイラルに突入する。これは、メールの特性上、1回で発信する情報量が多いことが原因にあると思う。

問題が解決しないばかりかストレスにもつながるので、直接的な対話を有効的に使いたいものです。

妻への感謝

今週のお題「感謝したいこと」

私の妻に感謝を伝えたいと思う。

普段、妻に感謝の言葉を伝えることは少ない。些細なことで「ありがとう」は「サンキュー」程度は言うが、改まっていうことはない。

同じ場所にいるのが当たり前な家族に対して、改まるって恥ずかしいが、いつも感謝をしている。美味しいご飯を作ってくれ、子供の面倒や成長を考えて何度も先回りをしてくれている。

本当は仕事で成果を出して評価もされたいのに、時短勤務や制約の中で、評価も普通でもどかしい気持ちもあるだろう。

たまに愚痴は不機嫌なときもあるけど、文句を言わないでいつもやっている。

それに対して自分は自分のことが中心で、仕事も遅く何かをしてあげられているわけではない。

いつもは面と向かって言えないけれど、本当に感謝しています。

 

This week's title "What I want to thank"

I want to say thank you to my wife.

I don't usually say thank you to my wife. "Thank you" is a trivial thing, and "Thank you" is said to be about "Thank you", but it does not change.

I'm ashamed to change my family for being in the same place, but I'm always grateful. They make delicious rice, and they go ahead many times thinking about the hassle and growth of their children.

In fact, I want to achieve results at work and be evaluated, but in the short working hours and constraints, there will be a feeling that evaluation is usually frustrating.

Sometimes are grumpy, but I always do it without complaining.

On the other hand, I am centered on me, and I am not doing anything.

I can't usually say it face to face, but I really appreciate it.

 

社内SEが苦手なWBS

誤解を恐れず言うが、社内SE はプロジェクトマネジメントが下手だと思われる。
少なくとも私の職場はそうだ。
定量的な報告を求める管理職。もっともらしく数値化さえしていれば、言葉巧みな担当者であれば、上司を納得させるのは簡単である。
上司は、数値にしか興味がなく、本当にそうなのか?と鼻の聞かないなんちゃってが多いからだ。
そんな上司には、

星の王子さま (新潮文庫)

星の王子さま (新潮文庫)

をおすすめしたい。
話はそれてしまったが、システム開発者とは異なり、そんな上司への報告やら契約やら、課題管理というなの伝書鳩対応など、割り込み作業の多い社内SEにとって、キレイにWBSをひくのは難しい。
大抵の割り込み作業は計画外で、力業でこなしていることがほとんどではないだろうか。
数値にしか興味のない人は、簡単に数値化できる情報だけを信じ、定性的な情報や突発的な作業、複雑な条件により数値化が難しい問題を取り扱えない。
そんなときは、割り込み作業が日常どの程度発生しているのか、概算でも良いから「プロジェクトメンバーの総稼働の10パーセントは管理作業に掛かってるな」など、可視化していくことが大事だと思う。
そんな社内SEも、世の流れで内製化が進めば、必然的にこのようなスキルは求められていくだろう。
転職を考えているベンダー企業のあなた。
プロジェクトマネジメントの正しいスキルを身につけて、いまいちなPMが多いユーザー企業で、遺憾なくマネジメント力を発揮し、昇進を目指してみてはいかがだろうか。
…という私はぺーぺーなので説得力がありませんね。

嫁の誕生日

平日の忙しい日に嫁の(旦那・彼女・彼氏)の誕生日がきた場合、みなさんはいかがしますか?

①残業をして遅くなるから週末に祝う。
 もしくは遅い時間に帰ってから祝う。

②誕生日を優先して定時ダッシュ&ケーキ片手に笑顔で帰る

③仕事を休む

さまざまな考えかたがあるだろうが、日本人は①が圧倒的に多いのではないだろうか。少なくとも、そういう文化の会社に勤めていて、信じて疑わない人が大勢いるのだと思う。わたしもそうだった。

前職では当然①であったが、今の職場では、いくら忙しくても、今の状況を整理し、リプラン案を立て、本当にやるべきことなのか、本当に今やらなければいけないことのか、本当に自分がやらなくてはいけないのか、を考え、なんだかんだでメリハリをつけて帰りたい日には早く帰っている人が多い。
こういった常に思考を止めず、最適な計画を行う考えは、残業代(もしくは外注日)が発生する環境でのみ生まれる。
なぜなら残業に追加コストがかからない場合、社員の健康とトレードオフにさえすれば、追加コストなく成果物が生まれるからである。
そんなこんなで今の職場に不満のある方は、「遅延している=自分が遅くまで残業する」だけが正解ではなく、むしろ考えのない安直な考えであると思って欲しい。いや、そうしなくてはいけない時もあるが、案外、自分が思っているほどそんな時はすくないのである。
話が脱線してしまったが、ここ数日は諸事情で会社を休んでしまったので、今年の嫁の誕生日は①になりそうである。明日は家庭に亀裂が入るかどうかの決戦の日だ。

残業

残業続きの一週間だった。
昨今は、極度の残業による精神疾患や過労死が問題視されているが、その重要な要素としては「裁量労働制なのに」があると思う。
もちろん「常識の範囲内の」という前提を置かせて頂くが、非管理職の私は、ぶっちゃけ割増賃金となる残業は嫌いでないし、対価以上の働きはしようとモチベーションの維持にも繋がっている。
前職では裁量労働制で帰宅時間も遅かったが、まわりをみても「意識低い系」の人が多かった。厳密には、意識の高い人でも、モチベーションを保てなかったのだろうと思う。
裁量労働制は粗利を出せない弱い企業が、支払いを免れることで利益を出すために存在してるようなもの。裁量労働制を適用している企業において、社員に裁量など無いのだろうから、さっさと禁止して欲しいものだ。

課題設定

趣味、仕事問わず、成長する人と成長しない人の違いは「課題設定をし、PDCAを回しているか」にあると思う。
このブログを書き始めたのもそのひとつ、文才のない自分に対して、課題認識をさせるために始めたこと。