（日記）新しい(？)技術に日々圧殺されそう

※駄文

そろそろ枯れてくるだろうと思ったら定期的に刷新されてきている気がするサーバレス

Amazon一強かと思ったら台頭してくるGoogle

じゃあもう完全にサーバレスでいいかと思ったら無視できなくなってきたDocker

徐々に嫌な予感がしてくるスマートスピーカー

いや、その前にサービス開発と会社経営を勉強しないとですね・・・あとRailsと

と、しょぼしょぼエンジニアには日々恐ろしさを感じる毎日ですが、とりあえずGoogleCloudの方に一旦舵を切ろうかと思っています。

ここらへんはスーパーエンジニアの弁を聞いても宗教論の話が多いので凡人には何が正しいか判断できないのですが、分かるものとしては

・Firebaseは恐らく避けて通れなくなるだろう
・Firebaseと仲がいいのはGoogleCloudだろう
・AWSの破滅的なドキュメントの分かりにくさより、GoogleClouldのドキュメントの方が遥かに分かりやすい

こんなところですね

幸い私はAWSにすら未だに疎いので😥GCとAWSの連携に悩むこともそうないでしょう（悩むよりGC側で解決する）

あと残る懸念は、サーバレスで作って軌道に乗ってきたから拡大しようとしてサーバサイドに強い人間を探すもサーバレスに強い人があまり居なくて詰むパターンですが・・・その時考えます

iOS界隈は当分貯金がある気がします。仕事でやってますし。
幸い（？）未だハイブリッド系は触らなくて良いような気がします。未だそれほど良くないみたいなので（ReactNative,Cordova,Xamarinあたり）
Androidに手を出せるリソースはありませんが、Androidより先にPWAな気がします。
そしてPWAに手を出すならサーバレスに手を出すべきです。

あー、何ですかね、こんなに戦略的に動きたくないです（白目）
しかもここらへんは中々ジャストで同じ悩みを持ってる人が見つからないので独りで悩むしかないですね。

機能・画面は一貫性を保とう

ココらへんの話ってどのくらい認知されてるんでしょうか？

機能や画面というのは、どういうルートで入ってきても一貫性を持った結果が出せるととても良い状態です。

文脈依存性がないとも言えます。

文脈依存はなぜ良くないか

別に良くないというほどじゃないんですが、上図を見ると分かる通り、この機能は実質２機能です。
内部で何割かは共通化されているでしょうが、２機能です。
２機能だと、１機能に比べて色々大変です（ざっくりｗ）

文脈は、状態数を爆発させる

２機能、というと違和感があるかもしれません。
１機能２状態でもいいです。

そして文脈は状態数を爆発させます。
この時はこういう状態で、あのときはこういう状態、と増やしていくと、文脈と文脈は掛け算されていつの間にか数十状態ということもありえます。

そうするともはや仕様がおもすぎて何もできなくなります。バグも多いですしテストも多いです。コードもスパゲティになります（仕様がスパゲティなんです）

仕様を決める際には、慎重に状態数を減らさなければなりません。

補足

一貫性というのはあくまでルールです。出力が１つじゃないといけないというわけではありません。

また、クラス、関数、機能、画面内で無用な分岐を減らしていくことで、状態数爆発にすぐ気づくことができるようになります。
安易な共通化は本当に悪としか思えません。

一方で、文脈に応じて柔軟な出力を出せるとユーザーフレンドリーでもあります。ただ、仕様上の状態数をあまり増やさずに、多種多様な出力に見せることは可能です。そこに頭を捻る必要があります。ちょっとした追加機能で状態数を増やすのは避けるべきです。

IT業界の見積もりの特殊性、外れて当たり前な事情

プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!

これ読んでてふと思い出したんですが、IT業界（特にWeb系）特有の見積もり事情というのがあります。

未経験技術に挑むことが多い

プログラミングの特殊性ではなく、IT業界のスピード由来の特殊性です。
言及先ブログでは「製造ではなく設計なのだ」と言っていますが、設計ですらなく調査から始まるケースが多いと思います。

他社もやってるし、たぶん実現可能だからスタートしよう、さあ見積もって。

みたいな、よくよく考えたら狂ってるとしか思えない状況が結構発生するのです。

どこをどうすれば実現できるのか、どうやるのが正しいのかも、フワフワしたままゴーサインが出ます。

どうしてフワフワしながらスタートするのか

普通なら完全に調べてから始めるのが当たり前ですが、ITの常識が変わる速度や、新機能が出る速度が速すぎて、作ってるうちにどんどん刷新されていくわけです。

なのでマゴマゴしていたら、調べているうちにレガシーになってしまいます。ある程度あたりを付けて特攻するのは致し方ない気がします（※IT内でも信頼性が重要になってくる界隈では少しだけ話が変わりますが）

調査フェーズ、設計フェーズ、製造フェーズ 

調査・分析フェーズというのは、「さあ作るぞ」というところより前の状態で、不確実性が高いです。（不確実性コーン - Google 検索 の左側）

