プログラマーが「フルスタック」という概念を見たとき、だいたい2つの反応がある

1. うわ、これいい、すげえ

2. お前何分かってんだよ、フルスタックは何でも中途半端だ

上記の2つの反応はどちらも偏っている。なぜなら、一つの技術だけを学んでも、レベルが低い人は大勢いるし、フルスタックエンジニアの中にも、何でもやりつつ、すべてをそこそこ上手くこなす人は少なくない。ましてや、この世界には別の「爆スタック型」プログラマーも存在する。何をやっても、すべてに精通している。

私の個人的な実践から言えば、フルスタック見習い少なくとも次のようなスキルを身につける必要がある：

  • Webフロントエンド開発、少なくとも1つのフロントエンドフレームワークを習得すること；
  • Serverバックエンド開発、少なくとも1つのバックエンドフレームワークを習得すること；
  • Server運用、Linux Serverの構築と保守を習得すること；
  • クライアント開発、iOSとAndroidの少なくとも1つを習得すること；
  • データベース、SQLおよびnoSQLデータベースを習得すること。

そして、フルスタックという称号は、少なくとも一人で製品の構築を成し遂げ、実際に商業運用を経験し、そして自分の愚かさに何度も痛い目に遭ったことがある。

このことから、フルスタックのハードルはかなり高いことがわかる。上記の5つのスキルを身につけたからといってフルスタックとは呼べず、少なくとも「見習い」という修飾を加える必要がある。あまりにも多くの見習いが自分たちをフルスタックと自称するからこそ、周りの人々は「フルスタック」を「何でも中途半端」の同義語だと感じるのだ。

しかし、この記事のタイトルは——なぜあなたは「フルスタック」を試すべきなのか。だから私が議論したいのは、フルスタックになるかどうかではなく、試すことだ。

素人と玄人

過去数年、私は多くのチームと話してきたが、ほとんどのチームの対立は次の点にある——

  • Server側がクライアントを理解せず、APIを設計した後で無責任に文句を言う；
  • デザイナーがクライアントを理解せず、インタラクションを設計しては無責任に文句を言う；
  • クライアント側がServerを理解せず、APIに対して無責任に文句を言う；
  • クライアント側がプロダクトを理解せず、要件に対して無責任に文句を言う；
  • プロダクトマネージャーが要件を理解せず、チームに対して無責任に文句を言う。

最後のプロダクトマネージャーは焼かれるべきだが、前の4つの対立はまだ救いようがある。

Argye

プログラマーは神モードの職業であり、日々の仕事は創造することなので、この職業はとてもかっこよく見える。しかしそれゆえに、プログラマーは多少なりとも自信過剰になる。自信過剰の結果、自分の限られた知識で他人の仕事がどうあるべきかを推測することになる。。

Server側がクライアントを理解していなければ、クライアントの仕組みに合わないAPIを設計しがちだ。そんな時、クライアント側のプログラマーが辛抱強く説明して、各APIに1、2日かけてすり合わせできればまだいいが、うまくいかなければ喧嘩になる。

しかしServer側のプログラマーが常に間違っているわけではない。クライアント側は、すべてのデータが渡されたら追加加工が不要なことを望むが、クライアントが必要とする構造に合わせて渡すと、一部のクエリに1、2秒かかることもある。クライアントがサーバー側の仕組みを理解せず、「サーバーはクライアントにサービスを提供するものだ」と一方的に要求すれば、また喧嘩は避けられなくなる。

技術者同士の議論が冷兵器による戦争だとするなら、さらに素人のプロダクトマネージャーやボスに当たってしまったら、核戦争が勃発することになる。

「ちょっとWebページを直すだけだろ、10分でできるだろ？」

「効果が難しいわけがない、俺が作ってやるよ！」

「明日リリースだ、早くしろ！」

「技術的にどんな困難があろうと知らないが、とにかく実現してみせろ！」

そしてこうした光景は、どの会社でもほぼ絶えず繰り広げられている。

相手の技術を理解してみる

まず私の技術的な成長の軌跡について話そう。

私は中学からLinuxを使い始め、メインシステムはUbuntuで、その後ArchLinuxに切り替え、またUbuntuに戻り、大学1年まで使い続けた。この数年のLinux使用経験がServerアーキテクチャの基礎を築き、大学1年から自分で製品を作り始めた。

その頃、まずWeb版を作って、それからクライアントを作ろうと考えていた。

