2020年の振り返りと2021年に向けて

2020年も終わるので毎年している振り返りをしたいと思う。

2020年の生活について

フリーランスでの常駐先は今年の2月からコロナの影響で在宅ワークに切り替わった。当初は1~2ヶ月ぐらいの処置だと思っていたが、現在も継続している。
もともと在宅で仕事が出来るように整えていたので、スムーズに移行できたが今年目標としていたもっと交友関係を増やすのはこの時点で難しくなった。

しかし、通勤が無くなったことで時間と体力の消費が少なくなったので常駐以外での活動時間は増やすことが出来た。この活動についてはまた下の方でで書く。

iOSの仕事について

まず個人アプリをリリースすることが出来たので、理解の浅かった証明書及びアプリ申請についての経験を積むことが出来たのは収穫だった。今思えばiOS13以上にしてSwiftUIで構築すれば良かったのかもと思うこともないが、色々とハマりそうだったのでやはり良かったと思う。

常駐先の仕事でも引き続きiOSアプリの開発をしている。そこでは音声通話やまだリリースしていないがリアルタイム系の処理を使った実装をした。こういうスマートフォンのハードウェアを使った開発はWebと違っているので楽しかった。また、Reactive Swiftの導入、テスト分割、ドメイン層での新しいアーキテクチャの導入をした。最初はあまり自分の意見を入れるよりも堅実に開発していたが、今年からは積極的に提案をするようにした。

改めてWebからiOSに鞍替えして良かったなと思える内容だった。 また週5でフルに働いた年なので意外といけるなと実感した。

個人的な活動

実は8月から友人を誘って2人でサービスを作っている。今年の後半はこの作業しかしていない。きっかけはテスト管理ツールを作った時に一人でサービスを続けていくのは難しいと実感し、また今年の前半にこれまでフリーランスでの活動を思い返していたところ、人を巻き込んだことをしていないなあと思ったことだ。
もちろん、一人でやった方が気楽だったり、相手より作業量が多いことで悶々とすることもない。ただ、それは結局自分で全部やった方が早いということと同じなので、いつまで立っても仕事のやり方が変わらないのでスケールしないし、より難しい目標を超えるには誰かと組むしかないだろう。

で、改めてサービス内容を一言でいうなら、「toB向けの情報共有の動画化」を目指す内容。例えば、社内ドキュメントを作成する時に今は文章で作成しているが、映像・音声で置き換えられないのかということ。

例えば社内ドキュメントを作成する時に注意しないといけないのは、誰に向けて、どのような構成で伝えてるのか、ドキュメントのレイアウトはどうするのかなどなど実は色々と考えることが多い。というか社内ドキュメントをきっちり書ける人というのは想像以上に少ない。その中で録画して共有してしまったほうが作成者にも視聴者にも良いケースは沢山あるかなと思っている。
ただ、これ以上書くと今回の記事の内容から脱線するのでまた改めてリリースした時にもっと詳細に書こうと思う。

技術力の向上について

あんまり技術力の向上については自分の中で優先順位がもうあまり高くはない。ただ、毎年書いているので少しだけ書いておく。

先ほどのサービスではサーバーサイドはKotlin・Spring Bootの構成で、フロントはTypeScript・Reactの構成で書いている。フロントに関してはあんまり言及することのない鉄板構成だからサーバーサイドだけ選択した理由を書いていく。

言語として最終的に迷ったのは、Elixir・Scala・Kotlinである。

実装スピードとしてはElixirが一番経験もあるし速いのだが、今回は環境をGCPに決めていたい。そうなると、GCPではJava・Node.js・PythonC#PHPRuby・GoのSDKが公式で提供されているので、この時点でElixirは不利であるため除外した(SDKを使わなくても実装できるが、それならGCPを選択する意味が無くなる)

この時点でJVMの環境で動かせるScalaとKotlinが残った。
気持ち的にはScalaの方がやりたかったが、Kotlinの成長性とScalaと比較しての学習コストの低さを考えるとKotlinの方がいいかなとなった。

