購読中です 読者をやめる 読者になる 読者になる

seri::diary

プログラミングのこととかポエムとか

継続的生き方改善

こういうことはどこに書けばいいのか、誰に吐き出せばいいかよく分からなくて、そうだ俺には私的なブログがあるではないかということで「ポエム」カテゴリーの創設と相成った。

TL;DR

  • 最近読んだ本に「人生で成し遂げたいことを見つける事が重要だ」「今の若い人は自分が本当にやりたいことを知らない」と書いてあって圧倒的つらみ
  • え、じゃあ俺どうやって生きてきたん?って考えたらその場その場での「やりたい」ことに寄せていって、結果的に今は満足度高いやん。やったぜ。
  • 明確な「やりたいこと」が無くても小さな「今はこれやりたい」「これ好き」「これ嫌い」ということはすぐ見つかるのでそれを頼りにやりたいことが出来るように努力していると人生そこまでつらくなくね?って最近思ってる

意識高い本を読んだのさ

自分は月に3〜4冊ペースで色んな本を読むのだが、最近読んだ自伝的な本の中に「最近の若い人はやりたいことを知らない」「まず自分が本当にやりたいことを知るべきだ」という主張が書かれていた。しかも1冊のみならず2冊。

たまたまどちらも自伝で、社会的に成功している人の話だからそういうことが書かれていたのかもしれないのだが、それを読んで「ほほー。自分の場合はどうだろ?」と考えだしてみたら、非常に恐ろしいことに気づいてしまった。

自分はやりたいことが無い。

いやいや、相変わらずプログラミングは好きだし、今の職業自体には満足しているじゃんよ。少なくとも「やりたくないことやってお金をもらっている」のではなく、「好きなことをやってお金をもらっている」状態に近い。

じゃあやりたいことやれてんじゃん?ってずっと思ってたけど、ではこの先もずっとどんな形であれ現場で開発し続ける1人のエンジニアで一生を終えて満足だろうか?他にやりたいことは無いだろうか?と考えた時に、正直自分は一生エンジニアで一生を終えても満足出来ると思う。一生会社員でも満足出来ると思う。というのは本音だった。

けれど、それは残りの人生の日々の生活が「エンジニアとしての日々」であったら良いな、ということであって、人生において成し遂げたいことではない。

では自分は何を成し遂げたいのか??…と考えると、「正直何もありません」というのが今の回答になる。

マジか俺!エンジニアとして成長し続けて生き続けて死ねたらそれで満足とか、そんな何も目的のない人間だったのか俺!そんなつまらない人間だったのか俺!ということに気づいたのがちょうど3ヶ月ぐらい前。

やりたいことがないとつらい?

自分の周りには明確にやりたいことがある人間が数人いる。他にも「お前何がやりたいん?」と聞けば答えてくれる人がいるかも知れないけど、明確に答えを聞いたことがあるのは数人しかいない。

「お金を稼いで働かなくても良いようになりたい」というやつもいて、それは確かに明確だ。彼にとって人生において

  • 「働かなくてもいいくらいお金を稼ぐ」

ということが人生で成し遂げたいことであって、

  • だから仕事も儲かることを優先的にやりたい、

とのことだった。非常に筋が通った話だ。放っておくとマグロ漁船かベーリング海のカニ漁船にでも乗りかねないのでもし相談されたら止めておこうと思う。

じゃあ自分はどうやって生きてきたのさ?

自分の職歴を振り返ると

SIerでSE

Web制作会社でエンジニア

自社サービス会社でエンジニア

受託開発会社でリモートワークしながらエンジニア

という感じになる。

SIerを辞めた時に思っていたのは「便利なWebサービスを作りたい」ということだった。だから独学でphpを勉強して良く分からないサービスをドメインまで取って公開したりした。

けど自分1人で作りたいとは全然思ってなくて、一緒にサービスを成長させていく仲間とチームでサービスを作っていきたいというのが最終的なゴールだと考えていた。

「作りたい」というよりは「同じ志を持った仲間が欲しい」が本音なのかも知れない。

なのでそれができる自社サービス会社に入ろうとしたが、プログラマとしての職歴がなければ難しいと考えて、まずはプログラマとしての職歴を持つために運良く内定を取れたweb制作会社に入ったという感じで、その後に念願の自社サービス企業に入社してサービス開発に携わる事が出来た。

ああ、やりたいことをやれているな、と思っていたはずなのだが、元々考えいてた地方で暮らしてみたいという別の欲求も強くなって、今度はそちらを実現させてみることにした(が、その結果色々わかったことがあって方向転換)、というのが今の状態である。

こうやって順番に書いてみると、自社サービス会社でエンジニアとして働くことができている時点でもう自分がやりたいことは満たされていた。

それでも自分の内から「やりたいこと」は見えてこなかった。ずっとこの会社にいて働き続けることはできるけど、それも何か違う、という違和感があったのも事実である。

単に移り気が激しすぎるとか飽き性だから、という理由もあるにはあるのだが、それでも自分の人生において道標となるような何かが見つからないせいで迷い続けているのも事実だと思う。

