DEVELOPMENT

投稿済FaceBookページのOGPの最新化

こんにちは12grid岡本です。 今回はOGPの最新化という事で、サイト運営者の方や技術者向けの話になります。 FaceBookへ投稿後、OGPのTitleやDiscriptionを変更したし、OGPの更新を反映させる必要に迫られることがあると思います。 そんな時、最新のwebページの内容がFacebookページに反映されない! と、はまらないよう手順を残します。

OGP確認方法

シェアデバッカーを利用します。 https://developers.facebook.com/tools/debug/ FaceBookがキャッシュしているOGP情報を確認します。

スクレ―ピング

前述のシェアデバッカーの「もう一度スクレイピング」で最新を読み込みます。 ここまでで問題があれば実装を確認してください。 補足) ウェブサイトから情報を抽出する行為です。Facebook自体、定期的にサイトの最新情報を抽出しに来ますがその周期は指定できません。明示的に最新ページの情報を取得させるためにこの操作を行います。

最新を反映

日付 or 時間が表示されている赤枠のアンカーをクリックします。 ページ遷移して記事ページに行くと、 赤枠の「シェアした添付ファイルを更新」が選べます。 クリックすると、Viewがモーダルで表示されるので保存します。 以上で反映されます。  

Postfixのあれこれ

北海道でも桜の季節になり、外出もしやすい時期になってきました。 新年度(年度末)を迎えるお客様も多く、新規に案件を頂いております。 新規の案件にて、お客様がWebページを公開するサーバがない場合や、現在利用中のサーバのスペックが足りないため移設後に・・・などの理由から黒い画面で過ごす時間も増えてきました。 そこで今回は、VPSなどでメールを利用する場合に使うことの多い「Postfix」について役立つTips(コマンド)をまとめてみました。 ※CentOSをベースに記載しております。  

Postfixのバージョン確認

下記のコマンドを実行することでバージョンが確認できます。

Postfixの現在の設定を確認

下記のコマンドを実行することで設定が確認できます。

Postfixの現在の設定と初期値での差分を確認

下記のコマンドを実行することで差分が確認できます。  

Postfixのメールキューの残数

下記のコマンドを実行することでメールキューの残数が確認できます。

メールキューの内容を確認

下記のコマンドを実行することで、[QueueID]にて指定したメールキューの内容が確認できます。

 メールキューを削除

下記のコマンドを実行することで、[QueueID]にて指定したメールキューを削除できます。

 一括でメールキューを削除

下記のコマンドを実行することでなかったことになります。   これだけを知っていてもサーバの構築や運用ができる訳ではありませんが、動作がおかしいなどと思った際に原因を特定するための1つの手段にはなるかもしれません。 早い段階で原因が特定できれば、それに対しての暫定対応も行いやすくなります。 今回は「Postfix」を中心にTipsを載せてみましたが、今後もすぐに使えて役に立つ(?)Tipsを載せていきます。

drupal7でハマった ver.2

太り過ぎたのでランニング始めたら疲労骨折しました。 こんにちは12grid岡本です。 drupal初心者がハマった。の第2段です。

Taxonomyページが超遅い

タクソノミー を page--taxonomy.tpl.php で拾い一覧画面として利用していたのですが、記事が数百を超えたあたりからレスポンスが10秒以上かかる。 タクソノミー自体もまだ1000未満。 Holy shit! page--taxonomy.tpl.php に来るまで10秒以上かかっているのでコアのどこかで処理がループでもしてるのか... ざっとコードを潜ってみるもあたりがつかず(無謀) コミュニティサイトでそれっぽい事例がいくつかありましたが解消にはつながらず。 https://www.drupal.org/node/131189 https://www.drupal.org/node/163448 結論としてはpage--taxonomy.tpl.phpを利用することを諦め、Basicのnodeページを別途用意してリダイレクトさせ、仮想page--taxonomy.tpl.php とすることで回避。 そもそもなんでnode?と言われそうですが(言われましたが)、基本的にはViewsでいいと思います。 今回の場合、既にCustomモジュールの共通処理をViewsの代替で利用していたので、いまさらViewsで作るのは都合が悪かっただけです。Viewsで複雑なSQL書いたり、特殊なページャ作るの難しいんですよね。 どなたかマニアックな処理中心の実践向けDrupal書籍出して頂けませんか。 ※遅延処理を特定する必要がある場合は、xhprofを導入すると良いかと思います。