また言語選定と同じくらいフレームワークの選定は重要になる。Kotlinにはデファクトスタンダードフレームワークが無いのでJavaで書かれたSpring BootとKotlinで書かれたKtorが候補に上がった。ただし、KtorはKotlin純正のフレームワークだがマイクロフレームワークに属するので今回の選定には少し力不足に感じたので、情報量も多いSpring Bootに決定した。
Spring Bootで開発してそこまで不満は現状ないが、そもそもKotlin純正のフレームワークではないのでJavaのコードに接することが非常に多いので、Spring BootならJavaでも良くないと思わなくもない(Kotlinの方が簡潔に書けるケースが多いので別に駄目ではないが)。 Spring Bootで良かった点は強力なDIの機能。さすが本家であるので、今まで使ってきたDIとはレベルが違う。

あと少し脱線するとなぜRubyを選ばなかったのかについても書いておきたい。もともと静的言語の中で決めようと考えていたので、Rubyはわりと早い段階で消えた。
ただ、そうでなくてもRubyは選ばなかったのかなと思う。理由として、Rubyを選択するとまあ必然的にRailsフレームワークを選定することになる。ただ、これから新規にサービスをしたい人がRailsを選択するのは個人的には微妙だと感じている(個人開発は除く)。
色々な企業をフリーランスで経験して実感したのはRailsを選択するとかなり人員の採用面で大変になるということだ。Railsを使用している企業はスタートアップ・大手含めてかなり多い。その中で新規サービスをRailsを選択してしまうとそれらの企業との技術面での差別化が難しくなり、残るのは知名度と待遇差だけである。そうなると新規サービスの企業はかなり厳しい。

ただ、Ruby3に並行・並列について機能が追加されたのでいつか機が熟したら触ってみたい気もしている。

2021年の目標

直近は今作っているサービスをβ版リリースまで持っていくこと。その上で改良して来年中に正式版リリースまで持っていけたらいいなと思う。 ただ、サービスをリリースすることではなくて、ビジネスとして落とし込むことが重要なのでそこにつけては目処を何かしら付けたいと考えている。 また、iOSについてもコンサル的な役割で参加して欲しいという依頼も来ているのでひょとしたら並行して働くのかもしれない。

まとめ

今年の前半戦はあまり良くなかったが振り返ってみると、フリーランスなって一番変化があった年になった。
久しぶり共同で何かを作ることになったのは楽しい面もあり、大変な面もあるというのが率直な感想である。とはいえ自分以外に誰かに相談できるというのはプラスに働いているので、今後このサービスがどうなろうとも続けていきたいと考えている。

おわり

ルーター(IPv6対応)を変えたらスプラトゥーンが出来なくなった話

久しぶり超ハマったので解決方法を残しておく。

新卒の時に購入したルーターもそろそろ新しいWifi6の規格に対応したルーターにするべく以下のルーターを購入した。

www.amazon.co.jp

説明書を見ながら設定してみると、すぐにインターネット接続まで楽勝で終わった。スピードもPCからWifi接続して計測してみると以前よりも5~6倍速くなっていたので非常に満足していたのだが、Switchのソフトであるスプラトゥーン2をやってみるとオンライン対戦がマッチしなくなった。

エラーコードから判断してみたところ、「NAT超え(エラーコード「2618-0516」)」が出来ないためマッチしないというのが原因らしい。接続テストしてみたところNATタイプはCだった。

ここから少し専門用語が入るが今までIPv4での接続をしていたのだが、新しいルーターになったところIPv6(厳密にはIPv4 over IPv6)で接続になっていたため対応していないスプラトゥーンではオンライン対戦が出来なくなってしまのだ。ただ、他の記事では接続できたもあったので断定は出来ないが、とにかくスプラトゥーン側で推奨環境ではないというのは確かだと思う。

速度はIPv6によって速くなったのだが、IPv4前提としたスプラトゥーンが出来ない、、これは困ったという状況になった。

以下では自分が行った対応方法を書いていく。

解決方法

まずプロバイダによってIPv4IPv6が共存して通信できることを確認した。自分はNTTコムのOCN 光を契約しているため共存することは可能というのが分かった。

