（メモ）最近作りたいアプリ・サービスリスト

最近何か多いんですよね

サクッと作りたい

仕事のちょっとした休憩中に作ってます。

・TODOアプリ

良いのがありません。
ほしいのは１人用のjiraみたいなやつです。
１割作りました（2時間）

・ダイエットアプリ

こちらも良いのがありそうでありません。
iOS標準のヘルスケアが近いんですが、運動と食べたものの記録を同時に行いたいです。
FIrestore連携さえできれば割とすっとできると思いますが、そんな時間はない（最近あまり寝てない）

作ったら上手くいく気がする

・ローカル特化型アプリ

主要駅で迷子にならないアプリが欲しい、というところから発展して考えました。
都内の超人口過密地域のみをピンポイントで狙ってアプリを作りたいです。

ただ結構頑張りが必要だと思います。予算500万はほしい。

ガチ

・コンテンツと視聴者の接点となるアプリ

Apple標準の幾つかのアプリのライバルです（iTunesやBookなど）
できれば年内上半期にリリースします。

将来やりたい

・電子コンテンツプラットフォーム

主にやりたいのは「電子グッズ」という概念を作ること。
次点で買い切り型の円盤（ブルーレイ）をDL販売できるようにしたい。
サブスクリプションへの対抗。

構想はありますが予算と信用と営業が必要なので今の自分には無理です。

多分予算3000万円は必要。

しかし年内時間が取れる気が全然しません。

睡眠時間を削るしか・・・（※既に削ってる）

（iOS）ProtocolExtension+Class-Only Protocolsをもっと使おうという話

qiita.com

書きました。
もっと広まって欲しいです。

この仕様は実際のところSwift2あたりからあったんでしたっけ？
仕様自体は自分も2年前には既に知っていたと思います。
そのパワフルさに気づいたのが1年くらい前で、検証する機会に恵まれたのが割と最近でした。
こんな良いこともっと早く気付けばよかったと少し後悔。

これを使えばInterface的な設計や、mixin的な設計や、抽象的な設計がある程度組めるので、どんどん使っていきたいです。
継承という仕様はほとんど要らない子になりました。継承が必要なシーンと言えば、あとはライフサイクル内で共通処理をしたいとかそういうパターンくらいかな？

extensionもそうですが、こういった疎結合に組める仕様が出てくると、モジュール化がプロジェクトを跨いで使えるようになるんですよね。
仕事すればするほど強くなれるようになるので、個人的には追い風です。

一つ苦言を呈するなら、何でこの仕様が初期に無かったのかが解せない。
Objective-Cの深い部分（cocoaの部分？）では出来てたはずなんですよねー。

仕事をどう決めるか、あとAIや機械学習を学ぶワナビのことを憂う話

ちょっとオッサンの毒吐き。

私は今アプリを作ってるんですが、他のことをするチャンスは何回か有りました。
例えば数年前はゲームが流行りました。明らかにゲーム業界の給料がぐんぐん伸びていっていたし、ゲーム好きな人はこぞってそっちへ行きました。
例えば大学院時代はAI領域の専攻だったのですが、修了後何年かでAIブームになりました。一応基礎は分かっていたのでAIの方に行くこともできたと思います。

でも私は行きませんでした。

私が右も左も知らない社会人一年目とかなら、喜んでいったと思いますが、残念ながらそのチャンスが来たときには既に社会人として擦れていました。

ゲーム業界が華やかなのは成功している極一部だというのはすぐ分かりましたし、成功してもとんでもないボーナスが貰えるわけではないと分かっていました。会社とは大体そういうものだし、自分が社長だとしてもそうします。

AI業界はもっと悪いです。まずビジネスがどう動いているのかが全然見えてきませんでした。バズはいくらでも起こるのにネタが見えない界隈に飛ぶこむほど子供ではありませんでした。

仕事を選択する時に分かっていたいこと