そこでバックエンドから始め、Djangoを使い始めたが、すぐにRails陣営に移った。Railsのアジャイル開発は開発コストを大幅に下げ、その規約の慣習によって、初心者が多くの危険地帯を無事に飛び越えられるようになった。

Webフロントエンドを書き始めたとき、フロントエンドフレームワークというものが存在することを知らなかった。Railsで書き終えて初めてEmber.jsというものがあることに気づき、Ember.jsで書き直し始めた。当初はRailsでフロントエンドをレンダリングする方法という理解だったが、後にフロントエンドフレームワークを導入した後、Railsの役割はAPI Serverになっていることに気づいた。

そこから新しい視点でRailsのAPIをどう設計するかを考え始め、API設計に関する大量の資料を読み、どう設計すればフロントエンドが使いやすいか、どうすればクエリ時間を短縮できるか、サーバーキャッシュ、redis、セキュリティなどについて学んだ。

Railsの自動化は大いに役立った。自分が知らない多くの場所をすでにうまく処理してくれていた。そして知りたいと思ったとき、その実装が実に巧妙であることに気づく。さらにRailsが新しい技術を受け入れる姿勢のおかげで、常に新しいものを試すことができた。CoffeeScriptとSassは、最初にRailsが自フレームワークのデフォルトフロントエンド技術として取り入れたものだ。

photo-1432691301971-c8b920198bd7

その後、Ember.jsからAngular.jsに切り替え、Angularで書き直した。その間にフロントエンドツールのGruntにも触れた（フロントエンドの変化は目まぐるしく、現在使われているものはもうこれではない）。

最後にiOSクライアントの開発を始めた。iOSのUI実装はWebのHTMLやCSSとは多くの点で異なるため、iOSのUI概念を理解するのにかなりの時間を費やし、思考をWebからiOSのインターフェース開発思想に切り替えた。

データベースもこの期間にMySQLからMongoDBに変更した。あの数年のトレンドがちょうどその移行だったからだ。

この技術実践の過程では、幸いにも一人だったので、誰と喧嘩することもなかった。もしそうでなければ、どの段階にもたくさん喧嘩の種があったと思う。

私が開発したプロジェクトがリリースされた後、運用の複雑さが徐々に増すにつれて、chefやAnsibleのような自動化運用の手法にも触れ、さらにNewRelicのような監視サービスも導入した。そして安定した開発環境のためにVagrantも使うようになった。

これらはすべて、たった1年の間に起こったことだ。

面白いことに、iOSクライアントを書いているときに、突然HTMLとCSSの実装原理を理解したり、Railsをやっているときに、突然より良いiOSアーキテクチャを思いついたりした。異なる技術の間での類推による理解が毎日のように起こっていた。

その後、この経験のおかげで、さまざまな技術者と非常に気軽にコミュニケーションできるようになった。なぜなら昨年秒视でフィルターを作ったため、openGLを研究し始め、再び学び直したBlender後、以前は分かったような分からなかった多くの箇所が、突然Hello Worldのように簡単に実装できるようになり、そのままUnityも試し始めた。これまでの蓄積の上で、Unityの学習は非常に簡単になり、夜の趣味のプロジェクトとなった。おそらく近いうちに、私が作ったゲーム（RPGかもしれない）を見られるかもしれない。

私は、フルスタックがあなたを全面的に凡庸にするとは思わない。各技術に取り組むとき、それは他の技術にアイデアを提供し得る。そして様々な技術を理解している前提で、その中の特定の技術を深く掘り下げると、しばしば他の技術への還元が生まれる。逆に、理解している技術が非常に狭いことが、自分の可能性を制限する原因なのかもしれない。

尊重と平和

チームでのコミュニケーションにおいて、相手の技術を理解することで、コミュニケーションコストを大幅に減らし、尊重と平和をもたらすことができる。

達人同士がどちらが譲るべきかで議論しているのはほとんど見かけない。むしろ、入門したばかりの人たちが一日中延々と喧嘩し、すぐにカッとなることが多い。

業界全体のレベルがすぐに質的に変化するとは言い難いが、もし製品要件を詳細に説明し、理由を明確にし、技術者同士が一緒に学び合い、辛抱強く議論し、デザイナーが技術的な側面を尊重し、今により適したプロトタイプを設計できれば、すべては良い方向に向かうだろう。そのすべては、相手の仕事を理解することから始まる。

作者：周楷雯

原文リンク：http://www.ifanr.com/551905