諦めのテストエンジニア

先だって、テスト界隈の方とディスカッションをする機会があった。その方は、所謂テストエンジニア、なのだそうだ。テスト工程のプロセスデザインについて関心があるのだという。

ご相談といか、お話をされたいということなので、まずは何に関心を持たれてお声がけをいただいたかを伺う。人は関心事があるとき、話すだけで自己解決することもある。兎にも角にも、お話を聴く。

ディスカッションをしたいのは、テストエンジニアにプロセスデザインを学ぶ機会を設けたいのだそうだ。なぜなら、テストに関わるテストエンジニア、テストオペレータはプロジェクトの度に、毎回、要件の整理、開発の工程を延ばされ、テストに残される時間がほとんどないため、半ば諦めで仕事をしている、だという。

圧縮される期間でできることは限られる。できることしかできない。でも、やらなければならない。こうした現実の中で仕事をしている。だから、外を見ようとする余裕もない。

もともと、テストエンジニアは開発の中でできないエンジニアに作業をさせていた歴史的経緯があったから、開発エンジニアからも下に見られている、という。

そうなのだろうか。

最近、テスト専門会社が上場したり、テストの自動化などでテストエンジニア界隈は、自分にとってとても必要性の高いエンジニアだと思っていた。ところが、お話を伺うとそうでもないようだ。

自分の認識と伺っていて思ったことは、多分、両方の面があるのだろうと。最新のテスト技術を駆使してテスト自動化に取り組むエンジニアもいれば、従来の開発のしわ寄せで四苦八苦しているテストエンジニアもいるということなのだろう。

こうした悩みの理由の一つに、工程を分断し過ぎてエンジニアが単機能工と化しているのではないか、と思うのだがどうだろうか。

開発エンジニアも然りである。仕様は降りてくるものだ、と口を開けて待っているエンジニアも仕様が出てくるの待ち、削りに削られた工程の突貫工事のような仕事をしているのと何も変わらないのではないだろうか。

聴きながら、頭の中では何を期待しているかを考える。

ただ、間違っても正論は期待されていない。正論を持ち出すと話は一瞬で終わってしまうだろう。

人は話したいとき、まずは聞いてほしいものだ。その上で、何かヒント程度のものが得られたら嬉しいのである。

下に見られていることも、ひどいスケジュールでテストをすることも実際の現場であるのだろう。ただ、全員がそうではない。ただ、現状はテストエンジニアがいなければソフトウェアはリリースされないにも関わらず、パワーバランスがおかしい現場があるということである。

あと、結果的にテスト工程に閉じこもっているのでプロジェクトの情報を把握しきれていないという見方もできる。

  • 単機能工と化している
  • パワーバランスがおかしい
  • プロジェクト情報を把握しきれていない

伝えたことは、この3点である。これをブレークスルーする切り口が見つけられれば、少しは環境を変えられるのではないか、と。

何か気づいたような表情をして、一礼された。

 

うんこかん字ドリルのボードゲーム

うんこかん字ドリルのボードゲーム

 

 

 

 

 

 

『2018年退職しました』退職エントリまとめ

平成最後の年の暮れ、日経の中の人の退職エントリが頭の片隅に残っていたからか、TLで退職エントリは若手エンジニアよりは新卒の学生に伝えた方がいいんじゃないかというのを見たからか、考えもせず、2018年の退職エントリをまとめはじめてみたが失敗であった。

思ったより多かった。『退職エントリ』以外にも『転職エントリ』もあったが、辞めた後、仕事につくとは限らないので退職エントリにした。退職エントリも辞める側のエントリもあれば、辞めたあと、残された側のエントリも稀にあって、そっち側もあるよなと改めて別れは2つの立場があるものだと思わされた。

そんなことを感じつつ、タンポポ作業(URLのコピペ)をしている中で読んだ記憶のあるものは、実はとても少ない。その少ない中でも記憶に残っているのは、9月の60歳定年で退職されたエントリである。やはり、年齢が近いと気にかかるものである。あとは、NTTのエントリと日経だろうか。

