タイトルにある働くべき理由や、キャリア論が明示的ではないと指摘された。記事に興味を持った人に対して、続きはブログで、という位置づけで、この文章を書くことにした。
「一般的な問題解決方法と、技術的知識/技能を、自分自身の環境に合った組み合わせで習得/実践することで、エンジニアが提供できる価値が大きくなる領域が存在する。クリエティブ業界はそのひとつだ。」という立ち位置で、インタビューに答え、この文章を書いている。
主語は、私（のようなエンジニア）
人口百人以下の村役場に勤める二十三歳の出納係と、丸の内の外資系証券会社に勤める二十三歳のファンドマネージャーでは恋愛のあり方が違う。（村上龍「恋愛の格差」）
インタビューもこの文章も、主語は「私」だ。あるいは「私のようなエンジニア」だ。似た状況になっている人なら、ヒントになると思う。エンジニアリング自体が目的になっていない組織に雇用され、エンジニアチームが数人で、1-2ヶ月単位でプロジェクトが編成され、人命に関わるような製品ではなく、技術レベルでの仕様がしょっちゅう変更され、自分自身はスーパーハカーではないアラフォー、という状況だ。まったく同じ状況ではなくても、似たような状況や、似たような派生状況（テストだけに1ヶ月もかけられないなど）ならヒントになるだろう。
一方で似ていない状況だと、役に立たないだろう。エンジニアリング自体が目的の組織、ものすごく厳格な品質管理プロセス、継続的に同じチームが同じ製品を開発、長期のプロジェクト、などだ。
ワインバーグの言葉を借りると、問題とは希望と認識のギャップだ。希望と認識に依存するということは、人に依存するということだ。同じ現象であっても、観測者によって異なる問題が定義されることがある。このへんは「ライトついてますか？」あたりを読まれたし。
汎用的なスキルと、個別具体的なスキル
そういう人たちは、二つの点で誤解をしている。一つは、好きなことを見つけることは大してむずかしいことではないと思っている点で、二つ目は、好きなことをやる場合にはたいてい訓練された高度な技術が必要になるということだ。（村上龍「恋愛の格差」）汎用的な問題解決スキルと、技術やビジネスの個別具体的な知識の両方が必要で、日々、更新していくことで、自分の価値を提供できるだろうと考えている。
汎用的な問題解決というのは、もれなくダブりなく問題のロジックツリーを描くだとか、原因と結果をきちんと分けて認識するだとか、仮説思考だとか、なぜなぜ5回だとか、そういうことだ。高い凝集度と低い結合度を維持するとかも、技術的ではあるが汎用的な知識だろう。汎用的な問題解決スキルがないと、たとえばある言語の仕様を知っていても、個別の知識やベストプラクティスをどう適用すべきかが分からないことがある。
一方で、具体的な知識や技能がなければ、現実的な時間で、問題の解決や、発見自体ができなくなる。HTMLとJavaScriptの知識なしで、ウェブアプリのレイアウト崩れを直すのは至難の業だ。
両方できるのがいいに決まっている。君も明日からフルスタックエンジニアだ、と言うのは簡単だ。けれど、両方ですごく高いレベルで習得するには時間がかかるだろう。状況によって適切なバランスも異なるので、次は何を学ぶか、に単一の回答はない。
おそらくは、日々、問題解決をして、細かい意思決定をしているはずだ。毎日でも毎週でもなんでもいいから、定期的に方法論と技術的知識と、あとは他のこと（穏やかに文句を言うスキルとか、おっぱいばっかり見て話さないとか）のどこが欠けていたのか、何を身につければいいのか、を繰り返していくことで、適切なスキルセットを構築していくしかない。
単一障害点を減らす
「自分一人で生活できる能力を持つこと」が自立だと仮定すると、リストラされたとたんに生活の基盤を失ってしまう人は果たして自立していると言えるのだろうか。（村上龍「恋愛の格差」）
"「作り方」を開発できること。たくさんの案件が同時に走った時、ゼロから全部つくっていたら死んでしまう。" http://t.co/ca2WBl5Ptj 実際話を聞きに行ったことあるけど、この辺凄く意識してる感じで、実際ものを持ってる。
— voluntas#1345 (@voluntas) 2014, 5月 20
記事には、コミュニケーションなしで開発を進める、というようなことを書いてある。関係者の仲が悪いという意味ではない。開発仮定における人的な単一障害点（Single Point of Failure / SPOF）を減らすために、そうなっている、ということだ。私が置かれている状況で発生する問題にたいする解決策のひとつだ。
とにかく仕様変更が発生する。「この仕様は変えないでください。事前に検討して決定してください」と言うことはできる。けれど変わる。もう少し上のレイヤでできることがあるだろうけれど、一朝一夕に変えることは（今の私には）できない。けれど作り方を工夫できる。
API やコンポーネントの設計をするとき、各担当者が「自分のタスクを完了させるために、誰かの助けが必要」という状況をできるだけ減らすようにしている。個々の工数が少々増えても構わない。「サーバがAPIにこの値をつけてくれないと、クライアントの開発とテストができないので、待ち」みたいな時間を減らすほうが効果が大きい。サーバとクライアントの両方が同時にデプロイしないと動かない、みたいな状況も減らしたい。個別の工数ではなくて、全体のリリースサイクルを短くしたいのだ。
NETFLIX のダイナミック・スクリプティング・プラットフォームとか、PaaS とか、Lua でスクリプトを組み込むとか、そういうのが理想だろう。いまの案件のエンジニアリング・リソースと、プロジェクトごとの要件のばらつき具合を見ると、躊躇している。一方で、汎用の BaaS をいくつか持っていて、プロジェクトをまたいで使用している。
というわけで
汎用的な問題解決方法と、個別具体的な知識/方法を、自分に合った組み合わせで習得/実践することが必要だと考える次第である。コンテクストに強く依存すると、話が長くなりがちなのだけれど、前提条件を明らかにすることで話がクリアになると考えたので、書いてみた。http://careerhack.en-japan.com/report/detail/332 に関するツイート