その上で家のネットワーク環境を考えるようにした。

まず新しく購入したルーターがAutoで設定していたのをマニュアルで設定できるようにした。この設定によりルーターに対して柔軟な設定が可能になった。

その次にPPPoEパススルー設定をONにした。この設定によりPPPoEで接続できるルーターやPCをこのルーターを通して接続できるようにした。

最後に以前のルーターと新しいルーターにLANケーブルを接続して、Switchからは古いルーターに接続するようにしたらオンラインマッチが出来るようになった。

手順をまとめると、

  1. 新しいルーターの設定をマニュアルで設定できるようにする
  2. 新しいルーターのPPPoEパススルー設定をONにする
  3. 古いルーターと新しいルーターをLAN接続してSwitchは古いルーターWifiに接続してゲームをする(Switch自身はPPPoE接続出来ないためルーターを介する必要があるので。接続したい端末自体がPPPoE接続出来るのであれば古いルーターは必要ないと思う)

この価格.comのやり方を参考にした

価格.com - 『ニンテンドースイッチでNAT越えしたい。』 バッファロー AirStation WSR-5400AX6-MB [マットブラック] のクチコミ掲示板

また考え方自体はPS4での接続のやり方だがこのサイトの説明が分かりやすかった

IPv6(v6プラス、IPv6オプション)でPPPoEパススルーを使用して、プレステ4のオンラインゲームを動かす設定方法(バッファロー) – 栗太郎ブログ(WiFiルーター、中継機 : 設定方法&つながらない対策)

他にもONU(モデム)からスイッチハブを使ってIPv4対応ルーターIPv6ルーターを並列させて接続させるやり方もあるらしがよく分からないので実行しなかった。ただ、この場合どちらかのルーターが死んでももう片方は残るのでネットワークの構成としてはこちらの方がいいと思った(家庭用であればそこまでする必要もないと思うが)

まとめ

6時間ぐらいかかったしネットワークの知識(IPv4, IPv6なにそれレベル)が全くない人がこれを解決するのは大変だなと思う。Buffaloにも問い合わせたが任天堂に確認しろという返答で何も役に立たなかった。 製品自体には問題ないのだからもっとサポートページを充実させてSwitch製品の連携の仕方とか事例をまとめてもいいのではと思う。
今回自分もわざわざ記事を書いたのはせっかく新しいルーターを購入してゲームをしようと思った人が出来なくなるのは避けたいなと思って書いた。

ソフトウェアエンジニアのキャリア

以前、常駐先の人からキャリアプランについてどう考えているか聞かれた。
正直、キャリアについてここ最近考えたことがなかったのであんまり上手く答えられなかった。そもそも心境としてはキャリアについて考えること自体があまり意味がないように感じているのも理由だ。

フリーランスとして変わったことの一つにキャリアについての考え方だと思う。自分のイメージとしてキャリアプランとは企業に属してその中で役割をどう変化させていくかの計画である。そのため個人事業主としてどう仕事内容を変化させていくかについては考えても、キャリアについては特定の企業に属していないので考えてないというのが答えになる。

もう一つキャリア戦略など難しいことを考えるのではなく、支出に対して収入が上回る計画をに立てるということだ。分かりやすく言うと需要に対して適切なサービスを提供し適切な報酬を貰えればいいわけである。 キャリアはその手段の内の企業に属することを前提にしているので、キャリアを重要視する時点で他の投資や事業の選択肢を狭めている。
現在は自分は主に開発者として収益があるが、これが将来的に不動産売買やメルカリ転売に変化しても良いわけである。確かに世の中の需要に合わせるだけの働き方が後で人生を振り返った時に正解だったのかと言われれば微妙だが、キャリアプランを考え実行することに違和感を感じる。

キャリアの多様性