IT特にWeb系ではこの調査フェーズを内在したままプロジェクトが走るので、それはもう不確実です。
コンサル業務や要件定義業務に近いでしょう。

コンサル業務は不確実性をどうコントロールしているか

受託会社で働いたことがある人は覚えがあるかもしれませんが、受託開発でも開発業務とコンサル・要件定義業務で契約を分けていることがあります。

不確実性が高い方は、一括請負ではなく時間払いのケースが多いのではないでしょうか。例えば１人張り付きで１ヶ月100万円など。成果物ではなく労働力の提供ですね。
これによって見積もりが外れてもお互いに損をしない仕組みができています。

そう考えると、IT特にWeb系で、不確実性が高い案件をやるときはやはり張り付き月幾らで契約した方が理に適っているのかもしれません。

って、そういえばソニックガーデンってそういう会社でしたね。

まあただの再確認でした。

個人サービス開発に必要なもの

一にアイディア、二に根性、三四が根性、五に根性

こんなスマートじゃないこと言いたくないんですが

金とチームというリソースがない（少ない）週末起業家はこんな感じになりそうです

どおりで成功者を見かけないわけだ

しんどい

でも一番はアイディアだと思います

なぜなら膨大な時間を掛けている内に何度も何度も迷うからです

アイディアに疑いを持ったらそこで詰みます（自分の気力が）

こんなことやっても意味ない！と絶対投げ出します

アイディアの良し悪しっていうより自分の納得感ですね

プロダクトって妙に高尚なものが多いイメージがありますが

それもそのはず、高尚じゃないとやってられないんですよね

そのアイディアを信じられる人がチームに１人居れば強いです、２人居ればかなり強いです

私も相方も本業がかなり忙しいので何度も停滞があったのですが、少し手が空いた時に前にすすめるかどうかはやっぱ自信があるかどうかなのかもしれません

まあそんな自信を持ってリリースしたものが全然流行らないという第二の関門が待ち受けているんですが

私はそれを体験済みなのでそこでは折れないと思っています

２年は鳴かず飛ばずの覚悟で挑みますｗ

（iOS）Wikipediaアプリのソースコード

MITライセンスなんですねこれ

GitHub - wikimedia/wikipedia-ios: The official Wikipedia iOS app.

WikipediaをWebViewで表示しようとして参考にしようと落としたんですが割りと難解でしたｗ　かろうじて読める程度

シンプルなように見えて結構エグいですね

でも一般的に出回ってるアプリで中を見れるのは貴重かも

設計周りで参考になるかもしれません。

（日記）疲労

疲労がヤバイです

PCしてる体を支えられない

休憩しながらコーディングできないてますかね？

頭も働かないんですが

受託新規開発と、内製継続開発の体制の差

観測数が少ないんですが、私の見た限りこういうのが多かった。というものと、その課題について。少し考えたこと。

受託・新規開発

だいたいこんなだと思います。

受託・新規開発で社会人デビューしたので、こちらが一般的だと信じ込んでいました。

PM、あるいはPMとディレクターがPO（プロダクトオーナー、つまりお客さん）との間に入って調整してくれます。

内製・継続開発

内製・継続開発的な会社に入った時、下図のような感じで割りと面食らいました。

案件はチケット単位で走ります。1チケットは軽いものだと1日で、重いものだと2ヶ月くらいです。
重くても新規開発の1プロジェクトの大きさには満たないので、エンジニアが割りと全面に出ることを求められます。
結果的に「エンジニア＝ディレクター＋PG」的な動きとなります。

PO側も非常に奇妙に感じました。お客さんに相当する人は部門であることが多いです。例えばQA、企画、広報、法務部など。いろんなところからいろんな要望が出て、それに対応するのがメイン業務となります（6割位？）

もちろんサービス自体の改善もあります。それが残りの業務です。

この体制の問題点

図を見ればわかると思いますが、情報の導線がカオスです。
これがどういう問題の顕在化に繋がるかというと。

• 全体を把握しづらい、戦略的に動きづらい
• 一貫した方針でプロダクトを作りづらくなる
• 質の担保がエンジニアの感覚値になる
• 無限に仕事が発生する
• 無限に複雑度が上がる
• エンジニア負担が大きい
• ディレクションまでできるエンジニアが必要
• 誰の認識している仕様が正しいのか迷子に成りがち

もっとある気がしますが、こんな感じでしょうか。

「よくわからない」状態になります。

もっと良い体制はないものか？

プログラムの設計に似ています。
誰に何を担わせるのか、どことどこを分けるのか。

まだ考え中ですが、こんな体制だとどうでしょう。

結局一般的なスクラム体制なんですが。やはりPMとSMをどう設計するか次第で良し悪しが決まりそうです。
正直物量を考えると、この中間層が2人でいいか自体疑問です。
3、4人はほしくないですか？

数値を計測する人、情報の流れを管理する人も欲しいです。

またそのうち書きます。