底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

プロジェクトにおける「仕事のできる人・できない人」の評価とは

あるプロジェクトに参画してしばらく経つ。現在絶賛結合試験の真っ最中だ。試験実施前まで試験準備としていろいろなドキュメントを作成したりして結構な時間が経過した。その間、チームメンバ間の人間関係も少しずつ構築されてきた。

 

  • Aさんはプロパーだけど、システム開発初めてだったのにいきなりリーダーまがいの立場に立たされて苦労してたけど、未だに苦労している。のんきな気風は相変わらず。
  • Bさんもプロパーだけど、誰とも分け隔てなく対応できてとても慕われている。
  • CさんもプロパーでBさんと同時期にチームに加入してきたけど、態度が偉そうで最近は誰からも話しかけられてない。態度が偉そうっていうかチームで一番年下なのに敬語も使えないし、常に詰問調でそれがプロパーとして正しい姿勢だと思ってるのかとても疑問。
  • Dさんは自分と同じ外注だけど、人柄もよくまじめでBさん同様色んな人から慕われている。
  • Eさんは経験は非常に長いけど、その経験があるゆえに勝手な判断が多すぎて結局仕事のやり直しとか無駄なことも多いし、その上仕事が案外雑。
  • Fさんは年齢は一番上だけど、仕事の質はハッキリ言ってそこらへんの1年生以下。愛嬌だけはいい。

 

自分はDさんとEさんの間くらい。仕事は一応普通にこなせてるけど、与えられた仕事をこなす程度で「プラスなにか」ということまで出来てないし、仕様の把握も未だに追いついてない部分も結構ある。勤怠もよくないのでプロパーの一部から目の敵にされてるっぽいけど、時間管理されてる仕事ではないのになぜ勤怠がそこまで重要視されるのかよくわからない(定時にミーティングがあるわけでもない)。

 

記事のタイトルでいうところの「仕事のできる人・できない人」のラインは多分自分までで、Eさんはギリギリなんとかって感じだろうか。Fさんは完全に「できない人」という印象がBさんからも持たれてる。

 

Fさんは、

この記事に出てくるおじさんエンジニアなのだけど、この記事を執筆時点ではまだある程度エンジニアの経験があるものと思っていたけど、実際は数年程度しかないのでは?と最近は思い始めている。その数年も「数ヶ月テスト要員としてプロジェクト参加してはブランクが空いて、またテスト要員として参加、またブランク空いて~」というのを繰り返しているのでは?イメージ。というのも、

 

  • Excelの印刷機能で「シートの選択範囲のみを印刷」をすることができない
  • MSペイントやメモ帳がプログラムのどこにあるかわからない
  • Internet Explorerのバージョンを調べる方法を知らない

 

っていうレベルだからだ。これでもおそらく肩書はSEなんだろう。

 

SIerでプロジェクトに参加してれば必然的にExcelで何か印刷する機会は死ぬほどあると思うのだけど、「選択範囲のみを印刷する方法」を知らないってどういうことか最初はよくわからなかった。知らない、ということなので「ここのラジオボタンを選択してください」と教えてあげた。MSペイントはもしかしたら使ったこともないかもしれないけど、メモ帳なら「プログラムの中のアクセサリーに入っている」ことくらい知っていても良さそうなものだし、IEのバージョンを調べる方法を知らなくても、基本的にアプリケーションはオプションを見たり、ヘルプを参照することでバージョンくらい調べられるという知識くらいあるだろうと思う。

 

話が長くなったけれど、自分のような底辺エンジニアの評価が比較的高い今のプロジェクトは、たまたま周りに飛び抜けて仕事ができない人がいたことが要因。

 

つまりプロジェクトにおける「仕事のできる人・できない人」というのは非常に相対的な評価でしかなく、「できない人が割と多い環境だった」「できる人に囲まれていた」もしくは「自分の適性に合った仕事をしているかどうか」というものが大きく関わるものなので、本当の意味で「仕事ができる・できない」の判断はまた別なところにあるということ。

 

今回は開発のプロジェクトではないまったく理系っぽくない仕事で、まるっきり文系臭のする仕事が故に自分のアラが表面化してないけど、これが開発プロジェクトであれば全く評価は違っていただろう。おそらくEさんの評価が上がっていたと思う。

 

