エンジニアって一人では生きていけないよね

どうも、NEEDCREARTEのエンジニア、中村です。実は最近MacBook Proを購入しまして、自由な体勢で仕事してます。

弊社はフルリモートなのでいつどこでどのように仕事をするかを問いません。私はつい先週、広島東洋カープの試合を観戦しに行きました。ちょっと仕事が詰まっていたこと + 大雨災害で電車が復旧していなかったので、バスの長旅中仕事をしていました。
球場に着いてからも、試合まで結構な時間があったのとキリが悪かったのでPCを開いて仕事を少ししました。(あまりにも人目が痛くて20分とせず止めました笑)

さてこの日、私の稼働時間は少なかったんですけど、いつもより効率よく仕事できていた気がします。私がリモートワークを初めてやっと5ヶ月が過ぎようとしています。
誰の監視もない中、課題は色々ありますが中でも「効率よく働けているか」です。せっかくのリモートワークなので、家事や仕事、プライベートなどもっともっと有効活用したいものですよね。

もともとインドア過激派だったからこそリモートワークという選択肢を選びました。しかし、外出した時の方が効率が良かったと感じたのはなぜか。自分なりに考えてみました。

  • 人目があるから、エラー画面を出さないように緊張感を持っていた
  • 試合が始まったら仕事はしない。タイムリミットが目前にあったのでいつもよりスピーディな思考ができていた
  • 仕事できるアピールを不特定多数の人にできてちょっとモチベーションが上がった

いやいや、当然じゃないか! 普段からそれくらい緊張感持って仕事しなさいよ!私。

そもそも上記を慮ると、もしかして私ってリモートワーク向いてない? ...いやいやそんなバカな、そもそも作業時間は普通の会社員時代から大幅に減り、コミット量は明らかに増えたので、効率自体は絶対上がっているはずです。

あれ、もしかして、私、孤独なのかな?孤独を感じているのかな? 人がいると安心するのかな。でも弊社のSlackは賑やかだし、ビデオ通話は1日1回以上しているし...ではなんだろう?

ソロでの開発はよくない?

もしかして、と思い当たることはあります。弊社はバックエンドエンジニアがまだ私一人です。どちらの書き方がいいか悩んだ時も、ちょっと良いソースかけた時も、詰まってしまった時も、自分の力一つで解決しなければいけません。そうなってくると、「動けばOK」の理論がとても甘い蜜の様に感じるのです。

動けばOKの何がダメかというと、保守性が悪い場合が多々あります。そうなってくると、条件網羅などのテストも大変になってバグFIXの回数が上がり、余計に時間を食います・・百害あって一利なし。

過去に私が働いた会社でもソロ開発の案件では、ソースは(悪い意味で)激しく自由でしたし、自分でもそういうソースを量産していました。それが今回再発しかかっているな、と感じています。具体的には以下みたいな感じです。

  • コーディング規約に揺らぎがある
  • 変数や関数の命名にセンスがない(check_**多用など)
  • アルゴリズムに妥協を感じる
  • デザインパターンを軽視

多少話は盛っていますが、こういったことが横行してしまうんです! 開発ってほんと気の遣い様だと思うのですが、最近の自分は「ん?」という箇所が少しずつ増えているんです。

もちろん、世の中にはスーパーエンジニア様が多々いると思います。そんな方々はおそらく美しい旋律の様なソースを瞬時に生成されると思います。しかしながら、私はいつもメンバーと相談や雑談を織り交ぜて開発してきていたので、メンバーのやりやすい環境を整えたいという気遣いがソースの可読性UPにも繋がっていたのかもしれません。

もともと、継承元のコントローラやモデルなど土台の部分を開発するリードエンジニア的な仕事をしていた開発メンバーだったのですが、それは他のメンバーが楽に開発できる様に、という気遣いからでした。誰に言われるでもなく、こういうのあったほうが楽でしょ?という半ば押し売りの様に実装していました。

メンバー全員がこの様に気遣いするチームは、本当に心地の良いもので、コミットをみているとワクワクとしたものです。(もちろん、そうではないメンバーもいますが、大多数が占めていれば、自然とこちら側に引き込まれ始めるのです)

「気遣いは、チームを救う」 チームを救うことはそのままプロジェクトの成功につながりやすくなります。少なくとも、開発の面に関しては。

ソロ開発の場合、気を遣う必要が薄いのでついつい、可読性や保守性が妥協されてしまうのも至極普通な流れなのかもしれない様に感じます。

ただそれって、ソフトウェア品質に大いに関わってきますよね?

可読性の低いコード、どうやって予防するか

単純に、開発メンバーを増やすのが一番いいのだと思います。互いのソースをコードレビューし合う。時にはペアプロ・モブプロしてしまうのも最高だと思います。相手のいい所は吸収し、悪いところは指摘し合う。もちろん、相談しながら。いいじゃないですか。しかし、メンバーが増やせない場合はどうするのか。

1つ考えたのはソース公開。Githubやなんかでソースを公開しちゃう。簡単に恥ずかしいものはアップできなくなるので、軽い予防策になると思います。
って、待ってください! 仕事で書いたソースなんで、公開はまずいですよ!

...となると、一部ソースをTipsとしてブログやQiitaなどで公開ですかね。誰かに見せる、という緊張感は得られて、残念なソースの常習化は避けられそうですね?
でもそれって、システム全体としてのチェックはできないですね。

じゃあどうする? どうすればいいのか。
誰かに見てもらいたいけど、見せる人いない! 誰か、見て! 私(のソース)を見て!!

「はい、見ます」
最終的に私が考えたのはプルリクエストを自分宛に自分で発行しちゃう。
ただし、プルリクの確認は開発後1週間、最低でも2、3日ほど置きたいものですね。1週間前の自分のソースについては思い出は残っても記憶はないです。
ここで言う思い出は「ああ、なんかこの実装辛かったよな」「そういえばなんかイケてることしたよな」というもので、
記憶は「このソースはここに書いて、ifがこうなっていたよね」「メソッドここで切ったっけ」とかってものです。

昔いた会社に、自身の整備したインフラやプログラムソースは全て思い出せるウルトラエンジニア様がいたんですが、一体どう言う思考回路なんでしょうね。嘘じゃないです、ガチです。ほんと、一言ですごいと思います。ただ、その人にはこの方法適さないですね。

なぜこの方法なのかと言うと、プルリクエストを通せば、必ずチェックが入ります。自分宛てでも、1週間後の自分は他人です。それってつまり、気を遣わざるを得ない環境づくりになる気がしますね。
もちろん、納期との折り合いが大事になりますし、そもそも他の機能実装と被らずにできるのかと言うところでは疑問も残りますが、現状これしか思い浮かびません(汗)

(もちろん、自分で自分を確認する上でも、他人をチェックする上でもプルリクのチェック手引書みたいなのはしっかり作らないといけません)

さて、こんな私の悩みを解決してくださる仲間となるエンジニアを募集しています。
私(のソース)を見てくださると言う方、お気軽にご連絡ください!

株式会社NEEDCREATE's job postings
4 Likes
4 Likes

Weekly ranking

Show other rankings