jfluteの日記 このページをアンテナに追加

2016-03-30

破片プログラマーの悲しみ

|

破片プログラマー

大きなシステムの改修、
巨大に積み上がったプログラムの上での実装、

難度の高い仕事、

ただし破片

巨大な破片

画面を0から

二年、三年、五年と経験を積み、
開発スキルを身に付けたディベロッパー、

だがしかし、
0から画面を作ってみると...

...

あれ!?

できない。

画面を0から作ったことがほとんどない。
あったとしても、隣の画面の真似ごとをしてただけ。

考えて0から作ったことがない

レールのないところ歩いたことがない。

クラスやメソッド

クラスを作る。

どうやって?どういう単位で?

決められた中でしか作ったことがない。
その決めがないと何もアイディアが浮かばない。

「どこに何を実装するか?」って、
白いキャンパスの上で考えたことがあるかい?

...

メソッドを作る。

どうやって?どういう名前で?
どういう引数戻り値で?

メソッドの修正はたくさんしてきたが、
メソッドを作ることはめったにない。
もしくは、隣のメソッドの真似ごとをしてただけ。

なぜ、その戻り値を思い付かない?

DB設計も!?

select文はさんざん書いてきた。
チューニングだってわかってる。

テーブルを作る。

何か変な形している。

変なテーブルも得意のSQLで
無理矢理カバーしてきただけ。
良いテーブルのかたち、
悪いテーブルのかたち、
考えたことがない。

あんなにテーブルさわってきたのに、なぜ?

気付いたら...

年を取って、頭も固くなっているようだ。
破片じゃないプログラミングが苦痛でしょうがない。

...
...
…
…
…

あれっ!?
破片のプログラミングしかできない。

乖離の立ち尽くし

もちろん、すべての人は破片。
すべてのことをできるひとはいない。
そんな0/1の話をしたいわけじゃない。
程度の話。

そして、その破片をわかっていれば問題ない。
わかっていれば、できないことがわかってるから、
どうすれば解決できるかわかるから。

破片プログラマーの最大の悲しみは、
破片であることを自覚せずに成長してしまうこと。

プログラミング経験年数と、
実はほとんどプログラミングをしてこなかった
という事実に乖離がある。

それに気付かず、
ステージが違うことに気付かず、立ち尽くしてしまう。
もしくは、足を引きずりながら突き進んでしまう。

破片とホールのバランス

小さなまるごとアプリを作る経験、
これって大切だと。

デザイン、HTML/CSS, JavaScript,
サーバーサイドプログラミング(Javaとか)、
SQLDB設計、インフラ...

それぞれを少しずつ。

そんなに深くやらなくても、
それぞれの全体の中でのバランスがわかっていれば、
破片仕事をしながらでも全体を見る力が養われる。

...

まあ、そこまでおおげさでなくても、
小さなアプリの画面を作る。
小さいので全体が見通しやすい。
小さければ、既存コードに惑わされない。
その分、自分で考えて書かなければならない。

画面作りの基本を学ぶことに等しい。

...

もちろん、破片のお仕事も非常に大切。
破片は破片ならではのノウハウがあり、
鍛えられる部分がある。
盛大な筋トレをしているような感覚。

単純に
破片だけでは鍛えられないことがある
ということ。
そして、逆もまたしかりで、
破片をやったことないとそれはそれで、
バランス悪い。

仕事以外のプログラミング

ただ、仕事のプログラミングだけやってると、
破片になりやすいでしょう。
仕事のプログラミングは効率重視ですから、
破片で仕事ができるような仕組みを構築します。
それは会社としては当然のこと。

仕事で「まるごと作れ」と無茶ぶりされた人は、
幸せでしょう。そんな人はごく一部。

だから、自分で脱出しないと。

f:id:jflute:20160107190113j:image

ueshimanueshiman 2016/04/02 08:07 小規模な新規開発の現場に呼ばれることがあります。
リソースもないのに、PMや設計者ばかり。
なので、プログラマーは初心者ばかり。
お客は、完全エンドユーザーの現場担当者。
なので、プロトタイピングと称して、なし崩しで作り上げてしまいます。
コード書けるものが勝ち