もう一つ理由として、そもそもソフトウェアエンジニアのキャリアにそこまで選択肢が無い(ほとんどの職種にも該当する)。最近は企業内でプログラムずっと書いていく専門の道も出来てきてはいるが、なかなか茨の道に見える。プログラムを書いて自分も8年のキャリアになるがこれ以上純粋なプログラミングの技量を高めるというのは難しいなと。つまりプログラミングで生きの良い若手とプログラミングのみで差別化するのは現実問題かなり難しい。そのため、マネジメントの仕事で若手との差別化を図る人が多い。またマネジメントというのは企業内スキルの傾向が強く今度は転職する時にあまり強みを発揮しない。さらにマネジメントは技術と違って絶えず進化していないので恐らく3年やればスキルとしては頭打ちになるだろう。

むしろ3年もやって頭打ちにならないのであればマネジメントの仕事に向いてないのではないのだろうか?

もし技術の経験で差別化するのであれば専門知識が必要でそこまで人気のないOSやコンパイラの低レイヤーの仕事があるが日本にいる限りその仕事を得るチャンスをそう多くは無い。

さらに50代のエンジニアがいたとしてどういう仕事内容が理想かと言うと、あるプロジェクトの最終責任者になる、取引先を持っていて自分の食い扶持のみならず若手の仕事を作れるというのが考えられる。もはやそれはエンジニアなのかという疑問もあるが、経営者から見れば人件費が高い50代の役割としてはプログラミングだけする技術者よりもそちらを優先したい。ただ、そういう役割の人が企業内で少子化のこの時代に多くいる必要は無い。 また、多くの取引先をもって仕事を作れるというのはフリーランスの営業と変わらないので、そう考えると結局企業に属するメリットがあまりない。

手を動かすエンジニアとして現役を続けたいのであれば例えばVR・ARエンジニアや機械学習エンジニアなどの時代によって必要になる新しいエンジニア職にコンバートしていくのが確実である。 しかし、企業内においては若手に優先してそういう新しい仕事が割り振られるので、それなら自分でリスクを取れるフリーランスの方が良いと感じる。

まとめに入るが結局キャリアにそこまで多様性はないのであれば、キャリアを重視するのではなく商売のセンスを上げていく方が個人の働き方として多様性があるのではないのだろうか。とくにリモートワークの比重は増えることはあっても減ることはないだろう。それならばキャリアを重視するという考え方自体も改めて考える必要はある。

ページ量産はSEOとして無駄だった話

サービスを運営していると、どうSEOの対策すれば上位に上げることができるのか色々と悩むことがある。

その中で興味深い記事を見つけた
www.suzukikenichi.com

読んでみた感想はやっぱり機械的に量産したページは意味なかったのだと思い出した

機械的に量産したページとは

いわゆる検索軸のかけ合わせによるページの量産のことだ。

例えば「新宿」× 「居酒屋」× 「個室」みたいな複数の条件を組み合わせてページを量産するやり方である。一つ一つのページを作成するのはとても大変であるので、このような組み合わせを使って沢山のページを作成するのだ。こうすることによってページをGoogleにindexをさせて、ロングテールでの検索を増やす。また同時に内部リンクを増やすことで相対的に重要キーワードのページを押し上げるやり方である。

ただ、これには以下のデメリットがあった

  • 実際のユーザーが訪れたとしても直帰率が非常に高い
  • 機械的にページを量産するので実は検索結果0件のページを作成されてしまう
  • 意外と保守コストが高い
  • エンジニアのやる気が下がる

上にあげたデメリットがあったとしても、メリットがあればいいのだがこの施策をやってSEOとして良い結果になったことはない。恐らくこの手法が通じたのは10年ぐらい前なので、もうとっくにGoogleには対策済みである。
今でもこの手法が通じるのはよっぽど新しい分野ぐらいだと思うが、そもそも新しい分野であればそこまでSEOに力を入れる必要はないのでやっぱり意味ない。

この手法の良いところは目に見えてindexやページ数が増えるので、なんだか仕事をやった感があるくらい。

独自性のあるコンテンツ

以前書いた記事にも書いてあったが、独自性のあるコンテンツ(手間ひまかけた)が結局長期的に左右すると自分は考えている。

6年間SEO対策に携わってみて - cassette

また自分が感覚で実感していたことを以下のレポートでも報告がなされている。