それでも今の生活はそこそこ満足できている

それは今好きなことを仕事に出来ているから、に尽きる。

エンジニアとしてコードを書くことを生業としていられる。堂々と仕事としてコードを書いて他のエンジニアと設計や実装について議論していられる。それが仕事だから。

そういう日々が今は楽しいと思える。以前はそうではなかった。

SIer時代は仕事がイヤでしょうがない時期もあった。

とにかく仕事がつまらなくて、自分でコードを書けない不満ばかり溜まっていて、早く抜け出したい一新で帰宅してからずっとphpの教本を写経したり掲示板もどきみたいなのを量産して勉強していた。

あの時は本当に仕事が「したくないこと」で、「やりたいこと」をやるために邁進していたのだと思う。コードを書くことが人生で成し遂げたいと思えることではなかったけど、あの時点では「自分でコードを書ける仕事をする」ことがやりたいことだった。

それが前述した通り次のステップで「自社サービスを開発するメンバーとしてチームで開発する」ことが次に目指すものになった。だからweb制作会社でも必死に仕事をしていた。

目の前には「今すぐやりたいこと」なら転がっていた

という感じで、自分の過去5年ぐらいを振り返ると、その場その場での「やりたい」と思えることはあって、それを達成するために努力して実現させてきて、その過程で自分が満足できる生き方に気づいたり、それに現実を寄せていくための活動を継続してきた、ということなのではないかと思う。「継続的生き方改善」とでも言ったところか。

それを支えてきたのは「今やりたいことを絶対やるんじゃ」と決めて、それに必要なことを学んだり身につけたりするために努力し続けた結果なのではないか思う。

今でもエンジニアとしての勉強は継続しているが、それは単に業務で必要なためというよりは、自分が何かやりたいことが出来そうなチャンスが来た時に、そこに飛び込む為だと考えている。

趣味でやっている部分もあるのだが、それ以上に「こういう会社のこういうチームでこういう求人が出ていて、そこに自分が行きたくなった時に飛び込めるかどうか」ということを基準に考えている。人間性やマインドはマッチしてるけど、スキルが足りなくてダメ!って言われるのは自分の努力不足だしな。

で、そういう生き方はどーよ

こういう生き方が本当に良いのかどうかは自分がもう少し長く生きてみないと分からないが、自分としてはこういう生き方が好きだと思う。

まぁ、それなりに歳も取ってきて年収も増えて、金銭的に若干余裕のある独身ならではのなせるワザなのかも知れない。それでも自由であるうちはこの生き方であり続けたい。結婚したら考え方変わるかもな。

相変わらず人生の目標とやらは見えないし、カニ漁船に乗ってでも金儲けして将来ダラダラ過ごしたいとは思っていないが、それでも継続的に自分の生き方を満足出来る方向に寄せていくこと、寄せるための努力を続けること。それがどうやら自分には合っているようなので、それがいいんじゃねーかな、ぐらいに最近は思えるようになって、ようやく気がラクになってきた。

近況 - 実家に引っ越した

TL;DR

  • 4月下旬に盛岡のアパートを引き払って栃木の実家に引っ越した
  • 今は実家からリモートで仕事している
  • 5/30は渋谷javaがあります

栃木の実家に戻ってきた

  • 所謂引っ越しである
  • 実家にネットが通ってて助かった
  • 新宿までは電車で2時間で出られる
    • 試しにGW中によく東京に行って人と会ったりしていた

仕事は

  • 引っ越しは土日にサクっと片付けて翌週の月曜日から実家でリモートで仕事している
  • PCとネット環境さえあればどこでも仕事できるなーとは思ってたけどホントに地理的な制約を受けない感じなので自分でビビっている
  • 特に問題は起きていない

なにゆえ

  • 色々今後のことを考えると東京にすぐ出られる場所に住んだほうが良いという結論になった
  • 半年ぐらい盛岡にいて東京近郊に住むメリット・デメリットを改めて整理する良い機会になった
  • 細かい話は本人捕まえて君の耳で確かめてくれ

直近では何やるの

  • 5/30の渋谷javaに出て久々にLT
  • とちぎRubyの会のイベントに出たいと思ってるけど開催地が主に県北で遠いのと自分が車持ってない上に10年運転してないペーパードライバーなのでちょっと参加しづらいので考え中
  • クラシックギターを本格的に再入門する予定

今後どうするの

  • 君の耳で確かめてくれ

近況

仕事

  • 2月から自社サービスを運営している会社の1エンジニアとして派遣?みたいな感じで仕事をしている。
  • 相変わらずリモートしてるけど上述の派遣先の会社のオフィスで仕事したりもした。久しぶりのオフィス勤務めっちゃ集中できたし聞きたいこともすぐ聞けるし、自社サービスの場合で多忙期はオフィス勤務の方が効率良いと思った。
  • やっぱ自社サービスいいなと思った。週2回デプロイでガンガン開発回してくの楽しい。自分が作った新機能もいくつか本番デプロイされている。
  • あと平日にリアルで人と接するのが久しぶりで楽しかった。
  • 今後も毎日ではないがタイミングを見て出勤する予定。
  • 急成長中の会社で、かつちょうど自分が前職にjoinした時と同じぐらいの規模感で共通点が色々あって何となく懐かしさを感じる。