jflutejflute 2016/04/03 00:22 ueshimanさん、こんばんは
逆境をチャンスにですね(^^。
コメントありがとうございます!

2016-03-16

成長するかしないかは選べる

|

できる人は...

  できる人になったことを選んだだけ。

できない人は...

  できない人になったことを選んだだけ。

...

実際に、多くの成長を見てきて、
本当にその通りだった。
単純に、選んだだけだった、選んでないだけだった。

行動のないアイディア

こちらの記事がとても印象的でした。
サクッと読めますので、ぜひ読んでみてください。

// いまだにアイデアに価値なんてあると思ってるの?
http://honz.jp/articles/-/42238

...
...
...
...
...

全く同じことを尊敬するCTOからも聞いてことがあります。

たぶん、自己実現でも全く同じ。

気付いたら年をとっていく

大抵の人は「できる人になりたい」と言って行動しない。
そして、成長するチャンスをどんどん逃して年とっていく。
気付いたら体力も気力もない。

もちろん、様々な都合でそうもいかない例外はあるだろうが、
進む道が選べる人は選んだだけだよ。多くの人が選べる。

能力はあんまり関係ない、
頭がいいとか悪いとかそんなに関係ない、

進む道を「真摯に」選んだだけ

大胆な行動はなに?

ただ、

効率の良い努力をする努力をした人が成功する

...

「こんな仕事したい」

「こんな自分になりたい」

そのために...
行動って何をすればいいんだろう?

…
…
…

いま思い付かないような大胆な行動

遠慮するのであれば、遠慮することを選んだだけ。

...

f:id:jflute:20160208164243j:image

2016-03-15

プログラマーになって、音楽は聴いてますか?

|

あんなにたくさん聴いてたのに、
社会人になった途端、全然時間がなくて
音楽からすっかり遠ざかっちゃうことも。

オフィスでBGM流れてればいいんですけど(^^

電車で音楽聴くか、本読もうか迷ったり。
聴きながら読めなくもないですが、
音楽に集中したいって気持ちもあって...
でも電車の中は本がゆっくり読める貴重な時間だし。

まあ、別に音楽だけの話じゃなくて、
学生時代はたくさん楽しんでいたもの、
働き始めたら一気に遠ざかりますよね。

パワーと勇気の源

jfluteにとっては、
音楽はかけがえのないものでした。
いまもリアルタイムでそうです。

何か苦しかったり、
落ち込んだり、
集中力を高めたり、
普通に楽しんだり。

常に音楽がそばにありました。

あんなにふさぎこんでたのに、
パワーをもらえるのです。

あんなにこわがっていたのに、
勇気をもらえるのです。

時代のBGM

聴いてる音楽がそのままその時期のBGMに。
だから、あとでその曲を聴くとそのときを思い出す。

「せつなーい」

ってのもあれば、

「たのしかったねー」

ってのも。

まあ、せつないのはつらいから、
なんとか上書きしようとするんですけどね笑。
でないとその曲、もう聴けなくなっちゃうから。

もうプログラマーになって、10年以上経ってますから、
10年の期間のそれぞれのBGMができあがってますね。
というか中学生や高校生のときから積み上がってるかな。

集中力サウンド

講演会勉強会新卒研修など、
まあ特に人前に立って大切なことをしゃべるとき、
集中力を高めるために、音楽を聴きます。

音楽を聴きながら会場入りします。
特に直前の曲を「集中力サウンド」と名付けて、
いつも「今回の集中力はこの曲にしよう!」
とか考えてます。

会場に入るタイミングで曲が終わらなかったら、
曲が終わるまで会場の周りをウロウロしてたり...

ここはもう、だいぶ偏ってますね。
集中力高める系サウンド!

o That's the Spirit! (安井さちこさん)
o The Entertainer (ビリージョエル)
o SHI WA ZU (赤木りえさん)
o リベルタンゴ (寺井尚子さん)
o All About Soul (ビリージョエル)
o などなど

もっともっとたくさんありますが、
こんな感じのよく聴いてます。
もしよければ聴いてみてください(^^。
jfluteがどんな気持ちで会場入りしてるのか、
イメージ湧くかなと笑。

そのときの内容とテンションに応じて選びます。

昨年の新卒研修は気合いを入れていました。
毎日朝、オフィスに入る前に、
その日の集中力サウンドを聴いていましたね。

今年も始まります。
毎日、曲を選ぶところから一日が始まります。

音楽で泣ける

実は、ぼくは音楽で泣いてしまいます。
(泣きそうになってしまいます)

ある意味、すごく単純で簡単な人です。
音楽で簡単に感動してしまいます。

まあさすがに異常な人かもしれませんね...。

でも、そのぶん、
常に音楽に支えられてます。
音楽で自分をコントロールしてるとも言えるかも!?

いまでも、常に音楽を求めています。

(でもさすがに、
自分で演奏する時間は取れなくなっちゃったなぁ...
KORG電子ピアノフルートもすっかり眠ったまま)

気持ちに直結するもの

音楽って言っても、たくさんジャンルあるし、
みんなが音楽好きとは限らないし、
別にそういうことはどうでもよくって...

みなさん、なにか、あります?
自分の気持ちに直結するもの。

プログラマーになって、
時間がなくなって削られていく中、
つらいこともたくさんある中、
でも大切にキープしていきたいですよね。

ぼくはプログラマーになり、
音楽とはすっかり無縁の世界で四苦八苦してますが、
音楽をそばに置いておきたいと。
そばにいないとなかなか前向けないから。

f:id:jflute:20160208155904j:image

2016-03-02

わけわかんないレビュー会こそスキルアップの場

|

特に若者、レビュー会のとき何をしていますか?

...

「いや、レビューしてますよぅ」

そうですか...

ホントに?

なんかメールチェックしてたりしませんか?
メール返してたりしませんか?
自分の仕事やってたりしてませんか?
Twitter見てたりしませんか?
まんが読んでたりしませんか?

...

いやべつにそれがダメだと言いたいのではありません。
そんな月並みのこと書いてもしょうがない。

ダラダラしたレビュー会であまりに退屈だから、
三国志60巻を会議室に持ち込んで読み切るとか、
したくなる気持ちわかります。
レビュー会はレビューワーが考える時間も必要だから、
なんだか間が空きがちですしね。シーン...って。

レビュー会を開催する方は、
そういう人が出てこないようにファシリテートしていく
必要がありますし、そのために色々と選択肢はありますが、
今日はそういうことを書きたいわけじゃないです。
(それはまた別途エントリ書いた方がいいかな)

...

レビュー会に参加しまーす。
でも、自分はレビューイーではないけれど、

「レビューできるほどスキルがない」

というか、

「レビューするための業務的・技術的な前提知識がない」

もーわけわかんない、でも、その場にいる。

...

というときに、どうしたらいいか?

他の人のコードが見れるチャンス

レビュー会は、他の人のコードが見れるチャンスです。
別に普段も見ようと思えば見れる環境かもしれませんが、
きっかけがなければなかなか見ないですよね。

だから

ソースコードリーディングやってる

と思えばいいのです。
わからなくてもとにかくインプット。
「あれはなんだろう?これはなんだろう?」
ひたすら思考を巡らしましょう。

説明されてるコードだけじゃなく、
画面に写っているコードは、
じゃんじゃん目に入れていきましょう。
その分、コードを追う力が付きます。

家に帰って一人でコード読んだりなかなかしないですよね?
(して欲しいけど)
であれば、レビュー会はスキルアップの大チャンスですよ。

他の業務を知るチャンス

大きなプロジェクトであればあるほど、
他の業務のことなかなか知ることができません。

「へー、こんな機能あるんだー、
こんなことやってるんだー」

エンジニアにとって、
業務を理解するって精神的になかなか
つらいものですよ。(多くの人が)
効率良く知っていければいい。

レビュー会は「業務理解の場」になります。
家に帰って一人で業務を理解しようとなかなかしないですよね?
(さすがにあんまりいないよね...)
であれば、レビュー会はスキルアップの大チャンスですよ。

発表の仕方、伝え方を知るチャンス

レビュー会は、講師がしゃべるわけじゃありません。
わりと自分と近い立場のレビューイーが発表します。
(レビュー会のやり方いろいろありますが...)

ある意味、上手・下手のギャップがすごく激しく出ます。
普段講演会だとか勉強会だと、
大抵は慣れている人が前に立ってしゃべりますが、
レビュー会はそうもいきません。

ギャップを見るチャンスですよ!

こう伝えると伝わりやすい、
逆にこうだと伝わりにくい、

レビューイーが次から次へと変わっていきますから、
比較もしやすい、自分とも当てはめやすい。

レビュー会は「観察できる貴重な場」です。
家に帰って一人でレビュー会をやろうとはなかなかしないですよね?
(絶対にいないでしょ)
であれば、レビュー会はスキルアップの大チャンスですよ。

どれだけ集中力だせる?

jfluteは、
多くの人のスキルアップ相談を受けていますが、
すべての人の Problem があります。

「時間がない」

です。

年齢を重ねれば重ねるほど、
人生のイベントも多くなり、
関わる人も多くなり、
どんどん時間は少なくなってきます。

いかに効率良く時間を使うか?

それがすべて。
短い時間でどれだけ多くのインプットするか?
以前のブログ「独学のきっかけ」でも書きましたね。

効率の良い努力をする努力した人が成功する

...

なかなか自分が役立てないレビュー会、
なんだか間延びして退屈なレビュー会、
ぼーっとしているよりかは内職してた方が...

と思いがちですが、

レビュー会でしかできないことがあります!

なので「インプットの場」という割り切りで、
最大の集中力を出してみてはいかがでしょう?

...

レビュー会自体がダラダラしてようが、
気にせず「自分が成長するんだ」と、
目をギラギラさせてインプットすればいい。
周りの人とは時間の進み方が違うと思って。

その繰り返しが、
本当にレビューワーとして役割を果たすことができる
スキルを身につけるのです。

f:id:jflute:20151221124705j:image

2016-02-21

エンジニアのモチベーションを下げる方法

|

モチベーションの高いエンジニア...

ガンガン働いてくれそうで、
放っておいても安心でしょうか?

安心してください。
簡単に下げられますよっ!

o 序の口: ディスプレイを小さくする
o 序二段: 毎日スーツを着させる
o 三段目: 椅子を固くして、机を狭くする
o 幕下: 簡単に作れるでしょ?って上から目線で言う
o 十両: 打ち合わせ一杯で連続した集中時間を与えない
o 前頭: 情報共有しづらい、風通しの悪い現場に
o 小結: 引き継ぎなしで人をどんどん入れ替える
o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う
o 大関: 仕事を突然終了させて無意味感を与える
o 横綱: 本質的でないことに時間を取らせる仕組み

序の口: ディスプレイを小さくする

エンジニアの仕事の多くはパソコンの中にあります。
そのパソコンの中を覗く唯一の手段はディスプレイです。
そんな狭い中で、色々な資料をみながら、
プログラミングをしていきます。
ドキュメント資料を開きながら、エディターで実装する。
それがスムーズにできればできるほど効率良く、
ストレスも少ないです。

なので、小さいディスプレイを支給すれば、
モチベーションは下げられます。
優秀なエンジニアほど効率を求めるので、
下がり具合は大きいものです。

小さなディスプレイでも二台あればエンジニアは
うまく使いこなして作業効率を上げます。
なので一台取り上げてしまえば、気分は最悪に。

すでに大きなディスプレイが支給されている場合は、
ガムテープで3割くらいの表示領域を塞いでしまえば、
同じ効果があります。
それどころか、全画面表示が役立たずになるので、
プラスアルファの効果が期待できます。

序二段: 毎日スーツを着させる

エンジニアは多くの時間、オフィスで座って仕事をします。
肉体的には、逆にけっこうつらいものです。
あまりにクタクタな感じのを着たいわけではないですが、
ある程度リラックスできる格好でいたいものです。

なので、毎日スーツを強制させれば、
モチベーションは下げられます。
「エンジニアがスーツを着てる会社には行かない」
とか言ってるエンジニアもいますから、
リクルーティング的にも、スーツを着たエンジニアを
前面に押し出せば、応募すらしてこないので、
最初からミスマッチも防ぐことができます。

これは個人差が激しいので、
ちょっと該当しない人もいるかもですが...。

三段目: 椅子を固くして、机を狭くする

エンジニアはオフィスで長い時間座りますから、
椅子が人体に与える効果をもろに受けとります。

良い椅子であればあるほど、
体のリラックスを長い時間キープできるので、
集中力の持続もしやすくなってしまいます。
なので、いかにも長時間座るのには向いてない
「固い椅子」を与えればモチベーションを下げられます。

すでに良い椅子が支給されている場合は、
クッション部分に鉄板でも挟んであげれば、
同じ効果を得ることができます。

机の広さも同様ですね。
広ければその分、色々な資料や本を並べて仕事ができるし、
他のエンジニアコミュニケーションも取りやすいので、
すでに支給されている机が広いのであれば、
ノコギリやチェーンソーで切り取れば台無しにできます。

幕下: 簡単に作れるでしょ?って上から目線で言う

IT系のエンジニアは、なかなか世間一般の方々から、
やっていることを理解されにくいものです。
何が簡単で、何が難しいのか、なかなかわからないもの。
しかも、そう思われていることを、
エンジニア自身よくわかっていて、
それがコンプレックスでもあったりします。

開発しようとしている画面があったとして、
画面の見た目から来るイメージと、
実際のプログラミングの難しさはなかなか比例しません。
簡単そうな画面でも作るのは難しい、よくあることです。

なので、よくわかってないフリして、
「えっ、こんなの簡単に作れるでしょ?」
って言ってあげると、大抵「はぁ!?」って表情をします。

ちょっと納得がいかないだけなら、
モチベーションを下げたことにならないですが、
そういうことを何度も何度も言い続けることで、
「難しいことを実現しても評価されないのでは...」
って気持ちになるので、
しっかりモチベーションを下げられます。

実際に、難しい画面を頑張って速く作り上げたエンジニアに、
「あー簡単そうな画面だったもんね、じゃあすぐ次これ作って」
と、軽くあしらってあげると効果が相当高いです。

十両: 打ち合わせ一杯で連続した集中時間を与えない

エンジニアの仕事は、もの作りです。
プログラミングしている最中は、
脳の中でたくさんの情報を扱います。
その状態はすぐにできあがるものではありません。
要は、スポーツするときのウォーミングアップと同じで、
ある程度ホットな状態に持っていくまで時間がかかります。
また、優秀なエンジニアほど、
そのホットな状態での作業効率を重視しています。

なので、その連続した集中時間を途切れさせるように、
中途半端に間をあけて打ち合わせをたくさん入れてしまえば、
モチベーションを下げられます。

とはいえエンジニアも、
打ち合わせが必要なことはわかってますから、
別に重要な打ち合わせであれば、
しっかりその辺をセルフコントロールします。

なので、なんだか無意味そうな打ち合わせや、
ダラダラして間延びした打ち合わせ、
本人には関係なさそうな打ち合わせを入れてあげれば、
イライラしてセルフコントロールを崩すことができます。

前頭: 情報共有しづらい、風通しの悪い現場に

大抵は、エンジニアはチームで仕事をします。
一人でもの作っておしまい、って思われるような仕事でも、
会社にいる限りは何かしら他人の情報に依存しています。

なので「必要な情報」というのは共有されないようにして、
エンジニアの成果物が的外れになるようにしてあげれば、
モチベーションを下げられます。
「いや、それ聞いてないよ」
ってセリフを出させることがポイントです。

エンジニアの中には、そういった情報を自らの行動で、
積極的に取りにいく方もいらっしゃいます。
そういうときは、
そういった積極的な行動をしても、
いまいち情報が出てこないような、
「他人に無関心なチーム」にしていけば、
情報を阻止することができます。
いわゆる「風通しの悪い現場」にすればいいのです。

良いコミュニケーションは、
気の利いたプラスアルファの情報のやり取りが発生し、
エンジニア同士のスキルの相乗効果を生んでしまいますし、
そういった技術交換が楽しくてスキルアップにつながり、
モチベーションが下げるどころか上がってしまいます。

なので、
「質問されたこと以上のことは答えない」
「何か困っていることに気付いても聞かれるまで教えない」
これらをテーマにしたムード作りをしていけば、
だんだん質問自体がしづらくなってきます。

「えっ、なんでそれ教えてくれなかったの!?
だってさっきそういう話してたじゃん、
なんかひとこと言ってくれても...」

って言葉が出てくれば、
「風通しの悪い現場」の完成です。

小結: 引き継ぎなしで人をどんどん入れ替える

エンジニアのやる仕事は色々と入れ替わるものです。
エンジニアの中で色々な仕事があるため、
あれできる人、これできる人と都合があるため、
すぐにチームを移動したりってのは日常茶飯事です。

人が入れ替われば、
そこに「引き継ぎ業務」というものが発生します。
特にエンジニアのやっている作業は、
人によって随分とバラバラであり、
かつ、パソコンの中に閉じ込められているため、
引き継ぎなしで新しい人がスムーズに作業を開始する
というのはまずありません。
なかなか仕事内容が定型的にならないため、
他人の作った環境や成果物を完全に把握するのには
時間がかかるし、ストレスのかかるものです。

そこで、
引き継ぎ業務は直接的なビジネス業務ではない、
という名目で、引き継ぎ期間を設けず、
引き継ぎ業務をさせずにどんどん人を入れ替えれば、
モチベーションを下げられます。

関脇: 背景わきまえず、コード汚い、仕組みひどいと言う

特に事業会社でのスタートアップは、
ジャングルの中でプログラミングしているようなもの。
会社も立ち上がったばかりなら給料も低いし、
次から次へとプログラムを作らなければなりません。
サバイバルコードもたくさん生まれます。
気の利いた仕組みを構築しようにも、
それを整備する時間もなければお金もありません。
(アーキテクトを連れてくるお金はありません)

それがわかった上で、現場のエンジニアは戦います。
単なるスキル不足のケースもあるかもしれませんが、
高いスキルがあってもサバイバルコードは生まれます。
ジャングルで突然、蛇に襲われたときに、
「正座して一礼をしてから刀を構える」
なんてしてられないのです。

その後、成長した事業の中で、
スタートアップのときのサバイバルコードを、
そういった背景もわきまえず、
汚いだとか仕組みがひどいだとか言えば、
モチベーションは下げられます。

「同じ状況でおまえやってみろよ」

と思わせれば達成です。

ですが、そういう背景をよくわかった上で、
サバイバルコードに敬意を表しながら、
役割を終えたコードを次のフェーズに向けて淡々と直す、
そういうエンジニアもいらっしゃいます。

そういうエンジニアには、
「へぇ、そういうコード、好きなんだ、君も書くんでしょ」
と、価値観を疑ってあげれば、
そのエンジニア自体のモチベーションが下がり、
スタートアップ時の背景を伝える人もいなくなり、
誰もスタートアップしたくなくなるでしょう。

スタートアップを例にしましたが、
似たような状況は他でも発生しますので、
応用はいくらでも効くと思います。

大関: 仕事を突然終了させて無意味感を与える

一生懸命モノづくりをしてきて、
さあ、さらに作るぞー、リリースするぞー、
というときに、その仕事が突然中断おしまい。
まあ、なかなかつらいことではありますよね。

とはいえ、
それがアクシデントだと確かに悲しいですが、
会社の方針とか合理性から来るものであれば、
エンジニアもよく理解していますから、
気持ちの整理して前向きに考えるようにします。
 => 仕事の先にある仕事は明るい

なので、そのこと自体よりも、
ポイントは「伝える言葉やニュアンス」です。
それまでそのエンジニアがやってきたことが

まったく意味の無かったことである

ってのを強調して伝えてあげれば、
モチベーションを下げられます。
具体的にどう言うか?はお任せします。
できるだけ軽率な言葉を選びましょう。

「一生懸命やってきたことの無意味感」を与えることで、
受けたショックを前向きな方向ではなく、
会社に対する不信感に変化させることができます。

その仕事に対してどのくらい情熱を燃やしてきたかどうか?
情熱があればあるほど、その落差が激しいもの。
今後、そのエンジニアはその会社の仕事で、
身を削ってプラスアルファの成果を上げようとは
思わないでしょう。

「そんなのエンジニアに限らずそうじゃん?」
ってのは That's right ですが、
エンジニアの仕事柄、そういう場面が多いということです。
つまり、モチベーションを下げられるタイミングが
たくさんやってくるというところです。

横綱: 本質的でないことに時間を取らせる仕組み

よーし、がんばるぞー、
と意気込むエンジニア。
たくさん成果を出してくれます。

なんとかして成果を出さないようにするためには、
本質的でないことに時間を使ってもらいましょう。

もしも、Aさんが、プログラミングする前に、
どうしても「ハサミ」が必要だったとします。
ハサミを探しています。あれぇ...ないなぁ、
えーとハサミハサミ、ここにも、あそこにもない...

A「だれかハサミ知ってる?」
B「Cさんが知ってたと思うよ」
A「(Cさんを探して探して...) Cさん、ハサミどこ?」
C「ああ、あの棚に置いてある」
A「ありがとう...あれない...やっぱりないよー」
C「あれ、まえあったんだけどなぁ、誰か戻してないかも」
A「じゃあ、大声で聞いてみればいいかな?」
C「いやぁ、迷惑かかるから全社メールで聞いたら?」
A「でも、メールもそんなしょうもないことで出すと言われそう。
  いいやもう、買ってきちゃおう」
C「じゃあ、会社の備品として申請するのでこれ書いて承認を...」
A「いや、もう個人のものとして買おうかと」
C「個人のハサミを持ち込んじゃいけないことになってるので」
A「なんでピンポイントでハサミだけ!?いいや、カッターで...」
C「ハサミで切ったものじゃないと成果として認めないらしいよ」
A「むっきゃー、しごと進まねー」

まあその後、幸いハサミは見つかりました。
でも今度は「ノリ」が必要で...「ホッチキス」も...

A「ふー、やっとプログラム書けるよ...
  ってもう17時じゃーん(><」

ちょと大げさですかね?
でも、こういったちょっとしたコスト、
当たり前ですが「チリも積もれば」理論が効きます。

「環境構築にすごい時間がかかる...」

「なんかアプリの起動が遅くって、
ちょっとしたこと確認するのに時間がかかる...」

「UnitTest書こう...にも、
そもそもテスト実行のための環境が整ってない...」

「間違ったドキュメントで実装して手戻り...」

「コードが読みづらくって、
既存コードの挙動の確認に時間がかかる...」

「DBに入ってるデータのルールがよくわかんなくて、
毎度毎度既存コード読んで確認しないといけない...」

「DB設計が微妙過ぎて、いちいちクエリが複雑になるし、
とにもかくにも間違えやすい...」

「テストデータが全然なくって、
毎度毎度自分で手作りしないといけない...」

「テストデータが間違ってて、
バグなのかデータ悪いのか判断に時間がかかる...」

いくらでもあります。
もっとケースバイケースでたくさんあるでしょうし、
別に開発環境だけの話ではないでしょう。キリが無い。
要は…

★★★★★★★★★★★★★
★           ★
★ 部屋が散らかってる ★
★           ★
★★★★★★★★★★★★★

ってことです。
散らかってる空間の中で何か作業しようとする。
「ハサミを探す」ような本質的でない作業が
たくさん発生します。

エンジニアじゃなくても同じ話ではありますが、
特にエンジニアの環境というのは、
「前提条件が多く、かつ、複雑」です。
なので放っておけばチリは簡単に積もります。

そういった「エンジニアストレス」を
溜めるような仕組みと環境を構築すれば、
モチベーションを下げられます。

というか、構築するまでもなく、
放っておけば勝手に下がります。
そう、エンジニアストレスを軽減することに、
何も関心も持たずケアもしなければ、
勝手にモチベーションは下がっていくんです。
これは楽ですね。

時にそういうストレスを解消しようと、
能動的に動く方がいらっしゃいます。
部屋が散らかってると片付けたくなるタイプです。
できるだけストレスを軽減し全体効率を上げようとします。
そういう場合は、いわゆる「減点方式の評価」にして、
何かちょっとでもミスをしたときに厳しく追及すれば、
誰も能動的な改善をやろうとする人はいなくなるでしょう。

合わせ技は効果抜群

「ほったらかしで本質でない作業たっぷりのシステム」を、

「引き継ぎなし」で任せて、

「助け合いもしづらい体制」の中、

「小さなディスプレイを支給」する。

でも、そういう仕事に限って突然終了しない。

会社は好きなのに去る人

会社が嫌いな人が会社を辞めるのは普通でしょう。

でも、その会社に対しては尊敬の念を持っていて、
良い会社だと思っているのに、

「自分はもうこの会社では働かない」

と言って去る人もいます。

「会社は好きだけど、このシステムのメンテはイヤ」
「会社は好きだけど、このチームで働くのはイヤ」
「会社は好きだけど、ここで働く気力を無くしてしまった」

とか。

会社に対する思いと、
エンジニアモチベーションは、
絡み合いながらも時に分離します。

モチベーションの下がる姿ほどつらいものはない

o 技術欲の高い系エンジニア
o 問題解決欲の高い系エンジニア
o 自己成長欲の高い系エンジニア

独学のきっかけ であったように、
エンジニアもさまざまですから、
当てはまる人が当てはまらない人もいるでしょうし、
タイプに固有の下がり方とかも存在するでしょうが、
おおよそのエンジニアで言えそうなものを
ピックアップしました。

そして、jfluteの10年以上の経験から来るものです。
実際に自分がモチベーションが下がったり、
下がってる人を見たり聞いたり。。。

もちろん、エンジニアもね、
簡単にモチベーション下がらないように、
しっかりセルフコントロールしていかないと。
加えて、チームとして、人同士として、
互いを尊重して気持ちのよい現場にしていかないと。

非エンジニアの方がエンジニアモチベーションを下げるだけでなく、
エンジニアエンジニアモチベーションを
下げることも大いにあります。

また、モチベーションが上がりやすい人は、
モチベーションが下がりやすいと感じています。
上がっていれば安心かと言うと、
その上がってる理由がなくれば遠慮なく下がると。

それにしても...

自分のモチベーションが下がるよりも、
モチベーションが下がる人を見る方がつらい

ですね。

チームを作るというときに、
できるだけこういったことが起きないように、
ファシリテーションをしていきたいし、
自分も気をつけたい。
それを整理するために書いた。

f:id:jflute:20160214161153j:image

通りすがり通りすがり 2016/02/25 12:47 SI屋が普通にやってることじゃん。こんなことに文句言ってたら日本じゃ就職先ないよ。みんなそうしてるんだから、みんなに合わせなくちゃ、生産性の高いこの美しい国ではね。

一つだけ一つだけ 2016/02/25 14:41 コードが汚いならそう言うべきだし言われた方は素直に反省すべきだな。時間がかかるのは奇麗に書くのに慣れていないだけ。

>役割を終えたコードを次のフェーズに向けて淡々と直す、そういうエンジニアもいらっしゃいます。

言葉にしないだけで腸煮えくり返ってるよ。

   2016/02/25 19:19 >o 三段目: 椅子を固くして、机を狭くする
>o 幕下: 簡単に作れるでしょ?って上から目線で言う
>o 十両: 打ち合わせ一杯で連続した集中時間を与えない
>o 前頭: 情報共有しづらい、風通しの悪い現場に
>o 小結: 引き継ぎなしで人をどんどん入れ替える
>o 関脇: 背景わきまえず、コード汚い、仕組みひどいと言う
>o 大関: 仕事を突然終了させて無意味感を与える
>o 横綱: 本質的でないことに時間を取らせる仕組み

これを2年間やられて、頭おかしくなりそうだったことがある。
おかげで今はニートですwww

kk 2016/02/26 09:05 良くあることだけど合わせ技がきついよな。
で、それら切り抜けても評価もしてくれないし。

sibire_olympicsibire_olympic 2016/07/12 15:21 突然すみません!
いつもブログ拝見してます。
移住をともなう転職を支援をするsibireというサービスを運営しています。
今度、こんなイベントやります。
http://www.sibire.co.jp/event/entry1
エンジニアの「幸せな移住」事例を増やしたいなあと思ってます。
参加者を募集しており。ブログで紹介してもらえると嬉しいです!

jflutejflute 2016/07/13 01:18 id:sibire_olympic さん、こんばんは。
ブログ読んで頂き、ありがとうございます。
さて、紹介の件ですが、申し訳ないですが、
こちらの記事の内容に対するコメントとしては、
あまり適してないというか、アクセス数の多い記事なので、
こういう形で宣伝すると変に勘ぐられて逆効果かなと思います。
なので、代わってTwitterの方でさせて頂きますね。
(申し訳ないですが、こちらのコメントは後で削除させて頂きます)
イベント頑張ってください。