プログラミングの遅い速いについての話

チョッパヤのシステム構築をするのが大好きな、ユゲタです。 「遅い」よりも、「速い」方がいいと思うのは、普通の人の感覚です。 当たり前ですよね。誰でも遅いよりも速いほうがいいに決まっています。 でも、たまにアニメーションなど動画を作っている時に「早すぎる」という事を言われることもあります。 画面をゆっくりスクロールして、画面内の遷移を映し出す時に、早すぎて一瞬で移動してしまっては、むしろ次のフレームで移動した方が見た目にもいい場合もあるので、 この「早すぎる」と「適度に速い」は、人それぞれの感覚によって変わりますが、感覚的な客観視を持っておく必要はあると感じました。 今回は、とある友達の会社の膨大なシステム変更の差作業をお手伝いすることに伴って、 古いcake(PHP)フレームワークからのリプレースで、Lalavel(PHP) + React + AWSという構成でのサービスを構築するということで、どれも以前に少し触りだけ学習していたこともあり、 事前に予備知識を持っておこうと、それぞれのリファレンスや、いろいろな人が書いてあるブログなどを読み漁っていた時に、 「Lalavelは、処理自体が遅い」という記述がやたらに多かったので、これから構築しようとしている中、こうした処理が遅いと言われているシステムでの構築で問題がないかどうかを伝えておく必要があると感じたのと、 そもそも、この「遅い」という事に対しての技術的見解を少しだけ考えてみたので、自分なりの考えを書いてみたいと思います。 ちなみに、Lalavelの処理を早くする方法を書いているわけではないので、一般的なITに関しての「速い・遅い」についての見解です。

ハードウェアの「速い・遅い」

MacBookにApple独自のCPUであるM1チップというのを搭載して、 「これまでと同じアプリケーションを使った時に、めちゃくちゃ早くなった！」 という声が連発していたので、ユゲタも思わず購入してしまいましたが、聞いていたとおり、自分も速度ストレスは以前よりもかなり少なくなったという印象を持ちました。 基本的に、これまでパソコンオタクとして、自分のパソコンは、自分で自作して組み立てるという事で、パソコンライフを過ごしていたんですが、 ノートパソコンはどうしても、それぞれのメーカーが駆使した、重量（軽さ）、スペックなどのクオリティ、スタイリッシュなデザイン、バッテリーの持ち時間などなど、 自作をするよりも、メーカーものの方がクオリティが高い。 でも、パソコンは、それぞれのパーツとそれらの相性によって、スピードが大きく変わるということを知っておくことが重要。 仕事で使える技術として考えれば、サーバーのハードウェアをどのようなスペックにすればいいか、どうすればより高速になるかはこうした知識と経験から生み出されるのだが、 最近のクラウドサーバーって、ハードウェアって、CPUとメモリとストレージぐらいなので、こだわったスペックには出来ず、カタログ値（しかもベストエフォート）というのが一般的になってきている気がする。 個人的には、MB（マザーボード）やら、MPUやら、ストレージのキャッシュスピードやら、GPUやら、拡張ボードの接続部の、バス規格やら・・・ こだわればこだわるほどスピードを高速にしたりできるのにね・・・ そして、スピードが早くなれば値段が高くなるのかと言うとそうではなく、そうしたコストコントロールもできてしまうのが自作の素晴らしい所。 ノートパソコンもBTOではなく、自由に自作する時代にならないかなあ・・・

システムの「速い・遅い」

システムの速い襲いは、ソフトウェアエンジニアの腕の見せ所です。 ハードウェアは関係なく、構築した、プログラミングの効率によって、スピードが雲泥に違ってきます。 最近の主流である、様々なプログラム言語における便利なフレームワークで「どのフレームワークがより高速なのか」というベンチマークを計測してくれるブロガーなどもいるようですが、 個人的には、「ネイティブが最速である」という認識は間違いないと思います。 そして、便利だと言われれば言われるほど、スピードが犠牲になっているようにも思えるので、利便性をとって、サービススピードを犠牲にするか、そうしないかは、それを構築するエンジニアの指向性によります。 ただ、フレームワークは、一度選択してしまうと、その後の変更が難しいので、非常に難しい選択であるかもしれませんが、簡単に考えると、ネイティブで独自コードで書くことを選択するか、 便利なフレームワークを使って、安易に開発を進めるかの違いかと考えられます。 ただ、安易にといっても、このフレームワークを使ってもそこそこ開発工数は掛かってしまうことを考えると、オススメは、やはりネイティブなんですけどね。

ネットワークの「速い・遅い」

なんともしがたいのが、ネットワーク速度です。 インターネット速度は、プロバイダのクオリティに左右されるし、障害発生率なども、いまや100%安心なプロバイダーは存在しません。 NT◯Docom◯など、超大手キャリアを使っているプロバイダでも、利用者数が多いため、今では、遅さのワーストランキングに入っている始末です。 かといって、ベンチャーキャリアを使うのも怖いというのもあるため、こうしたネットワークキャリア選択は、障害対応の時に、他社キャリアへ切り替えることができるという 柔軟構成が組むことができれば、障害対策としてはバッチリといってもいいでしょう。 でも、AWSなどを使っていると、そうもいかないので、AWS+安価ホスティングでの、ディザスタリカバリー用サーバー環境を用意するのがオススメです。 ※これ会社内に固定IPを引っ張っておいて、障害対応するようにしてもいいですけどね。

ユーザー・インターフェイスの「速い・遅い」

システム構築とは少し違う支店で、フロントデザインにおけるユーザーインターフェイスによる速度差は、体感値という風に考えると分かりやすいかもしれません。 お問い合わせフォームなどで、「送信ボタンが複数あって、どれを押せばいいかわからない」という用な場合は、UI速度が遅いという捉え方ができます。 UI理論は、様々なアプローチがあるため、ここでは、何が良くて何が悪いかの説明はしませんが、 ホームページにおける、お問い合わせ、購入フォームなどは、コンバージョンに直結するので、企業は研究開発費をしっかりと持っておくぐらいの指向性で取り組んだほうが経営戦略的にはオススメです。

最後に

ITにおける速度は、やはり「遅い」よりも「速い」方が良いです。 「早すぎ」て困ることはあるかもしれませんが、 「遅すぎる」事によるメリットは、何も考えられませんからね。 そして、開発速度や、自分の作業速度も、「速い」に越したことはありません。 何より、「思考の速さ」は人生の豊かさに直結するとも考えられるので、そのために脳を鍛える事は怠らないようにしたいと、このブログ記事を書きながら改めて感じてしまいました。