プライベート

  • 3月に所属してるマンドリンオケの年1回の演奏会終わって毎週の練習、毎月の集中練習がなくなり、音楽活動はしばらく暇になった。今後はクラギの独奏に専念する。
  • 新しいサービス作り始めた。5月連休中にはリリースしたいけどherokuの無料枠が減るという噂でサーバをどうするか考えてる。
  • 1年ぶりぐらいにslidesearch.jpに手を入れてrubyrailsのバージョン上げた。久しぶりに触ったらUIがひどかったのでこちらも手を入れたい。
  • 宇宙を目指して海を渡る読んだ。情熱をずっと保ち続けられることが何かを成し遂げる上では重要なのではないかと感じた。
  • ジョナサン・アイブの本読んだ。工業デザインにこれまで全く興味なかったけど本文の「まずストーリーを決めてからデザインを考える」という一節で興味を持つようになった。
  • Code complete読んでる。まだ上巻の15%ぐらい。ソフトウェアの手戻り修正コストがフェーズによって何十倍も差があることについて昔SIerの研修で習ったなと思い出した。
  • エリック・エヴァンスのドメイン駆動設計読んでる。まだ序章しか読んでない。なかなか読み終わらなそうなので地道に読む。
  • BOOK SCANで技術書を30冊ぐらいまとめて自炊したらkindle paper whiteだと文字が小さすぎて若干つらい。(読めなくはない)。PCでpdfで読むのは普通にアリ。字が大きめの本やマンガ向きのサービスのような気がする。

「志乃ちゃんは自分の名前が言えない」を読んだ

イケダハヤト氏のブログで紹介されていて気になっていた「志乃ちゃんは自分の名前が言えない」を読んだ。

www.ikedahayato.com

忘れてでもいない限り自分の名前は誰でも言えると思う。 だから大抵の人はこのマンガのタイトルを見て不思議に感じるのだと思う。

「大抵の人」はこのタイトルからどういうストーリーを感じるのだろうか。

「自分の本当の名前を知らない孤児の話?それとも何かの暗喩?」とかそんなもんだろうか。

自分がこのタイトルを見て最初に思ったのは「あー、あるよねー」みたいな感じ。

自分も「名前が言えない」タイプの人間である。

自分の名前を知らない訳ではない。親からもらった名前はスラスラ書ける。

webサービスでサインアップする時に入力できる。紙面やディスプレイ上の文字列を「自分の名前」として認識できる。

できないことを挙げるとするなら、「口頭」で「自分の名前」を「発音する」ことができない。

いつも、という訳ではなくたまに出来ない。だから美容室の予約とかするのに異常なほど緊張してしまう(ので最近はメールで予約している)。

ここまで書いても「なんのこっちゃい?」と思う人が大半だと思う。

いや、自分自身「なんのこっちゃい」と思っている。

吃音という言葉について

吃音」(きつおん)という言葉をどれだけの人が知っているのか知らないが、まぁそういう言葉がある。なお自分は大学生になってからwebで偶然見つけて初めて知った。

wikipediaによれば

発語時に言葉が連続して発せられたり、瞬間あるいは一時的に無音状態が続くなどの言葉が円滑に話せない疾病

なんだそうだ。で、自分もこれに該当する。

円滑に話せないというのも色々あって、

「おおおおおおおおおおおおにぎりが食べたいんだなななな」

みたいに無駄に連発してしまうケースと

「お、、、、、、、、お、、、、、お、、、、、」

となって何故か言おうとしていることが言えないパターンとか色々ある。

もっとリアルに書くと「あの、、、あの、、、、、、、あの、、、あ、、、あ、、、、、、」っていう感じになる。

自分の場合は後者の症状が出る。それまで流暢に会話してたのに突然発声できなくなる。

上手く表現できないのだが、話したい言葉は一語一句頭の中で完成しているのに、「何かが」発声を妨げている。そんな状態。なお、現代医学でも原因は詳しく分かってないそうなので、どうしてそうなるのかは分からない。

本作の内容について

吃音の説明が少し長くなったが、このマンガ、吃音持ちの人間からすると「異常なほどリアル」である。

リアルすぎて過去の数々のトラウマが蘇ってきて気分が悪くなるくらいリアルである(褒め言葉ですw)

吃音で辛いのはコミュニケーションが取れないことではない。 大抵、身振り手振りで何とかなるし、レストランで注文が出来ない時なんかはメニューを指さしてそれっぽい表情をすればよい。

辛いのは「自分が変に思われている」と思う点にある。

要するに、

普通の人は普通に口頭で会話ができる。 普通の人は友達とクソくっだらない雑談ができる。 普通の人は面白いことを思いついたらそれを話して友達を笑わせることができる。 普通の人は飲食店で注文ができる。 普通の人は居酒屋で注文ができる。 普通の人は道行く人に道を聞くことが出来る。