• 誰が金を自分に払うのか
• 失敗し続けても続けるだけのモチベーションはあるか
• 役割が変わってもやっていくモチベーションはあるか
• 競争に負けない自信はあるか（あまりにも人気すぎないか）

これらが重要だと思っています。

今の仕事は幸いそこら辺がわかりやすかったし、失敗しても折れない自信がありました。本当は最初はBtoBに行こうと思っていたのですが、BtoCがWebビジネスとして盛り上がってきたのは非常に幸運でした。

例えばゲームを作るとして、誰もプレイしてくれなかったら折れるんじゃないかと思います。私のゲームに対する思いはその程度です。

また、役割が変わることを想定しておいたほうが良いです。
例えばコードを書かなくなっても続けていけるのか、その業界にいる理由があるのか。これが無くなるとしたら厳しいと思います。

世の中仕事はたくさんあるけど、特徴は割と少ない

どこからお金をもらうかとか、モチベーションとか、そういう特徴は案外少ないです。

• 企業からお金をもらう
• 個人からお金をもらう
• 国からお金をもらう
• 仲介・手数料ビジネス
• 物を売る
• 価値を提供する
• 誰かに喜んでもらう
• すごいものを作って社会的なインパクトを得る
• 先進的なことをする

などなど

前に似たことを書きましたね。

otihateten.hatenablog.com

特徴というのは少ないから、すぐに自分は◯◯だとわかることができます。その仕事が自分に向いてるかどうかより、その特徴が自分に向いてるかどうかの方が簡単にわかります。
だから、まずは仕事の特徴を分解して自分に合うかどうか見たほうが良いと思うんです。

技術で選ぶとか、何となく面白そうだからで選ぶのは悪手だと思うんです。

それが言いたかっただけです。

AIや機械学習を学ぶワナビのことを憂う話

それで、AIや機械学習エンジニアってどういう仕事かな？って考えたり、募集要項を調べてみると、大体は

• 何か新しいものを作る仕事
• 機械系の何かの精度を高める仕事
• ECサイトなどのコンバージョンを上げる仕事
• 何かデータサイエンスにより分析評価をする仕事
• 大企業の業務分析をする仕事
• 上記のいずれかの受託

で、おそらく皆が想像してるのは一番上の仕事なんでしょうけど、これは花形で数も少なく、9割以上はそれ以外なんですが、
これからはAIだ機械学習だって勉強した人たちが、実務を想像できているのかと最近不安になってきました。

だって、これらのほとんどの業種はこれまでの仕事の文脈があってその中で精度向上のためにAI・機械学習があるのに、流行りに乗って勉強してる人はまず「AI・機械学習」ありきなわけです。
しかも先進的な何かを夢見てるはず・・・？

これは私も今年気づいたのですが、AI・機械学習というのは精度向上が主な強みですから、これまでのWeb・スマホ・ゲームと言う文脈の延長線上ではなく、むしろSIerやメーカー系の延長線上なのではないかと思います。

少し語弊がありますね。1を10にするとか、10を100にするではなく、10000を10100にする仕事と言いますか、つまり大規模向けという話です。

もちろん全ての仕事がそうとは言いませんんが、コンバージョンを数％上げてメリットが有るのはベンチャーより大企業の方です。

だから普通に祝活を始めたら、日本の場合は重厚長大かつ古い体質の企業に入ることになると思うんですが、これを分かっていて勉強しているんでしょうか。それならいいんですが。

もちろんお給料は今結構高めらしいですが、ブームというのは必ず揺れ戻しが起こります。
結構前に書きました。

otihateten.hatenablog.com

まあそれを言ったらプログラミングブーム何ていう事象はプログラマーにとって死活問題なんですが。

勉強するのはいいけど、その後何の仕事に就くの問題

この問題、割と蔑ろにされてますが、もうちょっと重視したほうが良いんじゃないかなあと前々から思っています。
有名所で言えば美術系や音楽系ですが。それ学ぶのは良いしけどその後どういう仕事があるか・その仕事は自分がやりたいことか理解してる？というのは押さえておきたいですね。

