高校生のなりたい職業の第3位にプログラマ

約3ヶ月かけたプロジェクトがそろそろ終盤に差し掛かってきました。
納期が近づくにつれ 仕事の負荷も上がってきており、最近 忙しくなりつつあります。
プロジェクトの進捗がやや遅れていることもあり 当初 今週末は休日出勤を予定していました。

ですが、結局 私を含めてチーム全員を休みにしました。

最近 残業＆休日出勤が続いていたということもありますし、あんまり無茶を強いると エース格の派遣の人がプロジェクトから離脱する恐れもでてきますし、まぁ無茶はよくありません。
何より私自身が疲れているんで 休みたかったというのが一番大きいです.

仕事が遅れたからといって、世界がひっくり返るわけじゃありませんしね(^^;)

さて、前職での私の上司は 典型的な体育会系型SEでして、残業や休日出勤当たり前の人でした。何より辛かったのは同様の労働を部下にも要求してきたことです。
そんな上司にうんざりしたのが転職した大きな理由のひとつだったりするんですが…
そういう経緯もあって 残業しまくり 休日出勤しまくりで工程遅れを挽回するという手段はなるべくとりたくありません。

現実はなかなか うまく行かなくて休日出勤や残業せざるを得ないのが辛いところです。

ここを見ると高校生のなりたい職業の第3位にプログラマが入っています。
果たして 現実を知っている高校生はどれだけいるんでしょう。
彼らが就職するころには少しは状況が改善されているといいんですけど、まぁ 変わらないんでしょうねぇ…

プロジェクト運営は難しい

これはいつものことなんですが、やっぱり プロジェクトの運営って難しいです。
当初の見積もりどおりに うまいこと進めることに成功したプロジェクトにめぐりあったことは一度もありません。

私のチームの場合 納期に間に合わせるという点では、一応どうにかしています。
しかし 残業しまくり、デフォルト土曜日出勤 でどうにか帳尻を合わせているのが実情です。

原因はいくつかあるんですが、大きいところでは
私の引く工程にはマージンがほとんど入っていないのがまずいです。
わかっちゃいるんですが、工程にマージンをあらかじめ入れるのはなかなかできません。

その分 事前に発生し得る作業は工程をできるだけ細分化して、見えている工数に対する漏れはほぼないようにしているんですが…
しかしながら やっぱり 想定外の作業は発生します。

想定外の作業が平均○○％発生するというのがわかれば、それを工程にも盛り込めばすむんですが、あいにくそんな数値はありません。だから 工程に マージンをとりこむことはなかなかできません。
「この工数がマージンです」ってことが 上司にバレてしまうと ほぼ確実にその工数は削られます。

冷静に考えると、納期をずらさずかつ機能も削らず、さらに 残業や休日出勤以外で 想定外の作業に対応するためには やっぱり工程にある程度のマージンは必要です。

マージンに対して上司を説得できる根拠があればいいんですが、何かいい方法はないもんでしょうかねぇ…

システム開発費を値切る理由

悪態のプログラマさん経由ThinkITからの引用です。

　予算の関係で、開発会社から出された見積もりに対して値引きを交渉することもあるでしょう。値引き交渉についてはそれぞれ事情もあるでしょうから、是非について一概にはなんとも言えませんが、よく聞く話であり、実際に私も多く経験しているのが、発注側の企業体質として「見積額からいくら値引きさせたか」が、発注担当者の社内評価になるというものです。

　その値引きへの根拠もなく、とりあえず値引きしたかどうかを上司は尋ねます。こうなると、開発会社も値引きされることを前提に見積額を算出するようになります。「値引きありき」のような考え方はなるべく避けたほうがいいでしょう。思い当たる企業の方も多いのではないでしょうか。

そこそこ大きい会社だとよくある話ではないでしょうか。