Viewsのリレーションがぶっ壊れた

まーたTaxonomyか!Son of a bitch!! 気づいたら壊れてました。Viewsには手を加えず数か月。 となると何かモジュールいじって関連付けがはがされた可能性が大ですが、心当たりがない。 同一モジュール同一設定の別環境では発生せず。リレーションを張りなおすこともできず。 ViewsやめてCustomモジュールでSQL書きました。

まとめ

なんら解決策を見いだせぬままフィニッシュです。 直すほどにスクラッチに寄っていく。でも「がわはDrupalです」。うーん。 関連記事 drupal7でハマった ver.1

中国版LINE – WeChat(微信)ボタンを配置する

こんにちは12grid岡本です。 中国SNSの状況を調べてみた で記載した流れでWeChatを使ってみようと思います。 前回の 中国版Facebook+Twitter - Weibo(微博)ボタンを配置する同様、こちらもサイト情報を拡散させるためのシェアボタンの配置をゴールに設定。

1.武器の調達

英語のリファレンスがありました。 http://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_open/index http://admin.wechat.com/wiki/index.php?title=Main_Page これもかな。weixinって何だろう。(微信=weixin と読むようです) https://open.weixin.qq.com/

2.アカウントを開設

https://www.wechat.com/ja/ Web WeChat だけでよいのですが、アプリとの連携でしか使えないようなのでまずiPhoneに入れます。 携帯にWeChatを入れたら、「発見」→「QRコードのスキャン」で読み込むと 携帯でログインを押します。 入れました。

3.ボタンを配置

ボタンの素材はこちらにありましたが、Weiboで利用したようなJS-SDKが見つけられず。 長時間探すのもあれなので自前で入れてみます。shareはgetで以下の形式。 ※SiteUrlはurlencodeしてください シェアボタンのデザインとしてよいかはさておき、このようになります。 クリックして頂くとわかりますが、投稿フォームは用意されていませんでした。 少し前のLINEと同じQRコードを読み込ませるスタイル。 (今はLINE itがあるので投稿フォームも利用できます) QRを読み込んでメニューから「チャットに送信」か「モーメント上で共有」を選択。 「チャットに送信」だとこのように投稿されました。 ちなみにモバイルからクリックすると URLをクリックしてペーストで手動シェア。 ということで目標は達成。 投稿フォームが欲しいとなると、自前でウィンドウを用意してPOSTで送信させるしかなさそうです。そのうちWeChatにもLINE it 相当が導入されそうな気もしますが。

まとめ

こちらもドキュメントを見るとLINEと似てるなという印象でしたが、今回のように必ずしも同じ機能が提供されているわけではないようです。 公式以外にもネットサーフィンをしまくったうえ、想像以上に中国語がフィーリングで読み取れずに翻訳を繰り返してどっと疲れてしまいましたが、実装そのものは一般的なSNSと同じ感覚でよさそうです。

初めてのシステム導入。システム作成費用の相場は?

こんにちは12grid岡本です。 先日システムのご相談を受けた際、他社導入済みのシステムに関して 「システム作成費用が高かったのか低かったのかもいまだにわからない」 と仰っている方がいました。 結論から言うと、要件を伺い見積もってみないとプロの我々にもわかりません。 作るモノによるのです。 ただ、システム費用は車や家の修繕費用と比較すると想像すらしにくいと感じます。 今回は「初めてのシステム導入で右も左もわからない!」という方のために、わからない部分を順に見てみます。 関連記事 はじめての制作会社選びに失敗しないための重要な5ポイント! ホームページ制作依頼前に知っておきたい!制作料金の相場とは?

