2014-05-26

クリエイティブ業界で働くべき理由、キャリア論

キャリアハックのインタビュー記事「エンジニアがクリエイティブ業界で働くべき最大の理由|バスキュール 古川亨のキャリア論」が公開された。こういうところにも、ソフトウェア・エンジニアのポジションがあることを知ってもらえるといいなぁ、という思いでグダグダ話した内容を、記者の白石氏がきれいにまとめてくれた。

タイトルにある働くべき理由や、キャリア論が明示的ではないと指摘された。記事に興味を持った人に対して、続きはブログで、という位置づけで、この文章を書くことにした。

「一般的な問題解決方法と、技術的知識/技能を、自分自身の環境に合った組み合わせで習得/実践することで、エンジニアが提供できる価値が大きくなる領域が存在する。クリエティブ業界はそのひとつだ。」という立ち位置で、インタビューに答え、この文章を書いている。


主語は、私(のようなエンジニア)


人口百人以下の村役場に勤める二十三歳の出納係と、丸の内の外資系証券会社に勤める二十三歳のファンドマネージャーでは恋愛のあり方が違う。(村上龍「恋愛の格差」)

インタビューもこの文章も、主語は「私」だ。あるいは「私のようなエンジニア」だ。似た状況になっている人なら、ヒントになると思う。エンジニアリング自体が目的になっていない組織に雇用され、エンジニアチームが数人で、1-2ヶ月単位でプロジェクトが編成され、人命に関わるような製品ではなく、技術レベルでの仕様がしょっちゅう変更され、自分自身はスーパーハカーではないアラフォー、という状況だ。まったく同じ状況ではなくても、似たような状況や、似たような派生状況(テストだけに1ヶ月もかけられないなど)ならヒントになるだろう。

一方で似ていない状況だと、役に立たないだろう。エンジニアリング自体が目的の組織、ものすごく厳格な品質管理プロセス、継続的に同じチームが同じ製品を開発、長期のプロジェクト、などだ。

ワインバーグの言葉を借りると、問題とは希望と認識のギャップだ。希望と認識に依存するということは、人に依存するということだ。同じ現象であっても、観測者によって異なる問題が定義されることがある。このへんは「ライトついてますか?」あたりを読まれたし。

汎用的なスキルと、個別具体的なスキル


そういう人たちは、二つの点で誤解をしている。一つは、好きなことを見つけることは大してむずかしいことではないと思っている点で、二つ目は、好きなことをやる場合にはたいてい訓練された高度な技術が必要になるということだ。(村上龍「恋愛の格差」)
汎用的な問題解決スキルと、技術やビジネスの個別具体的な知識の両方が必要で、日々、更新していくことで、自分の価値を提供できるだろうと考えている。

汎用的な問題解決というのは、もれなくダブりなく問題のロジックツリーを描くだとか、原因と結果をきちんと分けて認識するだとか、仮説思考だとか、なぜなぜ5回だとか、そういうことだ。高い凝集度と低い結合度を維持するとかも、技術的ではあるが汎用的な知識だろう。汎用的な問題解決スキルがないと、たとえばある言語の仕様を知っていても、個別の知識やベストプラクティスをどう適用すべきかが分からないことがある。

一方で、具体的な知識や技能がなければ、現実的な時間で、問題の解決や、発見自体ができなくなる。HTMLとJavaScriptの知識なしで、ウェブアプリのレイアウト崩れを直すのは至難の業だ。

両方できるのがいいに決まっている。君も明日からフルスタックエンジニアだ、と言うのは簡単だ。けれど、両方ですごく高いレベルで習得するには時間がかかるだろう。状況によって適切なバランスも異なるので、次は何を学ぶか、に単一の回答はない。

おそらくは、日々、問題解決をして、細かい意思決定をしているはずだ。毎日でも毎週でもなんでもいいから、定期的に方法論と技術的知識と、あとは他のこと(穏やかに文句を言うスキルとか、おっぱいばっかり見て話さないとか)のどこが欠けていたのか、何を身につければいいのか、を繰り返していくことで、適切なスキルセットを構築していくしかない。