って言っても若い人にそんなの分かるわけないので、おっさんあたりが教えられると良いのかもしれませんが。中々上手く行かないですね。

（小ネタ）ピタゴラ装置を作らないために

ピタゴラ装置というか、ルーブ・ゴールドバーグ・マシンなんですが。

参考：

▲超厳選▼ ピタゴラ装置傑作集(Rube Goldberg Machine)コロコロからくり装置 - NAVER まとめ

ステレオタイプの発明家が作ってるような、ゴテゴテの仕組みをループゴールドバーグマシンと言います。ピタゴラスイッチもその一種です。

www4.nhk.or.jp

ピタゴラ装置は見ていて楽しいです。
しかしこれらをプログラムで作ると大変なことになります。
保守改修できません。
何がどうなってそうなってるのかわからないし、1個手を入れたら全体のバランスが崩れて動かなくなってしまいます。
端的に言えば不安定なんです。

プログラムでピタゴラ装置を作らないためには

• それがいつ呼ばれるか明確（In）
• それがどう影響するか明確（Out）
• それが何なのかが明確（What）

たぶんこれだけです。
これだけで愉快な不安定装置は、面白みのない安定装置に変化します。

ですがこれができていないコードが世の中にあまりに多くて・・・というのはまあ別の話なので辞めましょう。

ピタゴラ装置を回避しようとすると割と難しい

実際に回避しようとすると難しいことがわかります。
特にチーム開発では難しいです。
「InとOutとWhatを明確に」とは言え、それらを一度作った時は明確でも、改修していくうちに何が何だかわからなくなるかもしれません。

• チーム内で設計ルールを明確にする
• コードレビューする
• 最初に作るときに「明確にせざるを得ない縛り」を上手く組み込んでいく

みたいな苦労をしないと、気づけばピタゴラ装置ができあがってるのです。
怖いですね。

途中参加が多いフリーランスはピタゴラ装置を修正できなければならない

上記の手段、途中参加の人には使えません。
つまりフリーランスは使えないので分解できることが求められます。
たぶんフリーランスに求められるレベルって普通に仕事できるレベルより一段上にあるんですよねここらへん。そのうちそれも書きたいです。

プログラムの設計思想には、全体的なものと部分的なものがあるっていう話（その1）

前と別軸の話。

otihateten.hatenablog.com

これも来年に向けて一つのテーマにしたいです。

設計には全体に及ぶ設計（喩えるなら戦略？）と、部分に適用できる設計（喩えるなら戦術？）があります。
この2つは非常に性質のことなるものですが、なぜか世間では同じく「設計」とかそういう類の言葉で同一視されてしまいます。

全体的な設計は、支配的な設計

全体に適用できる思想というのは大体の場合たかだか１つです。
移行期に複数の設計が混ざるケースもありますが、理想的には１つです。
なのでチーム開発の場合、誰かが適当に変更して良いものでは有りません。

中間的な設計ものもある（支配度・影響度）

ある一部分に適用するだけだけど、結果的にその影響が全体に及ぶみたいな設計もあります。
私はこの尺度を「支配度」「影響度」「感染力」などと勝手に呼んでいたりします。

もちろんこれは密結合のときの方が起こりますが、疎結合にしてもなお影響度の高い設計というのは生じてしまうものです。
（例えばModelの設計を変えたら全体がガラッと変わってしまいます）

研究課題

• 支配的な設計の悪いところ
• 支配的な設計との付き合い方
• どのように支配的な設計を評価するか
• ある変更の影響度はどの程度かを分かるようにする
• 設計思想を部分に留める方法
• 支配によるチーム開発の制御法
• 引き継ぐときに必要な情報

ここらへんですね。

プログラムの設計思想には、収束型と発散型があるっていう話（その１）

