フルスタックエンジニアと聞くと、WEBアプリケーションの構築ができる人（フロントエンジニア＋バックサイドエンジニア）且つ、サーバーに関しても、設計、構築、運用ができるという、理想のスキルホルダーなのですが、いま現在、どの企業においても重宝されますし、仕事における成果は凄まじいモノがあります。
フルスタックエンジニアとしてこれまで多数のWEBサービスを作ってきた僕が、いま取り掛かっているサービスも含めて、毎回感じることを、書き記しておきます。
自己紹介
元々の僕の経歴が以下のような少し特殊な流れで仕事をしてきたため、たまたまフルスタックエンジニアのスキルを持つことが出来ました。
1. 中学時代はMSXにひたすらBASICを打ち込んで、自分専用ゲームライブラリを構築。
2. 漫画家志望でずっとアナログイラストを描いていた。
3. ゲーム開発のグラフィッカー（ドット絵から、2D全般、3D全般、動画コーデック関連、サウンド編集、などなど）
4. 情報システム（某上場企業のERP構築とサバクラ型のデータベース設計などを某ベンダーSEから叩き込まれる）
5. 個人活動としてWEBサービスシステムエンジニア（perlを使ったWEBサイト構築を多数）
6. 上場企業のCTO（某ベンチャー企業に入り、商品開発を行い、部下育成から組織におけるエンジニアの取り組みを行う）
絵がかけて、デザインが出来て、色相などの知識を持てて、パソコンに関して詳しく、サービス構築を全て自分で行える、あとはセンスと経験であると考えていますが、プログラムのクオリティや、日々更新されていくサーバーやインフラなどの情報更新などに対応していくために日々の勉強は欠かせませんね。
サービス構築の手順
ベンチャー会社でサービス構築を行う時に、一番最初に「アイデア」が出ると思います。
これは、このサービスを作る意義だったり、サービスを作った時にどのようなビジネスになるかの初期概念のようなモノですが、この時点で詳細はフワフワしているモノが多く、サービス構築、運用に関係する人全員が、それぞれの視点でやりたい事を熱望すると思います。
実際に開発に入る前までに、こうしたものを整理して技術もマネタイズも含めた設計を行わなければいけません。
この時点で、ウォーターフォール型で行くか、アジャイルスタイで行くかを判断できると非常にその後の進行が効率的なのですが、ベンチャー企業や、少人数で行なっている場合、ウォーターフォールで進行するのは非常に困難な場合が多く、恐らくアジャイルで進行することになると思います。
アジャイルの場合は、モックアップを作り続けてブラッシュアップする方向になりますが、開発部隊以外は、実はそういう事には関心持たないため、その後の会議を行う度に、自分のやりたい事をひたすら要望し続けることになります。
この時点で、プロジェクトチーム内においてよくあるトラブルとして「言った、言わない」という無意味な議論がでるチームは、意見がまとまっておらず、スケジュールも共有できていない証拠なので、こうしたドキュメントは面倒くさくても都度作成し、チーム内で共有することをオススメします。
さらにアジャイルと言えど、製品としてのリリースをちゃんとスケジューリングしなければ、マネタイズが出来ないためキチンとα版、β版、本番リリース版、その後のバージョンアップ予定などを定めておきましょう。
サービス構築におけるジレンマ
サービス構築を行う人は、常に出来上がったものを、プロジェクトメンバー内で評価されます。
エンジニアは良かれと思って作ってみたシステムも見栄えが悪ければ、チーム内でも否定的な意見をもらうことになります。
よくあるジレンマとしては、否定的な意見をもらうが、エンジニアとしては必要な機能の時に、評価はデザイン面というだけなのだが、機能的に否定される事はよくある事。
きちんと話し合う必要がありますが、チームメンバーにおけるこうした評価会議とブレスト会議の質を高めなければ、ひたすら開発をする人がストレスを抱える環境になってしまうため、エンジニアリングを行う場合は、最初に周辺の人に対してキチンと発言する領域を理解してもらうようにしましょう。
ボク個人が非常に気になる発言は、非エンジニアの人がよく言う言葉として「自分は技術の事が分からないので・・・」という前置詞を付けて言う言いたい放題言う人、多くの場合、チーム内の空気を悪くするのはこのポジションの人です。
これが、チームリーダーだった場合は、目も当てられないストレスがのしかかることになるでしょう。
エンジニアは、営業の事も、運用の事も、ほぼ全てを担う事になりますが、それ以外の人は、部分的に対応すればいいという認識でいると、こういうチーム体制に陥りがちです。
しかし、チーム内全てのメンバーが、技術も全て精通するなんてことは、可能ではありません。
大事なのは、立場をわきまえることが必要で、空気を乱す行為は、チーム進行の妨げにしかならないことを理解してもらいましょう。
エンジニアはサービスの要
当たり前ですが、全てのサービス構築の要は、それを設計、構築するエンジニアにかかっています。
デザイナーが素晴らしいデザインを上げてきても、実際にコーディングするのはエンジニアという場合、デザインの良し悪しの評価はエンジニアに来ることになります。
こうしたチーム内のイザコザでいちいちストレスを抱えるのは、絶対によくありません。
構築担当する人が、チーム内のリーダー的存在になることが、ある程度の解決方法なのですが、そうでない時は、出来る限りポジションを確立できるように努力する事が必要になります。
改めてフルスタックエンジニアにとって、組織論も含めた「リーダーシップスキル」という事も必要なのかもしれませんね。
0 件のコメント:
コメントを投稿