Web制作の外注を検討する際、またはコンペティションを検討する際は、外注先に「なぜWebサイト制作（リニューアル）するのか？」を深く理解してもらわないければ、Web制作企業やクリエイティブエージェンシーから、良いアイデアやアウトプットは出てきません。 本記事では、コンペ参加のWeb制作会社も納得のRFP（提案依頼書）の記載のポイントや注意点を解説していきます。 RFPに記載すべき項目一覧RFPの基本的な項目サイト制作に欠かせない基本項目です。特に下記の項目は、外注先のWeb制作会社で行う市場調査だけでは見えてこない、業界の知見がある発注側だからわかる！といった内容も入れて行きたいですね。

大まかな前提条件はじめに要件定義、要件開発に関する記事、書籍は多くありますが（当然ながら特にシステム開発関連が多いですが）、ここではWebサイトのリニューアルに限定した要件定義の内容や進め方について、これまでの経験を元に、私なりにまとめていきたいと思います。 Webサイトについては今は、新規につくる場合のほうがレアケースかと思われるため、リニューアルにおける「要件定義」としています。 また、リニューアルの規模感によっても当然内容は変わってきますが、想定としては３ヶ月から１年程度の期間で行うリニューアルを想定した内容となります。 受託案件（発注側からは外注する）の想定となりますが、発注側、受注側双方の目線で記載しますが、基本受注側（制作者側）の内容として記載していきます。 対象サイトについて特に限定するものではありませんが、なんらかの『企業サイト』を想定しています。 Webサイトリニューアル

久しぶりのnote投稿です。今回は自分の勉強がてら、UX・情報設計・アジャイル開発など、デザインに関わる様々な局面で知っておくと役立つフレームワークを集めてみました。 有名なものからデザイン以外にも使えそうなものまで幅広く選んでいますので、気になるものがあれば改めて実作業に生かすなり、掘り下げて研究するなり、資料に生かすなりしてもらえると良いのではないかと思います。 （ちなみにここでいう「フレームワーク」とは共通して用いることのできる考え方や思考の型や枠のようなもので、いわゆるCSSフレームワークの類ではありませんので、その点ご了承ください） 1.UXの5段階モデル まずは有名なUXの5段階モデル。アメリカのUXデザイナーであるJesse James Garrett 氏が著書『Elements of User Experience（ウェブ戦略としての「ユーザーエクスペリエンス」）』にて提唱

GA4は進化を遂げているさなかにあり、扱う難易度も格段に高まっていることもあって、急いで導入することをためらっているケースが多いようです。GA4は、今までのGAのバージョンアップとはまったく異なります。なるべく早くGA4を導入するべきだと考える3つの理由があります。 ただし、GA4のデフォルト設定のままにしてくと、役立つ分析ができないどころか、不完全なゴミデータが増えるだけです。全面的に導入する前の段階であっても、将来に後悔しないよう、今すぐ取り組んでおきたいGA4の設定とその理由について具体的に紹介します。 （その1）GAのサンセットは来年にやってくる?! GA4は、Googleアナリティクス（GA）のこれまでのバージョンアップとは異なり、別ツールとして考えた方が良いほど、大きく変わりました。データの保持の仕方も根本的に変わっています。GAの普及率を考えると、この2つのツールを稼働させて

みなさんこんにちは。@ryuzeeです。今日は小ネタです。 3分くらいでスクラムをざっくり分かってもらうための説明を以前作ったのですが、意外と役に立っているのでブログで公開しておきます。 この記述については、CC BY-SA 4.0ライセンスとします。 クレジット表記（@ryuzee / Ryutaro Yoshiba）のもとで共有や派生物を作って構いません（その場合は元のライセンスを継承します）。 製品の目標や方向性、成果に責任を持つ人を1人決めます（＝プロダクトオーナー）製品の目標や実現したいことを一覧にして、常に最新の状態にしておきます（＝プロダクトバックログ）製品を作るのに必要な作業は色々な能力を持った開発者たちに任せます（デベロッパー）頻繁に動くものを見たほうが安心なので、固定の短い期間に区切って繰り返します（＝スプリント）短い期間をうまく過ごして成果を出すには計画が必要です（＝

「データベース設計」という言葉の定義はあいまいで、論理設計と物理設計であるとする場合と、概念設計と論理設計と物理設計であるとする場合があります。 きちんとデータベースを学んだ人であれば「あー…」と思うかもしれませんが、意外とエンジニアの多くはテーブル設計やSQL、INDEXを学ぶことはあっても、データベース設計全体を学ぶ人というのはかなり希少です。 だから人によってデータベース設計の定義が変わるのは仕方がないかも知れません。 概念設計でシステム開発における業務分析を行ない、システムに依存しない論理的かつ正規化されたデータモデルを作成します。 論理設計では、アプリケーションからの性能要求を考慮し、必要があれば非正規化を行ないます。また、データベースの論理的な構造（テーブル）と索引（インデックス）を決定します。さらに、利用者から見たデータ構造（ビュー）も作成します。 つまり、概念設計で理想的な