毎年新しいアーキテクチャーや設計手法が生まれては消えていきます。
毎回新しい案件に入るごとに、モヤモヤする設計を目の当たりにします。

そこでどうにも2つの大きな思想の違いがあることにようやく気づき始めることができました。
おそらく優秀な層の方々は数年前か、もっと前にそこにたどり着いているはずなので、この話は今更かもしれませんが、備忘録的にまとめていきたいと思います。

まだ頭の中でとっちらかってるので、今回は基本事項だけです。

なぜ気づいたか、きっかけ

リアクティブやRxの思想、あるいはデータバインディングという新しい方法を知る中で、彼らが何をしたいのか考える中で気づきました。
プラスアルファで、そういうったものを導入した時に、却って困る事象が起きた時に、既存コードの優位性を考える中で気づきました。

と言ってもこの考え方自体そもそも古典的な感じがします。

なぜ「２種類」なのか

ぶっちゃけ私がリアクティブ周りの思想を全部把握できないから、せいぜい2種類しか観測できないっていうだけです。

リアクティブシステムが注目を集める理由 | Think IT（シンクイット）

Reactive Programming（リアクティブプログラミング）
Functional Reactive Programming（ファンクショナルリアクティブプログラミング）
Reactive Extentions（リアクティブエクステンション）
Reactive Streams（リアクティブストリーム）
React.js 

あっあっあっ（脳が壊れる音）
難しすぎる。

でもこういうパラダイムを作るときって、色んな複数の思想がゴチャ混ぜで導入されて意味不明になりがちなので、結局どんな差があるの？と限界まで削ぎ落とす分析は重要だと信じています。じゃないと私の矮小な頭では理解できません。

発散型と収束型（仮名）

収束型（コールバック型、中央集権）

これまで皆がやってきたプログラミング方法。
メインとなる処理の流れがあり、関数に処理を投げて結果を受け取る。
メインとなる処理の流れが基本的に全てを取り仕切る。

発散型（通知型、分散型、リアクティブ？）

関数に処理を投げるがコールバックは受け取らず、投げっぱなし。
反応的（何かが起きたら、別の何かが起きる）
各モジュールが自分の責任範囲について処理を取り仕切る。

喩えとか

会社に喩えると
収束型は「このタスクやっといて、終わったら報告してね」
発散型は「このタスクやっといて、終わっても報告はいらん」

（思いついたら追記します）

オブザーバーパターン、KVO、リアクティブ、マイクロサービスあたりは発散型

例えばマイクロサービスが分かりやすいです。
これは１個のモノリシックなサービスを作るんじゃなく、複数の独立したサービスに分割しようという話です。

発散型が流行りつつある

発散型に該当しているキーワードを見ると、スタイリッシュで次世代チックな感じがしないでしょうか？
実際これらは流行りつつあると思います。
理由はおそらく「非常に疎結合に作れる」故に「テストコードが書きやすい」あたりです。悪言い方をすると意識高い界隈で流行ってますね（毒吐き）。クソ真面目界隈でも良いですけど。

発散型の欠点

ただこれらには欠点もあるようで、それに気づかず安易に導入して苦しい思いをしている人やその煽りを食らっている人（私）もいるようです。
問題なのは、疎結合という部分です。

WebAPIの例が分かりやすいと思います。
一つのシステム内で完結する場合に比べ、例えば「アプリーWebAPI」のようなシステムが分断している場合では、対応しなければならないことが非常に多くなります。WebAPIはどういうリクエストが来ても内部を正しい状態にしなければなりません。

「処理を投げっぱなしにしていい」という状態を作るには

• 完全にモジュール化されていて
• どんなリクエストが来るかのパターンを網羅し
• どんなリクエストも正しく処理できる

ような状態を作らなければならないのです。

つまり、１個のモジュールとして完璧でなければなりません。
これが非常に困難かつコストが高いのが問題です。
プログラムとしては理想的かもしれませんが、プロジェクト的には理想から程遠くなるかもしれません。