そもそも何の費用がかかるのか?

大雑把に分けると3点です。 1.設備費、代行手数料 サーバ設置、SSL取得(セキュリティ証明書)、ドメインの取得などです。 基本的にこれらは専門業者に依頼することになるため、お客様自身が契約されるか、システム会社に契約・設定を代行依頼する事で費用が発生します。 ちなみにSSLは赤枠の鍵マークの部分、ドメインは「12grid.co.jp」の名前です。 2.開発費用 システムそのものの開発費用です。 画面として見える部分や、内部でおこなうデータ計算や更新処理を作成したりします。 開発会社の「人件費」が相当します。 ここが大きな費用にあたりますが、システムの場合は画面数よりも内部的に何を行う処理かが費用に大きく影響します。 複雑なデータ管理、全銀協データ連携、クレジット決済...etc そのため一概に費用を明示できないのです。 3.保守費用 主にデータのバックアップ取得や、稼働状況の監視、不正アクセスの検知などを行います。 何をどこまでおこなうかは、お客様の業態や要望により異なります。 こちらも開発会社の「人件費」が相当します。

人件費の相場は?

システムエンジニア入門様のサイトに記載がありました。 http://nyumon-info.com/tanka/souba.html システム費用の見積り単位として使われるのが「人日」「人月」という単位です。 1人月の作業価格は、中小初級SEで60万、大手超上級SEともなると200万とのこと。 (SE=システムエンジニア) ※あくまで参考としてください。60万未満のSE、200万以上かかるSEもいます。 次いで、システムを作るまでに何人の人がどのくらいの時間をかける必要があるかを計算します。 中小初級SE 2名 × 5か月だと600万円になります。 後述しますが、「相場より安い=良い」「相場より高い=悪い」ではありません。

見積もり人日の根拠は?

必要なシステムの要件を伺い、画面数・機能数・難易度で作業人日を算出します。 システム部門がある、またはシステム導入実績のあるお客様だと、画面毎の人日の根拠を求める事もできます。 ですが、一般のお客様には結局妥当か否かの判断は困難ですね。

見積もりの妥当性を確認する方法

一般的な手法として「相見積もり」があります。2,3社見積もれば充分です。 ほとんどのシステム会社はホームページに問い合わせページを設けていますので活用しましょう。 電話での問い合わせでも構いません。 システム会社の選定は以下が参考になります。 はじめての制作会社選びに失敗しないための重要な5ポイント! 見積もり時のPoint 「何がおこなえるシステムが必要なのか」をできるだけ詳しく伝えると良いです。 後から機能を追加するよりも、事前に伝えて頂く方が費用が抑えられることが多いのです。 家を建てた後で、「裏口が必要だった」と言われてしまうことに似ています。

ひたすら安さを追求して選んだ結果

・言われたことしかしない ・その後のケアがない ・やたらと追加費用がかかる ・後々セキュリティの問題が発覚した ・機能の拡張ができない(システムがパッケージ化されている) こういった事は決して珍しくありません。 安いには安いなりの理由があります。 逆に相場より高い=技術力・提案力の高い場合もあります。 ・納得のいく説明を丁寧にしてくれた ・開発費用を抑える代案を提案してくれた ・より使い易いシステム仕様を提案してくれた ・伝え忘れた処理も取り入れてくれていた 等々、最終的に安く済むこともあります。

私の考える最適な方法