単一障害点を減らす


「自分一人で生活できる能力を持つこと」が自立だと仮定すると、リストラされたとたんに生活の基盤を失ってしまう人は果たして自立していると言えるのだろうか。(村上龍「恋愛の格差」)


記事には、コミュニケーションなしで開発を進める、というようなことを書いてある。関係者の仲が悪いという意味ではない。開発仮定における人的な単一障害点(Single Point of Failure / SPOF)を減らすために、そうなっている、ということだ。私が置かれている状況で発生する問題にたいする解決策のひとつだ。

とにかく仕様変更が発生する。「この仕様は変えないでください。事前に検討して決定してください」と言うことはできる。けれど変わる。もう少し上のレイヤでできることがあるだろうけれど、一朝一夕に変えることは(今の私には)できない。けれど作り方を工夫できる。

API やコンポーネントの設計をするとき、各担当者が「自分のタスクを完了させるために、誰かの助けが必要」という状況をできるだけ減らすようにしている。個々の工数が少々増えても構わない。「サーバがAPIにこの値をつけてくれないと、クライアントの開発とテストができないので、待ち」みたいな時間を減らすほうが効果が大きい。サーバとクライアントの両方が同時にデプロイしないと動かない、みたいな状況も減らしたい。個別の工数ではなくて、全体のリリースサイクルを短くしたいのだ。

NETFLIX のダイナミック・スクリプティング・プラットフォームとか、PaaS とか、Lua でスクリプトを組み込むとか、そういうのが理想だろう。いまの案件のエンジニアリング・リソースと、プロジェクトごとの要件のばらつき具合を見ると、躊躇している。一方で、汎用の BaaS をいくつか持っていて、プロジェクトをまたいで使用している。

というわけで

汎用的な問題解決方法と、個別具体的な知識/方法を、自分に合った組み合わせで習得/実践することが必要だと考える次第である。コンテクストに強く依存すると、話が長くなりがちなのだけれど、前提条件を明らかにすることで話がクリアになると考えたので、書いてみた。

2014-05-08

ベストプラクティス()とコンテクスト

第一四半期バタバタしていた。テレビの収録、リハーサル、放送の日程は残念ながら given な条件なので変えられないのだけれど、そうじゃないときは休みを取りやすい。代休も、もちろんちゃんと取れる。部署の上司が取らせようとしてくれるのと、周りが寛容だからだろう。自分ばっかり休んでる気がするけど、気づかないふりして、代休で5日ほど休んでいる。

休んでいると、いろいろ余計なことを見るし、考える。以下は、その考えの吐露である。

きっかけはTDDである。が、TDDの話はいい。よくわからないことはあるし、テストの重要性は分かっていつつも、スキルがー、とかでまだあるべき姿に追いついていないところだ。

そこで、あるべき姿とは何か、である。かーらーの、問題の発見/定義と解決である。たとえば(さまざまな紆余曲折を経て)ちょっとしたDBがあり、Webブラウザで閲覧/更新をしたいとしよう。解決策として Django の管理画面を使うことになったとしよう。たぶんテストファーストでユニットテストを書く必要はないだろう。フレームワークのデフォルト機能使うだけなのだから、そんなものテストする工数のほうが多くなりそうだ。

一方で、そのDBに外部からアクセスできるようにし、ロールごとに細かく権限が異なるようなAPIとして提供し、課金までするとなると話が一気に変わる。おそらくは、リリース後に「ACL間違ってました、てへ」は通用しないだろうから、テストファーストかどうか知らないが、何らかの形で自動テストをしたくなるだろう。

この2つは極端だしわかりやすいんだけど、製品やサービスの機能要件、非機能要件、組織のあり方、開発サイクルなどによって、テストの位置づけは全く違うと思う。コンテクスト抜きで問題定義できないし、解決策候補の評価もできない。