私の場合は お客さんから あらかじめ 数％高めの見積もりをもってくるようにと言われてました。
例えば、わざと１０％高めの見積もりを提出して、それを対面のお客さんが１０％値引きするという形をとるわけです。こうすれば お客さんは「見積り額から１０％値引きさせた」という実績を作れるし、こちら側としては初めから値引き分を考慮した見積もりを提出しているので痛くも痒くもないというわけです。

こんな手続きに意味があるのかいわれると 無意味なんですが…
その当時の上司からは何年も続いている慣習だと教えられました。

なくても困らないけど 決まりだからとりあえずやっとけってなノリですから、
まぁ相撲の儀式的動作みたいなもんでしょうね。

最近ソースを書いてない

私はソフト開発で チームの取りまとめ役(いわゆるリーダー役）を行う場合 ソースコードは書かないようにしています。
そのために 工程を作成するときは 自分へプログラマーの仕事を割り振りません。

自分にコードを割り振らない理由は大きく２つあります。
　１つ目：取りまとめ役はコードを書きつつ片手間でできるような作業量ではない
　２つ目：取りまとめ役のコード作成に進捗遅れが発生したときに 取りまとめ不在の自体を招く

私の経験上、プロジェクトが頓挫する場合 プロジェクトの取りまとめ役に問題があることが多いです。
取りまとめ役がいないため プログラマが仕方なしに取りまとめを兼任するとか、逆に 人が足りないために取りまとめ役が プログラマとして担当ソースを持ってしまうとかいうパターンがやばいですね。

プログラマは普通 自担当箇所の進捗が遅れると 自分の進捗遅れ挽回に集中します。
１プログラマが進捗遅れ挽回のために自作業に集中するのは一向に構わないんですが、取りまとめ役が自作業のみに集中すると チームが動かなくなります。他のチーム員に進捗遅れが発生したような場合に 手を打てなくなりますし、進捗遅れで危機的な状況にあるという上長への状況報告も止まりがちになります。

そんなわけで 最近は ソースコードを書いてません。
どーせコーディングはしないだろうと考えて デバッガもアンインストールしてしまいました。

でも、取りまとめをやって 人を動かすよりは ソースコードを組んでるほうが楽しいんですよね。
ソースコード書くの好きですし。
仕事を効率よく進める(というか チームをうまく動かす)ためにソースコードを書かないように心がけているものの、できれば プログラマもやりたいという ジレンマを抱える今日この頃です。　

言い訳から信頼は生まれない

「Life is beautiful」の「リーダーシップについて思い出したこと」というエントリからです。

------------------
プロジェクトの責任者の仕事は、「プロジェクトの成功に必要な作業の手配をする」だけでは終わらず、それらの作業が確実に実行されるようにして結果を出してこそ初めて評価されるものだ、そしてうまく行かないことがあっても決して他人のせいにしてはいけない、という認識である。
------------------
人間、「何としてでも結果を残す、言い訳は絶対しない」という意気込みを持って仕事をすると、ものすごく強くなれる。
------------------

私は 仕事での言い訳は極力しないように心掛けています。
ですが、ソフトウェア開発で ミスや工程遅れ等 問題が発生したときに、「駄目だなー」って人ほど よく言い訳をします。当人は言い訳することで頑張って自分を正当化してるつもりなんでしょうが、ぶっちゃけ見苦しいです。

同じ失敗を繰り返さないために なぜミスしたのか、なぜ工程遅れが発生したのか その原因を突き詰めることは必要です。ですから 私は問題が発生した場合は必ず「何故？」と聞きます。でも私が聞きたいのはあくまでも問題点の原因です。しかし、「駄目」な人は 問題点の理由ではなく 自分が悪くない理由を必死に説明しようとします。

まぁ、言い訳が必要な場合があるのは認めますが、まず 言い訳ありき な人は信用できません。とにかく自己正当化して「自分は悪くないんだ」と言いたい気持ちはわからないでもないですが、その行動は何も生み出しませんし むしろ不信感を募らせます。

重要なことは 上記の引用にもあるように「言い訳をしない」ことを心がけることだと考えます。
「言い訳をしない」ことを心がけると、許してもらえなくなりますので 必然的に仕事をどうやってうまく進めるかを真剣に考えるようになります。するとそこで責任感が生まれてくるんではないでしょうか。

バグの水平展開

バグがでた場合 当然改修しなければいけませんが 作業フェーズによって その作業量は大きく変わります。

例えば コーディングフェーズでは 問題箇所を修正してデバッグするだけですので 短時間でOKです。
しかし 出荷した製品でバグが出た場合は もう大変です。
製品のパッケージングやらレビューやらデグレード試験等 様々な作業が発生します。

そんなこんなで製品にバグがでると色々としなければならない作業があるのですが、中でもプログラマにとって面倒作業の一つが「バグの水平展開」です。

「バグの水平展開」とは 似たようなバグが他に潜んでいないか探して対策することを指しますが、これが非常にやっかいな作業です。

例えば セマフォ開放漏れがバグの原因であった場合、セマフォの獲得/開放を行っている場所を全部チェックしなければいけませんし、メモリリークがあった場合、メモリの獲得/開放箇所を片っ端からチェックしなけりゃいけません。

しかし、セマフォの獲得／開放関数や、メモリの獲得/開放関数はバンバン使用しますので、検索してチェックすると言ってもその量が半端ではありません。ましてやプロジェクト全体に対するチェックをしますので とにかく時間がかかります。

そんなわけで できることなら避けたい作業なんですが 今回は私が対応せざるを得なくなっちゃいました。
というわけで 今日は一日中 セマフォの獲得・開放まわりをひたすらチェックしていたんですが…
単調作業なくせに量が多いし、限界です。

だれかに代わってほしいんですが、代わりになる人がいません。

もう 勘弁してください(TT)

コードレビューとプログラマのプライド

今日はベテランプログラマのコードレビューをやったんですが、プログラマをちょっと怒らせてしまいました。
１関数が長すぎるんで 分割してほしいと言ったんですが、これが彼のプライドを傷つけちゃったみたいです。

でも レビューしたソースは、１関数が３００行ぐらいと長く、さらにifやらforやらのインデントが７、８段ぐらいまで深くなっており、かなり見辛くなっていました。ちなみに改修前は５０行ぐらいで インデントも３段ぐらいです。（C言語です。）

わからない人にはさっぱりわからないと思いますが、私のコードに対する美的感覚からは耐えられませんでした。

そんなわけで、今回 彼は「仕様」がわけわからんと憤慨していたわけですが、
プログラマのプライドを傷つけないようにソースコードの修正依頼をだすのは難しいです。
今回の件に関すれば、私はソースコードの構造が見にくいといっただけで、仕様を変えろとは言ってないんですが…

プログラマって、どんな形であれ ソースコードを否定されると 自分を否定されたような錯覚を持ってしまいますので、細心の注意がいるなぁと改めて考えさせられました。

なんにせよ、コードレビューは難しいです。

フローチャートは嫌い

私はフローチャートが嫌いなんですが、その理由がなかなか人にうまく説明できません。というわけで ＷＥＢ等を調べつつ、自分の考えも混ぜて フローチャートの問題点をまとめてみました。

まず、フローチャートは、アルゴリズムやプログラムを分かりやすくするための図です。
これがよく使われる理由は、とにかく「書きやすい」点につきます。
これがフローチャートの最大の長所ですね。

そして、プログラムやアルゴリズムが さらに見やすくなります。
まぁ、この長所は対象プログラム アルゴリズムが簡単な場合限定ですが。

…長所はこれだけです。

次に欠点を並べていきます。

欠点１：細分化が苦手

ソフトウェア設計で重要なことは、複雑なものを如何に簡単にわかりやすくできるかという点です。ここを重要視することで 設計フェーズで作りこむバグを減らすことができます。

簡単化を行ううえでの 基本的な作業が機能の細分化です。
巨大な処理や複雑な処理を一気に考えるのは難しいので 小さい単位に分割して 小さい単位ごとに検討するようにします。

たとえばＣ言語の場合、複雑な処理を簡単に表現するために、ある程度まとまりのある部分をまとめること(関数化)を行います。これを繰り返すこと、つまり「複雑→細分化」はプログラムを作成する上で基本です。

しかし、フローチャートはまとまりや関連のある処理群をまとめること すなわち細分化が苦手です。複雑なものを複雑なまま表現できてしまいますので、特に新人等プログラム初心者にフローを書かせるととんでもなくわけのわからないものを書いてしまったりします。

欠点２：読みにくい

フローチャートを読もうと思うと 先頭から順に追っていかなければいけません。
また、全体的に何をしているのか？というのが非常に把握しにくい性質も持っています。

長いフローチャートになるともうお手上げです。

欠点３：同じものを異なる書き方で書ける

これは自由度が高いための欠点なんですが 同じアルゴリズムでもぜんぜん異なる書き方ができてしまいます。人によって同じものが異なる表現になるということは 本来のフローチャートの目的がプログラムやアルゴリズムをわかりやすくすることであるにもかかわらず、かえって わかりにくくしてしまうということです。

フローチャートはこの性質のため、メイン処理や正常系処理 を把握するのが難しい という欠点を持ちます。(たとえば分岐を含んだフローの場合、どの処理が正常系で、どの処理が異常系なのか等)

欠点４：メンテナンス性が悪い

これは言うまでもありません。
ソースコードを修正した場合に、ドキュメントまで修正するのはたいへんです。
その結果、ドキュメントが修正されなくなり、いつの間にか実際のソースコードと乖離した役に立たないドキュメントが生まれてしまいます。

まとめ：

フローチャートを書く最大の目的は、プログラムやアルゴリズムを図にすることでわかりやすくすることです。複雑なものを簡単に表現したいというのが、フローチャートを表現する目的であるはずです。

であるにもかかわらず、複雑なものを複雑なまま表現してしまう、要するに 複雑なものがわかりにくいという短所をフローチャートは持っています。

つまり、複雑なものを簡単にするのがフローチャートの目的であるにもかかわらず、複雑になればなるほどわかりにくくなるというフローチャートの性質は 本来の目的とは逆の性質を持っています。

そんなわけで、私はフローチャートが嫌いです。

プログラマではなくテスターとして現場デビューする

プログラマではなくテスターとして現場デビューさせるのは、私のまわりではよくやる新人の立ち上げ手法です。

「設計者の発言」さんにも書かれていますが、メリットは 色々あります。
まず 自分の開発する装置についてよく知ることができます。
さらには単体試験せずに総合試験(組み合わせ試験)にプログラムをまわしてしまうととんでもないことになるということを身をもって知ることができます。まぁ、これは試験対象プログラムの品質がひどい場合限定の話ですが…
また 新人の教育担当の立場では 新人の教育に割く時間を(コーディング等開発側にまわすのに比べると)小さくできます。

ということで、新人をまずテスターにすることは いい考えだと思いますし 否定する気はさらさらありません。

ただ、注意しないといけない点があります。
いつまでもテスターをさせっぱなしにしてはいけないということです。

実際にあった話なんですが、数年テスターばっかりやって、一度も開発をせずに管理職にまわされた後輩がいました。その後輩は少しは開発をさせてほしいと上司に訴えたみたいなんですが「自分で勉強するもんだ」と突き放されてしまったみたいです。ちなみにその子は管理職にまわって2年後ぐらいノイローゼ気味になり 会社を辞めてしまいました。

さらに これは人から聞いた話なんですが、新人にはまず３～４年程テスターをさせるのが伝統ってな会社があったそうです。
んで、その会社は数年前に20台中盤の若い世代が大量に退職しちゃってえらいことになったらしいです。
その会社では そんな事態になってようやく 自分たちの伝統が如何にアホであるか に気づけたそうな…

というわけで、新人をプログラマではなくテスターとして現場デビューさせるのは大いに結構です。でも、期限は最長でも１年ぐらいにして、そのあとちゃんと「プログラミング」側に移してあげることを忘れてはいけません。

見積もり手法「KKD法」

これまでの見積もり手法 紹介の続きです。('08/3/4修正)

・見積もり手法「KKD法」

もっとも広く(?)普及している見積もり手法です。というか、こんなもの手法ではありません。「エンジニアの経験と勘に頼った見積もりのことを KKDと呼ぶ」というのが正しいです。

KKDとは、Ｋ（勘）、Ｋ（経験）、Ｄ（度胸）のそれぞれの頭文字をとっています。根性(K)根性(K)ど根性(D)の略でもないし、火事場(K)のくそ(K)力(D)の略でもありませんのであしからず。

KKDの長所は 短時間で算出できること。いわゆる「エイヤー」でだす見積もりですので そりゃまぁ算出は早いです。
また、熟練した技術者のだした見積もりはKKDであっても、説得力があるというのも長所です。(これが実際に当たるかどうかは また別問題ですが...)

欠点は 見積もり結果そのものが 見積もり担当者の主観とスキルに依存するため、精度が人によってまちまちになることです。ようするに 信頼性が低く、よく外れます。

また、主観に依存した見積もりなので、「いったい何に基づいて算出されたのか」という 見積もりの根拠が非常に薄いことも欠点です。見積もりが外れた場合に、その失敗を 次回に生かしたくても、そもそもの見積もり根拠が薄いため 生かしようがありません。このため、失敗を次回に生かすという、改善を行いにくいという欠点も持っています。

ということで、個人的には 非常にまずい手法だと思うんですが、残念ながら世間では 一番信頼されている見積もり手法です。

見積もり手法「FP法(Function Point）」

昨日の続きで５つ目の見積もり手法です。

・見積もり手法「FP法(Function Point）」
ユーザ視点からの機能を 定量化をすることを目的にしていて、システムの機能量を計算する見積もり手法です。
LOCと同じく客観性を重視しています。LOCとの対比で特徴をまとめると、
・LOCは開発言語に依存してしまうため 異なる開発言語間では使えません。しかし、FP法は開発言語に依存しません。
・実際に開発した量ではなく、開発する機能の量を測るため、ユーザの立場から値をとらえやすくなります。

ＦＰ法で計測された規模はファンクションポイント(FP)と呼ばれて、コード数や工数などに換算されて利用されることが多いようです。

FP法にはいくつかの計測手法があり、中でも一番普及しているのが、IFPUG法と呼ばれる計測方法です。これは GUI系アプリケーションに適していると言われていますが、組み込みにはあまり向いていません。

ちなみに組み込み用FP法としては、COSMIC-FFP法という計測方法が存在しています。

欠点ですが、FP法の算出は、要求仕様書から行います。つまり、要求仕様書が確定する以前には算出できません。また他の手法に比べると見積もりに時間がかかりますし、見積もり手法の習得にも時間が必要です。

本気でファンクションポイント法を理解しようとするとそれだけで本がまるまる一冊かけてしまいますし、それだけ敷居が高いのが大きな欠点です。

ただ、他の見積もり方法が持っていない 信頼性の置ける客観性を持った数少ない見積もり手法です。欠点を補うだけの長所を持っている手法だと思っています。

見積もり手法「COCOMO/COCOMO II 」

昨日の続きで4つ目の見積もり手法です。

・見積もり手法「COCOMO/COCOMO II (COnstructive COst Model)」
昨日までに紹介した類推法、ＬＯＣ法、ＷＢＳ法は手法というほどたいしたものではありませんでしたが、これは「手法」と呼んでよいと思います。
開発するソフトウェアの行数を把握し、その行数に補正係数を掛け合わせて開発工数に換算する手法です。

次の式から算出します。(実際はもうちょい ややこしいですが)
　　式：P = a×(K＾b)

(P：開発作業量、K：キロステップ、a, b ：要員の技量や組織特性に基づいて推定されるパラメータ）
プログラムステップ数とその開発作業量（工数）の間に一定の関係式があるという統計的推論に基づいてます。

さらにCOCOMOにFP法(Function Point)の要素を取り入れたものがCOCOMOⅡです。

欠点ですが、まだ開発していないソフトウェアの行数をどのように把握するのかという問題があります。
また、実際にはパラメータ（a, b）の推定が困難です。
というわけで、式は美しいんですが、結局LOC法における試行錯誤の一種と言えます。

…紹介しておいてなんですが、使ったことがありませんので どの程度使い物になるのかよくわかりません。

見積もり手法「積算法、WBS法」

昨日の続きで3つ目の見積もり手法です。

・見積もり手法「積算法、WBS法(Work Breakdown Structure)」
WBS等によって 細分化されたタスク毎に工数(作業時間)を求めて それらの推定した工数を積上げることにより 見積もりを行う手法です。
細分化の程度の差はあれ、どこでもやっている見積もり方法だと思います。手法というほどたいそうなものではありません。

この方法の欠点は 積上げによる見積もりであるため、項目の抽出漏れや想定外作業により、結果的に現実離れした見積もり結果になるという可能性が高いことです。
要するに 想定外の作業が発生するとアウトということです。
私の経験上、ほとんど場合過少見積もりとなって 結果にあらわれています。

逆に時々 積み上げ型の見積もりは 同じ作業内容を重複してカウントすることがあるため 実際よりも工数が多くなるはず…という人もいます。
言わんとすることはわかりますが、私の経験上 過少見積りになったことはあっても 過大見積りになったことは一度もありません。
また、重複する項目は工程のレビューを行えば たいてい排除されますし、積算法が過大見積りになりやすいというのは説得力が低いと考えています。

見積もり手法「プログラムステップ法、LOC法(Lines Of Code)」

間隔が空いてしまいましたが、前回の続きで見積もり方法です。(2008/3/2修正)

・見積もり手法「LOC法(Lines Of Code)」

プログラムステップ数(LOC)に生産性を掛け合わせておこなう見積もりです。
要求仕様から開発するプログラムのコード数を推定し、そのコード数と１コード当りの生産性から全体の工数見積りをします。
過去の類似システムにおける実績値(LOC)から推定することになるため、その意味では本質的には類推法と変わりません。

長所は 工数見積もりの根拠を数字で出せるため、一見説得力があること。
LOCの算出そのものは容易であることです。

短所は、要求仕様からLOCを推定する確実な方法は存在しない点と、根拠とするLOCそのものの信頼性が低い点 です。
要するにあんまりあてになりません。

使いどころはある程度限定されていて、開発の際の流用元のソースコードの記述内容(レベル）が ある程度安定していて、かつ 過去のLOCが残っている場合のみ、それなりに役立ちます。
実際にはLOC法を単独で使用することはあまりなく、類推法と積算法を組み合わせることが大半になります。
なお、完全な新規開発の場合は過去のソースがありませんので、当然LOCは使用できません。
だから、LOC法を完全な新規開発で使用するのは非常に困難です。

・LOCについて
LOCそのものはプログラムの規模を表す指標の一つで、ソースコードの行数のことです。
呼んで字のごとくコードの行数。プログラムの規模を計る指標のひとつです。

「いまさらライン数」と思いつつも、ほかにいい指標もなく、比較的よく使われる指標です。

よく使われる割に信頼性が低いという致命的な欠点があります。
理由は少し考えればわかることですが、ざっとピックアップするだけでも これだけあります。

・同じ機能のプログラムでもプログラマの力量や選択するアルゴリズムなどによって記述量が全然違う
・同じ機能でも冗長な書き方をしたほうが規模が大きいと判定されてしまう。
・現在利用されているプログラミング言語の多くはソースコードの改行に関して制約が少ないため、プログラマによって改行を挿入する「流儀」が異なる
・同じライン数でも、新規に開発するライン数 と 既存部分を改修するライン数は難易度が全然違う。

さらに、使用可能な環境も限定されます。
採用する言語が違えば 比較の対象には使えません。
そもそも GUIの開発なんかだと 言語がないため 算出が不可能です。

結局のところ 計測が簡単である以外 特にメリットはありません。

見積もり手法「類推法」

  ようやく仕事が落ち着いてきました。
  …と思ったら次のプロジェクトがもう動きはじめています。

  んで、どの程度の作業量になるのか見積もりしないといけないわけなんですが、やっぱり見積もりは難しく、とにかく苦しんでます。
 
  というわけで、何か言い方法が無いか色々と調べてみました。
  いくつか方法が見つかったんで、各方法を私なりの解釈を加えつつ ざっとまとめてみます。
 
類推法
プログラムステップ法、LOC法(Lines Of Code)"
積算法、WBS法(Work Breakdown Structure)"
COCOMO/COCOMO II(COnstructive COst Model）
FP法(Function Point）"
KKD法

 
・見積もり手法「類推法」

経験値による見積もりであり、過去の類似の開発事例から開発規模を類推する手法です。
「手法」と言うほどたいそうなものではありませんが、過去の数字を使えるため あてずっぽうの見積もりに比べれば有効です。

ただし、欠点もあります。
過去のプロジェクトのデータを役に立つほど蓄積できるところとなると、ある程度大手の開発業者に限られてしまうため、なかなか過去のデータを入手できません。
また、開発手法の変化があったとか、過去に類似の開発事例がないと使えないとか、過去のデータが役に立たない場合も多いです。

とは言うものの、過去の実績が使える環境にあるならば 積極的に用いたい手法です。

続きはまた次回に…

テストエンジニアにはサドが向いている

ここしばらくバグの山に埋もれていましたが、ようやく一段落してきました。
まだ油断はできませんが ようやく一息つけそうです。

そんな大量のバグの山に埋もれながら ふと感じたことがあります。

いろんな方がバグの報告をしてくれるわけなんですが、中には本当に申し訳なさそうにバグを報告してくる人がいます。

バグの指摘は 我々 開発側の人間、実装者に作業負荷をかけるのは確かですし、こちらのことを心配してくれること自体はありがたいです。
ですが、テストエンジニアはバグを見つけるために試験しているわけですし、そこで「いい人」になる必要はないでしょう。テストエンジニアがバグを見つけて申し訳ないと思ってしまうことは、テストエンジニアの仕事を自己否定しているように感じてしまいます。

そんな人を見ているとテストエンジニアにはやっぱ性格的な適正があると思うんですが、実際のところはどうなんでしょうか？

人の不具合を嬉々として指摘できるぐらいの方がテストエンジニアには向いていて、いわゆるサド(S)、マゾ(M)でいうならサドが試験者向きだと私は思うんですが...

エース格の外注さん

　前回、「外注さんを雇う最大の理由はいざと言うときの人減らしを簡単に行うため」と書きましたが、実際のところ、全員を解放するようなことはまずありません。
そんなことをしてしまうと、開発のノウハウも一緒に消えてしまうからです。

これは発注元のジレンマなんですが、開発のノウハウは外注さんが蓄積していくため、発注元にはなかなかノウハウが残りません。そのため ノウハウの塊のような人 いわゆるエース格の人は必ず残そうとします。逆に駄目な人は本当に容赦なくバッサリ切ってしまいますが…

また 他のチームにそのエース格の人が暇であることがバレルと引き抜かれる恐れがあるんで、少し暇になった場合 無理にでも仕事を渡して引き止めておいたりもします。

基本的に エース格の人は、引く手あまたなんで こんな無駄ことをしたりするわけですが、要するにそれほどデキル人は貴重で 大切にするってことです。

でも、まぁ 本当にすごい外注さんにめぐり合えることは残念ながら あまりないんですけどね…