と、一般的な内容を書きましたが、私が考えるベストな方法は、決める前に「直接会う」です。 わたしは良いモノになるかどうかは結局「人」だと考えています。 それらを共におこなえる人間であるか判断するために、直接顔を合わせるのは大切ではないでしょうか。 システムはただ作ればいい。というものではありません。 導入したことにより経営にどのようなメリットをもたらすのか、考え、今後の運用に対応してくれる相手を探す必要があります。 保守の有無に関わらず、システムを一度導入すると様々な問題に直面します。 そんな時に相談できる相手を作っておくことは非常に重要だと思います。 ただし、距離や時間の問題で「会う」ことが難しい方も多くいらっしゃると思います。 12gridでは、このようなオウンドメディアでも会社の魅力を伝えられるよう、情報を発信していければと考えています。 関連記事 はじめての制作会社選びに失敗しないための重要な5ポイント! ホームページ制作依頼前に知っておきたい!制作料金の相場とは?

中国版Facebook+Twitter – Weibo(微博)ボタンを配置する

こんにちは12grid岡本です。 先日の記事、中国SNSの状況を調べてみた で記載した流れでWeiboを使ってみようと思います。 小難しい事をして時間をかけ過ぎると途中で挫折しかねないので、オーソドックスにサイト情報を拡散させるためのシェアボタン配置をゴールに設定。

1.武器の調達

英語のリファレンスがありました。 http://open.weibo.com/wiki/API%E6%96%87%E6%A1%A3/en 何とかなりそう。というかシェアボタン程度だと終わった感もありますが、一応最後までやります。

2.アカウントを開設

まずは公式 何故か開いただけで疲れてくる。 登録ボタンは右上と相場が決まっているので適当に押してみます。 おお。 「アカウントがない? そんな人はここだよ!」 っぽい「注册微博」を押してみます。 おお。 なんてことをやってると日が暮れそうなのでわからなければ翻訳してください。 言語は違えどやることは同じでした。 できました。2,3分です。 注意点はSMS携帯認証が入ってるので電話番号が必要なくらいでした。

3.ボタンを配置

http://open.weibo.com/sharebutton shareボタンのjsが用意されていました。 やはり終わった感が否めませんが、一応最後までやります。 STEP1:ボタンの見栄えを選択して内容を記載、画像は3つまで STEP2:AppKeyの設定。今回は使わないのでスルー STEP3:Codeが生成されるので貼り付けて 非常に簡単です。XSSが出てしまうのでここではコードのみ記載します。 こんな感じになります。 クリックすると、設定した内容でシェアウィンドウが開きます。 投稿に画像を含める場合は選択しておく必要があります。 (画像をクリックすると✔が付きます) 左の画像のみ選択しておくと以下のように投稿されます。

4.カスタマイズ方法

流石に味気ないのでボタンの画像を変更したい場合などのカスタムも試してみます。 提供されるJSは使わず、URLのパラメータを組み立てます。 単純なリンクだと Weiboのボタンにしてね このようになります。 これにボタン用の画像をあてるなり、CSSをあてるなりするだけです。
KEY VALUE
type button / icon
style simple / number / text / full
title 内容
pic 画像URL パイプ(||)で区切る。最大3つ
searchPic ture / false
language zh_cn / zh_tw

まとめ

特に落とし穴もなく、感覚的にはFacebookやTwitterと同じ感じでした。 掘り下げるのは業務要件があればいずれ。 取りあえずできること、できないことを把握しておけば大丈夫かなという印象ですが、ざっと見た限り「Facebookで出来てWeiboで出来ない」ことはなさそうです。 WeChatも試してみます。

Webアプリケーションの脆弱性

Webアプリケーションの脆弱性、、、怖いですよね。 何かあった時の責任を考えると、慎重に取り組まなければならない課題です。

そもそも脆弱性って