もちろん、退職エントリなどを書かずに退職された方は数多くいるのだろう。自分としては、

  • 退職時に何が合わなくて会社を辞めたか
  • 転職時に何を基準に次の会社を選んだか

が書かれていると、学生がエンジニアになるときに参考になると思うので、退職エントリを書く方は一言書いていただけると嬉しい。

 

1月

bluenotefit.hatenablog.jp

2月

mutoreimu.hatenablog.com

 

yutailang0119.hatenablog.com

findy-code.io

k1low.hatenablog.com

creativememomemo.com

orgachem.hatenablog.com

3月

media-massage.net

sujoyu.hatenadiary.com

高専(高等専門学校)を退職しました。|知識情報処理研究室(Okumura-Lab)

 

4月

kiyokura.hateblo.jp

ninatokaniwarosu.blogspot.com

 

taro.hatenablog.jp

53ningen.com

note.mu

5月

yamacraft2.exblog.jp

note.mu

c-mitsuba.hatenablog.com

dev.classmethod.jp

 

6月

 moro.hatenablog.com

blog.nabettu.com

blog.tamotamago.com

note.mu

7月

hiragram.hatenablog.jp

sue445.hatenablog.com

blog.thara.jp

tech.misoca.jp

nippo.wikihub.io

note.mu

aryzae.hatenablog.com

diary.hashedhyphen.com

 

8月

takezoe.hatenablog.com

blog.shibata.tech

taisyoku.company

akihiro0228.hatenablog.com

 

9月

niwatako.hatenablog.jp

medium.com

kohki.hatenablog.jp

d.hatena.ne.jp

 

10月

aripy.net

www.yatekoko.com

ybt.blog.jp

 

11月

www.akiradeveloper.com

namaninotiteti1026.hatenadiary.jp

note.mu

note.mu

osa.hatenablog.com

 

12月

 

tokyodwarf.blog.jp

note.mu

sisidovski.hatenablog.com

awana1023.hatenablog.com

 

 

 

 

 

 

 

 

楽しく、明るく、飲み、食べ、話すための飲み屋の選び方

やることが多く、夜は早々に帰宅したい。そうは言っても忘年会、年を越せば新年会の時期である。

これまで所属した組織の方のそういった宴会で面白かった試しはほとんどなく、出ても仕事だと思って出ていたがほとんど出なくなった。出るときは、何か特別な催し(記念的な)か何かいつもと違うことがあることが予めわかっている時だけである。

組織の飲み会は人数も多いのでほとんどが居酒屋だというのも行かない理由の一つだ。わざわざ揚げ物ばかり、この時期は鍋を出しておけばいいのだろう的なメニューとどこの銘柄だかわからない酒やチューハイやハイボールなどのかだらに合わないアルコールを自分で摂るなんてバカらしくて出ていられない。どうしようもないときは瓶ビール一択である。

結局、ほとんど行かない。

とは言え、特別な2ケース(例外処理のようだ)については飲みに行く。

1つは、主宰している勉強会のアフターである。これは行くことが習慣になっていることもあるが、勉強会で話しきれないことを話す場としての意味があるのと、主宰=オーガナイザとしての立場であるためである。ただ、どうしてもいけないときは今日はいけないと断っておく。

2つ目は、仲の良い役員とのさしのみである。これは頻繁に行くものではないが、サシで飲むのは良い。ただ、毎回店選びがネックになる。ただ、そうしたことも経験を積めばいい感じに店選びハックできるようになる。

ぼーっとして店を選ぶのだけは馬鹿らしい。同じ金を払うなら美味しいものを、どうせ飲む回数は少ないのだから組織の宴会の2−3倍払ったとしても満足度がべらぼうに高い。

最近の店選びフロー

 ここ2−3年、環境が揃っていい感じに回せている。3つのステップでやる。ポイントは、1と2を家に本が届いたときにやっておく。あとで、はやらないので。

  1. 定期購読している雑誌できになるお店の目星をつける
  2. アプリで行きたいに入れておく
  3. 飲む相手により、選ぶ

お店のネタ元