そういう「普通の人」ならできることができない、ということが「異常」であり「不自然なこと」だと周囲が感じる以上に本人自身が強く思っていて、それを気にしている。

これが吃音の本当の恐ろしい所であり、世間からあまり理解されない所である。

「周囲からそういう変な目をされた」と自身が思うことで、自分自身を傷つける。 それがどんどんトラウマになって性格も控えめになる、人と距離を置こうとしてしまう、結果ますます孤立する、という負のループにハマってしまいやすい。学校教育で「普通であること」が強く求められるこの国では、「普通の人と同じことが出来ない」ってのは思っている以上に人を追い込む要因なのかも知れない。

作中でも主人公は上記のような「負のループ」によって辛い目に遭う。

詳細は内容を読んでいただくとして、高校生だと辛いよな。女の子ならなおさらじゃないだろうか。「日常会話」の重要度が男のそれとは恐らく大分違うだろうし。

いや、男でも辛いか。少なくとも、本来対して人見知りでもないのに、同級生とまともに会話できないせいで無駄に距離を感じて親しくなれなくて自分は辛かったし、そのせいで高校時代は完全にグレちまって、小説をめちゃくちゃ読み始め(何故か夏目漱石が好きだった)、Medal of HonorCall of Duty(初代)等のFPSにのめり込み(思えば高校時代からFPSクランに入ってた)、アニメやギャルゲにまで手を出して完全に二次元にハマってしまい、現在の自分がある(完全に言い訳)

自分は18年もこの謎の症状と付き合ってきたので、もう最近はまともに発声できない可能性を分かった上で会話しているし、いざ「どもって」も「あーどもってるわー。まじつれーわ。まぁいいや。」ぐらいにしか思わない。今日もzoomで朝会やってて豪快に吃った気がするが、自分が伝えなければならないことはちゃんと伝えられたはずなので業務に問題はない。

とは言え、世の中の吃音持ちの人達の中にはかなり深刻に悩んでる人も結構いるらしく、「吃音」でググると「吃音対策サイト」みたいのが沢山出てくる。その中には「吃音でも就ける仕事リスト」みたいのもあって結構驚いた。吃音によって自分の仕事まで制限されてしまうケースもある、ということなのだろう。自分は幸い職業を制限される程ではない。そこまで喋りまくらなくても何とかなる仕事をしているから、という側面もあるかも知れない。

随分長々と書いてしまった。

自分も同じ経験があるだけについ自分のことを書きたくなってしまったのだが、この漫画自体は一巻完結で、気持ちのよい終わり方をする高校生の青春ストーリー的な構成になっていて、決して重々しい話ではない。重々しい気持ちになるのは自分のつらい経験と照らしあわせてしまうからかも知れない。

気分が落ち込む原因と対策

こういうのブログに書くのどうなんだろうなって思ったのですが、後から読み返した時に何らかの役に立つかも知れないし、別にさらしてもまぁ問題はないだろうということで書いてみます。

概要

  • ここ2ヶ月ぐらい(今年入ってから?)気分が非常に落ち込んで何もやる気がでない日が週に1日~2日ぐらいあってあらゆるモチベーションがなくなって困っている
  • よくよく考えると色々自分の生活に問題がありそうだったので改善するようにした
  • 油断すると簡単に再発しそうなので日頃から気をつけたい

気分が落ち込む原因と考えられる生活習慣と対策

1日中誰とも会話しない(改善済み)

  • 独身リモートワーク生活だからしょうがないとか言ってる場合じゃない
  • ハングアウトで必ず毎日誰かと話す。最近は幸いにも業務で毎日Mtgが入って沢山会話できるようになって楽しい
  • コンビニの店員とか郵便局の局員とかだれでもいいので無駄にフレンドリーに接してみるだけでも大分違う
  • リアルで人間と触れ合うのはすごく大事!人は1人では生きていけないのだ!

毎日同じ食事メニュー(改善済み)

  • 忙しいのと寒くて外に出るのが億劫になるとなりやすい
  • 朝・夜は仕方ないケースがあっても、昼はできるだけ毎日別のものを食べるように心がける
  • 昼食というイベントを用意して「毎日何がしかイベントがある」という状態を保つだけで日々に張りが出る
  • 前職でも忙しい時に毎日コンビニばかり行ってたら毎日同じような感じになって辛い気分になった記憶がある