下記、引用(http://it-trend.jp/words/zeijaku)です。
脆弱性とは、コンピュータやネットワークなどにおいて、システム上の欠陥や仕様上の問題点の事を指す。 ハードウェアの欠陥やソフトウェアのバグを始め、開発者が予想しなかった利用形態や設計の際の見落としなど、潜在的な問題点もある。
Webアプリケーションでのバグは、簡易なものから潜在的なものまで存在していると思われますが、それらにどんな危険性があるかを下記にまとめてみました。

XSS(クロスサイトスクリプティング)

Webアプリケーションの中には、利用者からのリクエスト(GETやPOSTなどでのパラメータ)やHTTPヘッダの情報をもとにページを表示するものがあります。 ここでページへの出力処理に問題があると、そのページにスクリプト等が埋め込まれてしまい、ページを閲覧している利用者、しいてはサイト全体へ影響していきます。

脆弱性によるリスク

  • 本物のサイト上に、存在しない偽ページが表示される
  • ブラウザが保存しているCookieを取得される
  • 悪意のあるCookieをブラウザに保存させられる

セッション管理に関する脆弱性

Webアプリケーションの中には、セッションID(利用者を識別するための情報)を発行し、セッション管理を行っているものがあります。 セッション管理に関する脆弱性については、下記2つが有名なものです。

セッション・ハイジャック

セッションIDの発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッションIDを不正に取得され、その利用者になりすましてアクセスされてしまう可能性があります。

セッションフィクセーション

悪意のある人があらかじめ用意したセッションIDを、何らかの方法で利用者へ使用させ、利用者がこれに気付かずにパスワードを入力するなどしてログインすると起こりうる問題です。 この攻撃に成功すると、あらかじめ用意したセッションIDを利用し、利用者になりすましてサイトにアクセスすることができてしまいます。

脆弱性によるリスク

  • 利用中のサービスの悪用
  • 情報の改竄(変更や削除)、新規登録
  • 非公開情報の閲覧

SQLインジェクション

Webアプリケーションにて、データベース(OracleやMySQLなど)が使われることが多いです。 そのデータベースへ利用者からのリクエスト(GETやPOSTなどでのパラメータ)をもとに、SQL文(命令文)や条件を設定することになると思われますが、SQL文の組立て方法に問題がある場合、攻撃によってデータベースの不正利用が可能となる場合があります。

脆弱性によるリスク

  • 非公開情報の閲覧
  • 不正ログイン
  • 情報の改竄(変更や削除)、新規登録
  • ストアドプロシージャ等を利用したOSコマンドの実行

CSRF(クロスサイト・リクエスト・フォージェリ)

Webアプリケーションの中には、サービスの提供に際しログイン機能を設けているものがあります。 ログインした利用者からのリクエストについて、その利用者が意図したリクエストであるかどうかを識別する仕組みを持たないウェブサイトは、外部サイトを経由し悪意のあるリクエストを受け入れてしまう場合があります。 このようなWebアプリケーションにログインした利用者は、予期しない操作を行ってしまう可能性があります。

脆弱性によるリスク

  • 利用中のサービスの悪用
  • 情報の改竄(変更や削除)、新規登録
今回記載したもの以外にも、たくさんの脆弱性があります。 システムやアプリケーションを作るだけではなく、これらの内容にも対応していくために、セキュリティ関連の情報にもアンテナを張り続ける必要だと思われます。 次回は脆弱性を発見するための手段を紹介していきます。

drupal7でハマった ver.1

drupal初心者が陥った内容を残しておきます。 他にも出てきそうなので初回からver1を宣言。 本来はお作法的なものを備忘にしたいのですが、未だに使いこなせません。 今回は解析に手間取ったいくつかを挙げておきます。

ドメインを変更(またはリダイレクト)させたらJS/CSSが効かなくなった

settings.phpのbase_urlを確認。古い場合は最新に設定。または未設定に戻す。

httpsにした場合、JS/cssが効かない

settings.phpのbase_urlをフルパスで設定することで有効になります。 base_urlが未指定の場合はhttp+ドメインでパスを作っているのでしょうか。

特定のコントリビュートモジュールを利用時、設定値が反映されない

これは結構ありました。 Drupalモジュールのお作法(?)として設定値はvariableのテーブルで管理させているようです。 しかし、一部のコントリビュートモジュールでは管理画面からこの値を変更する術がないことがあります。 admin/config/system/variable から操作できそうでしたが、断念。 コードを見ると初期化が足りなかったりするので、まあバグなんでしょうね。 反映させられないときは以下で確認してみてください。 select * from variable where name like '%モジュール名%'; valueに古い設定値が入っていればこれが原因です。 value = 's:11:"http://hoge" このような形で格納されている場合、↓のように直接update。(Stringはs、intはiの:桁数) value = 's:17:"https://hogehoge2

コントリビュートモジュールが動かない

これは非常に稀だと思うのですが、修正patchが公開されているにもかかわらず、ダウンロードファイルが最新になっていないものがありました。 log を見るとundifine function ~ 等、根本的にwhat?!と思う挙動を示した場合、まずpatchの有無を確認してみてください。 想像で他人の実装の続きをするとかはしなくないですね。。

まとめ

Drupalに限りませんが、まず基本的な仕組みをつかむこと。 低コストで実装できること・できないこと(スクラッチ寄り)を把握するのが重要そうです。 ちなみに初期実装中、カスタム定義項目の型変更などで直接SQLの手パッチをするなどして Drupalそのものが動かなくなることが何度かありました(汗) core系には手を加えずhookさせなさい、がCMSの指針なのでDB側もまあ当然なのですが。 やむなく行う場合はbackupは必ず取りましょう。 という事で上記の修正方法は独自であり非推奨です。解析の参考程度にどうぞ。 DrupalはDries Buytaertの登録商標です。 https://www.drupal.org/

FuelPHPを使ってみた~その1

Googleトレンドで検索する限り底辺を行っているFuelPHPですが、慣れてしまうと速度もそれなりで良いフレームワークと言う認識でしたが、トレンド的には「Laravel」が人気なんでしょうね。 自分の受けている案件では、2017年現在でもFuelPHPで実装の案件がいくつもありますが、一部の記事では新規に使わない方が的に記載されていたり・・・とさみしさを感じました。 もともと、Codeigniterを使っていた私からするとフレームワークは基本的な処理部分だけをやってくれれば良いので、その考えからFuelPHPを使っている感が強いです。 ※v2は早く出て欲しいですが・・・。 基本的な処理部分(ベース)はしっかりしていると思いますので、これから何か作るときにどのフレームワークを使おうか?と悩んでいるアナタ。 「FuelPHPはいかがですか?」

FuelPHPを使って何かをつくろう

FuelPHPは下記のサイトからダウンロードするか、composerからインストールが可能です。 ちなみにversion 1.8からはPHP7にも対応しているので安心してください。 https://fuelphp.com/ こちらのサイトから「Download v1.8.0 now!」をクリックすることでファイルがダウンロードできます。 composerを利用する場合については、別の機会に紹介していきます。 ファイルはzipで圧縮されているので、解凍することで下記のようなファイル構成を確認できます。 [Directory] docs [Directory] fuel [Directory] public [File] .gitignore [File] .travis.yml [File] CHANGELOG.md [File] composer.json [File] composer.lock [File] composer.phar [File] CONTRIBUTING.md [File] LICENSE.md [File] oil [File] README.md [File] TESTING.md 実際に触るコードとしては、「fuel/app/」と「public/assets/」の中にあります。

fuel/app/

ディレクトリがいくつもありますが、基本的にはclassesとconfigディレクトリの中を触っていきます。 classesの中には、「controller」や「model」、「presenter」が存在しています。 ちなみに、classesの中に入れたファイルは動的に読み込まれるので、独自の処理などを別クラスに書いておきcontrollerから呼び出したい場合などは、このディレクトリにファイルを置いておくといいです。 configの中には、環境別のディレクトリと共通の設定ファイル(config.phpやdb.phpなど)が設置されています。 環境に応じて設定を変えたい場合には、環境別ディレクトリに対応するファイルを設置することで有効となります。 環境の切替については、次回以降で記載していきます。

public/assets/

cssとjs、imgディレクトリが設置されています。 読んで字のごとく、cssディレクトリにはスタイルシート(xxx.css)を設置し、jsディレクトリにはスクリプトファイル(xxxx.js)、imgディレクトリには画像ファイルを置くことでViewへ表示する際に下記のような記述で呼び出すことが可能となります。 public/assets/css/style.cssをViewで出力する場合 <?php echo Asset::css('style.css'); ?> public/assets/js/script.jsをViewで出力する場合 <?php echo Asset::js('script.js'); ?> public/assets/img/img01.pngをViewで出力する場合 <?php echo Asset::img('img01.png'); ?> 上記はざっくり記述ですが、これだけでも画面上にはそれぞれのcssやjs、画像ファイルが表示されます。

今回のまとめ

ディレクトリ構成を把握することで、何となくこのディレクトリにあるファイルが何をやっているのかが描けると次のステップに進みやすくなると思います。 全体を見るとファイルがたくさんありますが、まず必要なのは上にあげた「fuel/app/」と「public/assets/」のディレクトリの中だけです。 導入への敷居を少しでも下げられるように、次回は「何かを作りはじめる」ところまで記載予定です。

ホームページ制作依頼前に知っておきたい!制作料金の相場とは?

自分のホームページが欲しい!どうも、エンジニアの吉舌です。 エンジニアの仕事をしていて、自分用のハウツーや今後同じような場面で使えそうなコードをまとめた自分用のホームページが欲しくなってきました。 簡単なページであれば用意できるのですが、もっとこう、おしゃれな?モダンな?人に自慢できるようなページが欲しいのです。 それには普段の仕事以外でもweb制作をしなければいけないという苦行が待っているため、他社に任せるとどれだけの金額がかかるのか、私なりにちょっと調べてみました。 目次
  1. 制作料金の相場
  2. 私の主観でとりまとめた相場
  3. 少しでも安くホームページを作るには
 

制作料金の相場

皆さんは一般的なホームページの制作費用はどれくらいだと思いますか? 数万円?数十万円?100万くらいかかると思っている人もいるでしょうか。 正解は「それは案件による」です! 怒らないでください!本当なんですよ! ですが、私の知っている周囲の一応の相場というものがありますので一例をご紹介しましょう。
構成設計・ディレクション(一式) 40000円~
TOPページデザイン・コーディング(トップページのみ) 60000円~
下層ページデザイン・コーディング(1ページあたり) 20000円~
CMS導入(一式) 80000円~
JavaScriptカスタマイズ(難易度による) 20000円~
  ...わかりずらいですよね? ですが時と場合によって作業の難しさが変わったりするので、制作会社としては最低金額しか載せていない場合が多いのです。 よく言われているのが、「小さなホームページであれば20万前後~50万前後、大きめのホームページで100万程度」というものです。 ですが、こちらもどんなホームページを作るかによってあてにならない場合があります。 どれくらいのページが必要なのか、どんなシステムが必要なのか、素材は用意されているのかなど、様々な要素によって制作料金が決まるため、 そこの仕様が固まっていないと「○○万円で作ります!」とは断言できないんですね。

私の主観でとりまとめた相場

断言できないとは言っても、判断の指標となる相場を知りたいですよね? そこで!私の主観での相場の一例をお教えしたいと思います。 それでは今回、町の整骨院がホームページを作りたいと考え、
  • トップページ
  • 初めての方へ
  • 当院の想い
  • 施術メニュー/料金
  • 施術の流れ
  • よくある質問
この6ページから構成されたホームページを制作依頼します。 オリジナルのデザインをしてもらい、写真も撮ってもらうことにします。 要望として、画像のスライダーを使用したい、ブログを使いたい、スマートフォン対応にしたい、以上の3点です。 結果、大体は以下のような金額になります。
構成設計・ディレクション 40000円
トップページデザイン・コーディング 40000円 × 1 = 40,000円
下層ページデザイン(共通) 20000円 × 1 = 20,000円
下層ページコーディング 15000円 × 5 = 75,000円
写真撮影 半日 40,000円
スライダー実装 5,000円
ブログ機能実装 80,000円
スマートフォン対応 60,000円
合計 360,000円
  結果的に360000円となりました。 え?町の整骨院のホームページなのにそんなにかかるの?とお思いでしょうか。 今回のホームページ制作で大きなポイントは「写真撮影」と「ブログ機能実装」です。 写真撮影のためにカメラマンを用意するとどうしても費用が高くつきます。 また、ブログ機能実装についてですが、オリジナルデザインのページにブログ機能によるお客様投稿を反映させるという作業は、皆さんが思っているより大変な作業になります。 よく「wordpressを使えば簡単でしょう?」と言われますが、それでも尚時間のかかる作業です。 タイトルが短いとき・長いときはどうする?画像があるとき・ないときはどうする?画像のサイズが小さすぎるとき・大きすぎるときはどうする?などなど様々な場面を想定して作業にあたりますので、ブログ機能実装の金額は決して高すぎるわけではないのです。 今回はありませんでしたが、予約システムなどを入れようとすると金額が更に増えます。 また、この金額はサーバーやドメインといった諸費用を含まない「単純な制作費用」ですので、総合的に考えて40万円程度が必要になるでしょう。

少しでも安くホームページを作るには

いくらホームページ制作にお金がかかると言っても、かかるお金は安い方がいいですよね? お金をかけないでホームページを用意する方法はいくつかあります。 まずwordpressなどを使って自分で作る方法ですね。 確かに安くホームページを用意することができます。 ですが元々パソコンが得意な人でさえ、初めてのホームページ制作には多大な時間と労力がかかるはずです。 餅は餅屋と申しまして、自分は自分の仕事に精を出し、ホームページはホームページ制作会社に依頼することを強くお勧めします。 では、格安ホームページ制作の業者を使うのはどうでしょう。 私個人としては全くお勧めしません。安さには安いだけの理由があるのです。 大きな特徴としてはデザインが似たり寄ったりになってしまいます。 写真やロゴ、テキストや色をお客様に合わせて変更はしますがレイアウトはほぼ同じ。 また、細かな要望に応じてくれないときもあるでしょう。そこはそう決まっているので変更することはできません、と。 じゃあホームページを少しでも安く作る方法がないのかと言われればそうではありません。 例えば、制作期間を長めに設定することで安くしてくれるかもしれません。 また、写真素材などをこちらから提供することでその分の費用をかけずに済みます。 必要な要素と不必要な要素を見極めることも重要です。 ブログ機能を欲しがるお客様は多いですが、更新の手間を考えずにブログ機能を実装し、途中でブログの更新をやめてしまうお客様は少なくありません。 であれば、最初からブログ機能はナシでホームページを用意した方がよっぽどいいと思いませんか? ちなみに以前の記事「ちょっと待って!その企業ブログは本当に必要ですか?」でブログが必要かどうかについて少しまとめています。 そういった工夫をすることで、先ほどの一例で挙がった金額360,000円を240,000円にまで下げることだってできるのです。 また、はじめてのホームページで制作会社選びに失敗しないための重要な5ポイント!では制作を依頼する際の会社選びについてまとめていますので、はじめての制作依頼前にはぜひ一度ご覧ください。   いかがでしたでしょうか? ホームページを作ろうかと考えているあなたの助けに少しでもなれたでしょうか。 ホームページは必須ではありませんが、有効に運用すれば役立つことは間違いありません。 ですので、しっかり考えしっかり比較し、後悔しないホームページを是非作ってほしいと思います。