仕事ができないとかって評価をされるのは仕事が遅いとかそういうことで判断されるのではなくて、「こんなことも知らないの?!」って思われるようなことや、仕事の内容が雑であることのほうが仕事ができないと判断される気がする。

 

だいぶ前に参加したVB.NETのプロジェクトで「interface」について無知だった自分はコードの中に書いてある「interface」という文字を見つけて、「コレはなんですか?」と無邪気に質問したけど、「interfaceも知らないの?!」と驚愕されたのを強く覚えている。その質問以降、その現場では立場が大きく落ちてしまい何も挽回できないままフェードアウトとなった。

 

ただ、「こんなことも知らないの?!」の正直どのへんからが「こんなこと」なのかは人や仕事の内容によるので判断が難しい。基本的にググってもよくわからなかった場合質問するようにしている。業務的な知識は正直知らなくて仕方ない場合が多いので、その点今の仕事は知らなくて当然なことが結構あるので気が楽なのである。

 

しかしやはりエンジニアを名乗っているのなら、ゴリゴリとコーディングをしたり設計をしたりする部分で評価を得たいものだ。

 

 

その仕事のやり方だと、予算と時間がいくらあっても足りませんよ。

その仕事のやり方だと、予算と時間がいくらあっても足りませんよ。

 
仕事が速い人ほどマウスを使わない! 超速エクセル仕事術

仕事が速い人ほどマウスを使わない! 超速エクセル仕事術

 

 

 

 

 

 

 

【ゲーム感想】レジェンドオブレガシーをはじめました

何か新しいRPGはないか、と思ってたところでゲームショップで目についたのが今回プレイする「レジェンドオブレガシー(以下、LOL)」でした。フリューというなじみのないメーカーの作品ですが、パッケージからして明らかにワクワクする感じだったのでこれは期待できる!と思いました。

 

f:id:starscream1999:20170910001017j:plain

 

まだプレイして10時間程度なので、ファーストインプレッション的な感想になりますが、記事を書きたいと思います。

 

続きを読む

【ゲーム感想】ペルソナ4ザ・ゴールデン(P4G) クリアしました

前回の記事(【ゲーム感想】ペルソナ4ゴールデン(P4G)をはじめました - 底辺過ぎてちょっとビビる)からだいぶ経ってしまいましたが、クリアしてしまいました。

 

前回はインプレッション的な記事だったんだけれども、今回はクリアしたのでちょっと全体的な感想なんかも書いていきたいと思います。例によって?これからplayする人のためにもネタバレは基本的「なし」の内容です。

※ちょっと長めの記事です。ダラダラとすみません

 

f:id:starscream1999:20170806235041j:plain ※ペルソナ4の登場キャラクターたち

 

続きを読む

【詳細設計書】参照すべきドキュメントが多すぎる問題

今のプロジェクトでテスト仕様書を作成し続けてしばらく経つ。
基本的に、テスト仕様書は詳細設計書に書かれている仕様をベースに作成しているので、
そこに記述がないものについては、「そういう仕様ではない」ということでテスト仕様書には記述しない。


たとえば各項目の活性非活性に関して、

  • Aというチェックボックスにチェックが入っている状態だと、Bというボタンは押せない
  • Cというラジオボタンにチェックが入っている状態だと、Dというテキストボックスは入力不可


などという部分は設計書に記載があればテスト仕様書に挙げられるが、なければ当然スルーされる。で、実際にテスト消化の際に、
「ここにチェックが入ってると、このボタンが押せません」とか
「ここのラジオボタンにチェックを入れていると、このテキストボックスには入力できません」とか上がってくる。


実際のアプリの挙動と仕様書を見比べて、アプリ側の挙動を「正」とするかどうかは微妙なので
一応確認するのだが、大体仕様書に記述が足りていないことが原因で、結局テスト仕様書を修正することになる。
(というか、制御に関する網羅的な表もなくて作ってる側は混乱せんのか)


これくらいならアプリと仕様書を見比べるだけで済むのでそこまで苦労はないのだけど、
実際は仕様変更という名のもとに、仕様書とは別のファイルが存在し、そちらも確認しなければいけないので手間が倍になっている。


  1. 今年春の段階で凍結した仕様書と
  2. 設計バグ等が見つかったことにより、ページ単位で修正の入ったドキュメント


