はじめに
BitStarのモリヤです。
BitStar Advent Calender11日目です。
組み込み開発のみの経験値から入社し1年4ヶ月ほどが経過しました。
現在ではBitStar Matchというプロダクトに携わり、主にフロントエンド・バックエンドの両者を担当しています。
BitStar Matchとは
BitStarが蓄積してきたSNSプラットフォームのデータと取引データを元に、
企業が簡単にインフルエンサーマーケティングを実施できるオンラインプラットフォーム
この記事の目的
Web系実務未経験の状態で書いた記事を、1年程度の実務経験を積んだ今の視点から振り返り、共有します。
入社前には持ちえなかった考えを書き出していく形になりますので、他の分野からの転職を志している方々にとって有益な内容となれば幸いです。
※事前にこちらの記事をぜひご一読ください
読んでみる
以下、読みながら書き殴った文章になります。駄文失礼致します。
📗やったこと
概ね良さそう。
ポートフォリオサイト等の小規模制作物だとしても、全フローを意識した開発は是非一度やってみるべきだと思います。
Web系ベンチャーでの開発と組み込み・業務系開発との差として一番強く感じたのはスピード感と裁量の広さです。
与えられた企画・要件から、要件詳細の抽出・擦り合わせ~評価まで1人でやり遂げることがザラです。
そのため意識せずとも
- この要望を叶えるには何が必要か
- 実現するにはどの領域を変更すれば良いのか
- 最小工数で完了させるにはどの案が最前か
などを頭の中もしくは簡易的なドキュメントだけでまとめる力が必要になってきます。
そのため、開発フローの大枠だけでも事前に掴んでおくことは非常に大切だと思っています。
📗制作目的の明確化
Q. 誰に見てもらうため？
Q. どのようなイメージを持ってもらうため？
ユーザーストーリーの概念を学んでおければ良かった。
JIRAでの開発管理をする企業は非常に多いため、事前に概要的な部分だけでも学んでおくと良いと思います。
📗開発言語環境選定
TypeScript [4.6.3]
React [18.0.0]
React × TypeScript 今バリバリ使ってます。選んで良かった。
Railsでの簡易アプリ(別途作成)作って良かった。
動的型付け言語しか触ったことない方は、静的型付け言語を…
静的型付け言語しか触ったことない方は、動的型付け言語を…
是非触ってみることをオススメします。
特に静的型付けしか触ってない状態で動的型付け言語をメインで扱う会社に入社する予定のそこのあなた。
あの面倒な記述から解き放たれる！と呑気に喜んでいるそこのあなた。
………油断するとバグ量産しますよ。
公開方法
レンタルサーバー契約 ＆ 独自ドメイン
無料で公開できる方法にしときな…。
解約忘れて年会費無駄遣いすることになるよ…。
転職活動用の制作物としてのみであれば使い捨てで十分かなと。
📗サイトマップ作成
戻る場合の導線を設計段階で考えておけると良い。
実務でも割と漏れやすいポイントです。
自ら気づいてデザイナーさんと調整できるように、利用者目線を培っておくのは大切です。
📗ワイヤーフレーム作成
デザイナーを兼業する予定が無いのであれば、ココまで綺麗に清書しなくても…とは思うものの、フレームを作ったこと自体は良かったと思っています。
toB, toCどちらのプロダクトでも利用者目線が最も大事だと思っています。
いくら超高機能でもUIがボロボロだったら誰も使わないですしね。
企画者・デザイナーさんの要件を100%鵜呑みにするエンジニアではなく、
より良い案を提案できる、価値のあるエンジニアになるべく「サービスとは」「デザインとは」についても最低限は学ぶべきだと感じています。
📗コンポーネント設計
無理に固いフォーマットにしようとしなくて良い！(結局途中でメンテするの折れてるし…)
普段の癖で、先方の決めた「体裁だけで中身の薄い設計書」を作ろうとしていませんか。
いりません。
スピード感の必要な分野で体裁ガチガチの設計書は足枷になるだけです。
開発サイクルのスピードに合った、適切な粒度の設計書を書きましょう。
この場合はコンポーネント1個1個の定義を作ろうとするのではなく、
atoms, molecules…etcの切り分けルールを明確化しておくことの方が優先でしたね。
📗Atomic Designでのコンポーネント分割・共通化
現在感じているAtomic Designへの印象と驚くほど同じ。
個人開発ですら感じていたメリデメは、集団開発になるとより顕著に感じるようになります。
部品の分類基準を事前に定めなければ、迷いが生じやすい
特に分類基準。
元祖Atomic Designの思想をそのまま取り入れるのか。チーム独自のルールと組み合わせて使うのか。
今のチームでも度々議論になるポイントです。
とはいえ、分かりやすいディレクトリ構成・共通化の意識が生まれやすいという点は非常に強いメリットだと思うので、一度触ってみること自体はオススメです。
📗所感・改善点
状態管理が簡単かつ、どのコンポーネントが持っているのか分かり易い
こう書いて入るが…グローバルstateの管理が非常に辛かった記憶。
この時、Reduxを知っていれば選択肢の1つに入ったのかもしれない。
useContextとRedux、どちらも触って比較してみると良いかもしれません。
TypeScriptはundefinedの考慮が大変 (逆に良いところでもある)
1年半前にも感じていたとは…。
TypeScriptがプロジェクトに導入され始めてから現在に至るまで、全く同じことを思っています。
どのデータがundefinedを持つ可能性があり、どのデータが持つ可能性がない(持つべきではない)かの設計は非常に重要です。
一人で仕上げるにはデザインの勉強も必要だと感じた
カラーコーディネータの資格を取得してみるのも面白そう
最近、色彩検定2級を取得してみました。
専門家であるデザイナーさんが居るので、実務で直接使うかと言われると難しいですが、知識の引き出しの1つとして持っておいても面白いと思います。
おわりに
ひと通り読み直してみて、個人的にも変わったコト・変わらないコトどちらもあることに気づけた良い機会になりました。
これからも定期的に思考の振り返りをしていこうと思います。
それでは次回
『Web系未経験者がReact×TypeScriptでポートフォリオサイトを作る』を読むを読む
でお会いしましょう。1
BitStarでは冒頭でご紹介させていただいたBitStar Matchの開発に携わっていただける仲間を積極募集中です!
ご興味のある方はぜひ以下の募集情報をご確認ください。
-
タイトル着想 『土偶を読むを読む / 望月昭秀 他 著』 ↩