1日中外に出ない(改善済み)

  • 忙しいのと寒くて外にでるのが(ry
  • コンビニでもなんでもいいから毎日外に出る
  • 時間がなければ近所を歩くだけでもする
  • とにかく外に出よう!

運動不足(WIP)

  • 川崎に住んでた頃はほぼ毎日ジョギングか散歩していたのを盛岡寒い&雪積もってる&仕事忙しいみたいな理由でサボってた
  • 実際雪積もっててあまり出歩きたくない気持ちが高い
  • 同僚に相談したら「ラジオ体操いいですよ」というので毎朝ラジオ体操始めたら非常に調子が良い

ぶっ続けで仕事してしまう(WIP)

  • つい仕事し過ぎて気が付くと23時とかよくあってそういう日が続くと段々疲れが溜まり続ける
  • 適当なところで休む、サボる。オフィスで働いていた時はおそらく1日30分は同僚と雑談していたが、それがなくなるとエンドレスで仕事しがち
  • 「早くやらなきゃ」という強迫観念を感じ始めたら「ちょっと待て、ホントに急ぐ必要あるのか?まったりやってもいいんじゃないか?他にやるべきことがあるんじゃないか?」と自問する

過去の失敗を振り返ってくよくよしない(WIP)

  • 「なんであんなことしたんだろう?」ってなるから

未来のことを考えて不安にならない(WIP)

  • 「大丈夫かな?アハ~ン」不安になるから
  • 今後どうやって生きようとか難しいことを考え過ぎない
  • 最近「自分はどういう風に死ねば満足なのだろうか」ということばかり考え過ぎて自分を追い詰めている

リードエンジニアを3ヶ月やって得た開発マネジメントに関する教訓

ここ3ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。

リードエンジニアのお仕事とは

会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。

開発スタート時

要件確認

  • 仕様書を読んで全体像やどこから着手するかなどを考える

Railsアプリのベース部分の実装

  • rails new
  • DB周りの設定
  • 初期モデルクラスをDB定義に基づいて作成
  • factoryも使いそうなものについてのみ作成
  • rspecrails_config等諸々の設定
  • ローカル環境動作用のseedsを整備
  • 使いたいGemを追加
  • 共通で使うCoffeeScriptのライブラリを思いつく限り実装
  • CoffeeScriptの実装方針が人によってブレるとイヤだったので早い段階でサンプルになるような実装を入れた

情報共有

  • 開発環境構築に必要な情報をgithubwikiやREADME.mdに記載
  • 連携する外部APIなどを事前に検証し、問題がある場合は関係者に確認して解決して対応方法をwikiに記載

開発中

コア機能の実装

  • ひと通りのControllerとviewを実装してひと通り画面が動くように。細かい調整は個別にissue立ててメンバーに割り振り
  • 要件がふわっとしててクライアントに確認が必要な機能や重たい機能の実装

issue量産

  • 各機能ごとに親issueを切り、それに紐づく子issueを作って管理した。

例: 「A機能」が親issueで「Aデータ登録」「Aデータ編集及び削除」「Aデータ一覧」「Aデータ詳細画面」「AデータValidation」が子issueといった具合

その時description内で #100みたいに親issueのIDを参照させておくと、親issueの一覧に子issueのリストが表示される格好になるので進捗管理に便利である。

  • タスクはなるべく親機能ごとに割り振ったがデッドロックになってしまう所もあってやりながら調整した。

他のメンバーのレビュー

  • Railsのレベルはバラバラだったので、Rails経験が浅いメンバーには「何故こうしないといけないのか?」と細かく説明するコメントをつけるよう心がけた
  • 要件自体があまりしっかり決まっていなかったので、かならずローカル環境で動作させて、動作自体に違和感がないかまで含めてチェックした
  • specが落ちていたらまずspecが通るように直してもらってからレビューした
  • Turbolinksの動作原理を理解していないメンバーが数人いたようなので参考資料を読んでもらうよう頼んだりもした

クライアントとのコミュニケーション

  • 要件で不明確な部分の質問
  • 工数的に厳しい場合の代替案の提案
  • 問い合わせ対応

インフラ作業

  • サーバに入れるのが自分だけだったので追加でimageMagickをインストールしないといけないとか、ステージング環境のログを見るとかは全部自分でやっていた

得た教訓

開発方針を統一できるように最初の段階でサンプルになるような完璧な画面を作ってしまうべき

specをどの程度の粒度で書くか、とかConcernに何を載せるか、といった「決め事」が統一出来ずに開発後半では画面によって大分差が出てしまった。

大体のメンバーは自分が実装した所を手本に進めてくれていたが、それも完璧ではなかったので(例えばValidationは後で実装する、とか書いてたらそれまで真似してvalidation処理抜けの画面が量産されて死ねた)、やはり最初に完璧な手本となる画面を実装してしまうべきだった。

特にRailsだと、この機能はControllerにベタ書きか、それともconcernに切り出すか、みたいな判断基準が人によってかなり差がある。

放っておくとfat controllerになったり機能が重複しまくってたりということがいとも簡単に起きて後で泣きを見る羽目になるので、なるべくそういう事故を防ぐためにも最初にサンプルとなる実装をリーダークラスの人間が実装してしまうべきだと考える。

issueを細かく切りすぎず、ある程度大きいまとまりでどばっと渡してしまうべき

これは完全に失敗だったなと思ったのだが、とある機能の画面で以下のようにissueを分けて、それぞれ別の担当者に振ったことがある

  • A入力画面の細々した修正
  • A入力確認画面の細々した修正
  • A入力プレビュー画面の細々した修正
  • A入力最終確認画面の細々した修正
  • A登録画面の細々した修正

そしたら本来共通で実装すべきユーティリティ系のクラスをそれぞれが別々に実装したり、前後の画面で辻褄が合わなくなって自分が全部調整する羽目になったりと、あとで整合性を取るのに凄く労力を要してしまった。

他にあまりタスクが無い時期だったのと、ベースとなる部分は全て自分が実装し終わっていたので大丈夫かと思っていたが、完全に判断ミスだった。

画面の前後でちょっとずつ実装スタイルが違うよりはA機能全体で統一性が取れていた方がレビューもラクだしコードの変な重複が発生する可能性も低い。

実際、開発後半はある程度デカい機能をまるっと投げて、PRのdescriptionでtaskをチェックボックス付きリストにしてもらってそれを一個ずつ消化してもらうスタイルに変えた。上記の例で言えば「A機能の登録・編集・削除全部」みたいな粒度である。そしたら開発効率も品質もかなり上がったように思う。

開発の進め方は最初にきちんとルール化しておくべき

PR駆動の開発の仕方が理解できていないメンバーがいたりして、まぁそんな初歩的なことを教えるのも失礼だし、慣れれば勝手に他の人に合わせてくれるだろと思ったら、数週間経っても全くPRも作らないしcommitも適当だしみたいなスタイルで開発を進め始めたメンバーがいた。

さすがに一人だけ足並みそろえていないのはまずいので、口酸っぱく「作業が終わったらPRを出してください」とか「commitはもっと細かく入れてください」とか「間違ったcommitが入っていないかチェックしてからPRを出してください」とか言い続けて改善してもらったのだが、これが普段の業務において意外なほど大変だった。

少しイライラもしていたのだが、見かねたマネージャーに「長年やってきた人のスタイルはそう簡単に変わりません」と窘められることもあった。確かにその通りだし、自分もたまたまPR駆動で開発するのに慣れているから出来ているだけということもあるだろう。

そんな訳で、今後は開発スタート時にその辺の教育コストを削減できるように、Githubの使い方やらPR駆動のスタイルなどをまとめたドキュメントを作っておいて、それを最初に参照してもらった上でスタートできるようにしようとしている。

具体的には以下のような感じでまとめていく予定である。

丁寧にレビューすれば人は育つ(と思った)ので時間かけてでも丁寧にレビューすべき

何度もレビューの指摘→修正のやり取りをしないといけないケースもあって、そういう時はさすがに「もうめんどいから俺で巻き取るか」といった感情が芽生えてきやすい。この案件もそういう時が何度もあった。

でも、それをやって自分一人で全部巻き取っていたら開発はスケールしないし、費用対効果も悪い。なのでなるべく「一度指摘したことは2回目以降はちゃんとやってもらいたい」と思い、レビュー時に指摘する時も

「これだとXXのケースで動かないので○○としてください」

だけで終わるのではなく、

「これだとXXのケースで動かないので○○としてください。なぜなら△△で□□でほげほげで。。」

みたいな感じで、なるべく理由もセットで指摘するようにした。

そうすれば似たような場面でも応用効かせてくれるかという期待を込めていたのだが、実際一ヶ月も一緒に開発していると段々と効果が現れたのか、同じ指摘は段々と2回しなくても勝手にちゃんとやってくれていたりというケースが増えてきた。

もちろん変わらない人もいたが、一部のメンバーはちゃんと一度指摘したことを守ってくれるようになったので、レビューする側としてはかなり楽になってきた。

ただ、これらの指摘事項は当然自分自身が実践するべきで、多少めんどくさいからと自分が手を抜いていたら「アイツ他人には厳しくて自分は甘えてんじゃん」ということで効果は半減していたように思う。そういうこともあって、なるべく他人に厳しくする分自分のコードにも厳しい目で実装してきたつもりだが、これは自分自身のトレーニングにもなって良かったと思う。

レビューばかりすると自分の担当分が進まない

PRでレビューを依頼されるとすぐに対応して次のタスクを振りたくなるものだが(少なくとも私は)、レビューばかりしていて本業が進まない、という典型的なパターンに自分もハマりかけた。

これに対する解決策としては以下の様なことで対応してきた

  1. すぐにレビューしなくてもやることがすぐ枯渇しないように常に大量にタスクを積んでおく
  2. 本当にすぐ見ないといけないレビューでなければ後に回す
  3. 自分の1日の作業時間においてレビューに割く時間と作業に割く時間を決めておき、それを守る

一番のリスクは「自分がレビューしないことでそのメンバーのタスクが進まない」というロック状態を作り出してしまうことだが、それを回避する方法としては1が意外と有効だった。

レビューする時間を短縮するというのは品質に関わるので避けた方がよく、どちらかと言えば期限を決めてタスクをどかどかと積んで「上から順番にやっていって~」という風に任せてしまった方がラクだと感じた。

この方法を行うリスクとしては、知らないうちに進捗が悪くなっているとか、間違った設計で実装を進めてしまっているということがあるが、なるべくはやくWIP PRを出してもらうことで大体解決していた。

若者と転職

このエントリーはしょぼちむ Advent Calendar 2014 の21日目の記事です。
前日は @fukai_yasu さんの記事でした(まだ未登録?)。その前は@setoazusaさんのしょぼちむにテストファーストについて説明してみるでした。

しょぼちむご本人とは東京で働いていた頃に3回ぐらいプライベートでお酒の席でご一緒させて頂いたぐらい?の関わりでしょうか。何となくjava一派ということで仲良くさせて頂いていました。

お酒の席ではしょぼちむ氏に「いつ辞めるの?」と転職を持ちかけるネタでいじるのが一部界隈では定番なようなので、「若者と転職」というタイトルで駄文を書かせて頂きます。
しょぼちむ氏の参考になれば幸いです。

概要

私は2014年12月現在で28歳になります。
23歳で社会人になったので社会人としては丸5年半やってきたことになりますが、この5年半で3回転職をしています。
平均すれば1つの会社に1年と10ヶ月弱しか勤めていません。
人によっては「だから今どきの若者は…」と眉をひそめられそうな数字ではありますが、それぞれの転職には私なりの考えがあってのことだったりするので、その辺の考えについて説明しつつ、自分の転職感について述べたいと思います。

自分のこれまで

私の社歴をざっくり説明すると以下のようになります。

  • 2009年4月〜2011年11月 某SIerでSE
  • 2011年12月〜2012年12月 某制作会社でエンジニア兼SEのような何でも屋
  • 2012年12月〜2014年6月 某自社サービス会社で自社サービスの開発エンジニア
  • 2014年7月〜 ハートレイルズwebサービス受託開発エンジニア

過去3回の転職の経緯についてはそれぞれ退職or入社エントリーを書いてるのでそちらを参照ください。

それぞれの会社で働いて得られたものをまとめてみると以下のようになります。

SIer

  • 社会人としての基礎スキル(特に電話の取り方からタクシーの乗り方までビジネスマナーについて細かく叩きこまれたのは後々役に立った)
  • IT全般の広く浅い知識
  • 分かりやすいドキュメントと分かりにくいドキュメントの違い
  • 伝統的な日本企業ってこういうものなのかという知見
  • SI業界の現状と課題
  • Oracleを触る貴重な経験

某製作会社

  • 社員5人の会社で働く経験
  • 「自分1人しかエンジニアがいない」という後がない状況での開発をしたことによる精神的な耐性
  • PHPで何でも作る経験(画面からバッチまで)
  • 謎設計の自社フレームワークに泣く経験
  • 前任者が書いたクソコードと戦う力
  • クソコードからドキュメントを起こして正しい仕様を整理しなおしてバグを直してリファクタリングする経験
  • レコメンドエンジンの知識(代理店販売してたので導入サポートをしていた)
  • Objective-Cを1ヶ月で勉強して初めて作って納品したiphoneアプリがいきなり有料アプリとして販売されるというロックな経験
  • 要件定義〜見積もり〜設計〜開発〜テスト〜納品までを全部一人でやるという全フェーズの経験
  • アメリカ人との英語でのメールコミュニケーション(代理店販売しているパッケージ仕様の問い合わせを英語でやってた)

某自社サービス会社

  • 「システムを作ること == お金になる」が成り立たない世界でのエンジニアの会社への貢献
  • 公開中のサービスを◯◯時間バグらせて放置すると☓☓万円の損害になるというお金の考え方
  • ざっくりとした仕様から自分で必要な機能を考えて作る経験
  • すさまじい無茶ぶりにどうにかこうにか頭を捻って形にしてリリースする経験
  • 営業、マーケティング、運用サポート、経理といったエンジニア以外の色んな職種の人の役割、コミュニケーションの取り方
  • 毎月中途採用社員が10人ずつ入ってくる急成長する企業で働くという経験
  • java
  • struts2
  • spring
  • SAStruts
  • dbflute
  • aws
  • fluentd
  • mongodb
  • solr
  • elasticsearch
  • kibana
  • チケット駆動開発の経験
  • gitでやらかした時にどうにかするスキル
  • コードレビューをする、されるという経験
  • 開発現場から離れた技術サポートの仕事の経験
  • 社内外向けの勉強会を会社のオフィス使って開催してアウトプットする経験
  • 40人が参加する開発合宿を企画運営する経験

3回転職をしてみて思ったこと

最初のSIerについては面白くなくて飛び出した感が強いのも正直な所なのですが、振り返ってみればこれまで務めてきた会社で学びがなかったものは一社もなく、それぞれの企業で自分が出来ることを増やした上で転職してきたのだなと今にして思います。

転職する目的というのは人によって沢山あると思いますが、何にせよ「プラス思考の目的」が無いと上手くいかないのではないかと思っています。

給料が安い、仕事が面白くない、人間関係が悪い、といったマイナス思考の目的だけで飛び出しても、また次の会社で同じトラブルがあった時に対処する術を身につけていないのでまた辞めるしかありません。 Team Geek にも書いてありますが、組織というのは組織の問題を解決してくれる人を求めている訳で、自分が課題だと感じたことにどうアプローチしてきたかという実績が無いと企業から見て魅力的な人材にはなれません。

それは本人にとっても会社にとっても不幸だと思うので、自分は必ずプラス思考の目的が無ければ転職はしませんでした。
プラス思考の目的があれば、直面した課題を上手く解決するモチベーションが湧くか、プラス要素で相殺して我慢できます。 (自分は我慢できないタイプなので大抵課題には口を出してしまうのですが…)

最初のSIerには2年半いて、最初の1年目にして「仕事が面白くない…つらい…」とずっとぼやいていましたが、自分がやりたいこと、目指したいことがはっきりするまで辞めませんでした。 それは前述したように、マイナス思考の目的だけで飛び出しても問題は解決しないし、なんかカッコ悪いと感じたからです。(なお、当時見つけた「やりたいこと」は自分でインフラの面倒もコードも書けるようになってwebサービスを作ることでした)

転職するという行為自体について考えれば、文字通り職場を変えることになるので基本的にリスクが大きいわけです。何度その会社の社員と面接をしても、その会社の空気や思想というのは入社して働いてみないと分かりません。

だから、自分が実現したいことがはっきりとしていて、その会社に転職すれば自分にとってプラスになる、と思えるのであれば積極的に転職すれば良いのではないでしょうか、というのが自分の考えです。

逆に、そういうのが見えなければ転職すべきではなく、するべきは自分が感じている課題を解決することだったり、自分のキャリアを考えることだと思います。

課題を解決するために

いくつか方法があるかと思いますが、自分にとって良かったと思えた方法が、他社の人にその人の会社の状況について聞いてみることです。 隣の芝は青いと言いますが、自分が抱えている問題が自分の組織だけの問題なのか、はたまた他も同じような課題があるのかという判断は社外の人と話さないと区別がつきません。

エンジニアの場合、大抵twitterFacebookやっているので、面識がない人でもコンタクトを取るのはさほど難しくありません。(実際、一度も会ったこと無いのにいきなりDM送って飲みに行って仲良くなったエンジニアが何人かいますw)勉強会の懇親会とかでも良いと思います。

あとは転職エージェントにコンタクトを取ってキャリアについて相談してみるのも良いと思います。自分も2回目の転職は転職エージェントに相談した上で紹介してもらっています。

対象は誰であれ、自分一人で抱えていても仕方がないのでなるべく普段接していない人との接触が重要かと思います。内輪だと大抵愚痴大会になってしまうのでw

自分のこれから

どんだけ年を取っても、自分が手を動かす、あるいは常に動かすことができるエンジニアとしてのスキルと知識を保ち、それらをコアにビジネスにコミットしていける人間でありたいと考えています。

今は自分が持っているスキルを「お客様の事業を行うためのwebサービスの受託開発」という形で発揮し、お客様の様々な事業に関わりながらwebサービスでどういう価値を社会に提供出来るのか、ということについて勉強している最中です。

とにかく案件の数をこなして、

  • それを自分がどれくらいのスピードとクオリティで開発できるのか
  • どう開発したら上手くプロジェクトが回せるのか
  • チームの生産性を上げるにはどうすればいいのか
  • どうやってメンバーのスキルを上げていくのか

ということについての方法を学びたいと考えています。

自分が目指すポジション

ここ5年以内に目指すキャリアパスとしてはエンジニアのマネージャーとしてのポジションを目指しています。プロダクト開発をリードする立場というよりは、チーム内のメンバーのマネジメントをするポジション、のようなイメージです(伊藤直也さん的な?)

ビジネスより技術が好き!でスタートしたこのキャリアですが、結局ソフトウェアは人が開発するものであって、どんな開発現場でも人の問題が絡んできます。社員のほとんどがエンジニアという現職でも人の問題は起きるし、これまでの経験においても人の問題でプロジェクトが上手くいかなかったりしました。

そういう時に、エンジニア間で起きる問題を上手く解決し、適切にリスクを考慮して意思決定をしてくれた人が前職には数名いたのですが、彼らのような振る舞いはどんな開発チームにいっても必要になる振る舞いで、またそれが出来る人が非常に少ないと感じています。 大体エンジニアは自分含めて変な人が多いですし、そういう人の気持ちを理解できる立場でありつつ、上手くまとめて開発をワークさせる仕事はビジネス的に価値があると感じているし、何よりそういう人に自分が憧れました。

そういうポジションで働くことが出来るのが今の会社なのか、はたまた別の会社になるのか分かりませんが、その時はその時で自分にとって最善の選択をしたいと思います。

自分がなりたい自分になるために

これまでの自分の転職の目的は、どれも「自分がチャレンジしたいことをするため」という感じでしたが、それが実現できたのも自分がそれぞれの企業でスキルを磨いてきたからだと思っています。 なんだかんだでエンジニアはスキルが重要なので、やりたいことをやろうと思ったら常に自分を成長させ続ける必要があると考えています。

@kwappa さんの「The Art of Job Hopping」というスライドにも以下のように書かれています。

I'm happy because I could escape
I could escape because trained day by day

日々努力を怠らず、これからも一人のエンジニアとして自分を鍛錬し続けたいと思います。