SIer では、エンジニアは評価されにくい？
うちの会社はそこそこ大きい SIer です。
そういう環境であることを前提に話を進めます。
とあるきっかけがあって、
プロジェクトマネージャより高評価を得るエンジニアになるにはどうすればいいか。
なんてことを考えています。
スーパープログラマ不要論
標準化や共通化が一定のレベルを越えると、暴れ馬なスーパープログラマが一人いるよりも
従順な低レベル作業者数人を厳密なルール下で強制労働させる方がよさそうに見えます。
大規模プロジェクトでは数こなして、進捗率上げるのが至上ですからね。
実際はそんなことはなく、問題が起こった時には役に立たない烏合の衆と化したり、
動くだけでなんの付加価値もない成果物ができあがったりします。
人を管理できる方が評価しやすい
とは言え、うまくいかなかった時のことなんて頭の片隅に置いておくのが世の常なので
一匹狼なエンジニアよりも、複数人を管理するプロジェクトマネージャの方が重要視されます。
もちろん、顧客をシャットダウンしてシステムしか見ないエンジニアは論外ですが、
顧客もシステムも見ながらすごいスキルを発揮するエンジニアもいるわけです。
そういうエンジニアって管理重視な視点で見ると、評価されにくくなります。
「結局あの人は進捗管理とかやっぱり弱いし、リーダー経験してないし…」
人事評価の場でそういう声をよく聞きます。マイナスポイントのほうが目立ちます。
「でも、あの時あの人がいなかったらダメだったでしょ。徹夜してがんばってくれたよ」
といった意見は加点対象にならないことが多いです。
エンジニアは技術で苦労して当然、家帰って技術書読むのも当然なのでしょう。
逆を言うと、技術を全く知らない管理者に苦労したりします。
そもそも違う役割なのだから
人を管理しているのがプロジェクトマネージャで、
一方で技術を管理しているのがエンジニアです。
あつかう対象が違うのだから、評価も違った見方で行わないといけないはず。
確かに人を管理するほうが一般的には難しいことは違いないですが。
でも、プロジェクトには役割がそれぞれ必要なわけで。
プロジェクトマネージャだけでも成り立たないし、エンジニアだけでも成り立たないです。
総じて最高責任者たるプロジェクトマネージャの評価が高くなるのは避けられないですが、
そうはいっても、エンジニアもその努力にうまくフォーカス当てて評価されるようにしたいです。
じゃあ、どうする？
エンジニアが自由に自らのスキルで持って価値を生み出せるようにしたい。
そして、それを評価されるようにしたいと思っています。
大きな会社には保守派が多くて大変ですが。
まずは自分の力でなんとか変えれる、小さな範囲から。
実例を積み上げる。
ポモドーロ、愚直にやってみた
ポモドーロ自体は知っていました。
少し25分測ってやってみた時期もありました。
最近、やることも山積みで帰るのも24時超え。量的に多すぎるというのも確かにあるのですが、TODOをまったく消化できないという感覚がありました。
ポモドーロ再入門
ということで『ポモドーロテクニック入門』を手に取りました。
この本の存在自体はだいぶ前から知っていたのですが、
わざわざ読むほどのこともないと、たかをくくってました。
誤認していたポモドーロ
きちんと本を読んで認識しなおしました。
「25分内でなんとかタスクを終わり切る」ためのテクニックだと思っていたのですが、
「25分間集中する」ためのテクニックであることがわかりました。
集中するので結局はタスクが終わり切るのですが、
まず第一は集中すること、でした。
これが前提をくつがえす、大きな誤認。
本を読んで、このことに気づきました。
ポモドーロはいかにして集中するための環境づくりをするかのテクニックでした。
ということで今日実践しました
・Android のPomodoro アプリ
・紙
・ボールペン
今日やること、とりあえず書き出してタイマーセットしてやってみました。
結論から言うと・・・むちゃくちゃ、仕事がはかどりました。
あ〜自分はここ最近、まったく集中してなかったんだなあと痛感しました。
今日は集中し過ぎましたね。頭がいたい。
ふりかえり
工夫したこと
・目の前の事以外考えないようにするように、とりあえず走り書きメモを意識
・メールボックスを閉じておく（受信通知もOFF）
・デスクトップのファイルをお掃除
・コーヒーやジュースの補充は休憩の時だけ
・休憩の時はPC触らない、とりあえず歩く・放心する
・最後にふりかえりをした
やってみてわかったこと
・ひとつのことに集中する感覚、重要
・タスクを何とか終わらせるというのは二の次
・集中するための準備は大切
・25分集中したら、休まないとやってられない
・意外と割り込みは少なかった（おそらくメールを見なかったから）
・頭がいたい（いい意味で。集中した証拠）
失敗したこと
・今日やることの全量を書き出していなかった（エンドレスになりかけた）
・25分過ぎても延長してしまったこと数回。そのときはやっぱりダラダラした。
その他、副次的な事象
・メールが溜まるようになった（５件も溜まったことなんて最近なかった）
・メールの返信を後回しにしなくなった（早く送って忘れたくなった）
・イライラしなくなった（あれもこれもやらなきゃという感じがない）
ということで…
おかげさまで、いっぱいTODOが消化できたので、正確には消化できたという確たる感覚を得られたので、今日は早めに帰る気になりました。（とは言え22:00退社ですが）
ひさびさにブログ書くこともできました。
（このブログは２ポモドーロでした）
読書感想文 in ブログ
ブログで読書感想文を書く難しさ
読書感想文をいざ書こうとすると書けないことが多いです。
下手すれば、初めの１文を書きだすのにも多大な時間を要します。
また、書くにしても話すにしても、読んだ本の良さをうまく伝えるのは難しく、
適切な言葉が出てきません。
自分の考えや思いをアウトプットするのは非常に困難なことだということを痛感します。
ブログを書くことと論文力の関係
情報処理技術者試験には論文問題があるのですが、
ブログを書くようになってから、採点評価があがりました。
ブログを書くことと論文技術の関連性があると必ずしも言えないですが、
少なくとも論文問題を書くスピードが上がったのは確実です。
ブログは不特定多数の目にさらす文章なので、自然とセルフチェックも厳しくなります。
自分しか見ないメモや身内のメールとはまったく異なります。
きちんと意図が伝わるかという点に私は気を配っていたりします。
そういうところのつながりはあるかと。
失礼な敬語や間違った語彙が散りばめられたメール。
字面や体裁がよさそうな言葉を並べているだけのプレゼン資料。
うまく明文化するのに手間がかかりすぎるため、引き継がれないノウハウ。
文章力というのは実はビジネスという領域では重要です。
ですが、一朝一夕で成長するものではないです。
ブログを書いている理由
インプットばかりで消化不良だったのでアウトプットの場としてブログを始めました。
ブログを続けている理由は今もアウトプットの場というのが第一の目的ですが、
最近は文章力の練習の場としても意識するようになった気がします。
目的・ねらいを外さずにまとめられるか。いかにはやく書くか。
簡単そうに思えて実は難しく、うまく書けていないことが多いです。
また、時間をかけたらいいかというとそうではなく、書きだめすると結局書かなかったりします。
ブログを初めて約１年経ってみて、なんとなくブログを書くことの良さが
わかってきたかなと思います。
もっと文章力を向上させるために、今後は読書感想文なトピックも書いていこうと思っています。
技術的な不安とうまく付き合う
「やばいです。まにあわないです。無理です」
また、こんな言葉を投げつけられました。
技術的な不安に負けて弱気になる
システム開発はどれとして同じものはなく、技術的な課題は毎回発生します。
技術的な課題の調査や解決にはとてつもない時間がかかることも少なくありません。
時間をかけたとしても、満足の行く解決ができるとは限りません。
そのため、技術的な課題に対して、過剰な不安を示す人がいます。
不安が理由となって、根本的な解決や斬新な改善に踏み出す機会を逸していることも多く、とても残念に思うことがあります。
「やったことがないので無理です。やるとしても見積りの３倍の時間がほしい。」
「よくわからないですし、時間もないので、前と同じやり方でとりあえず進めます。」
「社内の有識者をアサインしてくれ、有償サポートを検討してくれ」
これらの弱気な発言を全否定はしませんが、技術者なんだからもう少し踏ん張れよと思ってしまいます。
不安なのはわかるけれど、考え方を変えたり取り組み方を変えれば、なんとか打開できる道は残されているものです。
なんとなく全体的に不安という状態をなくす
課題を切り分けて、できる部分とできない部分を明らかにする。
この切り分け整理は技術的課題の解決にとって大切なことです。
残念ながら、この切り分けをせずに「難しい」「できない」と言わることが多いです。
実は、全体の中の特定の部分が厄介な課題であって、それ以外は単純なことかもしれません。
その厄介な課題にリソースを手厚く施せばいいわけで、そうすれば全体的な不安はなくなるはずです。
切り分けて、できるところから片付ける。これの繰り返しなんだと思っています。
盲目的なコピペをやめる
過去事例の成功パターンを盲目的にコピペするのをやめたいです。
前回成功したからといって、同じやり方が今回も成功するとは限らないです。
そもそも客観的に見て成功パターンなのかも怪しい。
それに、進歩や改善がないですよね。次につながらないやり方だと思います。
理解も追いつかない状態で、時間もなければ、とりあえずコピペしたい気持ちは理解できます。
でも、その不安を棚上げしておいて困るのは未来の自分たちかもしれません。技術的負債ですね。
専門家を呼ぶのは我慢しよう
未経験な技術を採用する場合に多く聞かれます。
「その道の専門家を呼んでほしい。有償サポートを検討してほしい」
リスク対策として非常に有効な手段です。
でも、技術者なら任された領域に対してもう少し前向きになるべきだと思います。
書籍を呼んで勉強する、英語サイトもがんばって読む。
専門家を呼ぶ前にまだまだ打つ手は残っていると思うのです。
不安とうまく付き合う
不安があるからこそ、勉強するし、成長する機会でもあります。
不安を解消する、つまり課題を解決することで達成感を得ることもできます。
不安はゼロにはできないです。
だから、不安とうまく付き合うことが大切なのだと思います。
JavaFX でダブルクリックを検知する
JavaFX ではダブルクリックされたのをどうやって検知するんだろうと疑問に思っていたら簡単にできました。
こんな感じです。
sampleNode.setOnMouseClicked(new EventHandler<MouseEvent>() { @Override void handle(MouseEvent event) { boolean doubleClicked = event.getButton().equals(MouseButton.PRIMARY) \ && event.getClickCount() == 2 if (doubleClicked) { println "ダブルクリックされたよ" } } })
sampleNode となっているものは javafx.scene.Node クラスのオブジェクトです。
Button とか、TextField とか @FXML で指定する GUI の構成要素のことです。
ダブルクリックを直接的に検知するメソッドはない
マウスでクリックされたことを検知する Node#setOnMouseClicked() があるので、Node#setOnMouseDoubleClicked() があるはずだと思ってたら世の中そんなに甘くはなかったです。そんなメソッドはないです。
MouseEvent#getClickCount() がすぐれもの
MouseEvent クラスには getClickCount() というクリック回数を返してくれるメソッドがあります。
setOnMouseClicked のイベントハンドラ内で、「クリック回数が２のときにダブルクリックとみなす」という判断をすることができます。
とはいえ、この getClickCount() メソッド。
カウンタを初期化しないと、ダブルクリックどころか延々とクリック回数が増えていって大変なことになるんじゃないかと…(ーー;)
調べてみると、優秀でした。
クリックしてしばらくするとカウンタが０に戻るようです。
安心してクリック回数を調べられます。カウンタの初期化も不要です。
左クリックのみに限定する
MouseEvent#getButton() でクリックしたマウスのボタンを MouseButton オブジェクトとして取得できます。
次のような定数がマウスボタンの種類に合わせて設定されているので、比較することでボタンを特定できます。
・MouseButton.PRIMARY（左クリック）
・MouseButton.SECONDARY（右クリック）
※OSの設定で左右を逆にしてたら、おそらく逆になる？
まとめ
「左クリックで、かつクリック回数が２回のとき」という条件分岐を使用することで、ダブルクリックを検知できるということです。
うまいこと設計されているなと感心しました。