ネットでの情報は手軽で良いが、1次情報としては創刊号から読んでいる雑誌から得ている。雑誌名はdanyuである。

dancyu(ダンチュウ) 2019年1月号「たのしい宴会」

今月号は、宴会らしい。自分としては5人くらいがいいが、カンファレンスやコミュニティなどではそうも言っていられないのでそれなりに情報としては持っておきたい。

 

お店をチョイス

自分の好みにあうお店を雰囲気で選ぶ。紙の本のいいところは、デバイスとして表示面積が多くどこでも持ち運べるところである。ただ、スペースを取るので3年以上前のバックナンバーは捨てる運用をしている。

だから、メモをデジタルで持っていないといけない。

 

f:id:fumisan:20181209090949j:plain

 

取材記事なのでお店情報がある。それをアプリで検索し、『行きたい』とバックログにしておく。 

アプリはretty一押しである。実名でやっているところが良い。別に他のユーザの評価は気にしないが、他のユーザの行きたいが多ければ、多い店なんだな、くらいは思う。

それよりは自分の感性と何を食べたいか、である。

 

f:id:fumisan:20181209090833j:plain


で、予約を取り、楽しく、明るく、飲み、食べ、話す。下の画像のときは、サシ飲みだったので、かなりお高いが安価なときは+財布に優しい、となる。

 

 

f:id:fumisan:20181209093637j:plain

 

なにぶん、お店が良いので出てくる酒もハズレはない。だから、悪酔いしない。翌日も楽しく働ける。

次のお店に行くために。

なぜ人は苦労話を聞きたがるのか

先だってプレゼンする機会があり、プレゼンの後に

 

『何が大変だったか』

『大変そうな経験をさらっと話されていたが』

 

と質問があった。つい、うっかりと

 

『大変そうに聞こえたかもしれないが、プロなのだから、さらっと話して当たり前じゃないか』

 

と答えてしまった。こちらとしては、15年も前にPMPを取ったとき、いや、受験の勉強でPMBOKのイズムを読んだときからプロとしての覚悟をしているのである。

だから、『何を言っているんだ、コイツは』と思ってしまったのだ。

それまで、伝えたいことを伝わるように話すことに集中していたのだが、この質問で素に戻り、もう、そのあとは成り行きに質疑応答となってしまった。

さて、聞かれていた方々は、どう受け止めをされたのか。

 

帰る電車の中で、なんとなくプレゼンを振り返ってみたのだが、そう言えば自分自身もエンジニアの採用では『人生で一番苦労したこと』を聞いている時期があった。その質問の意図は、『人生で一番苦労したことをどう乗り越えたか』という対処や工夫や腹を括ったなどの乗り越えられたポイントを聞きたかったんじゃないかと思う。

質問されるシチュエーションに依存するだろうが、今思えば(自分が質問されて)そんな質問には意味がないのだ。

つまり、いくら苦労話を聞いても、質問の意図がただ大変だった物語のような定性的なことを知ったとしても全く参考に値しないのである。

聞くとするならば、どうすれば回避することができたか、その大変な思いをしたあと、どうやって繰り返さないようにしてきたかを尋ねなければならない。

質問の意図が人の採用に関わるなら殊更である。なぜなら、学習する能力を推し量るためである。昨日のあなたが成果を生み出すエンジニアであるかを知る10の質問にも当然、含まれている。

 あと、もう1つ苦労話を聞いても聞いた人にとってほとんど役に立たないと考える理由がある。それは苦労話はある意味、エラーケースでしかないからだ。苦労話の話し手は実体験を話そうとするので個別のケースを話す。その個別ケースは、様々な組み合わせの結果の事象であるから、話をした人と同じ条件で聞き手が体験することなんてあり得ない。だから、その体験以降にどうやって回避したかを尋ねた方がトップダウンな思考で回避した可能性が幾分あるので意味があるのだ。

 

 

 

Bohemian Rhapsody (The Original Soundtrack)

Bohemian Rhapsody (The Original Soundtrack)

 
ファヨール (経営学史叢書)

ファヨール (経営学史叢書)