今年、勤めている会社で初めて自分が携わったサービスをローンチしました。
そのサービスを実装する過程で学んだ心構えをまとめます。
これから初めてプロダクトを作る人に、なんらか足しになることが言えていれば嬉しいです。
まずはとにかく目の前の仕事をこなす
本当の本当に初めはとにかく自分が持つ手段が使い物になることを目指した方がよいと思います。
どの職業でも通じることだとは思いますが、特にエンジニアという職業は前提知識が多く求められる職業です。
その前提知識が足りないうちは本当に使いものになりません。
社会人なり立ての時ってあれもこれも手を出したいと目移りしがちだと思うんですが、初めの1，2年はとにかく目の前の仕事に集中して、そもそもの価値を出せるような実力を身に着けることを優先した方がいいのではと思っています。
とにかく動くものを作る
初めて業務でソフトウェアを設計する際、1，2回作り直すくらいの気持ちで、まずはとにかく動くものを作るのが大切だと思っています。
私は初め、"設計"と言われても何をしたらよいのか、何をすれば設計の目的を果たしたと言えるのか、それがちんぷんかんぷんでした。
個人的にこのエンジニアリングという業界は"正しいやり方"で行うことへのプレッシャーが強い業界だなと感じており、
プロジェクト開始当初の私は特にそのプレッシャーを無駄に感じてしまい、勉強にすごい時間を投じてしまいました。
強い目的もなくUMLの図を量産して(結局ほとんど使いませんでした)、前には全く進まない時期を過ごしました。
勉強すること自体は悪くないんですが、結局のところ実際に作ってみないと「設計の勘所は分からない」と言うのが自分なりの結論です。
ものすごい頭のいい人はそうでもないんでしょうが、私は座学で学んでも骨身にしみた知識となることは非常に稀です。
大学で学んだコンピューターサイエンスの知識も9割がた忘れています。
昔読んだ本を読み返して「ああ、こういうことだったのか…！」みたいに経験を積んだことによって、より深く理解できるようになった、という経験がありませんか？
それと同じでアプリケーションの設計を上達するためには、雑でもいいから設計してみて、
実際にちょっと実装してみて、それで早く失敗して学ぶことが大切なんだと思います。
ので停滞してしまったら、まずはとにかく動くものを作る、それからよりよい設計で作るという考えで行けばよいと思います。
(時間が無い時は汚い設計でもプロダクションに持っていかざるを得ないですが…)
自分が使うものを理解する
自分が使う言語なりライブラリ、フレームワークなりがどう動いているのかはある程度知っておかないと、
思わぬバグを踏んだり、そもそも実装でベストな手段を取れないことがあるので、回り道に感じても勉強が大事です。
"ある程度"というのがどの程度がベストかは模索中なのですが、とりあえず関連するドキュメントの
主要なところ(細かい関数の詳細などを除く)全部読むくらいやってもいいんじゃないかと思っています。
エンジニアなり立ての時は自分が使う部分だけをサラッと確認して、ブラックボックス的に使いがちだったんですが、
それでバグを仕込んでしまったりして、結局最初にちょっと勉強しておけば防げたものだった、という経験がたくさんありました。
エンジニアたるもの急がば回れで堅実に勉強するのを心掛けるべきだと考えています。
(時間が無い時はry…)
最初はシンプルな構成にする
フロントエンド以外の領域であんまり問題になるのか分からないんですが、
最初はあまりあれもこれもとライブラリを継ぎ足さないで、必要最小限の構成で行くのがいいと思います。
なぜなら、「とにかく動くものを作る」の項と若干言っていることが被るんですが、
そのライブラリが本当に必要なものなのか今いち分からないからです。
例えばなんですが、私はReactを用いて開発をしているんですが、Reduxないしステートマシンのライブラリを使っていません。
これ他社さんのエンジニアに言うと結構驚かれるんですが、一個一番上の親のコンポーネントに状態を寄せ集めています。
何故利用しなかったかと言うと必要に感じなかったからです。
本当に必要がないという訳ではなく、単純に私の知識・経験不足から、「なぜ必要なのか」が理解できませんでした。
実際今は利便性を理解できるようになったのでReduxの導入を検討しています。
これに対して後悔しているかと言うとそうではなく、むしろ利便性を全く理解できてないまま使ったら、
おかしな作りで実装していまっていただろうなと思います。
時間がある時は勉強も兼ねて、とりあえず試してみるというのもアリだとは思いますが、
最初は詰め込み過ぎず、最小の構成で進んで必要性を感じたら足す、くらいでよいと思います。
チームメイトにリスペクトを持つ
大分エモい話になりますが、チームメイトに対してリスペクトを持つことは
チームとしてソフトウェアを作っていく上で非常に大事です。
アプリケーションというのは多くの場合一人でなく複数人で作ります。
となると自分の領域と他の人の領域のインターフェイスを折衝する必要があります。
インターフェイスというのは、プログラミング上のインターフェイスも含みますが、
もっとゆるっとした要件定義と実装みたいな区切りもここでは含めます。
私個人の話で言うと、私は実装の担当者で、要件定義をする人がチーム内に別にいました。
お互い心に余裕がある時は「ここは実装まで進めないと読み切れない要件だったんだろうな」と
よしなに折衝できるんですが、切羽詰まっている時だと「要件決めるのがてめえの仕事だろ！」(実際にはそんなこと言いませんが気持ち的な意味で)
と謎に切れ気味になることが何回かありました。
当然なんですが、そんなコミュニケーションを取っていても仕事は前に進みません。
人と人が協同して仕事するんだから、お互い足りない部分は出てきます。
それを補完しようとする姿勢を持つことが、とにもかくにも大事なんだと思います。
相手にリスペクトを持って自分が思っていることを伝えれば、よっぽど相手の性格が悪くない限り、
物事は前に進みます。切羽詰まっている時でも常にリスペクトは持つようにしましょう。
ゴールを具体的に定義する
チームに対してできてないものを「できた」、と嘘をついたことはありますか？
私はありません。(ありませんよ)
ありませんが、割とちょくちょくやらかしてしまっているのが、「これここまでやったしもう終わりでいいっしょ！」
と途中でゴールをすり替えて終わったことにしてしまうことです。
ゴールを変えること自体は場合によっては悪くないんですが、上述のような場合は大抵
「めんどくさい詳細は後回しにしたい。後で帳尻合わせよう。」という感じです。
それでうまくいくことも正直な話割とあるんですが、しっぺ返しを食らうことも多々あります。
どうせやらなければいけないことは、然るべき時にきっちりやった方がリスクヘッジにもなるし、いいことになる場合が多いです。
なので今自分がやっていることのゴール・終了条件はなんなのか、を具体的に定義して仕事に取り掛かるのが大事だと思います。
ただ、進めていく中で、元々想定していたものが不要だった、このフェーズではやる必要のないことだった、
などが見えてくることがあると思うので、その場合は適宜調整しましょう。
結果でなく成果にフォーカスする
割とエンジニアあるあるなのではと思っているんですが、たくさん実装していると、たくさん何かを成し遂げた気分になってくるんですよね。
ですが、それはただの結果に過ぎず、ビジネスとしてソフトウェアを作っている場合、実際にそのソフトウェアがユーザに価値を提供していない場合、成果を出しているとは言えません。
特によく考えがちなのが、「リファクタリングしたい～」とか「新しい技術使ってみたい～」などです。
もちろんエンジニアとしてそういう欲求を持つことは健全と言うかむしろサイコーではあるんですが、
それを今やることによってユーザに対しての価値を高めることができるのかという視点は忘れてはいけないと思います。
とは言え、そういった中長期的なことは先延ばしにされがちなので、放っておくと
気づいたら「組織が全く成長していない、むしろ負債めっちゃ溜まってる」という事態に陥りかねないので、
事業の状況を鑑みて、いつやるかを決める必要があります。
短期的にもそうですが、中長期的にユーザへの価値を最大化するにはといった、成果にフォーカスする姿勢を持てば
あまり考えていなかった時と比べて、やることも大分変ってくるのではと考えています。
関連？書籍
最後に、この記事のような自己啓発的な内容の本でオススメのものを紹介します。