midori

こんにちは、iOSエンジニアの広瀬、武藤です。
11月28日に弊社で運営している『はたらいく』のiOSアプリがリニューアルされました!
私たちがディレクターからエンジニアに転向して手掛けた初の案件でもあります。今回は、新米エンジニアの奮闘記をお届けします。

プロジェクトの概要

広瀬: 「これまでObjective-Cで書かれていた『はたらいく』のiOSアプリをSwiftに変えよう」というプロジェクトが6月中旬にスタートしました。
当初は、私と新人エンジニア2人、サーバーサイドエンジニア1人の合計4人のメンバーでチームを作り、今までObjective-CのアプリをエンハンスしていたiOSエンジニアから引き継ぎながら学習していく方針で、2ヶ月ほどかけてSwiftに入れ替えていく予定でした。
その後にメンバーの入れ替えがあり、武藤くんとサーバーサイドエンジニア1人が追加されて、7月くらいに現在のメンバー全員が揃い、ようやくプロジェクトを進めることになりました。
でも私たちはサービス開発のプランナー・ディレクターから転向したばかりで、仕事としてのプログラミング経験がなく、本当に一からの作業でした。

武藤: 僕は入社してからずっと『タウンワーク』のWebディレクターとして働いていたので、そもそもアプリのことは全然わかりませんでした。Xcodeも触ったことなかったですし、どうやって動くのかさえもわからないところからスタートしました。(笑)

なぜエンジニアに転向したのか?

武藤: 開発に対する知識や経験不足が仕事を進める上でのボトルネックになっていることを実感したからです。
入社2年目で携わったプロジェクトで、私はチームの中で意思決定をする立場だったのですが、打ち合わせの中で飛び交う専門用語だらけの会話に全くついていけず、チーム内のベテランエンジニアに頼りきってしまう、といったことがありました。もちろん要所要所でわからないことは聞いてキャッチアップしていましたが、結局、「自分で開発を行わないと本質的な部分はわからないのではないか」と考え、エンジニアのグループに異動しました。 異動後、初めての開発案件がこちらのプロジェクトでした。
その前にはグループ内の先輩エンジニア主導のもと、Rubyを用いてプログラミングの基礎教育を受けていました。そのため、「ソースコードを読めばなんとなく何が書かれているかはわかる」という状態だったのですが、Objective-CとRubyは書き方がまったくと言っていいほど違うので、書かれているソースコードを読み解くのにかなり苦労しました。

広瀬: しかも、「はたらいく」アプリは仕様書などのドキュメントはなかったため、「Objective-Cのコードを解読しながら仕様を理解していく」という作業には非常に時間がかかりましたね。

武藤: 僕の場合は同じタイミングで加わった先輩エンジニアとペアを組んで開発をしていたので、経験のある人と一緒に進めることによって段々と理解が追いつくようになっていきました。

広瀬: 私の場合はひとりでやっていたので、コードレビューのときに指摘事項をたくさんもらう感じでした(笑)。その際によく出た質問は「どういう意図でこう書いたの?」ですね。チームメンバーの師匠役の方々は、基本的に私達に考える機会を与えてくれるので、育成という観点でも敢えてそのように質問してくれました。
でも、メソッドや変数の命名から構文の書き方まで質問されるという経験が今までなかったので、説明できない自分にストレスが溜まることがありました。
でも、クラスやメソッド、変数の命名から構文の書き方まで質問されるという経験が今までなく、説明できない自分にストレスが溜まることが日々続きました。当時は「Gitってどう使うの?」「クロージャ?」というレベルでしたので調べながら進めていても作業中に詰まってしまうことが結構あったのですが、そういうときは周りのメンバーに聞いて学習していましたね。