B2Bサイトにおけるコンテンツマーケティングのあるべき姿についての提言|WACUL TECHNOLOGY & MARKETING LAB | 株式会社WACUL

そもそもSEO対策をして半年間で検索順位をぶち上げること自体が無謀である。独自性のあるコンテンツを継続的に出してSEOにも反映していくには最低でも1年くらい期間が必要であるため、あまり余裕がないサービスでは費用対効果が悪いなと思う。

まとめ

素晴らしい価値・機能さえあればいいとはさすがに思ってはいないが、SEOに力を入れすぎてユーザーへの還元を疎かにしてしまったサービスは多い。しかもSEOや広告にお金をつっこまないとサービスが成り立たなくなるようであるなら、もはやサービスとしては賞味期限が切れてしまったと感じる。なまじそういうサービスは下り坂ではあるが企業の中での売上の貢献度は高いためエース級の人材を投入してしまう。

ただ、エース級の人材といえども賞味期限が切れてしまったサービスを立て直すのかなり難しいと思うし、その中で人材が摩耗して転職してしまったことを何度も見てきた。

最後はSEOと関係のない話だがそんなことを思い出した。

個人開発での収益化について

個人開発したサービスで何かしら収益化して生活したいと考えている人は多いですよね。そんな時に2020年の今自分が考える収益化について書いていきます。

結論からいうと、サービスを大きくしてから収益化について考えるというのは難しいのかなと。
何で難しいのかについて言うと、課題の解決と実際にユーザーが負担して払うことは全然違う問題だから。

例えば、自分は2ちゃんねるのまとめを読むことがあるが、あれがいくら有料課金になったとしてもお金を払わないと思う。反対に自分はIntelliJ IDEAというIDEに課金している。その違いについて考えてみると、IDEに投資することで仕事の生産性が上がるが、2ちゃんねるのまとめはただの暇つぶしだから。

2ちゃんねるのまとめが無くなってもすごく困らないが、IDEは無くなるとすごく困る。だから、課題の解決だとしても何の問題を解決するかで実際にお金を払うかどうかが決まる要素は大きい。

ユーザーを集めてから収益化を考える

もともとこの考え自体はFacebookTwitterなどのサービスからこの考え方が来ていると思う。 日本で言うとLINEやアメブロが思いつく。共通しているのはそれぞれプラットフォーマーの立ち位置で膨大なユーザーを抱えて成功している。

つまり、ユーザーを集めてから収益化というのは膨大なユーザーを集める必要性があるので、個人開発のサービスで集めるのは厳しい。というよりも個人ではなく企業だとしてもこのビジネスで成功するのはかなり難しい部類に入ると思う。もちろん、特定ジャンルに絞ればまだ大丈夫なのかもしれないが、どちらにせよ広告などの手段で稼ぐのは難しい。

個人開発での収益化

そこでどうすればいいのかというのを考えると、自分ならお金を払っても使用するサービスを作るのが良いと思う。

すごく普通だけどサービスのクオリティをどこまで磨くのかを決める時はこの基準が良いと考えている。企画段階でも課金する前提でアイディアを考えてしまった方が最終的に楽だと思う。

もちろん自分ならお金を払っても使用するサービスのクオリティはすごく高い基準だ。デザイン・機能の両方を満たすのを考えると個人のレベルではかなり難しかったりする。他にもマーケティングもやらないといけない。

結局、課金までを想定したサービスを考えると自分1人では難しく、チームを組んで取り組んだ方が良いのではと今では考えている。収益で言えば受託でやった方が明らかに効率は良いので。

ということで自分は受託事業を誰かと組むのは微妙だけど、そういったサービスを作るのは今後誰かと組んだりしたいなということでした。

お金が貯まる予算管理アプリを作りました

クイック予算というアプリをリリースした

apps.apple.com

必要な予算を最初に設定してその中で支出を管理していくアプリになっている。アプリとしての特長はお金を貯めるというのを意識して作った。

既存のマネーフォワードやZaimなどのアプリは銀行口座と連携していくら使ったのかを把握することに強いが、どうしても支出を確認して終わりになってしまいがち。

