カテゴリー: エンジニアリング

  • 【苦手克服】Webデザイナーが選ぶコーディング知識が身につく本 6選 +α

    【苦手克服】Webデザイナーが選ぶコーディング知識が身につく本 6選 +α

    この記事では、コーディング業務をしている・していないに関わらず、コーディングに対して苦手意識や課題意識を持っているWebデザイナー・Web担当者向けに、コーディング知識がしっかり身につく本を難易度別に6冊、+αで読むと更にコーディングへの理解が深まる本を2冊ご紹介したいと思います。

    どの本を買ったら良いか迷っている方は参考にしていただけたら幸いです。

    pc alt
    pc alt

    Webデザイナーに必要なコーディング知識とは

    おすすめの本を紹介する前に、なぜWebデザイナー・Web担当者がコーディング知識を身に付けた方が良いかご説明します。

    コーディング知識が ”ない” ”ある” の差は大きい!

    まず、みなさんにお伝えしたい事は、コーディング知識が ”ない” Webデザイナーが作成したデザインカンプは、コーディング知識が ”ある” Webデザイナーが作成したデザインカンプに比べ、エンジニアがコーディングする際に必要な情報が不足していたり、レスポンシブが考慮されておらず実装不可能なデザインだったり、開発や運用の際にトラブルが起きたりと、多くの問題を引き起こすことが多々あるという点です。

    そして、それによって一番迷惑を被るのがエンジニアです。

    逆を言えば、コーディング知識の ”ある” Webデザイナーは「この配置は実装に手間がかかるな・・・」「CSSだけで実装するのは無理だな・・・」という配慮ができるのでエンジニアの負担が減り、スムーズなコーディングが可能になります。

    さらにWebデザイナーから直接エンジニアへコーディング指示をすることができるため、デザインカンプ通りにコーディングしてもらうことも可能になります。

    また、シンプルなコードでコーディング可能なデザインにすることでページ速度が向上するというメリットもあります。

    pc alt

    HTML・CSSとレスポンシブの理解は必須!

    Webデザイナー・Web担当者の方には、前述した問題を防ぐためにも、まずはコーディング・Webページの基本的な仕組みや知識を理解しておくことが必要です。

    デザインとコーディングを完全分業で制作をしている会社もありますが、作成したデザインをきちんと表現するため・制作現場でのムダを省くため・今後業界で生き残っていくためにも、しっかりとしたコーディング知識を身につけましょう。

    ただ、漠然とコーディング知識を身につけると言っても、Webに関連するコーディング言語・知識は膨大にあるため、まずは1番デザインに影響し・比較的学習しやすいHTML・CSSから勉強していきましょう。

    pc alt
    HTMLとCSSを理解するだけでも、Webデザインの考え方・見え方が大きく変わります。個人的には、インターネット関連の知識も身につけると、Webを理解する上で大きな土台になるので学ぶことをおすすめします。

    Webデザイナーがコーディングを苦手と感じる理由

    「コーディング知識が業務に与える影響力が大きいことは分かった。ただそれでも、コーディングに対して苦手意識がある、難しそう。」と思われるWebデザイナー・Web担当者は多いと思います。
    それでは、どうすればコーディングに対しての苦手を克服でき、コーディング知識を身につけ、自分のものにしていけるか、私自身の経験を元にご説明します。

    私もかつてコーディングに対して苦手意識があった

    私はWebデザイナー歴9年目になりますが、今まで2社ほどWeb制作関連の会社を経験してきました。
    どちらの会社もディレクション・デザイン・コーディングが完全分業制で、コーディングの実装指示はディレクターとエンジニア間で行っていたため、コーディング知識がなくてもデザイン業務をすることができていました。
    そのため、デザインカンプを作成したら、あとはディレクター・エンジニア任せで、公開完了して初めて自分の関わったWebページを見るということがザラでした。
    実際、公開されたWebページは私が作成したデザインカンプから見た目やアニメーションなど大きく違うことが多々ありました。

    しかし、コーディング知識がなくてもデザイン業務をすることができていると勘違いしていたせいで、コーディングを勉強するキッカケを逃してしまい、自分の専門外と勝手に決めつけることで、コーディングを学ぶことを避けてきました。

    その結果、コーディングに対しての苦手意識だけがどんどん膨れ上がりました。

    コーディングを学ぶ前まで、コーディングって何かの呪文のように意味不明なコードの羅列で自分にはできなさそう、難しそうって思って、今からコーディングの勉強してもなーって思っていました。

    わからない(=知らない)から苦手と感じる

    私自身、コーディングを苦手と感じていた原因は、単にコーディングに関する情報・知識不足だったことが1番の原因でした。
    また、デザインだけをしているWebデザイナーは仕事柄、ビジュアルで情報を把握する癖があるため、コーディングといったソースコードを見慣れておらず、感覚的に苦手に感じる人が多い気がします。

    HTMLとCSSはプログラミング言語の中では、特にシンプルで分かりやすい言語になっているので、正しい知識を身につけていけば、挫折することなく学ぶことができます。
    まずは、わからない(=知らない)→わかる(=知る)ところから始め、苦手意識を無くしましょう。

    まずは自分のレベルに合った教材選びから

    自分に向いていない教材や、自分のレベルより高い教材を選んでしまうと、挫折につながり、さらに苦手意識が増します。そのため、自分のレベルに合った教材を選ぶことが、苦手克服の一歩になります。

    pc alt

    本は苦手意識をなくす最適な教材

    本は、わからない(=知らない)→わかる(=知る)ための最適な教材です。
    また、良書を読むことは、コーディングの全体像をつかみ、正しい基礎知識を体系的に知り・学ぶことができる上、苦手を克服しさらにレベルアップする際の手助けになります。

    次章では、正しいコーディング知識が身につく良書を難易度別にご紹介します。
    Webデザイナーにも分かりやすいイラスト・図解が多い本をピックアップしています。

    【コーディング初心者のWebデザイナーにおすすめの本 2選】これだけ読めばコーディングの全体像がわかる!

    まずは、コーディング初心者におすすめの2冊を紹介したいと思います。
    基礎的な内容ですが、コーディングの全体像が分かり体系的に学べるので、どちらか1冊を読むことをおすすめします。

    これだけで基本がしっかり身につく HTML/CSS&Webデザイン1冊目の本

    img01.png
    pc alt
    コーディングをゼロから学びたい方は本書がおすすめ!説明の大半を図解やイラストを使って分かりやすく解説してくれるので、苦手意識が強い人はまずはこの本から読んでみよう!

    1冊ですべて身につくHTML & CSSとWebデザイン入門講座

    img02.png
    pc alt
    Web業界で働かれていて、コーディングの基礎的な内容を知っている方はコチラがおすすめです。私も一番最初にこの本で学びました。

    【コーディング中級者のWebデザイナーにおすすめの本 2選】これを読めばコーディング苦手克服までもう少し!

    では続いて、基礎的なコーディング知識が身についているWebデザイナーにおすすめの2冊を紹介したいと思います。
    必ずしも必要な知識ではありませんが、Webデザイナーが実務でも役立つ内容があり、こちらを読めばコーディング指示がとても楽になります。

    ほんの一手間で劇的に変わるHTML & CSSとWebデザイン実践講座

    img03.png
    pc alt
    上で紹介した「1冊ですべて身につくHTML & CSSとWebデザイン入門講座」を読んだあとは、こちらも一緒に読むとより一層理解出来ます。

    Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

    img04.png
    pc alt
    エンジニアの人に勧められて購入しました。CSSの設計手法の考え方を身につけるには非常に優れておりよくまとまっています。Webデザイナーには少しハードルが高いため、2・3冊目以降に読むのがおすすめです!

    【コーディング上級者のWebデザイナーにおすすめの本 2選】これを読んでコーディング知識を武器にしよう!

    コーディング知識は身についていて、大規模なWeb制作・開発の現場でデザインをしている上級者Webデザイナーにおすすめの2冊を紹介したいと思います。
    こちらは必ずしも必要な知識ではありませんが、大規模開発に必要な実装の設計方法や手順が載っている数少ない本で、難易度も高いですが、大規模なWeb制作・開発の現場でデザインをしているWebデザイナー・Web担当者の方には是非読んでいただきたい本です。

    フロントエンド専門制作会社が教える速く正確なWeb制作のための実践的メソッド

    img05.png
    pc alt
    大量ページなどの大規模プロジェクトの時はとても重宝しました。現場目線で使えるノウハウが書かれている本がほとんど無いので一読の価値があります。

    CSS設計完全ガイド ~詳細解説+実践的モジュール集

    img06.png
    pc alt
    ページ数も多く、分厚い本ですが、これがわかるようになれば怖いものなし!CSS・コンポーネント関連で困った時はコチラを読み返してます。

    【+αで読みたいWebデザイナーにおすすめの本 2選】これを読むと更にコーディングの理解が深まる!

    こちらは+αで読むと、よりコーディングの理解が深まる本を紹介します。

    これからの「標準」を学ぶ マルチデバイス対応サイト構築

    img07.png
    pc alt
    マルチデバイスについて細かく書かれている珍しい1冊。Webデザインにも活かせる内容が多く掲載されているので、読んで損は無い1冊です!

    HTMLコーダー&ウェブ担当者のためのWebページ高速化超入門

    img08.png
    pc alt
    制作をしているとWebパフォーマンスまで、なかなか気が回らないですが、Webサイトを運用していくにあたって、Webサイトの表示スピードはとても大事なので、Web担当者の方には必ず読んでいただきたい1冊です。

    最後に

    コーディングへの苦手意識を克服したことで変わったこと

    私自身、前述で紹介した本で段階を追って学習することで、コーディングに対しての苦手意識を克服していきました。一つ一つ学んで行くことで、今まで難しく見えていたHTMLやCSSがとてもシンプルな言語だと分かり、サイトのソースコードも読めるようになりました。
    その結果、レスポンシブ・実装環境を考慮したデザインカンプを作れるようになり、実装できないトラブルもなく、エンジニアへ直接コーディング指示が出来るようになりました。

    本以外でもコーディング知識は身に付けられる

    コーディングは本以外でも身につけることができます。
    実務でもしっかりコードを見て、構造を理解し、分からないことがあれば、辞書を引くように書籍で調べたり、検索するように癖付けましょう。
    本で学習が苦手という方は、YoutubeやUdemyなどの動画学習サイトを活用したり、Progateなどの学習サービスで、手を動かしながらコーディング学習することもおすすめです。
    そうすることでより速く理解でき、コーディング知識を自分のものにすることができます。

    HTML/CSSが理解できたら、次はJavaScriptやCMS構築に必要なPHPも学んだり、インターネットの仕組みなど知るとよりさらにWebデザインやコーディングの知識が深まると思います。

    最後までご覧いただきありがとうございました。
    今回の記事が読者のみなさまの参考になれば幸いです。

  • 【エンジニアリング×モダン開発】JAMstackのサイトジェネレーターについて

    【エンジニアリング×モダン開発】JAMstackのサイトジェネレーターについて

    近年、Web開発で広がりつつある「JAMstack」と「静的サイトジェネレーター」ですが、国内ではマイナーなこともあり、使いどころ、メリットがいまいち理解されていないのが現実です。
    本記事では、JAMstack を実現する際に利用される要素技術、「静的サイトジェネレーター」の仕組みについて解説していきます。
    「そもそもJAMStackって何?」という方は、先に以下の記事をお読みになっていただければと思います。
    【モダン開発とは?ヘッドレスCMSとは?】

    ※文中で多用するので、より短く以下より「静的サイトジェネレーター」を「SSG(static site generation)」と記載している個所があります。

    SSG(Static Site Generator)とは

    まず簡単に「静的サイトジェネレーター」(SSG)とは一体何なのか、解説いたします。

    エンジニアリング_図版1.jpg

    SSGとは「Static Site Generator」の略で、日本語に訳すと 「静的サイト生成 」です。 これはビルド(※1)時に事前にHTMLを生成しておいて、リクエストがあったら単純にそれを返す、といった仕組みです。
    通常のWebサイトでは、ユーザーからリクエストが投げられる(HTTPリクエスト)度にサーバがHTMLを生成し、ページをレスポンスとして返します。
    この方法だと、一度読み込んだ部分もリクエストが投げられる度に再度、生成する必要があるので処理速度が遅くなり、負荷もかかってしまいます。

    ですが、SSGはビルドのタイミングで事前にHTMLを生成しているため、リクエストが投げられたときも生成は終わっており、それをレスポンスとして返すだけになり、結果的に速度が非常に速くなります。

    これでSSGについては理解できたかと思います。

    次章ではメリット・デメリットについて解説していきます。

    ※1 ビルドとは、記述したソースコードに問題(バグ)がないか解析を行い、問題がなければ実行できる形のファイルに変換し、組み立てることです。

    「JAMstack」を支えるSSGの4つのメリット

    ここでは高速なウェブサイトを実現する「JAMstack」を支えるSSGの4つのメリットとデメリットをご紹介いたします。

    SSGのメリット

    エンジニアリング_図版2.jpg
    ▼サイト表示の高速化

    前章でも説明いたしましたが、SSGで作られたサイトはビルド時にすべてのページを生成し、サーバでHTMLを動的に生成しません。
    したがって、「プログラムが動いてページを生成する」という過程が無い分 CMS(※2) よりもページ読み込みのスピードが早くなります。

    ※2 CMSとは、Contents Management System(コンテンツ・マネジメント・システム)の頭文字をとった略称です。web制作に必要な専門的な知識が無くても、webサイトやコンテンツを構築・管理・更新できるシステムのことを言います。

    ▼パフォーマンス向上

    事前にHTMLが生成されるという仕組みは、ページ読み込みスピードもそうですが、大量のアクセスへの対応といったパフォーマンス面でもメリットがあります。パフォーマンス上のデメリットを補うために CMS の場合はさまざまな手法を駆使する必要がありますが、SSGは CMS であらゆる対策を施した後の状態が最初から実現できるようなものです。

    ▼バックアップ不要

    CMSでサイトのバックアップを行うには「CMS のコード」「アップロードファイル」「データベース」の3つを保存する必要があります。これらはタイミングを変えて保存すると不整合が起こることもあるので、極力同じタイミングで保存する必要があります。バックアップの中身を確認したり特定のバックアップの状態に戻したりするのには一般に手間とコストがかかります。
    ただ、SSGだとソースコードをGit で管理しているので、そこがすなわちバックアップデータになります。リポジトリにすべてのデータが格納され、さらにはローカルにも同じデータがあるのでバックアップは不要となります。

    ▼セキュリティリスクの低減

    SSGで作られたサイトはビルド時にすべてのページを生成するため、ブラウザからのアクセス時には動的な処理は行いません。そのため、サイト上での各種インジェクションや不正ログインの被害を受けるリスクが低くなります。

    SSGのデメリット

    エンジニアリング_図版3.jpg
    ▼ビルドの時間がかかる

    CMS の場合は管理者がコンテンツを編集したらすぐにサイトに反映されることが一般的ですが、SSGの場合はビルド処理が必要な関係で、コンテンツの編集からサイトへの反映までにタイムラグが生じます。なので、ページ数が多くなるにつれて、ビルドに時間がかかってしまいます。

    ▼動的ページを原則配置できない

    基本的にはサーバ上での動的出力を行なわず、静的サイトを生成するものなので、「コンタクトフォーム」「コメント機能」などの動的な機能の表示は難しくなってきます。
    サイトに動的な機能を付けたい場合は、クラウドサービスを利用したり、別サイトでその機能を用意したり等といった対応が必要になります。

    ここで、メリット・デメリットをまとめてみましたが、使い所としては、LPや小~中規模のブログ系コンテンツ、ページの表示速度で高いパフォーマンスが求められるサイトなどに使用するのが向いているということになります。

    代表的な静的ジェネレーター

    DigitooではNuxt.jsという、Vue.jsをベースに開発された、SSGを採用しております。
    なぜ、DigitooがNuxt.jsを採用したのか、他のサイトジェネレーターの種類と特徴と一緒に解説していきたいと思います。

    ▼Next.js

    Next.jsReact.jsベースの静的サイトジェネレーターです。プリレンダリング方式としてSSG(静的サイト生成)とSSR(サーバサイドレンダリング)の2つをサポートしている点が大きな特徴です。元々はSSRがメインだったようですが、 2020年に登場したバージョン9.3からは動的ルーティングができるようになり、SSG の機能が強化されました。

    ▼Gatsby

    Gatsby はNext.jsと同じReact.jsベースのSSGです。 Next.jsとは異なりSSRはサポートしていない純粋なSSGです。すべてのコンテンツをGraphQL(GraphQLとは、クエリ言語とスキーマ言語で構成されたWeb APIの規格)を経由して取得します。プラグインシステムやテーマシステムを備えており、どこかWordPressにイメージが似ています。利用数が昨年あたりから急速に伸びており、Next.jsとGatsbyの2つが今世界的に最も注目を集めているSSGです。

    ▼Nuxt.js

    Nuxt.jsVue.js ベースのSSGです。名前の似たNext.jsがReactベースなのに対しこちらはVue.jsベースです。シンプルさ・わかりやすさをウリにしています。日本国内ではVue.jsの人気が高いこともあってNuxt.jsの人気が非常に高いようです。世界的にはReact ベースのNext.jsやGatsbyの方が断然多く使われていますが、国内ではNuxt.jsの方が利用者数がまだまだ多そうです。

    ▼Hugo

    静的サイトジェネレーターはフロントエンド寄りのテクノロジーなので、言語にはJavaScriptを使うものが多いですが、このHugoにはGo言語が使われています。JavaScript以外のSSGで最も人気のものと言ってよいでしょう。 HugoがJavaScriptベースのSSGに大きく勝る点として、「ビルド時間の短さ」と「環境構築の手軽さ」があります。こちらの調査でもビルド時間はHugoが最短になっています。
    今回ご紹介するSSGはHugo以外はすべてスクリプト言語ベースのものなので、ビルドのパフォーマンス重視で選ぶならHugo一択になるかと思います。

    ▼Jekyll

    JekyllRubyベースのSSG です。最古の静的サイトジェネレーターといわれており、近年のJAMstackトレンドが来るずっと前から広く使われており、今でも新しいバージョンがリリースされていますが、GatsbyやNext.jsといった高機能な静的サイトジェネレーターの登場で、近年は個人のブログや小規模サイトでの利用が主になっています。

    上記以外にも、まだまだ静的サイトジェネレーターは存在しますが、本プロジェクトDigitooでは、「PWAモジュールが用意されている」、管理がしやすい「単一ファイルコンポーネント」が使用できるという点からNuxt.jsを採用しております。

    DigitooでのSSGの仕組み

    前章でNuxt.jsを採用した理由を記載いたしましたが、ここではJAMstack構成で開発された、「Digitoo」でのSSGの仕組みについて簡単に解説していきたいと思います。

    SSGの仕組み

    ここまでSSGについて解説してきましたが、Digitooではどのようにしてファイルを保存し、公開しているのでしょうか?
    それは以下の二つのAWSコンテンツを使用しております。

    エンジニアリング_図版4.jpg
    ① Amazon S3

    こちらは、Amazonが提供するオリジンサーバになります。
    ここにファイルを配置しており、初回アクセス時やキャッシュ失効時には、このオリジンサーバからコンテンツを取得するようにしております。

    ② Amazon CloudFront

    こちらは、Amazonが提供するCDNになります。
    CDNとは一体何なのでしょう?

    CDNとは「Content Delivery Network(コンテンツデリバリーネットワーク)」の略で、ウェブコンテンツを効率的かつスピーディーに配信できるように工夫されたネットワークのことで、アクセスが集中したりコンテンツが大容量化したりしても、キャッシュサーバに負荷を分散させることでオリジンサーバの負担を減らすことができます。

    エンジニアリング_図版5.png

    Amazon S3だけでも事足りるのでは?と思われがちですが、Amazon CloudFrontを使用することで、世界各地に設置してあるキャッシュサーバからコンテンツの配信を行うことができます。これにより、自動でユーザーから一番近いキャッシュサーバにアクセスしてファイルのダウンロードを行うことができ、結果的にユーザーへのレスポンスを早め、ダウンロードを速くすることができます。

    他にもGitからpushした後の処理や、ヘッドレスCMSの設定のため、数種類のAWSコンテンツを使用しておりますが、そちらについては今回は割愛させていただきます。
    Nuxt.jsでビルドした後、上記のAWSコンテンツに静的ファイルを保存することで、サイトを公開しております。

    JAMstackな環境

    「JAMstackって何?」という方は、以下の記事をご参考にしてください。
    【モダン開発とは?ヘッドレスCMSとは?】

    ヘッドレスCMSと合わせて、詳しい構成図が知りたい方は以下のサーバ構成図をダウンロードください。

    最後に

    Digitooはマーケターに向けた情報集約メディアなので、SNSのような「多人数が同時に接続してデータを更新するような」サイトではありません。
    つまり、ブログのように小〜中規模のサイトで会員機能がなければ、SSGのメリットを最大限活かすことができるということになります。

    今回は代表的な静的サイトジェネレーターを紹介いたしましたが、その他の静的サイトジェネレーターもたくさんあるので、開発に応じたサイトジェネレーターを使用いただければと思います。

    ▼参考
    https://jamstack.org/generators/

  • Webサイトの表示速度改善方法を徹底解説!たったこれだけで滞在時間が約5倍に-画像編

    Webサイトの表示速度改善方法を徹底解説!たったこれだけで滞在時間が約5倍に-画像編

    「自社サイトの表示速度が、他のサイトに比べて遅い気がする・・」そんなお悩みはありませんか?
    表示速度が遅いと、ユーザーにストレスを与えるのはもちろん、SEO対策の観点においても大きなマイナスとなります。表示速度が遅くなるのには様々な原因がありますが、きちんと突き止めて改善すれば、アクセス数やCVが向上する可能性もあります。
    本記事では、表示速度を改善するメリットや確認方法と、画像の修正によって表示速度を改善する方法についてご紹介します。

    メリットしかない!Webサイトの表示速度を改善する重要性

    表示速度とは、サイトにアクセスした時やサイト内の遷移時の表示までにかかるスピードのことを指します。
    そしてこの速度は、速ければ速いほど良いとされています。

    Googleは、2018年にモバイルサイトの表示速度と直帰率について、以下のように発表しています。

    Find out how you stack up to new industry benchmarks for mobile page speed
    図1:Find out how you stack up to new industry benchmarks for mobile page speed

    出典:https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/

    上記から分かるように、表示速度が遅くなればなるほど、ユーザーの直帰率は悪化しています。
    (直帰率:サイト内で1ページしか見ずにサイトから離脱してしまったユーザーの割合を表す指標)
    ページの表示速度が遅いと、それだけでユーザーのストレスになり、ユーザーに嫌われてしまいます。どんなに優れたコンテンツを作っても、サイト速度が原因でサイトを閲覧してもらえなくなるのは非常にもったいないです。また、表示速度が遅いとGoogleからの評価でも不利になる可能性が極めて高いと言えます。

    表示速度改善による具体的なメリットとしては、以下が挙げられます。
    ・ユーザーにとって快適なサイトになるため、直帰率が下がる
    ・Googleの評価が上がるため、検索順位が上がる。検索順位が上がることにより、アクセス数・CVが上がる可能性が高い

    2021年6月(※1)よりGoogleの検索ランキング要因に取り込まれることが予定されている「コアウェブバイタル(Core Web Vitals)」(※2)というUXの3つの指標のうち、2つに表示スピードに関する指標が含まれており、今後表示スピードがよりSEOに影響することが確実視されています。そのため、今まで以上に表示速度の改善の重要性が高まってくることが予想されます。
    Webサイトの表示速度を改善する重要性を踏まえて、次項からは自社サイトの状態を確認してみましょう。

    ※1. Googleの発表では2021年5月から導入予定の発表でしたが6月予定に変更となりました。
    ※2. Core Web Vitalsは、下記、3つの指標により評価されます。

    コアウェブバイタルの指標
    図2:コアウェブバイタルの指標

    参照:https://web.dev/vitals/

    LCP: 読み込みパフォーマンスの測定になります。ブラウザ表示領域においてもっとも大きな画像などのメインコンテンツが表示されるまでにかかった時間になります。ページの読み込みが最初に開始されてから2.5秒以内にすることが求めらます。
    FID:クリックしてからの挙動スピードを測定するもので、ユーザーが第一印象として感じる、反応速度になります。100ミリ秒以下でことが求められます
    CLS: 視覚要素の安定性を示す指標になり、本記事の表示速度とは関係ない指標になります。

    無料かんたんチェック!Webサイトの表示速度の確認方法

    Page Speed Insightsを使う方法

    まず、Googleが無料で提供している Google PageSpeed Insights(https://developers.google.com/speed/pagespeed/insights/)というツールからご紹介します。
    URLを入力するだけでGoogleの評価に沿ってモバイル・PCの表示速度を100点満点で計測し、具体的な改善点の提案をしてくれるので、慣れない方でも簡単に利用することが可能です。

    Page Speed Insightsのページ

    GTmetrixを使う方法

    次に、GTmetrix(https://gtmetrix.com/)での確認方法についてご説明します。
    GTmetrixは、PageSpeed Insightsと同様に表示速度計測ができる無料ツールです。
    日本語表示には対応しておりませんが、ページごとの表示時間をタイムラインを見たり、結果をPDFで出力することができます。結果をより細かく分析したいという方におすすめです。

    GTmetrixのページ

    さっそく実践!Webサイトの表示速度改善方法(画像編)

    表示速度が遅くなる原因はサイトによってさまざまですが、今回の記事では、画像のサイズや形式が原因の場合の表示速度改善方法に絞ってご紹介させていただきます。

    特に、容量の大きい画像を使用しているサイトや、画像をたくさん使用しているサイトでは大きな効果が見込まれます。「画像が原因かどうか分からない」「画像はおそらく大丈夫」と思っている方も、自社サイトで使用されている画像に以下の対応がきちんと実施できているかを確認してみてください。

    サイト内で使用している画像の容量を削減する

    近年はRetinaディスプレイ対応のため、実際に表示されるサイズよりも画像を大きく書き出してサイトに掲載しているサイトが多くあります。画像はサイズ・解像度が大きいほどきれいに見えますが、必要以上に大きい容量のまま使用してしまうと画像の読み込みに時間がかかってしまい、結果的にユーザー体験を損ねてしまいます。
    画質を落とせば画像容量が下がって読み込み速度が改善されますが、それでは視認性が落ちてしまいますので画質を保ったまま容量を圧縮する必要があります。
    画像一つ一つをPhotoshopなどの画像編集ツールで手作業で調整する方法もありますが、時間がかかってしまいます。そのため弊社では下記のような画像圧縮ツールで容量を圧縮するようにしています。少ない手間で、かつ画像の劣化を最小限に抑えながら容量を落とすことができます。
    ・Compressor.io (https://compressor.io/
    ・Optimizilla(https://imagecompressor.com/ja/

    Retinaディスプレイ対応の場合もそうでない場合も、実際のサイトでの表示サイズで見た時に画質が粗いと感じない範囲内で、容量削減の対応を実践してみてください。

    画像情報に応じた適切な書き出し方に変更する

    次に、画像を適切な書き出し形式に変更する対応をご紹介します。画像には以下のようにそれぞれ最適な書き出し形式があり、内容に合わせて設定をすることで画質を保ったまま容量を落とすことができます。
    ・JPEG:色数の多い写真など
    ・SVG:文字やアイコンなど、色数が少ない単純な画像
    ・PNG:キャプチャ画像、図など

    PNGは扱える色数も多く、透過が可能、「可逆圧縮」の画像形式なので低画質で保存しても元の画質に戻すことができるなど、非常に便利な拡張子です。そのため、つい「とりあえずPNGにしておくか」となってしまいがちですが、反面、他の拡張子に比べて書き出しの際に容量が大きくなってしまうことが多いという難点があります。

    その点、JPEGやSVGはPNGに比べて容量が比較的削減できる場合が多いため、色数が多い場合はJPEG、少ない場合はSVGなど、画像の情報によっては書き出し形式をJPEGかSVGにすることをおすすめします。
    ※それぞれの拡張子には強みと弱みがあるので、画像によってはJPEG・SVGにすることでかえってPNGの時よりも容量が大きくなってしまう場合があります。必ず画像の情報によって使い分けの判断をするようにしましょう

    以下の表を参考に、現在サイト上で使用している画像に最適な書き出し形式を検討してみてください。

    画像の拡張子使い分け表
    図5:画像の拡張子使い分け表

    【事例】画像を改善して平均ページ滞在時間が約5倍に!

    次は、本サイト「Digitoo」で、画像の容量・書き出し形式の修正によって表示速度が改善された事例をご紹介します。

    実施内容

    ・画像圧縮ツールを使用し、画像の容量をできる限り圧縮
    ・画像情報に応じた適切な書き出し形式に変更
    ・容量の大きい写真素材はPNG →JPEGに修正

    実施結果

    実施後の計測結果は下記の通りでした。

    ①PageSpeed Insightsの計測結果、改善前と改善後で38ポイントアップ!
    まだ改善の余地はありますが、画像の対応だけでも表示速度が大幅に改善され、以前の3倍近くまでポイントをあげることができました。

    PageSpeed Insightsの計測結果

    ※実際は、技術的にもまだまだ対策が必要なポイントになります。

    ②Googleアナリティクスでの計測結果、直帰率の低下と平均ページ滞在時間が約5倍にアップ
    blogの平均ページ滞在時間は実施前の1月と比べて1分10秒から5分24秒にアップ、変化率は366%!
    直帰率・離脱率に関しても30%以上の低下を実現しました。

    Googleアナリティクスでの計測結果

    表示速度改善(画像編)のまとめ

    本記事では、表示速度を改善するメリットや確認方法と、画像の修正によって表示速度を改善する方法についてご紹介しました。

    前述の通り、表示速度が遅くなる原因はサイトによって様々ですが、画像の改善をするだけでも、表示速度とユーザビリティを大幅に向上させることができます。
    現在、表示速度の遅さに悩まれている方は、一度自社サイトの画像が適切な状態になっているか、チェックしてみてはいかがでしょうか。

    「Webサイトの表示速度改善方法を徹底解説-ソースコード編」ではソースコードを修正して改善できる方法をご紹介します。

  • Webアプリにおけるテストの役割とは?項目や工程まで細かくご紹介

    Webアプリにおけるテストの役割とは?項目や工程まで細かくご紹介

    Webアプリケーション(以下Webアプリ)開発に携わる企業の方の中には、開発工程が多岐にわたるため、実装後の作業であるWebアプリにおけるテストの必要性や、実施方法について把握しきれていないという方も少なくないと思われます。

    本記事では、検証工程に携わったことが少ない方に向けて、検証の重要性と効果的な導入方法について詳しく解説していきます。

    Webアプリにおけるテストとは

    Webアプリの開発工程におけるテストとは、作成された成果物に対して評価を行う作業です。

    評価基準は工程やWebアプリによってさまざまですが、まずはWebアプリにおけるテストの前提である実施の理由について簡単に解説していきます。

    テストを実施する目的

    Webアプリにおけるテストで最初に思い浮かぶ目的は、欠陥(バグ)の摘出ではないでしょうか。
    ただ、欠陥の摘出とはあくまで目的を達成するための手段であり、本来の目的は欠陥の摘出を内包した、より広義的なものになります。

    目的はプロジェクトによってさまざまですが、ここではよく用いられるステークホルダー(利害関係者)基準での、Webアプリにおけるテストの達成基準について4件ご紹介します。

    • 明確にしたすべての要件を満たしていることを確認
    • ソフトウェアの品質が不適切になるリスクレベルを軽減
    • 契約上、法律上、または規制上の要件や標準を遵守
    • ステークホルダーが意志決定できる品質レベルについての十分な情報提供

    テスト工程を実施しなければならない理由

    【1-1】において、テストを実施する目的は明確になりましたが、ここでは目的を達成するためになぜテストを実施する必要があるのかについて解説していきます。

    まず、ステークホルダーの観点からすると「開発工程における大きな手戻りや、リリース後の致命的な不具合による損失を防ぐため」が挙げられます。
    開発工程の手戻りは工数の増加、リリース後の致命的な不具合は利益の損失につながってしまいます。そのため、テスト実施の理由としては損失の回避と将来的な利益の確保となります。

    また、開発工程の観点からすると「テスト終了後に欠陥の根本原因を分析するため」が挙げられます。
    開発工程においては、どこでどのような欠陥が出たか、どのような欠陥が開発工程のスケジュールに影響を及ぼしたかなどを欠陥ベースで情報集積することで、次回以降の開発工程における改善案の提示を行うこともテスト実施の理由となります。

    Webアプリテストの作業工程

    ここでは、Webアプリテストの目的と理由についてより理解を深めるため、具体的な作業工程を解説していきます。

    実行計画

    Webアプリにおけるテスト工程を実行することが決まった段階で、まずは実行計画を開始します。

    最初に、テストに必要なリソースの確認を行います。
    必要なリソースは主に下記の6つになります。

    • プロジェクト方式
    • 仕様書
    • 設計書
    • 製品マニュアルやテスト対象機器
    • 旧バージョンが存在する場合の各種テスト情報
    • 競合製品が存在する場合は競合製品の情報や実機

    これらの情報をもとにテストの内容やスケジュールを策定していきます。

    次に、スケジュール策定を実施します。
    テスト対象物のテスト実行範囲(確認を行う事項)を明確化し、優先順位を付けます。また前述の過去のテストデータなどから不具合の予想件数を想定できる場合はその数を割り出しておきます。
    必要な情報を集め終えた後、その情報を元にタスク・工数・マイルストーン・要員・終了基準を決定し、スケジュールを組みます。

    最後に、テスト工程における連携手段とリスクの明確化を実施し、本工程を終了します。
    考えられる主なリスクは下記の4つになります。

    • 要員のトラブル
    • コミュニケーションミス
    • テスト実行を阻害するブロックバグやテスト対象物の品質
    • 機器の不足や故障

    上記に関しては発生してからの対応のため、スケジュール策定段階で想定することは難しいですが、前述の過去のテストデータなどから計画段階で回避策を用意しておくことでリスクを低減することが可能となります。

    環境準備

    Webアプリにおけるテスト環境準備とは、テスト実行する上で必要なリソースを確保・確認する段階になります。
    具体的な準備は下記の6件になります。

    • 作業環境の準備
    • テスト環境やテスト対象の準備
    • 必要なリソースの動作確認
    • プロジェクト用語集と組織図の準備
    • コミュニケーションツールと運用ルールの準備
    • テスト実行に必要な管理表の用意

    テストケース準備

    Webアプリにおけるテストケース準備とは、テスト実行に必要な実施条件、動作、期待結果を示したドキュメントの作成を行う段階になります。
    具体的な事例は【3-3】において説明します。

    実行

    Webアプリにおけるテスト実行とは、【2-1】~【2-3】の工程で作成した内容を用いてテストを実行する段階になります。
    基本的には「テスト項目と予定時間の確認・打鍵」を行うだけの作業ですが、障害の発生に伴い不具合報告と確認テストが追加で発生する場合があります。

    不具合報告

    実行段階において確認された不具合や確認事項はエンジニアへ報告する必要があるため、不具合報告書を作成します。
    手順としては下記の通りになります。

    • 期待値と異なる事象の確認(テスト実行時に確認)
    • 不具合かどうかの判定(各種ドキュメントとの整合性チェック)
    • 事象の発生条件の明確化
    • 再現手順の明確化
    • 不具合の評価(品質への影響度や修正優先度)
    • (3)~(5)を記載した不具合報告書の作成
    • 環境準備において不具合管理表を作成した場合は管理表へ記載

    実行報告

    実行完了後にテストケースの実行件数や不具合率などの実行計画段階で定めた終了基準を満たしているか確認し、テストを終了する判定が下された際にはテスト実行報告を作成します。
    テスト実行報告にまとめる内容は下記の4点になります。

    • 実行件数や不具合率などの集計
    • 実行中に発生した問題点とその解決策の提示
    • 次回への改善点や要望の提示
    • テストに使用した各種データ・物品の整理・保管

    本工程は欠陥を取り除くというテストの直接的な目的からは乖離する内容ではありますが、【1-2】の「テスト終了後に欠陥の根本原因を分析するため」に該当するテストを実行する理由の一端であるため、必要不可欠と言えます。

    Webアプリテストの手法

    ここでは、【2】で示したテストの流れを実行する際のテストの区分方法や、テスト仕様書の作成方法について解説していきます。

    テストレベル

    テストレベルとは、テストを系統的にまとめ、マネジメントしていくグループです。
    具体的には下記の4件になります。

    ・単体テスト
    個別にテスト可能なコンポーネントに焦点をあてるテスト。

    ・結合テスト
    コンポーネントまたはシステム間の相互処理に焦点をあてるテスト。

    ・総合テスト
    システムが実行するエンドツーエンドのタスクと、タスクの実行時にシステムが示す非機能的振る舞いといったシステムや製品全体の能力に焦点をあてるテスト。

    ・受入テスト
    システムテストと同様、一般的に受け入れテストはシステムやプロダクト全体の振る舞いや能力に焦点をあてるテストではあるが、目的は不具合を検出することではなく、システムが導入に向けて準備できているかどうか、および顧客 (エンドユーザー)が使用できるかどうかを評価するテスト。

    各工程は一回だけ行い、原則として後戻りは許されません。
    前工程の成果物をインプットし、次工程にアウトプットする成果物を作成することをウォーターフォールモデルと呼びます。

    下記のような左側が設計プロセス(上流工程)、右側が検証プロセス(下流工程)のV字モデルでは、横に対応する仕様書をインプットとして、仕様書通りの成果物ができているかどうかの確認を行います。

    ウォーターフォールのV字モデル
    図1:ウォーターフォールのV字モデル

    出典:https://thinkit.co.jp/article/22/3/

    テストレベルごとに目的・テストベース・典型的な欠陥・アプローチ方法が異なるため、【2-1】実行計画段階の必要な情報として挙げることができます。

    テストタイプ

    テストタイプとは、ソフトウェアシステムの目的や特性毎に条件を束ねたものです。
    具体的には下記の4件になります。

    ・機能テスト
    システムが実行する事項が機能要件を満たしているかを評価するテスト手法。

    ・非機能テスト
    システムやソフトウェアの使用性、性能効率性、セキュリティといったシステムが「どのように上手く」振る舞うかを評価するテスト手法。
    こちらの具体例は【3-3】の”手順⑦”に記載してあります。

    ・ホワイトボックステスト
    システムの内部構造や実装にもとづいてテストを導出する手法。
    この手法は内部構造を理解しているコードの実装者で行われるテストやレビューが主軸になるため、テストチームとして実行されることは少ないです。

    ・確認テストとリグレッションテスト
    欠陥を修正、追加、変更といったシステム対応を行った場合、元の欠陥が修正されたこと、機能が正しく実装されていること、予測しなかった悪い影響が発生していないことを確認するためのテスト。

    すべてのテストタイプはすべてのテストレベルで実行可能ではありますが、プロジェクトの方針にあわせて各テストレベルに全テストタイプを適用する必要はありません。
    テストタイプは必要となるもっとも早い段階のテストレベルで行うことで大きな手戻りや致命的な欠陥の作りこみを防ぐことができるため、どのテストタイプも可能な限り早い段階で実施することが重要です。

    テスト項目作成

    ここでは、【2-3】の工程において作成する仕様書の内容について解説していきます。

    手順①:開発仕様の確認と熟知

    下記5件の資料を収集し、収集した内容をテスト設計文書として記録する。

    • テスト設計の上で必要なドキュメント
    • テスト対象の機能要求から必要なドキュメント
    • テスト対象のコンプライアンスに関わる情報
    • テスト対象の非機能要件
    • 過去のテストドキュメント

    またテスト設計文書は作成した際に修正作業や後の作業工程のために参照元のドキュメントとのトレーサビリティ(追跡性)を確保しておくことが重要です。

    手順②:テスト対象物の仕様をベースにテスト要素とテスト条件の抽出

    テスト要素は”手順①”で作成したテスト設計文書をベースにテストの実行できるパターンを抽出したものになり、テスト条件はテスト要素に与えるさまざまな入力値になります。
    また、この2件は量が増えやすく、テキストでの管理が困難であるため、下記のような管理体制であることが望ましいです。

    ・テスト要素
    抽出後に要素同士の関係性を明確化し、樹形図の作成によって管理する。

    図2:テスト要素-樹形図
    図2:テスト要素-樹形図

    (参考:IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP115「図 M3-3 機能樹形図(Function Tree)」を参考の上作成)

    ・テスト条件
    複数条件が絡み合う場合、テキストベースでの管理は難しいためデシジョンテーブルやマトリクス表の作成によって管理する。
    ※例として、有効値と無効値の数値処理を行う条件には下記の2件を用いる場合が多いです。

    同値分割法:有効値と無効値といった条件をひとまとめにし、その中から代表の値を選定する手法
    境界値分析:有効値と無効値の境目の値にフォーカスをあて、その数値を条件とする手法

    図3:同値分割法・ 境界値分析
    図3:同値分割法・ 境界値分析

    (参考:IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP132「図 M4-7 同値分割と境界値分析による”月”データの有効値と無効値の抽出」を参考の上作成)

    手順③:テスト要素とテスト条件を組み合わせる

    テスト要素とテスト条件を組み合わせたものが、テスト設計の最小単位であるテストケースとなります。
    この工程で組み合わせるものを検討するのではなく、”手順①”で示したテスト設計文書のトレーサビリティを参照し、組み合わせを導き出していきます。

    手順④:テスト要素と例外のテスト条件又はテスト要素と異常のテスト条件を組み合わせる

    本来は開発仕様書を始めとするドキュメントを用いることで、想定する動きが正常に動作しているか確認できるため、問題はないように思います。
    しかし、想定していない状況(サーバーダウンなど)に陥った際、次に説明する2パターンのテスト条件を実行していない場合、脆弱性により大きな損失を被る可能性があります。

    例外のテスト条件とは、仕様の範囲内ではあるが仕様で定められていない値を与えられる条件のことです。
    ・例外条件(数値パターン)
    web_test4.jpg

    (参考:IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』より P144「表 M5-4 有効値30~50の例外条件」を参考の上作成)

    ・例外条件(名称パターン)
    web_test4.jpg

    (参考:IVEC知識試験テキスト制作委員会 『IT検証技術者認定試験(IVEC) 知識試験 テキスト』よりP144「表 M5-5 都道府県名称の例外条件」を参考の上作成)

    異常のテスト条件とは、仕様に関係なくテスト要素に本来使用する想定ではない値が与えられる条件のことです。
    具体的な例としては下記が挙げられます。

    • 整数入力欄に文字コードではないデータが与えられた
    • データが与えられなかった
    • データの処理中に次のデータが与えられた
    • データの入力先が排他状態だった

    上記2パターンのテスト条件については、開発仕様書などで範囲が定められていないため、条件になり得る量は膨大になります。
    そのため、テスト仕様書作成担当者とレビュアーがテスト設計文書や開発仕様書からプロジェクトのスコープに適応する条件や、リスクの大きい条件を選定することが理想です。

    手順⑤:テストケースをテスト仕様書へ落とし込む

    ”手順③”と”手順④”で作成したものを実際にテスト仕様書に落とし込んでいく作業になります。
    この作業で重要なのは、テスト実行担当者のレベル、テストの期日、工数を考慮した上で『記述の粒度』を変えるという点です。
    『記述の粒度」の例としてログイン確認の項目を書いた場合、下記のようになります。

    ・『記述の粒度』が低い場合
    「登録済みアカウントでログイン」

    ・『記述の粒度』が高い場合
    「IDに“XXXX”、Passwordに“AAAA”を入力し、ログインボタンを押下する」

    スキルレベルが高いテスト実行担当者の場合、『記述の粒度』が低い場合でも理解することが可能ですが、スキルレベルが低いテスト実行担当者の場合、『記述の粒度』が高いと、テストケースの意図を理解するまでに時間を要してしまいます。
    また、『記述の粒度』が高い場合、スキルレベルが高いテスト実行担当者が読了に時間を要し、テスト仕様書作成担当者が記述に多くの時間を割くことになります。
    そのため、テスト実行担当者のスキルレベル、テストの期日、工数にあわせて最適化することを念頭に置き、テスト仕様書作成にあたることが重要になります。

    当然ではありますが『記述の粒度』の高低に関わらず、理解しやすい文章や作りにすることはテスト実行担当者の補助のみならず、実行報告や次回以降のテスト工程のサンプルとして生かしやすくなるため、気を付ける必要があります。

    手順⑥:作成したテスト項目に対して期待値を設定する

    作成したテスト仕様書のテスト項目に対して、正誤の判断に用いる期待値が必要になります。
    こちらはテスト設計文書と参照元のドキュメントとのトレーサビリティ(追跡性)を用いて設定することが多いです。
    例外のテスト条件や異常のテスト条件を用いた項目や参照元のドキュメントとの整合性が取れない場合に関しては、開発者やプロジェクト責任者に確認を取る必要があります。
    また期待値が文章化できない場合には、リファレンスを用意して期待値を示します。

    手順⑦:非機能テストのテスト基準策定

    【3-2】で示した非機能テストの内容を精査します。
    代表的なものは下記の3件になります。

    ・性能テスト
    ・負荷テスト
    ・脆弱性テスト

    これらのテストの実行可否、使用方法、ツールを選定しテスト仕様書に追加またはチェックリストを作成します。

    Webアプリテストの今後の展望

    今後Webアプリにおけるテスト実行は、テスト自動化ツールや “Sizzy”などの検証補助に利用できるツールを導入することで最適化できると考えます。

    テスト自動化ツールは、そもそもツールを開発できる技術者がテストチームにいないことや、短期的な視点で見れば工数を損失するなどの障害も多いですが、導入後の長期的な視点で見ると工数の削減やヒューマンエラーの削減につながるため、導入には前向きな検討が必要です。

    検証補助ツールは、昨今の開発従事者の在宅勤務化に伴い、在宅環境における検証端末の有無や、テストチーム内の検証環境の差異といった問題を解消するためにも急務であると考えます。
    もちろん“Sizzy”を始めとする検証補助ツールは、検証の効率化といった面でも大変役に立ちます。
    そのため、在宅勤務化がこれからというテストチームであったとしても、テスト実行者の負担軽減、工数削減、そしてプロジェクト全体の品質向上につなげるため、導入への前向きな検討が必要です。

    Webアプリにおけるテストまとめ

    Webアプリのテストは開発工程で発生するあらゆる不具合を拾い上げ、製品としての魅力を担保する役割を担っています。

    将来的な不利益を回避や利益の確保につながるため、Webアプリに携わる方は最低限の目的と工程を理解することでよりよい成果物を目指しましょう。

  • 非エンジニアのためのGit-flowの運用方法とケーススタディをご紹介

    非エンジニアのためのGit-flowの運用方法とケーススタディをご紹介

    現在、世界でも多くの開発者がシステム開発、アプリ開発の際に使用しているバージョン管理システム「Git」ですが、開発体制が大きくなるに従い、

    「ソースコードのコンフリクトが頻繁に起きてしまう」
    「先祖返りばかり発生して、なかなかプロジェクトが思うように進まない」
    「Gitは導入するだけじゃダメなの?」

    なんてことは無いでしょうか?

    本記事では、バージョン管理システムの必要性と重要性、さらにGitを使用したバージョン管理のワークフローのうち、最もメジャーな「Git-flow」の運用とケーススタディについて、ご紹介致します。

    バージョン管理の必要性と重要性について

    本記事では主にバージョン管理システム「Git」を使用したワークフローについての解説をいたしますが、Gitについての解説に入る前に、開発をするうえで欠かせないバージョン管理の必要性と重要性について少し触れておきます。
    version control system

    「バージョン管理」とは一体何でしょうか。これは開発の中で更新されていくソースコードやファイルの変更を記録することです。
    さらにそのサポートしてくれるソフトウェアのことをバージョン管理システムといいます。

    では、なぜそのバージョン管理システムが開発をする上で必要になってくるのでしょうか?
    バージョン管理システムを使用することによって、以下のことが可能になります。

    • 変更履歴の記録(= commit)
    • 変更の取り消し、復元
    • 変更理由、その担当者の履歴

    バージョン管理システムを使用せずに開発を進めてしまうと、他の作業者が編集した内容に気づかずに、ソースコードを上書きしてしまったり、時には不要なコードと認識し、削除してしまい、結果としてエラーや*デグレートが多発してしまうことになります。
    (*デグレートとは、ファイルを更新した際に以前修正したバグや不具合が再発してしまうことです。)

    しかし、上記の3つが可能になった場合はどうでしょう?
    変更履歴を辿ることで、変更理由が確認でき、さらにその担当者も確認できるので、不用意にコードを削除してしまうことも無くなるでしょう。それによりエラーやデグレートの発生率を下げることに繋がってきます。

    GitとSVNについて

    1章ではバージョン管理の重要性についてお伝えしましたが、ここではメジャーなバージョン管理システム「Git」と「SVN」の違いについて簡単にご説明いたします。
    ※SVNからGitへ移行についての解説は、今回は省かせていただきます。

    そもそもGitとは?

    「Stack Overflow Developer Survey 2018」の開発者調査レポートによると、世界中で9割近い開発者がバージョン管理システムとしてGitを活用していることが分かりました。

    Stack Overflow Developer Survey 2018 開発者調査レポート
    画像1:Stack Overflow Developer Survey 2018 開発者調査レポート

    出典:https://insights.stackoverflow.com/survey/2018

    ですが、2005年にGitが誕生するまでは、「SVN」というバージョン管理システムが多くの開発者に使用されていました。

    GitとSVNの大きな違い

    GitとSVNというワードがこの章では出てきていますが、その違いとは一体何なのでしょう?

    Gitとsvgの違い
    ▼SVN

    ローカルリポジトリが無く、commitをすれば即座に共有リポジトリに反映される。

    ▼Git

    commitすると、一旦ローカルリポジトリに格納され、そこから共有リポジトリに反映する部分を選べる。

    つまり、Gitの場合は各作業者の修正部分のみを共有リポジトリに反映することができるので、デグレートの発生を防ぐことができます。少人数のプロジェクトであれば、SVNの方が楽に運用できる場合もありますが、Gitを使いこなせればこれほど便利なツールは無いので、ぜひ導入していきましょう。

    Gitブランチを運用する必要性について

    せっかくGitを導入してもしっかり活用できていない、その理由はブランチモデルを導入していないからではないでしょうか?

    Gitのブランチモデルについて

    ブランチモデルとは、開発を進めるにあたって、どのように*ブランチを活用していくかのルールです。Gitではブランチを分けることで、他のブランチに影響を与えずにcommitでき、複数人で別々の機能を開発することができます。
    (*ブランチとは、共有リポジトリから分岐させた開発者の作業場のようなものです。)

    有名なブランチモデルには「Git-flow」と「GitHub-flow」があります。

    「Git-flow」と「GitHub-flow」の違い

    ▼Git-flow
    Git-flowの流れ

    Git-flowとはオランダのエンジニア、Vincent Driessen氏の"A successful Git branching model" を元にしたワークフローです。
    Git-flowでは、役割が決められた5種類のブランチを切り替えながら開発を進めていきます。
    ※この5つのブランチについては次の章で詳しくご説明いたします。

    ▼GitHub-flow
    GitHub-flowの流れ

    Git-flowでは5種類のブランチを使い分けるのに対して、GitHub-flowでは、2種類のブランチ(master、topic)しか使いません。つまりGitHub-flowでは、masterブランチへのマージとリリースはほぼ同義になってきます。

    それぞれのメリット、デメリットについては以下のようになります。

    Git-flowとGitHub-flowのメリット・デメリット

    それぞれにメリット・デメリットがありますので、現場に合わせたよりよいブランチモデルを使用しましょう。

    Gitブランチの運用にルールが必要な理由

    ではなぜ、ブランチの運用にルールが必要なのでしょうか?理由はたくさんありますが、大きな理由は以下の3点です。


    • ルールがないと、各々の開発者が自由にブランチを切ることでリポジトリのブランチが乱立する。
    • ルールがないと、各々の開発者が自由にPush等をしたりして、誰がどこをどれだけ作業したのか状況がつかめなくなる。
    • ルールがないと、各々の開発者がmasterブランチ、developブランチにPushをしてしまい、誤って開発途中のソースコードや非公開の情報が本番公開されてしまう。

    これらの問題が起こっていることに気づいた時にはもう手遅れで、これらの整理を行うのにかなりの工数がかかってしまいます。

    しかし、ブランチモデルを利用することにより、これらの問題を回避することができます。

    今回は、開発環境を明確にできることから、当社でもっとも利用されているGit-flowについて、掘り下げて説明をさせていただきます。

    ※当社の多くのプロジェクトは、開発者が複数おり、検証者(テスター)も複数いることから、GitHub-flowモデルが採用されることは少ないです。

    Git-flowを形成する2つのメインブランチと3つのサポートブランチ

    ここでは前章でも軽く触れた、Git-flowの5つのブランチのブランチ元、マージ先、それぞれのブランチ命名について解説します。

    ▼メインブランチ【master、develop】

    基本的にはプロジェクトの核になる2つのメインブランチがあります。
    この二つのブランチはマージを行うだけのブランチになりますので、直接作業したり、commitすることは避けましょう。

    こちらは、重要なブランチになりますので、のGitからサーバへアップするまでの構成図と一緒にご説明させていただきます。
    サーバ構成図

    ※本プロジェクトでは上の図のようにAmazon API Gateway、Lambdaを利用し、開発者がmasterブランチもしくは、developブランチにマージすることによって閲覧者・検証者側のサーバ側に自動反映(ビルド)され、ユーザー確認できるような構造になっております。

    masterブランチとdevelopブランチ
    メインブランチの補足事項

    ・masterブランチ
    masterブランチは常に本番環境と同期が取れている必要があります。厳密に言うと、常にリリースが可能な安定したブランチです。

    ・developブランチ
    ブランチ元はmasterブランチで、developブランチは動作や表示などについて最終的な確認が行われるステージング環境と同期が取れている必要があります。
    このブランチを中心にブランチを作成していき、開発を進めていきます。

    ▼サポートブランチ【feature、release、hotfix】

    タスクごとに「feature」、「release」、「hotfix」のいずれかブランチを作成し、作業を行います。
    これらのブランチはメインブランチから作成され、マージが完了すると削除されます。

    サポートブランチ
    サポートブランチの補足事項

    ・featureブランチ

    featureブランチとは

    featureブランチは実際に開発者が作業を行うブランチになります。
    ブランチ元、マージ先は共にdevelopでブランチ名は「feature」から始まります。

    ・releaseブランチ

    releaseブランチとは

    releaseブランチはリリースをする段階になった時点で使用するブランチです。
    ブランチ元はdevelopで、そのブランチでリリース作業(リリースバージョンを示すタグを作成)を行います。リリース作業が完了後、developとmasterの両方にマージします。ブランチ名は「release」から始まります。

    ・hotfixブランチ

    hotfixブランチとは

    こちらは、リリース後に発生したバグを修正するブランチになります。したがってブランチ元はmasterで、修正が完了後はmasterにマージし、リリース作業を行います。その後、developにマージします。
    ブランチ名は「fix」もしくは「hotfix」から始まります。

    ブランチの流れは掴めたでしょうか?Git-flowは少し複雑なので、SourceTreeなどのGUIツールを使用して視覚的にブランチの流れを掴むのも一つの方法としていいでしょう。

    Digitooでのケーススタディ

    さて、ここまでバージョン管理の大切さや、Gitブランチの運用の大切さについて紹介してきましたが、実は本サイト「Digitoo」の制作当初はブランチの運用に厳密なルールを設けていませんでした。

    それに伴い、何が起こったか

    • マージが確定するまでの間で、同一ファイルの複数作業が発生
    • developブランチで作業
    • commit履歴の残し方が簡略化しすぎる

    結果として、先祖返り、デグレートが多発し、さらにcommit履歴が簡略化されすぎたせいで、どこが原因か追いづらくなりました。そのせいで再修正が多発し、予定工数の2倍の工数がかかるという結果に…

    お世辞にもGitを使いこなしているとは言えない状態でした。

    そこで本プロジェクトメンバーは、基本に立ち戻り、Git-flowを取り入れ、以下のルールを決め、忠実に従うことにしました。

    • 特定のレビュアーを決め、レビュアー以外の人間は、例えどんな小さな修正でもmaster、releaseブランチ、developへmergeすることは避ける。
    • commitコメントはルールに従うこと。(後述記載)

    1については、先祖返りは勿論のこと、品質担保の面で作業者とレビュアーを決める必要があると考えたため、「開発者→レビュアー」のレビューのワークフローをとることにしました。

    2については以下のcommitコメントルールを徹底しました。

    基本的な書式
    • [プレフィックス]:(コロン){半角スペース}作業内容{半角スペース}Backlog課題キー or No-00(Google Spreadsheet FB番号)

    ※本プロジェクトではBacklogやGoogleスプレッドシートを使ったタスク管理をしていました。

    ・プレフィックスの種類
    プレフィックスの種類

    ・ 関連課題が無い場合は課題キーを省略可能

    ・ 作業内容はできるだけ具体的に入れる

    ・ 作業途中の場合は作業内容の頭に「WIP」を入れる

    上記を徹底した結果、先祖返り、デグレートが起こらなくなり、さらに、commit履歴を具体的に記載することで、個人の作業フローが見えやすくなったため、業務の引継ぎなど、スムーズに行うことが可能になりました。

    Gitのcommitとブランチ運用の心がけ

    ここで、commit時と、ブランチ運用時に心がけておくべき事を、良い例、悪い例を記載しながらまとめていきます。

    commitとブランチ運用の心がけ

    まとめ

    いかがでしたでしょうか?Git-flowは少し複雑で理解するのは容易ではありませんが、各ブランチの役割を把握して運用することで、開発をスムーズに進めることができます。

    また、Digitooのインフラ環境のように、Git-flowのブランチと、実際のサーバの本番環境と開発環境を自動連携して、わざわざ、FTPでアップロードのような手間を省き、作業もミスなく楽できるように、AWSなどのクラウドのインフラ環境も整ってきております。

    今回の記事では、「Git-flow」について解説しましたが、記事内で解説したように、Gitの運用方法はこれだけではありません。
    「GitHub-flow」や「GitLab-flow」などさまざまな運用方法がございますので、開発の規模や状況に合わせて使い分けてみることをお勧めいたします。

    今後、インフラ環境などに即した、新しいブランチモデルも生まれると思いますし、当社でも、様々な試行錯誤を繰り返し、最適な開発環境に常に注目していきます。

    当社では、Gitでの運用方法の支援をしておりますので、お困りのことがございましたら、お問い合わせくださいますと幸いでございます。

  • モダン開発とは?ヘッドレスCMSとは?非エンジニアのWeb担当者が、困らないように、わかりやすく解説致します。

    モダン開発とは?ヘッドレスCMSとは?非エンジニアのWeb担当者が、困らないように、わかりやすく解説致します。

    多機能・高機能でシステムを選ぶ時代は終わりました。

    CMS(コンテンツ・マネージメント・システム)も、選定する上で重要なのは、必須条件がクリアでき、拡張性の高いベースがしっかりしたシンプルなものを選ぶべきです。

    シンプルにすることで、システムもスピードが出て、リーズナブルに運用できます。

    本記事では、ITツールの選定に関わる非エンジニアの方や、Webマーケターが知るべき、エンジニア情報を、わかりやすく解説していきます。

    第一回目は、CMS選定をされる立場の方が多いため、モダン開発と紐付けて、選択肢の一つになっているであろう、ヘッドレスCMSの概要をご説明します。

    Web担当者がモダン開発を理解する必要性について

    3〜5年に一回は、CMS選定やサーバ選定をされてことが多いと思います。
    企業担当者は、経営陣から中長期の予算をかけるプロジェクトとして、Web課題を解決できる新しいシステムアーキテクチャを求められるはずです。

    その際に、下記の3つが必ず話題になるのではないでしょうか?

    • セキュリティの堅牢性を保ちたい
    • サイトの表示速度を早くしたい
    • 新しいアーキテクチャにして、ランニング費用を下げたい

    ※今回は、従来のCMSとモダン開発のCMSとの比較のため、CMSが持っているコンテンツ運用チームの負担改善についての言及は、要件から省きます。運用の要件により優劣が変わる、もしくは、優劣がつかないためです。同様に、MA機能を含めたCMS比較も、MAの要件により優劣が変わる、もしくは、優劣がつかないため省きます。

    blog-jam-img01.png

    モダン開発は、そういった課題をシンプルに解決しますが、アーキテクチャの根本に関わるため、サーバ選定=モダン開発ができるかどうかの重要な要になります。
    そのため、しっかりサーバを含めたアーキテクチャの概要を理解していきましょう。

    blog-jam-img02.png

    そこで、相談先として横断的に進められるベンダーの存在に期待したいのですが、実態は、インフラベンダーは開発手法に関与せず、システムベンダーは現環境を見てLAMP環境(後述で簡単に解説します)で開発手法を進めます。運用ベンダーは全体工数ではなく運用メンバーを過剰に心配し、運用フローの変更が少ない現環境と変わらない運用を求めます。

    blog-jam-img03.png

    結果的に、レガシー環境のため根本解決ができなくなり、未来になればなるほど、運用工数は増加し、セキュリティ保守費用が高額になります。
    せっかく新しいシステムを入れようとしているにもかかわらず、予定よりも早くシステムの再検討することも多いようです。

    そういった状況から、アーキテクチャは、社内で概要を理解して、最適なものを取捨選択する指針を打ち出し、社内で推進していく人が必要です。

    当社では、横断的な視点で、CMS選定のお手伝いをしておりますので、お気軽にご相談ください。
    お問い合わせ

    では、アーキテクチャの概要を理解することは、そんなに難しいことなのでしょうか?

    ヘッドレスCMSとは

    ここ数年で聞かれることも多くなりました、ヘッドレスCMSですが、従来のCMSとの違いは、20秒で理解できます。

    blog-jam-img08.png
    図1:ヘッドレスCMSと従来のCMSの違い

    上記(図1)は、いろいろ省いた簡略図にはなりますが、

    ▼従来のCMS
    閲覧者が閲覧するたびに、サーバが閲覧するファイルをいちいち生成され出力します。

    ▼モダン開発のヘッドレスCMS
    閲覧者が閲覧すると、そのまま出力されます。

    ヘッドレスCMSとは、つまり、いちいち生成しない(=ヘッドレス)ということだけなのです。
    簡単に理解できたと思いますが、いかがでしょうか。

    ※「モダン開発のヘッドレスCMSの図が静的ファイルと変わらない」「CMSを更新する管理者側の構造がどうなっているかわからない」については、後述に簡単に記載しています。
    ※静的ファイルのみの説明だと、例えば、SSGであるMovable TypeもヘッドレスCMSになってしまうという、ビューやAPIの話は一旦、省かせていただきます。

    ヘッドレスCMSの表示スピードが早い理由

    こちらも非エンジニアでも簡単に理解できます。

    blog-jam-img04.png
    図2:ヘッドレスCMSと従来のCMSとの表示スピードの違い

    上記(図2)を料理に例えると、下記(図3)のようになります。

    blog-jam-img05.png
    図3:ヘッドレスCMSの表示スピードが早い理由

    ▼従来のCMS
    コックが料理を作り(生成出力)、それが出来上がってからウェイターがお客様に運びます

    ▼モダン開発のヘッドレスCMS
    料理されているものをそのまま出力ウェイターがお客様に運びます

    また、このことから、コックという人件費に当たるものが、実際にサーバ処理しないため、その処理をしない分、サーバ費用も安くなることがわかります。

    スピードが早くて、サーバ費用も安い、ヘッドレスCMSは、そんな素敵なCMSです。

    コックがいないと、スペシャルな料理が食べられないのでは?とお考えになられた方もおられるでしょう。
    ITでもその点は否めない点もありますが、料理もコックだけではなく、食材やレシピ、メニューの豊富さなど、いろいろな要素があって、料理全体が評価されるはずです。
    また、ジュースを飲むのに、レストランに行かずに、コンビニや自動販売機で買うことが多いと思いますが、それは、コンビニや自動販売機を皆さんは知っているから、選択肢として選べます。
    そのため、企業の皆様は、知らないのではなく、選択肢を持つことが、重要になるかと思います。

    ヘッドレスCMSがセキュリティに強い理由

    こちらも非エンジニアでも簡単に理解できます。

    blog-jam-img06.png
    図4:ヘッドレスCMSがセキュリティに強い理由

    ▼従来のCMS
    動的に出力するため、攻撃者が攻撃する対象が多いです。

    ▼モダン開発のヘッドレスCMS
    誰でも閲覧できるものしか置いていないため、攻撃者が攻撃する対象が少ないです。

    ※上記は、大枠の比較説明ですが、ヘッドレスCMSも攻撃する対象がないようにするためのインフラ作業など、セキュリティ対策は取る必要があります。

    前段落でも、余計な処理をしない分、サーバ費用が安いとお伝えしましたが、セキュリティの部分でも必要最低限で済むため、ランニング費用も安くなることがほとんどです。

    セキュリティが担保しやすく、サーバ費用も安い、ヘッドレスCMSは、そんな素敵なCMSです。

    その他、静的ページを吐き出しているのみのため、従来のCMSより、部分的にCMS(たとえば、ニュースページのみCMS)にし、それ以外はCMS管理外にすることができます。そのため、より簡単に導入できます。

    貴社サイトがヘッドレスCMSの導入に適しているかは、下記をダウンロードしていただき、ご確認ください。

    ここまでで、必ず最初の話題に上る、セキュリティの堅牢性を保ちたい、サイトの表示速度を早くしたい、新しいアーキテクチャにして、ランニング費用を下げたい、という3つの課題をモダン開発はクリアしてくれましたが、デメリットはあるのでしょうか。

    モダン開発のデメリットについて

    サイト閲覧者側の視点では、ご紹介しているモダン開発は、デメリットがありません。

    サイト運営側の視点では、向いていないプロジェクトがあることは確かです。しかし現在、欧米の有名なITサービスは、APIファーストなモダン開発をしているサービスが主導権を得ています。

    そのためCMSも、ご紹介しているモダン開発が主流になっていくでしょう。

    ただし、日本においては、下記3点がネックになるかと思います。

    • 従来のサーバ環境から大きく変更できない
    • モダン開発をするに当たってエンジニアが不足している
    • システムベンダーがモダン開発を理解していない

    1については、次の段落にてご説明します。

    2と3に関しては、Web業界の話のため、飛ばしていただいて構いませんが、簡単に記載しておきます。

    ※わからない単語が出てきても、今は飛ばしていただいて構いません。

    大きな理由は、Webエンジニアリングの分野としては日本が後進国になっており、モダン開発の土壌が会社として作れていないことが多いためです。
    現場エンジニアが遅れてしまっていて、なおかつ、その上のマネージャーはさらに情報が遅れておることが、大きな原因です。

    その理由としてエンジニアの情報の多くが、英語で書かれており、英語が不得意な日本人エンジニアは英語圏の外国人エンジニアに比べて情報が遅いことは否めません。

    それに拍車をかけて、Webのモダン開発では、APIファーストになっており、フロントエンドエンジニアがバックエンド領域を理解し、インフラ領域も理解しないといけない状況で、フロントエンドエンジニアの業務範囲が拡大し、忙しさが倍増し、需要と供給のバランスが崩れて、人員単価も高額になっています。

    また、システムベンダーは、バックエンド領域から広げずに、従来システムを提供することが多いようです。
    海外では、バックエンドエンジニアが、フロントエンドエンジニアにコンバートすることが多くなっていますが、日本ではまだまだ少なく感じています。

    バックエンドエンジニアの進化は、マーケティングでのデータを扱う分野としては、さらなる発展がありますし、AI進化にともない仕事は増えるでしょう。それにAPIファーストでBFFを作るのがフロントエンドエンジニアの仕事になったとはいえ、それでもその先はバックエンドエンジニアに活躍してもらわないといけない領域がたくさんあります。

    なお、アメリカのシリコンバレーのWeb開発の多くは、システムアーキテクチャは本国のアメリカ人が作ることがあっても、その先のエンジニアリングは、アジア圏を含めた海外の人間であることが多く、よりグローバルな作り方をしています。

    本サイトも、モダン開発をしております。システムアーキテクチャは、編集長の配下であり、最近、日本の市民権を取得しましたが英語圏の外国人エンジニアが担当しております。
    また、コロナの影響で、途中から、3名の外国人エンジニアが外国から開発に関わってもらい、11月には、日本からもう1名の編集長の配下の外国人エンジニアが参加しております。

    そういった時代の流れを鑑みて、外国人エンジニアについて理解していただくために、別途、彼らへのインタビューの企画しておりますので、その時にさらに、本件については掘り下げていきたいと考えております。

    モダン開発に必要なインフラ環境について

    ここからは、少し難しくなってきますが、それでも3章と4章が理解できていれば、すんなりと理解できると思います。また、この章では、非エンジニアの方は、サーバの構成をなんとなく、理解できれば大丈夫です。

    今までの図では、CMS管理画面から、閲覧者に情報が届くまでのフローを省いてきましたので、そちらからご紹介します。

    blog-jam-img07.png
    図5:モダン開発に必要なインフラ環境について

    ご覧になって、従来のCMSと、モダン開発のヘッドレスCMSでは、サーバ構成が違うのがなんとなく、ご理解いただけるのではないでしょうか。

    本サイトのサーバ構成図は、別の記事にてご紹介させていただきますが、簡単に違いをお伝えすると、下記の通りです。

    ▼従来のCMS
    LAMP環境が主流です。

    今後は覚える必要がない時代になってきておりますが、L(Linux)=OS、A(Apache)=WEBサーバ、M(MySQL)=DBサーバ、P(PHP or Perl)=プログラミング言語で、構成された環境で、多くのWEBは未だにこの環境が多いはずで、編集長もこちらの時代の方が長いです。

    日本でも2015年頃から、多くのWebべンダーも、AWSなどのクラウドベースにシフトしていきましたが、それでも、LAMP環境をクラウドにしているだけという印象が否めませんでした。

    ▼モダン開発でのヘッドレスCMS
    本サイトもそうですが、モダン開発のヘッドレスCMSでは、JavaScriptを利用したAPIファーストで作成されております。また、Node.jsがインストールしてあり、静的サイトジェネレーターが自動で実行できるサーバレス環境が望ましいです。
    それが簡単にできるのが、AWSやGCPなどのクラウドベースです。AWSではサーバレス環境として代表的なLambda(次の段落で説明します)があり、本サイトでも利用しています。

    AWSのLambdaに対抗して、GCPもCloud Functionsがあります。AWSのシェアもサービス拡充も圧倒的ですが、編集長の個人的な意見では各Googleサービスとのデータ連携を考えると、GCPの方がマーケティングの観点でもAWSより良い点もあり、まだまだAWSの1択ではないため、頑張って欲しいです。

    上記の通り、AWSなどのクラウド環境に変えないと、モダン開発は難しいです。しかし先日、ご要望はモダン開発のヘッドレスCMSにマッチしていましたが、クラウド外のLAMP環境でサーバ構築しているため、踏み切ることができないお客様がいらっしゃいました。

    そのため、サーバ環境をご検討の際には、クラウド環境を選択肢に入れて、今後のシステム環境も視野に入れてからプロジェクトを進めることをお勧めします。

    当社では、サーバ環境構築まで支援しております。
    モダン開発のヘッドレスCMSである、本システムのサーバ概要図をダウンロードできるようにいたしました。
    中間CV導線「モダン開発のヘッドレスCMSのサーバ構成図」は下記からダウンロードしていただき、ご確認ください。

    サーバレス環境について

    サーバレスとは何か、「サーバがないのに、Webが閲覧できるわけがない」と思われるでしょうが、その通りで、サーバはあります。

    サーバレスとは、「一部のサーバが一時的に稼働していないのに、サービスが問題なく提供できているサーバ環境」です。これだけでは難しいですが、これもすごく簡単に理解できます。

    blog-jam-img08.png
    図6:サーバレス環境とは

    サーバレス環境では、基本的には、サーバが分離されており、閲覧者とサイト運営者のサーバの行き来は、ネットワークから分離した一方通行です。

    前の章にてLambdaというサーバレス環境をお伝えしましたが、モダン開発では、静的サイトジェネレーターというのがあります。こちらがLambdaサーバの役割です。

    ※CodeBuildなどのサーバの詳細構成の話は、別の記事のサーバ環境にて詳しくお伝え致します。

    3章では、コックを必要としていないのが、ヘッドレスCMSだとお伝えしましたが、コンビニエンスストアのお弁当も、コックが現場にいないだけで、工場で大量に作って出荷しているからお弁当が売れるだけです。この例に当てはめると、Lambdaサーバの一部のマシンは、工場に当たります。
    つまり、静的サイトジェネレーターがあることで、事前に静的ファイルが作れるため、従来のCMSのように、アクセスがあるたびに閲覧データを生成する必要がありません。そのため、コックが必要ないのです。

    では、サーバレスを図で表します。
    下記(図7)の隠れているサーバは、サイト運営者が作業していない時は、必要としないサーバです。

    簡単にいうと、それがサーバレスと言われるゆえんです。隠れているサーバがいなくても、サイト閲覧者はサイトが見られて、サービスが止まらないわけです。

    blog-jam-img09.png
    図7:サーバレス環境にて、サーバレスなサーバとは

    また、通常クラウドサーバでも、人を雇っていて、月給を支払うのと同じで、毎月固定の費用を請求されますが、LambdaサーバやCodeBuildなどは、実行した時だけしか請求されないため、本当の意味でのサーバレス(実行している以外、待機もしていなく存在もしないサーバ)です。またそのため、従来のCMSよりサーバ構成が複雑になっているにもかかわらず、費用がリーズナブルになります。

    ※本サイトは2020年10月にリリースしましたが、同月のAWS請求額は、Lambdaは0ドル、CodeBuildは1ドル未満です。実行している数がどれも少ない訳ではなく、開発環境と本番環境もこみでGitも連携しているため、ビルドもリリース作業のため数えきれないほどしております。

    最後に、JAMstackについて

    blog-jam-img10.png

    冒頭から「モダン開発のヘッドレスCMS」という、あいまいな伝え方でしたが、今回ご紹介した開発手法は「JAMstack」というものです。

    JAMstackは、「JavaScript」「APIs」「Markup」の3つの技術を組み合わせた、WEBアーキテクチャです。APIなど省きましたが、大枠は、本記事に書かれている内容です。

    ヘッドレスCMSでも、歴史があり、色々と試行錯誤を繰り返して、今回、ご紹介したJAMstackが生まれました。
    単にSPA(シングル・ページ・アクション)で作るとSEO問題が発生しました。
    そのためSSR(サーバ・サイド・レンダリング)で作り、SEO問題は解決できましたが、別サーバが必要になり複雑な構成になってしまいました。
    それであれば、SSG(スタティック=静的・サイト・ジェネレーター)で開発することが最適となり、インフラ構成も考えていき、今に至ります。

    7章の図の赤枠に記載ある、静的サイトジェネレーターとありますが、それがそのままSSGのことを指しますので、SSGも簡単には、ご理解いただけたと思います。

    なお、SSGとJAMstackの違いに関しては、JAMstackはサーバ構成やSSGが自動実行できる環境を含めたアーキテクチャです。JAMstackはSSGですが、SSGがJAMstackとは限りません。

    JAMstack開発には、SSGを自動実行できるためのサーバ構成やCDNでの負荷分散を含めたインフラ環境の考えも根付いているため、それを忠実に本サイトでは実行しています。

    サーバ構成も、もう少し触れたかったのですが、次回の記事にてご紹介します。

    今回、全く触れませんでしたが、JAMstackを対象としたヘッドレスCMSは80製品ほどあります。

    ▼参考
    https://jamstack.org/headless-cms/

    本サイトでは、世界シェア率と拡張性を考えてStrapiというCMSを選定しました。
    Strapi に選定した理由に関しては、ヘッドレスCMSの比較表も含めて、別記事にてご紹介させてください。

    日本製のmicroCMSも別プロジェクトで利用しておりますが、日本語対応で導入のハードルが高くなく、要件によっては、とてもお薦めです。

    横文字が多くて、非エンジニアの方は、理解が大変だったと思いますが、思ったより難しくなかったのではないでしょうか?

    当社では、モダン開発である、JAMstackのヘッドレスCMSの制作・開発を推奨しております。

    ぜひ、CMS環境でお悩みがあれば、ご相談ください。