対して収束型と言うのは、言ってしまえばモノリシックなコードを見やすく分割しただけに過ぎず、しばしばモジュール化が甘くなります。
ただし代わりに全てのリクエストに対応する必要はなく、仕様上存在する有限個のパターンに対応できていればシステムは動きます。
プログラム的、テストコード的には理想的ではないにしても、プロジェクト的には正解であることもあります。

今後の研究課題

最近考えてる内容です。書かないと忘れそう。

• 発散型、収束型に適したシステムはそれぞれどのようなものか
• 発散型、収束型に適したプロジェクトはそれぞれどのようなものか
• それぞれの得意分野はどこにあるか
• 発散型、収束型は混ぜることは可能か
• 発散型、収束型が適していない場合どのような自体になるか
• 発散型、収束型が適していない場合、経験的に修正に非常にコストがかかるがそれは何故か（両立はやはりできないのか？）
• 発散型、収束型の利点と欠点
• 発散型、収束型の具体的な処理の流れ
• 収束型でテストコードは書けないのか
• それぞれの理想的な設計とは
• うっかり別の思想を導入してしまいがちなシーン

少なくともモバイルアプリについては、発散型が適していないと感じています。
一部の先進的な会社は確かに発散型を導入しているのですが、元々モバイルアプリに適していないのを理解した上でそれでも余りある理由があるから導入していると思うんですが、どうも他のプロジェクトでその文脈が無視されがちなのでは？と疑っています。

本件、中途半端ですが。
来年いっぱいくらい掛けて考えていきたいと思います。

いつまで「シリコンバレーでは」をやるの？

こういうのいつまでやるんですかね？

www.nikkei.com

もちろんこういう「煽り記事」を書くとバズるのでメディアとしては有りなんでしょうけど、日経あたりがやってるとガッカリします。

「安いニッポン」というテーマは良いと思いました。世界的に円高かつ物価が高かった90年代に比べて、最近は相対的に安くなってきた。それはなぜか、またどういう影響があるか？というテーマだと思います。

上はこちら。

www.nikkei.com

そういった時に、もちろん比較としてあげるべきは「他の先進国」ですし、もしくは「人材流出がどのくらい進んでいるか」という話でしょう。
決して「世界最高峰の地域ではこんだけ高い給料が出ていて1400万円なんて低所得者だ」という話では有りません。そういうのは週刊誌とかネットの隅でやる話です。

シリコンバレーITや中国ITは特殊となった

経緯を書くと長くなりそうですが、御存知の通りこの2地域は特殊な状態です。
アメリカや中国国内から見ても特殊です。
果たして日本や他国のIT業界と比べられるのかは慎重にならなければなりません。

もちろん比較対象としては不適切です。

「特殊地域とどう戦うか」というテーマなら有り

例えば日本国内において「地方はどう東京と戦うか」という話があると思います。
それと同じような話はできるはずですが、もちろんその話をするなら実際にどのくらい流入出があるのか、生活費や税制面でどういう差があるのか、働き口はどのくらいあるのかなど、多角的に分析するのが普通でしょう。

決して「都内で600万円は低所得〜」なんて記事にはならないはずです。

というか金額だけの比較は優秀な人をバカにしていない？

A社よりB社の方が高いからそっちに行く、というのは普通にありますが、それは他の条件が揃っている場合です。

仕事の内容、国や地域、自分がどういう雇われ型をするのか、など条件が揃って初めてお金の話になります。
「きっと優秀な人はさっさとこんな国なんて捨ててアメリカや中国に行くんだろうなあ」っていうのはどうもバカにしてる感じがします。

実際向こうに行ってる人の経歴を見ても、よりよい仕事がしたいとか、家族の都合とかの経緯がメインで、高いからそこに行くという人はまだ見たことが有りません（中国に一瞬絡んで儲かったという話はちょいちょい見たことがありますけど）

何がしたいんでしょうね。こういうゴシップ記事って。