ちょっと長いけれど、引用する。


たとえば、エクストリームプログラミング(XP)の方法論でよく知られている
格言のひとつに、「失敗する可能性のあるものすべてをテストせよ」があります。 初心者にとっては、これはレシピとなってしまいます。初心者は何をテストすればよいのでしょうか?オブジェクトの属性値を設定する「セッターメソッド」と属性値を取得する「ゲッターメソッド」のすべてをテストすればよいのでしょうか?プリント文をテストすればよいのでしょうか?見当違いなものをテストするのが関の山でしょう。
熟練者なら、何か失敗するか ― 正確にいえば、何か失敗する可能性が高いか ― を知っています。経験と判断力を備えているので、この格言が特定の状況(コンテキスト)において何を意味するかわかっています。

(Hunt「リファクタリング・ウェットウェア」)

あなたが置かれている状況と、私が置かれている状況が異なり、コンテクストが違うなら、TDD の意味が違う。TDDの解釈に揺れがない、としてもだ。テスト、devops の意味や位置づけもだろう。なんなら、「開発」とか「製品」とかの意味だって違う。「いやいや、テストとは〇〇だ」と言いたいかも知れないけれど、全く残念なことに、そんなことはない。比較的近いと思っている仕事の人達と話しても、違うことあるんじゃないすか?そんなことないすか? そんなことないと、ここまでドヤ顔で書いてきた私は、ちょっと困るんですけどね。

というわけで、もうちょっと前提条件やコンテクスト明らかにしたほうが、意味のある議論や意見交換ができるんじゃないかな、と思う。私は自分のコンテクストを鑑みて、次のビールを飲む。



2014-05-06

片付けゴールデンウィーク

放置していたことを片付けた。 

トライアスロン中島大会に申し込む

スイム1.5km、バイク40km、ラン10km。5年くらい毎年参加している。紙に書き込んで郵送するか、Excel のファイルをダウンロードして記入してメールするの二択。Excel ファイルが地味にチェックボックスとかになっていて、Mac にプリインストールされていた Number.app では編集できない。Office for mac の DVD を探し出したが、マウントできない。いろいろやってUSBケーブルがダメだと気付き、インストール。記入して、出場許可がでることを祈りつつ申し込んだ。
https://www.city.matsuyama.ehime.jp/shisei/shiminkatsudo/sports/triathlon.html



CDをiTunesに取り込む

Office for Mac の DVD を探していたら、音楽CDが出てきた。音楽を聞いていた時期が私にもありました。ってわけで、iTunes に取り込んでいなかったCDを取り込んだ。


  • Incognito 「Beneath The Surface」
  • 岡村靖幸「OH!ベスト」
  • C-C-B「GOLDEN BEST」
  • Dave Grusin「Now Playing」
  • Thomas Hardin Trio「Satie & Debussy」
  • Dave Grusin「Two For The Road: The Music of Henry Mancini」
  • 渡辺美里「Sweet 15th Diamond」
  • 上原ひろみ「Spiral」
  • 「JET STREAM ニューヨーク/サクセスストリート」
  • David Benoit 「Remembering Christmas」
  •  「Now Jazz 4」

イーモバイルのsim交換

なんかよくわからないけど、機種変更した時にemチャージなるプランに変更になっていたらしいので、sim を入れ替えて、チャージや自動更新の設定をし... ようと思ったら、この sim カードはでかすぎて、pocket wifi に入らない。放置。

東京・江戸前トライアスロン

10月のレースなのだけれど、早めに申し込む。どうせぎりぎりまで粘っても、年に何回はレースをキャンセルする羽目になる。スイム0.5km、バイク12km、ラン5km。会場が、自転車で軽く自走できるくらい近いし、距離も短いので気軽に参加できる。

その他

  • 先週のランニングレースの結果入力
  • 昔の上司からメールに返事をかく。軽く返事を書いたんだけど、改めて丁寧に。