その点クイック予算では初めから使える額を設定した後に支出を登録していくので、厳しい金額を設定しておけば無駄な出費を抑えることができる。

このアプリを作ったきっかけ

実はアイディア自体は嫁さんがきっかけです。月ごとの期間ではなく自分で期間を設定したい、最初に予算を設定したいという要望があった。
当初、自分は貯金に関しては得意ではないのであらかじめ予算を設定するという考え方にいまいちピンとこなかった。ただ、最近結婚式を通して共同でお金の管理をすることが多かったのでアプリで他人と予算を管理することが出来たら便利そうだなと感じてはいた。

また今後不況になる予測を去年の段階からしていたので(コロナの出現は想定外)、お金の管理は今後より重要になりそうだなと同時に考えてはいた。

そういうことが重なってアプリの開発がスタートが始まった。

開発について

実はQiitaの方で記事を書いているので興味があれば見てね
【個人開発】個人の予算を管理するiOSアプリを作った - Qiita

補足するとバックエンドは流行りのFirestoreを一部使っている。RDBと違って癖はあるが簡単にバックエンドが構築出来て楽だなと実感した。

今後について

有機能があったらいいなと言いつつまだその機能を実装していないので、その機能を作ることが目下の目標。
この機能があれば家庭の支出を互いに管理することが出来て便利になるかなと考えている。

ただ、全然ダウンロードされていないのでこの記事を読んでいいなと思ったらダウンロードしてくれると嬉しい。

業務知識と技術

エンジニアは技術よりも業務知識の方が重要だということを昔からよく耳にした。
ただ、自分がWeb業界で長らく仕事してきてプログラミングなどよりも業務知識の方が重要だと実感したことは正直無い。もちろん、歴史があるサービスにおいてはそのサービスの仕様に詳しい方が断然有利ではあるがこれがポータブルなスキルかと言わればそうではない。では何故業務知識の方が重要だと言われるのか考えてみた。

業務知識がより重要なのはSIer業界だろう。例えば、金融システムの構築などは各社それぞれ微妙に業務内容が異なっているが法律でクリアにしなければいけないシステムの箇所は基本同じである。また、バッチ処理などの大変さも各社によって規模の違いはあれ同じである。
つまり同じ業界に対して同じようなシステムを作るのであれば業務知識は非常に貢献する。

反対にWeb業界やスタートアップのサービスは基本的にはニッチなサービスを作るので、そこで得た業務知識を他社に展開するのは非常に難しい。出来るとしたらマーケティングやデータ分析では業務知識を横展開できるのかもしれないが、業務知識は難しい。そのため、Web業界やスタートアップのエンジニアは最新技術の取得によって差別化するのでオーバーエンジニアリングをしがちである。

業務知識と技術の違いは

こう考えると業務知識は経験であり、技術は専門性である。経験は運にも左右されるため誰でも身につけられるものではない。反対に専門性を身につけるのはポジショニングの問題でもあるので全員に比較的チャンスがある。経験を活かせれば大きなホームランを打てるが時代遅れになったり、むしろ経験に縛られて動けなくなるリスクもある。反対に技術は内野安打ぐらいのレベルであるが、技術は螺旋階段のようになっているのでこれはと思った技術が例え流行らなくてもその後活かせることは結構あったりする。

業務知識と技術の両方伸ばすのは難しいし、それに両方伸ばしても中途半端な人間になってしまうのではと考えている。

経験は業務知識だけなのか

上では業務知識は経験と書いたが、あくまで経験の中にある一部でしかないと思っている。経験というのも結局あやふやなものではなく、言語化できることが重要だったりする。他にも以下のことが該当する。

  • 人数拡大におけるエンジニアの組織設計
  • エンジニアの評価基準の設計
  • 経営面から見たエンジニアリング意思決定
  • 採用強化

こう考えるとWeb業界での経験というのはCTOぐらいにならないとあんまり差別化できないのではと考えている。また、こういう知見こそ顧問としての力を発揮できると考えている。これらは一旦決めると後戻りは難しいしので、とりあえずやろうで何とかなるものでもない。