プロジェクトが凍結された話
要約
- これは技術記事でない。
- 前に取り組んでいたプロジェクトが凍結された。
- 新しくTwitterクライアントを作り始めた。
目次
始めに
プロジェクトに大きな変化があった。というのも、バックエンド担当の相方がプロジェクトグループを脱退した。当記事ではその事情等は説明を省くが、それによって筆者がどういう思考をして、どのような結論を出したのか、について説明する。
では以下からがこの記事の本文だ。
経緯
事前状況
バックエンド担当は、以前から定期的に数週間から一か月ほどの休みを不定期に取っていた。かつその頻度や長さが次第に長くなっていったので、いつかこのプロジェクトはバックエンドの担当のリタイアを迎えるだろう、と筆者は薄々勘づいていた。ただ、だからといってフロントエンド制作の手を抜くことはしない。筆者は制作自体のノウハウ目的でプロジェクトを進めていたからだ。しかし純粋にプロジェクトを進行させるというよりかは、リファクタリングやUtilの外部ライブラリへの移行等、直接フロントエンド制作には関わらない裏方に近く、また他プロジェクトでも応用が効くような作業を率先して行っていた。
リタイア報告
これは直接バックエンド担当から連絡が来て、そういった旨を伝えられた。筆者はそれをその場で承諾した。筆者自身に思うところが無かったかと問われると、正直なところ無いとは言い切れなかったし、バックエンドはもう八割方完成していたからには、簡単な修正だけでもやってくれないかと言いたくなった。しかしそれを伝えたところで、彼は実行できなかったろう。実行できないからこそ、直接筆者に謝罪と中途退陣を申し出たのだ。むしろ無言で連絡を取れないような形にして逃げることも可能であったのに、勇気を持って自ら言い出してくれたことを賞賛すべきなのである。そういった考えの下、筆者は特段抗議せずに話を収めた。
なお、それからは主に筆者が確認したいことをいくつか尋ねて会話は終わった。そのうちの一点は、筆者が個人で残ってプロジェクトを進めてもよいか、ということ。これについては快諾を貰った。これが次の項に関わってくる。またこぼれ話ではあるが、その脱退に伴って、彼が運営しているプログラミンググループの管理人役職を筆者が引き継いだ。
発生する問題
この問題はかなり致命的であった。
サーバサイドの管理は全てバックエンド担当に任せていた。なので、筆者が個人で進める場合はまずサーバの確保から始めねばならない。その後の環境構築や、Rubyの記述等、諸々の学習コストが高すぎるのだ。しかも筆者が志望している分野はいわゆるフロントエンドであるので、それらのスキルは死ぬとまでは言えないものの、十全に活かし切ることができるとは言い難い。無論フルスタックエンジニアとなるなら話は別だが、筆者の志望としてはあくまでフロント一本であるのだ。
検討案
発生する問題項に記述したような課題に対して、筆者は大きく分けて二つの解決案を考えた。
個人でのプロジェクトの続行
これは上記のデメリットを飲んだ上で、プロジェクトを続行するというものだ。勿論サービスを作るという経験は非常に重要な資産となるだろうし、完全にないとは言い切れない程度には有力だ。ただしこれのデメリットとして、このプロジェクト自体に時間を取られすぎて他の技術を学べなくなってしまうものがあると思われる。他の技術とは、たとえば代表的なもので言えば、アルゴリズムや高速化のノウハウ、設計技巧等が挙げられる。
別プロジェクトの作成
これは完全に新規で新たなものを作り出すという案だ。この案を取った場合前プロジェクトは完全に失敗扱いとなるので、ポートフォリオの進捗を失うというリスクがある。ただし、フロントエンドが重視され、バックエンドはほぼ必要ないようなWebアプリケーションの構築を目指せば、かなりの学習コストの低減が見込める。
結論
検討案のメリットデメリットを鑑みた上で、筆者は過去に作ったTwitterAPIからツイートを取得する機能のノウハウを利用し、新たにTwitterクライアントを作成することにした。vscode-serverのようなクライアントのコンピュータ自体をサーバ化できるような仕組みにするか、Chromeの拡張機能として実装するかはやや迷ったが、Chrome独自の仕様と格闘することによるコストを重く認識し、localhostでブラウザからアクセスするアプリケーション構築を行うと決断した。TwitterのAPI自体はラッパーライブラリを利用できるし、過去にはそういったノウハウも存在するということで、制作面、学習面からコストを大幅に削減できる案だと考えている。
そして、そのポートフォリオを作り上げた上で、余力からバックエンドも学習したいと考えたときに前プロジェクトを再開し、それまでは凍結するという形で行くことに落ち着いた。
といったところで、今回の記事は以上である。
終わりに
検討案から新プロジェクト側を選んだが、そのときのデメリットとして進捗を失う、と記述したふうに思う。これに関してだが、すでに前プロジェクトでフロントエンドのノウハウが溜まっていたおかげか、割合すらすらと書けており、要件が難しくないこともあって、すでに完成率は５０％を超えている1。あとは細々としたユーザビリティ向上のシステム実装と、それに伴うスタイリングを残すのみだ。キャッシュにはindexeddbを利用していて、フロントエンドのみでほぼ全てが完結できるような仕組みにしているので、バックエンドにデータベースは存在していない。あくまでフロントエンドエンジニアとしてのポートフォリオであることを意識している。
これが終わり次第、また様々なことに手を出してみたいと考えているが、そのうちの一つにはnext.jsが含まれる。Reactとの親和性も高いので、ぜひとも習得したいところである。ただし、バックエンドも必然的に学ばねばならないので、まずはHaskellかelmかを学んで関数型言語の作法を学び、AtCoderなどのプログラミングコンテストに参加することでアルゴリズムの学習もしておくべきかと考えている。
ところで、次の記事は前プロジェクトでの失敗談を纏めたいと思う。