広瀬: ハプニングとしては、ちょうどこのプロジェクトが始まった時期が、会社がリモートワークを推進する時期と重なったことです。場所が離れてしまうと開発経験のない人は簡単に聞くこともできなくなってしまうため、コミュニケーションを取るのが難しくなります。そのため、できるだけ近い距離にいたほうがいい、ということで、ひとりのメンバーの家に集まってみんなで作業をしていました。
Amazonでダンボールを取り寄せて、手作りの机を5、6人で囲みながら開発する光景はまるで合宿みたいな感じで楽しかったですね。コードレビューは、TVをモニター代わりにして皆で見て指摘するというスタイルでした。

武藤: そうですね。あとは、「自分だけが理解できるコードではなく、他人が読んでも理解できるコードを書け。コードは作文と一緒。」ということを先輩エンジニアから口を酸っぱくして言われていましたね。おかげでメソッド名、変数名一つとっても、この名前で読み手は理解できるか、ということを意識的に考えるようになりました。

captya

プランナー・ディレクターからエンジニアに転向したからこそできること

武藤: 数字を意識しながら開発できるというのは一つ強みだと思います。ディレクター時代は、定性と定量の両面から課題を分析して検証していくことをメインに行っていたので、課題抽出の為、あるいは検証結果の振り返りのために、数字を見る機会が多くありました。経験があったからこそ、今でも数字に対する意識は強いですし、ディレクターの提示した数値だけではなく、開発側から「もっとこうしたほうが良い」という提案ができたら、もっと議論が活発になると思うんです。ゆくゆくは課題抽出→企画→実装→リリース後の分析まで一気通貫で行えるようになれたら理想だな、とは思います。

広瀬: 今回はプロダクトの方向性に言及するまでには至っていませんが、ディレクターから開発に転向した私たちは、仕様に関して意見を言うことが多かったと思います。
私はもともと新規サービスを立ち上げたり、ユーザーテストやインタビューをくるくる廻して機能要件をブラッシュアップさせていく経験があったので、「どうしてその仕様やデザインになったのか」という背景にきちんと納得したい質なんです。
その結果、他のチームに比べて、ディレクターが考えた仕様に対しての議論が活発にできたという印象があります。それは今回担当してくれたディレクターも好印象だったようですね。
もう少しエンハンスしていったら、方向性にまで踏み込んで議論できるようになるのではないかな、と思います。ただ、思った以上に技術の壁が数多くありますし、また大きく立ちはだかってきたりもします。

武藤: そうですね。最低限のことはわかるようにはなりましたが、コミュニケーションの壁はまだまだあります。今振り返ってみると、以前はそれすらも知らなかった中でディレクションしていたんだな、ということを実感しています。開発のことを少し知ったら余計にその壁の高さに気づきました。

広瀬: 技術も含め、今までは知らなかったから気づかなかったのですね。考えなければいけないことが予想より遥かに多くありました。エンジニアに転向せずにそのまま続けていたとしたら、開発ディレクターと名乗りながらもそれに気づかずにいたと思います。

武藤: それに気づけたことは良かったです。今後はAWS/GCPといったクラウドに関してももっと深く学んでいきたいですし、アプリだけに留まらず、Webの開発もやりたいな、と思っています。

広瀬: 技術はすべてつながっているから終わりがないですね。今回はiOSのフロント部分だけだったので、次はAPIもやってみたいです。欲を言えばAndroidも(笑)

広瀬: 今は自分の手を動かしながら開発をしているので、エンジニアの方とのコミュニケーションという面においては、半歩進めたという実感があります。しかし、実際この半年間は先輩エンジニアにレールを敷いてもらうことで開発ができていました。自分自身の開発スピードやインプットの遅さを目のあたりにして何度も心が折れましたが、周囲のメンバーの足手まといにならないように、また、本質的な議論に絡めるように自分から掴みにいく努力をもっとしていきたいです。半歩ではなく大きな一歩にできるように。

武藤: ディレクターやプランナーが分析のために自分でSQLを叩いたり、エンジニア・デザイナーの垣根なく最低限の素養として開発の知見を持ったり、と、自分の職種の中でうまく使えることができると良いなと思います。
とはいえ、まだまだ理想には全然近づけていないですけどね。これからもがんばりたいと思います。