書きました。
もっと広まって欲しいです。
この仕様は実際のところSwift2あたりからあったんでしたっけ？
仕様自体は自分も2年前には既に知っていたと思います。
そのパワフルさに気づいたのが1年くらい前で、検証する機会に恵まれたのが割と最近でした。
こんな良いこともっと早く気付けばよかったと少し後悔。
これを使えばInterface的な設計や、mixin的な設計や、抽象的な設計がある程度組めるので、どんどん使っていきたいです。
継承という仕様はほとんど要らない子になりました。継承が必要なシーンと言えば、あとはライフサイクル内で共通処理をしたいとかそういうパターンくらいかな？
extensionもそうですが、こういった疎結合に組める仕様が出てくると、モジュール化がプロジェクトを跨いで使えるようになるんですよね。
仕事すればするほど強くなれるようになるので、個人的には追い風です。
一つ苦言を呈するなら、何でこの仕様が初期に無かったのかが解せない。
Objective-Cの深い部分（cocoaの部分？）では出来てたはずなんですよねー。
ちょっとオッサンの毒吐き。
私は今アプリを作ってるんですが、他のことをするチャンスは何回か有りました。
例えば数年前はゲームが流行りました。明らかにゲーム業界の給料がぐんぐん伸びていっていたし、ゲーム好きな人はこぞってそっちへ行きました。
例えば大学院時代はAI領域の専攻だったのですが、修了後何年かでAIブームになりました。一応基礎は分かっていたのでAIの方に行くこともできたと思います。
でも私は行きませんでした。
私が右も左も知らない社会人一年目とかなら、喜んでいったと思いますが、残念ながらそのチャンスが来たときには既に社会人として擦れていました。
ゲーム業界が華やかなのは成功している極一部だというのはすぐ分かりましたし、成功してもとんでもないボーナスが貰えるわけではないと分かっていました。会社とは大体そういうものだし、自分が社長だとしてもそうします。
AI業界はもっと悪いです。まずビジネスがどう動いているのかが全然見えてきませんでした。バズはいくらでも起こるのにネタが見えない界隈に飛ぶこむほど子供ではありませんでした。
これらが重要だと思っています。
今の仕事は幸いそこら辺がわかりやすかったし、失敗しても折れない自信がありました。本当は最初はBtoBに行こうと思っていたのですが、BtoCがWebビジネスとして盛り上がってきたのは非常に幸運でした。
例えばゲームを作るとして、誰もプレイしてくれなかったら折れるんじゃないかと思います。私のゲームに対する思いはその程度です。
また、役割が変わることを想定しておいたほうが良いです。
例えばコードを書かなくなっても続けていけるのか、その業界にいる理由があるのか。これが無くなるとしたら厳しいと思います。
どこからお金をもらうかとか、モチベーションとか、そういう特徴は案外少ないです。
などなど
前に似たことを書きましたね。
特徴というのは少ないから、すぐに自分は◯◯だとわかることができます。その仕事が自分に向いてるかどうかより、その特徴が自分に向いてるかどうかの方が簡単にわかります。
だから、まずは仕事の特徴を分解して自分に合うかどうか見たほうが良いと思うんです。
技術で選ぶとか、何となく面白そうだからで選ぶのは悪手だと思うんです。
それが言いたかっただけです。
それで、AIや機械学習エンジニアってどういう仕事かな？って考えたり、募集要項を調べてみると、大体は
で、おそらく皆が想像してるのは一番上の仕事なんでしょうけど、これは花形で数も少なく、9割以上はそれ以外なんですが、
これからはAIだ機械学習だって勉強した人たちが、実務を想像できているのかと最近不安になってきました。
だって、これらのほとんどの業種はこれまでの仕事の文脈があってその中で精度向上のためにAI・機械学習があるのに、流行りに乗って勉強してる人はまず「AI・機械学習」ありきなわけです。
しかも先進的な何かを夢見てるはず・・・？
これは私も今年気づいたのですが、AI・機械学習というのは精度向上が主な強みですから、これまでのWeb・スマホ・ゲームと言う文脈の延長線上ではなく、むしろSIerやメーカー系の延長線上なのではないかと思います。
少し語弊がありますね。1を10にするとか、10を100にするではなく、10000を10100にする仕事と言いますか、つまり大規模向けという話です。
もちろん全ての仕事がそうとは言いませんんが、コンバージョンを数％上げてメリットが有るのはベンチャーより大企業の方です。
だから普通に祝活を始めたら、日本の場合は重厚長大かつ古い体質の企業に入ることになると思うんですが、これを分かっていて勉強しているんでしょうか。それならいいんですが。
もちろんお給料は今結構高めらしいですが、ブームというのは必ず揺れ戻しが起こります。
結構前に書きました。
まあそれを言ったらプログラミングブーム何ていう事象はプログラマーにとって死活問題なんですが。
この問題、割と蔑ろにされてますが、もうちょっと重視したほうが良いんじゃないかなあと前々から思っています。
有名所で言えば美術系や音楽系ですが。それ学ぶのは良いしけどその後どういう仕事があるか・その仕事は自分がやりたいことか理解してる？というのは押さえておきたいですね。
って言っても若い人にそんなの分かるわけないので、おっさんあたりが教えられると良いのかもしれませんが。中々上手く行かないですね。
ピタゴラ装置というか、ルーブ・ゴールドバーグ・マシンなんですが。
参考：
▲超厳選▼ ピタゴラ装置傑作集(Rube Goldberg Machine)コロコロからくり装置 - NAVER まとめ
ステレオタイプの発明家が作ってるような、ゴテゴテの仕組みをループゴールドバーグマシンと言います。ピタゴラスイッチもその一種です。
ピタゴラ装置は見ていて楽しいです。
しかしこれらをプログラムで作ると大変なことになります。
保守改修できません。
何がどうなってそうなってるのかわからないし、1個手を入れたら全体のバランスが崩れて動かなくなってしまいます。
端的に言えば不安定なんです。
たぶんこれだけです。
これだけで愉快な不安定装置は、面白みのない安定装置に変化します。
ですがこれができていないコードが世の中にあまりに多くて・・・というのはまあ別の話なので辞めましょう。
実際に回避しようとすると難しいことがわかります。
特にチーム開発では難しいです。
「InとOutとWhatを明確に」とは言え、それらを一度作った時は明確でも、改修していくうちに何が何だかわからなくなるかもしれません。
みたいな苦労をしないと、気づけばピタゴラ装置ができあがってるのです。
怖いですね。
上記の手段、途中参加の人には使えません。
つまりフリーランスは使えないので分解できることが求められます。
たぶんフリーランスに求められるレベルって普通に仕事できるレベルより一段上にあるんですよねここらへん。そのうちそれも書きたいです。
前と別軸の話。
これも来年に向けて一つのテーマにしたいです。
設計には全体に及ぶ設計（喩えるなら戦略？）と、部分に適用できる設計（喩えるなら戦術？）があります。
この2つは非常に性質のことなるものですが、なぜか世間では同じく「設計」とかそういう類の言葉で同一視されてしまいます。
全体に適用できる思想というのは大体の場合たかだか１つです。
移行期に複数の設計が混ざるケースもありますが、理想的には１つです。
なのでチーム開発の場合、誰かが適当に変更して良いものでは有りません。
ある一部分に適用するだけだけど、結果的にその影響が全体に及ぶみたいな設計もあります。
私はこの尺度を「支配度」「影響度」「感染力」などと勝手に呼んでいたりします。
もちろんこれは密結合のときの方が起こりますが、疎結合にしてもなお影響度の高い設計というのは生じてしまうものです。
（例えばModelの設計を変えたら全体がガラッと変わってしまいます）
ここらへんですね。
毎年新しいアーキテクチャーや設計手法が生まれては消えていきます。
毎回新しい案件に入るごとに、モヤモヤする設計を目の当たりにします。
そこでどうにも2つの大きな思想の違いがあることにようやく気づき始めることができました。
おそらく優秀な層の方々は数年前か、もっと前にそこにたどり着いているはずなので、この話は今更かもしれませんが、備忘録的にまとめていきたいと思います。
まだ頭の中でとっちらかってるので、今回は基本事項だけです。
リアクティブやRxの思想、あるいはデータバインディングという新しい方法を知る中で、彼らが何をしたいのか考える中で気づきました。
プラスアルファで、そういうったものを導入した時に、却って困る事象が起きた時に、既存コードの優位性を考える中で気づきました。
と言ってもこの考え方自体そもそも古典的な感じがします。
ぶっちゃけ私がリアクティブ周りの思想を全部把握できないから、せいぜい2種類しか観測できないっていうだけです。
リアクティブシステムが注目を集める理由 | Think IT（シンクイット）
あっあっあっ（脳が壊れる音）
難しすぎる。
でもこういうパラダイムを作るときって、色んな複数の思想がゴチャ混ぜで導入されて意味不明になりがちなので、結局どんな差があるの？と限界まで削ぎ落とす分析は重要だと信じています。じゃないと私の矮小な頭では理解できません。
これまで皆がやってきたプログラミング方法。
メインとなる処理の流れがあり、関数に処理を投げて結果を受け取る。
メインとなる処理の流れが基本的に全てを取り仕切る。
関数に処理を投げるがコールバックは受け取らず、投げっぱなし。
反応的（何かが起きたら、別の何かが起きる）
各モジュールが自分の責任範囲について処理を取り仕切る。
会社に喩えると
収束型は「このタスクやっといて、終わったら報告してね」
発散型は「このタスクやっといて、終わっても報告はいらん」
（思いついたら追記します）
例えばマイクロサービスが分かりやすいです。
これは１個のモノリシックなサービスを作るんじゃなく、複数の独立したサービスに分割しようという話です。
発散型に該当しているキーワードを見ると、スタイリッシュで次世代チックな感じがしないでしょうか？
実際これらは流行りつつあると思います。
理由はおそらく「非常に疎結合に作れる」故に「テストコードが書きやすい」あたりです。悪言い方をすると意識高い界隈で流行ってますね（毒吐き）。クソ真面目界隈でも良いですけど。
ただこれらには欠点もあるようで、それに気づかず安易に導入して苦しい思いをしている人やその煽りを食らっている人（私）もいるようです。
問題なのは、疎結合という部分です。
WebAPIの例が分かりやすいと思います。
一つのシステム内で完結する場合に比べ、例えば「アプリーWebAPI」のようなシステムが分断している場合では、対応しなければならないことが非常に多くなります。WebAPIはどういうリクエストが来ても内部を正しい状態にしなければなりません。
「処理を投げっぱなしにしていい」という状態を作るには
ような状態を作らなければならないのです。
つまり、１個のモジュールとして完璧でなければなりません。
これが非常に困難かつコストが高いのが問題です。
プログラムとしては理想的かもしれませんが、プロジェクト的には理想から程遠くなるかもしれません。
対して収束型と言うのは、言ってしまえばモノリシックなコードを見やすく分割しただけに過ぎず、しばしばモジュール化が甘くなります。
ただし代わりに全てのリクエストに対応する必要はなく、仕様上存在する有限個のパターンに対応できていればシステムは動きます。
プログラム的、テストコード的には理想的ではないにしても、プロジェクト的には正解であることもあります。
最近考えてる内容です。書かないと忘れそう。
少なくともモバイルアプリについては、発散型が適していないと感じています。
一部の先進的な会社は確かに発散型を導入しているのですが、元々モバイルアプリに適していないのを理解した上でそれでも余りある理由があるから導入していると思うんですが、どうも他のプロジェクトでその文脈が無視されがちなのでは？と疑っています。
本件、中途半端ですが。
来年いっぱいくらい掛けて考えていきたいと思います。
こういうのいつまでやるんですかね？
もちろんこういう「煽り記事」を書くとバズるのでメディアとしては有りなんでしょうけど、日経あたりがやってるとガッカリします。
「安いニッポン」というテーマは良いと思いました。世界的に円高かつ物価が高かった90年代に比べて、最近は相対的に安くなってきた。それはなぜか、またどういう影響があるか？というテーマだと思います。
上はこちら。
そういった時に、もちろん比較としてあげるべきは「他の先進国」ですし、もしくは「人材流出がどのくらい進んでいるか」という話でしょう。
決して「世界最高峰の地域ではこんだけ高い給料が出ていて1400万円なんて低所得者だ」という話では有りません。そういうのは週刊誌とかネットの隅でやる話です。
経緯を書くと長くなりそうですが、御存知の通りこの2地域は特殊な状態です。
アメリカや中国国内から見ても特殊です。
果たして日本や他国のIT業界と比べられるのかは慎重にならなければなりません。
もちろん比較対象としては不適切です。
例えば日本国内において「地方はどう東京と戦うか」という話があると思います。
それと同じような話はできるはずですが、もちろんその話をするなら実際にどのくらい流入出があるのか、生活費や税制面でどういう差があるのか、働き口はどのくらいあるのかなど、多角的に分析するのが普通でしょう。
決して「都内で600万円は低所得〜」なんて記事にはならないはずです。
A社よりB社の方が高いからそっちに行く、というのは普通にありますが、それは他の条件が揃っている場合です。
仕事の内容、国や地域、自分がどういう雇われ型をするのか、など条件が揃って初めてお金の話になります。
「きっと優秀な人はさっさとこんな国なんて捨ててアメリカや中国に行くんだろうなあ」っていうのはどうもバカにしてる感じがします。
実際向こうに行ってる人の経歴を見ても、よりよい仕事がしたいとか、家族の都合とかの経緯がメインで、高いからそこに行くという人はまだ見たことが有りません（中国に一瞬絡んで儲かったという話はちょいちょい見たことがありますけど）
何がしたいんでしょうね。こういうゴシップ記事って。
これ読みました。
努力2.0面白そうです。
「努力はもうしてる、でもまだ足りない、じゃあどうする？」という話は前に書きました。
「じゃあどう努力すればいいの？」について考えをまとめたいと思います。
何か高い目標に対して頑張れる時間・機会というのは有限です。
これは、人によっては部活のときに、あるいは受験の時に、あるいは仕事を通して気づく事が多いと思います。特に競争が絡むと有限を感じるかもしれません。他の人も頑張ってるから、自他の差が出ず、努力してる／してないでは勝敗がつかなくなります。
実はこれ、問題設定がまずいと思います。
努力という言葉は非常に抽象的で、一般化するのは難しいはずです。
eスポーツ選手なのか、受験生なのか、社会人なのか、様々な状況で具体的な行動はガラッと変わってくるでしょう。
「努力」を一段階具体化すると「目標に到達するための行動」となると思います。
なぜこれほどまでに「努力」という言葉が多用されるのかといえば、その話題が出てくる前提状況として「目標に到達できていない」があるのだと思います。
この感情から生じる言葉の代用現象（今命名）というのは外でもあります。
例えば「金がほしい」は本当に欲しいものは金じゃないはずです。「死にたい」は大体の場合本当に死にたいわけではないはずです。
これらと同じように「努力」という言葉が飛び出す時は大抵「目標に到達したい」が根底に有り、しかしその方法がモヤモヤしてるから「努力」という言葉が出てくるわけです。
感情から生じる言葉の代用現象というのは、大抵その解決策が具体化されるとその抽象的な言葉は出てこなくなります。
金を得るには仕事をすればいい、となれば「金欲しい」が「仕事したい」になります。
死にたくなくなるためには恋人がいればいい、となれば「死にたい」が「彼女欲しい」になります。
例えば山登りを考えると、登頂のための手段は「歩いて登ること」です。
じゃあ「あなたは登頂のために歩くという努力をしているのですね？」と言われると、何かしっくり来ません。「登頂のために色んな道具を用意するなんて、努力家だなあ」と言われても、しっくり来ません。
単に目標達成のために普通にやってるだけです。
努力という言葉が出てくるシーンでは、目標到達のための方法が分かっていないわけですから。まず、
「どう努力すればいいか」は
「目標達成のために何をどれくらいすればいいか」に置き換えましょう。
そちらの方が具体的です。
先程の登山の例を再び使うと
「歩くという努力を重ねればいずれ登頂できるか」
という話になります。
これはもちろん山次第です。「たしかにそうだ」という山もあれば、「んなわけあるか！」という山もあります。
これと同様に、目標次第で「努力でどうにかなるか」は変わってくるはずです。
これは人間の悪い癖なのかもしれません。
登山ならそんなことないと分かるでしょうが、方法論がわからなかったものが分かるようになると、途端に目標達成できるような気がしてしまいます。
この順で議論されるべきですが、どうしても1,2に終止してしまいます。
努力を考えた時、既に方法が確立されているかいないかは大きな違いがあります。
既に方法が確立されているものは、たしかに努力しているか／していないかが重要なウェイトを締めるのですが、そういったものは言葉がより具体化される（例えば「勉強してるか」）ので、努力で悩むのは結構「方法が確立されていない方」だったりします。
それで努力＝「目標達成のために何をどれくらいすればいいか」で悩むわけですね。誰に聞いても教えてくれないので。
前人未到の目標に対して邁進している人は誰がいるか、世の中を見渡してみると、実はスタートアップ企業がそれに非常に近いです。
努力の方法は彼らから学ぶところが大きいと思います。
企業がどのように目標達成していっているか、というのは語るととんでもない量になってしまいますが、基本的にやってることは変わらないと思います。
目標の明確化
行動の選択
定期的に振り返り
※目標が非常に遠い場合はそれを分割する。
※選択できる行動がなければ前もって調査する。
「行動」実は最初はあくまで仮説です。
「この行動をしたらこういった効果があり、目標に到達するはずだ」
これが実際どうだったかを振り返りでジャッジして、結果その行動を続けるのか、他の方法を試すのかを決めます。
何のことはない、試行錯誤です。
色んな原因があります。むしろ失敗のほうが多いですね。
特に広大な未踏ゾーンから短時間で目標に達しようとするほど、結果は確率的になります（要は運）
1万人の努力家の中で1人が達成したとして、それはその1人が優れていたのか、運だったのかは実際のところ分からない事が多いです。
一番手っ取り早いのは模倣です。
しかし模倣した時点で、模倣対象が確信を持ってその行動をしているかどうかはわかりませんし、その行動が自分に効果あるかどうかはわかりません。
例えば教科書を読んで理解できる人もいれば、理解できない人も居ます。「教科書を読む」という行動を模倣しても、自分が理解できない場合は別の手を探さなければなりません。
なので、世の中に対して模倣できそうな対象はたくさん見つけなければならないし、そのために日々観察が必要になります。
その行動を1回実行するのに5年かかるとしたら、それが成功するかは極めて運次第になります。
その運要素を下げるには、その行動を既に行った人を探して観察・ヒアリングする方法があります。
先輩の話を聞くとかがそれに当たりますね。
ある行動仮説を実行した際に、どのくらい良い効果があるかの平均を才能と呼べると思います。
才能のある奴というのは、どの行動を選択しても一定の成果を上げてしまうし、才能のない奴というのは、どの行動を選択しても効果が上がらないため、目標達成難易度に非常に差が出ます。
これらを上手くやるのは所謂「努力の天才」で、領域によってはそちらの方が重要なものもあります。
まあ今度は「努力の天才に勝てない」で苦しむんですけどね。
戦ったら負けそうなシーンで逃げるという選択肢が有りなら、目標設定は非常に重要です。
自分ができない程度の目標を掲げてしまうと、如何に天才だろうが失敗してしまいます。失敗は非常に多くのリソースを無駄にします。
才能に自信がないなら、自分ができることを着実にやったほうが結果的に多くの目標を達成できると思います。
では目標設定はどのようにうまくやるかと言えば、
からある程度見積もれるはずです。
なので「自分がどのくらい精度良く努力できるのか」というメタ的な認識は非常に重要で、これは才能を使わずに何度目標達成してきたかに依存します。レベルアップするわけです。
結果的に「やらない」選択が増えて「チャレンジしないおっさん」になるリスクもありますけどね。
思ったほどまとまりが悪い文章になってしまいました。
そのうち書き直したいです。
ちなみに前回の話と結構似ています。
ここらへんが似てる気がしますね。
所謂プログラミング的思考がそれだと思うんですが。
