辞める際に、当時お世話になっていた先輩から「理想と粘りを持って、挑戦し続けたやつだけが成功する」という言葉をいただきました。思い出して、やってやろう!と勇気をもらっています。業務委託の方がメインとなり、プロダクトがリリースされていました。組織に在籍しているエンジニアは存在せず、代表とデザイナーとCSの3人。4人目のメンバー、そして組織に常駐する1人目のエンジニアとして、入社しました。わたしの入社と同時に、業務委託でお手伝いいただいていたエンジニアの方は、契約終了となっており、入社時点でエンジニアはわたしだけでした。設定を見直すでしたwwエンジニアが1人もいない組織でしたので、ハードだろうがソフトだろうがお構いなしで、「技術」でくくることができるものは全てわたしのタスクだったと思います。ルーターも初めてだったので、説明書を見ながら本当に合ってるのか不安になりつつ、設定していたのが懐かしいです。当時のわたしは、リーンスタートアップや起業の科学を読んで、スタートアップでのエンジニアをイメージしていたこともあり、そのギャップに相当ストレスを感じていたと思いますwww「んなこと、おれもわからんわ!!」と叫びたくなることもありましたがwなんとか受け入れ(受け入れきれずに漏れ出していた可能性もあります。ルーター」とかでググってましたww開発したいからスタートアップに入社したのか?キラキラした気持ちでスタートアップに入ってすぐ、なんとも冴えない日々を過ごしていたわけですが...少しずつ自分の中で整理がついてきました。入社したのか?という問いが心の整理ができるきっかけだったように思います。自分の中で会社に対してできる価値貢献の幅を狭めていたように思います。開発は大好きなので、四六時中アプリを作っていたいですし、エンジニア同士で技術の話に花を咲かすことができるランチ等は最高だと思っています。「世界から国境をなくす」というビジョンを達成したい魅力ある開発(プロダクト)チームを1から創りたいプロダクトで世界を変えたいであり、Webアプリケーションの開発がしたいからではありませんでした。目的が明確になることで、創意工夫もできるようになってきました。なると自然と楽しくもなってきます。(もちろん、苦痛なことだって当たり前のようにあります。「バリューストリーム(価値の流れ)」と「価値の最大化」です。上記を意識することで、エンジニアという職種と、バリューストリームの一つの工程にしか過ぎない『開発』を同一視して見ていたこと自体が間違いだなと思うようになりました。バリューストリーム(価値の流れ)(図は、クライアントに価値を提供する上で、『開発』が一つの工程にしか過ぎないということをご理解いただくために作成しました。プリンターの設定では当時人数が4人しかいない中で、「IPアドレス」といった言葉に一番抵抗なく、そして毎日のようにググりまくっているエンジニアであるわたしが担当することが、適任だなwと感じるようになりました。世の中(クライアント)に対して、よりスムーズに価値を届けるために自分のリソースをどう使うべきか。その価値を最大化するには...と考える癖を身につけられるようになってきた気がします。スタートアップだからこそ、価値提供のためのあらゆる工程を効率的に行うべきですし、エンジニアとしては、そうしたあらゆるオペレーションをハックする必要があります。メンバーが価値創造に集中できる環境を作ることも、エンジニアとしての大きな価値貢献だとわたしは思っています。現地点で社員9名と着実に人数が増えています。開発陣も、わたしが1人で開発を行っていたところから、4人まで増えました。エンジニア採用に関しては、プロダクト開発と並行してわたしがメインとなり進めています。求職者の方のやりたいこと・求めていることを具体的に聞くことで、ミスマッチを一番なくすことができると思っているからです。(その代わり、他の開発メンバーには、開発面で負担をかけてしまっているかもしれません。いいように言えば、なるべく開発へ集中してくださっています。いつも感謝しております。)わたし1人であった開発から、人数が徐々に増え、チーム開発へと変化していきました。1人で開発していたときに比べ、複数人の開発では、すり合わせを行うことが非常に重要だなと感じています。大切なのは、開発チームが大切にしている価値観・思想のすり合わせだと思っています。今年に入り、開発チーム4人で、そうした価値観・思想のすり合わせを行ったので一部抜粋で共有いたします。組織やミッションにプライドを持つ(仕組みを作る)といった具合です。しては、こうした価値観を大切にしていますよと足並みを揃えることが非常に大切ですし、こうして明文化することで日々の行動の指針にもなると思っています。開発チームだけで、弊社のプロダクトと密に関わりがある入国管理局に見学へ行ってみるという企画を立ち上げ、実際に行ったりもしました。自分たちがどんなユーザーにどういった価値を届けようとしているのかは、チーム全員に知っておいてもらいたいし、こうした取り組みやそこから得た経験が、組織やミッションにプライドを持てる一部になると考えています。一機能を実装するという単位であれば、エンジニア1人が黙々と開発するほうが早くリリースまで持っていけると思います。圧倒的にデカいビジョンがあり、本気でそれを達成しようと思ったときに、足並みが揃ったチームがいることよりも頼りになることはありません。実際、現在リリースしているβ版のプロダクトからほぼ刷新する形でプロダクトを作り直しているのですが、わたし1人では絶対に成し遂げることはできないと思っています。1人で開発をするよりも、チームで開発をすることで視座が引き上げられますし、自分のアウトプットの質があがっていると実感しています。チームで開発を行うことで、より遠くへ(高みへ)いけると信じています。この1年では、1人で開発を行っていた経験があるからこそ、特にそういったチームの存在のありがたみをひしひしと感じることができました。スタートアップでエンジニアに求められるスキル上記のように、この1年でエンジニアとして、どのように価値貢献をすべきかチームで闘っていく大切さを学んできました。サーバ移行と、フロント〜インフラまで多岐に渡っているのですが、中でも必要だなと感じているスキルが2つあります。それは、プログラミングの基礎アンラーンできる勇気です。「プログラミングの基礎」というとざっくりしているかもしれませんが、やはり、基礎力は高ければ高いほうがいいと思います。その時折で、求められる技術は変わります。すごい早さで...この3ヶ月をみても、フロント〜インフラと幅広く担当をしており、必要なときに必要なものを学ぶことも求められます。なんだってことでは困るわけです。精通している必要はないかもしれませんが、(わたしも精通できていません。)ある程度、オブジェクト指向ってなんだとか、IPってなんだとか、コンポーネントってなんだみたいな部分は、理解しておくほうが良いと思います。その上で、実際に利用する技術が変わってもなんとかなります。今回の意図としては、「自分がやったことがあるやり方・うまくいっているやり方に固執しない」というのがより近いかなと思います。これは技術だけにとどまる話ではないのですが、1人でやっていたときに上手く行っていた方法が、2人チームになったときに上手く行くとは限らないですし、2人チームで上手く行っていたことが、4人チームで上手く行くとも限りません。状況が刻々と変わる中で、上手く行って「いた」方法に固執せずに、その時の新しい解を出し続けることが求められると思います。思い切って判断できるスキルがあると非常に良いのではないかと考えています。まとめ長々と書いてきましたが、最後まで読んでくださり、誠にありがとうございます。偉そうに述べてまいりましたが、所詮まだ1年しか経っておらず、なにも成し遂げられていないというのが現状です。結局今回が初めてのブログになってしまいました。これを機に定期的に更新できるように頑張ろう。最後に告知ですが、、スタートアップで、エンジニアとして働くことに興味を持っていただける方がいましたら絶賛募集中ですがので、お声がけいただけますと幸甚です。(こちらフロントの求人ですが、フロント以外も絶賛募集中なので、ぜひ。生成する基盤を作成したチームの開発速度をあげるSPAで利用するAPI設計を考える...月別アーカイブはてなブログをはじめよう!tobb422さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。