これらが別々のSubversionに置いてある。
現状のアプリは「春までに凍結された仕様書通りに作られている部分」と
「修正の入ったドキュメントで作り直された部分」が存在していて
テストを実施した際にテスト仕様書の期待値(確認項目)と差異が出ているのはどちらのドキュメントに対応しているのか探さなくていけない。


この、修正の入ったドキュメントというのも、「5/10時点」で見つかったバグ対応の修正と「6/15時点」で見つかったバグ対応の修正では
ドキュメントが別なので、それぞれ見比べなくてはいけない。


・・・なぜ仕様書にそのまま修正を反映してくれないのだろうか...


実装する人からすれば、修正箇所のみをピックアップしたようなドキュメントなので
どこをどう修正するかわかりやすい、ということなのかもしれないが...


しばらくテスト仕様書の準備作業は続くし、今後はテスト結果のチェックも必要になってくるわけだけど
バグ修正も延々続いていて、そのたびに仕様変更ということでドキュメントが増えていくのだろう。
頭痛い。

見るべきドキュメントはなるべく少なくすべきなんじゃなかろうか
おそらくリリース後にドキュメントの整理というタイミングで今あるバラバラのドキュメントと仕様書を統合していくのだろうけど。
(本来は統合したいのだけど、修正が多すぎて中途半端な状態で設計書として統合出来ないんじゃないかと思う)

工数、という部分を重視しすぎておかしなことになっている気がする。
優先すべき作業を置いておいて、とりあえず当初のスケジュールを尊守すると言う形になっているように見える。

実際、テストの工数ってプロジェクトにおいてもわりと割かれているはずなんだけど
こういう無駄な作業のおかげで手間ばかりかかっている。そりゃ、スケジュール通りに進まんわ。


研修プログラム開発の基本 ~トレーニングのデザインからデリバリーまで~ (ASTDグローバルベーシックシリーズ)

研修プログラム開発の基本 ~トレーニングのデザインからデリバリーまで~ (ASTDグローバルベーシックシリーズ)

【Oracle】DATE型をWHERE句で比較するときの注意点

今日たぶん人生で初めてDATE型のデータをSQL文のWHERE句の条件で使った気がする。

比較条件の使い方を完全に勘違いしていたので、メモ書きとして
今後のために残しておく。

 

ピンポイントでSTART_DATEが2017-6-29のレコードが取得されるように、
こんなSQLを書いた。

SELECT
*
FROM
TABLE_A
WHERE
START_DATE = '2017-06-29';

START_DATEはDATE型で定義されていて、実際にレコードには「2017-06-29」というデータが入っているのだけど、
いくら実行しても、結果は表示されず。

なんでだろう~、と思ってググったところ
そもそもDATE型は「=」で結ぶような比較は出来ないということが判明した。


では、どうやって比較すればいいのか。


その前に、DATE型に格納されている値について確認しておく。
表示上、「2017-2-29」とされていても実データの方には、
「2017-2-29 00:00:00」といった感じで時分秒まで格納されているのだ。


ということを踏まえると前述のSQLの場合、

SELECT
*
FROM
TABLE_A
WHERE

START_DATE > TO_DATE('2017-6-28', 'YYYY/MM/DD')
AND START_DATE < TO_DATE('2017-6-30', 'YYYY/MM/DD'); 


という、SQL文になる。一旦、TO_DATE書式を使って、書式をそろえる。
(実際はいちいちTO_DATE書式に揃えずとも問題ない)

時分秒まで指定したい場合は、

  TO_DATE('2017-6-29 12:12:12', 'YYYY/MM/DD HH24/MI/SS');


のように記述する。

DATE型の比較については、BETWEENを使う方法もある。
範囲で検索結果を取得したい場合に有効。

以下の場合、2017-6-28の00:00:00から2017-6-30の23:59:59までに該当する
レコードが検索結果として取得される。

 START_DATE BETWEEN TO_DATE('2017-6-28', 'YYYY/MM/DD') 
 AND TO_DATE('2017-6-30', 'YYYY/MM/DD') 

※間違えていたらぜひ指摘してください('ω')ノ


スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ)

スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

徹底攻略 Java SE 7/8 Bronze 問題集[1Z0-814]対応

徹底攻略 Java SE 7/8 Bronze 問題集[1Z0-814]対応