目次
まえがき
秋は一体どこへ行ったのでしょうか？この季節は体調を崩しがちなので、しんどいですね。
寒いのもしんどいですが、暖かすぎるとそれもまたしんどいので空調の自由が効く自宅が最強です。
そんな日々を過ごしながらのお話。
地図コーディングの最後の対応
前回までで地図コーディングのほとんどは終えていましたが、今回はコーディングを終えたあとの修正対応があったので、それについてお話します。
…といっても一瞬で終わる内容なので少し内容を濃くお話します。
バグ修正と原因の究明
条件や情報などは完了していて、一見問題ないように見えるサイトでしたが、マップのホバーアニメーションがうまく動いていませんでした。
バルーン(吹き出し)の所にホバーアニメーションがついていて、そこを触れば確かにマップも差分のデザインが表示されているのですが、肝心のマップをホバーした時に何も変化がないどころか、クリックしてもそのエリアが表示されない状態でした。
色々と探ってみると、マップのホバーアニメーションをするところで問題が起きていました。
不具合解消
プロトタイプの状態では、読み込む画像ファイル名にコロン【 : 】がついている記載方法で、それでホバーアニメーションがしっかりと動くサイトもあります。
しかし、今回はエリアの指定が少し特殊だったため、記載がそのままだとうまく動きませんでした。
今回、画像ファイルにナンバリングする場合(画像_1のように)、【 : 】は使用できません。そのため、ファイル名にはアンダースコア【 _ 】が使用されていました。
実際にマップバルーンの記述を行っている場所では、str_replaceを使用して「 : と _ が入れ替わる」という記述をしていましたが、その設定をマップ自体の方にもかけなければいけませんでした。
ということでファイル名と読み込む記述を適切になるように設定して無事ことなきを得ました。
これで、地図コーディング完全討伐です！
OGP設定の修正
新しい課題として、「OGP設定の修正」というものを行いました。
その課題を行う上で必要な「環境構築」も一緒にお話ししていきます。「環境構築」とは、動的サイトの作業内容を随時確認するために、”ローカル環境”でサイトを構築することです。
WordPressサイトの環境構築
WordPressサイトの複雑さ
WordPressサイト(以下：WP)、実はこいつが一癖も二癖もある代物でして、不動産サイトとは違う構造でつくられています。不動産サイトは基本的に下層ページが重なる構造で環境構築もシンプルでした。
しかし、WPサイトはそもそもの構造が違うため、それ相応の対応をしないといけません。
説明が難しいのすが、WPはブログなどの更新や管理が簡単で、それを活用するとサイトの管理者も更新者もWinWinなサイトを構築できます。その反面、WPをローカル環境で確認するのがかなり難しい。
ローカル環境構築の難しさ
詳しいことは省略しますが、とにかくあれやこれやしてやっと構築できる + データベースと呼ばれるデータを効率的に管理・保存するための構造化された情報の集合体を扱わないといけないため、またこんがらがる作業でした。
一定の方法でできればいいのですが、使っている環境によってまたそこが異なってくるため、自分に合った方法を見つけ出すのにすごく時間を使いました。
環境構築の苦労と達成感
社内の方に手伝ってもらって3時間ほどかけて基礎的な方法を見つけていったのが思い出ですね。
それでも、最終的にサイトを立ち上げることができた時の達成感はえげつなく、何ものにも代えがたいので、それを目指して頑張るしかないのです。
OGP設定の修正
OGPとは？
「OGP」というのは、WebページのURLがXやFacebookなどのSNSに投稿されたときに、「タイトル」「画像」「説明文」などの補足情報を表示するための仕組みのことを言います。
この設定がなくてもWebサイトとしての動作は基本問題ありませんが、SNSの使用が主流の今、サイトを各媒体で拡散していくのには必要な設定です。
今回の課題
今回は、不動産サイトに付随するWPのページ内で、URL部分の設定がうまくいっていない事象を解消する内容です。
詳細な修正内容は省略しますが、WPを使用した複雑な内容のため少し難解そうでした。
右も左も分かりませんが、とりあえずやってみることに。
作業内容と発見
詳しい手順はここでは省略し、所感をお話ししていきます。今回の課題も初めての要素で、最初は参考課題を見てもどういうことなのか、よく分かりませんでした。が、作業しながら読み込んでいくことで、何となくではありましたがどう対応していくかが分かっていきました。
対応サイトの中には古いサイトもあったため、その場合は記述の仕方が違ったり、それぞれのサイトに対して正しい対応をしたりする、柔軟さが問われる内容でした。
静的サイトとの比較と今後の課題
この作業を通して、より一層サイトの構造が理解できた気がします。
どうしても比べる対象が静的サイトなのですが、静的サイトの場合はそういうメンテナンスは基本なかったし、ページの内容はそのhtmlを見て間違った記述の部分を探す作業が主でした。しかし、物件王の不動産サイトは複数のページで処理がうまくいくように調整していく必要があります。「この変数が使われている場所はどこ？」ということを明確にして、そこでの処理はどう行っていて、その書き方の何が良くないかを知る必要があるのだなと感じました。難しい。
今回は参考を見ながらだったため優しい難易度でしたが、1から対応となると今の僕では流石に難しすぎる内容だと思うので、サポートいただいた方に感謝でした。
ブレイクポイント
ブレイクポイントと呼ばれるものがWebサイトにはあり、それの調査とまとめを任されております。ブレイクポイントという言葉は、うっすら知っていたかな？程度でしたので調べました。
ブレイクポイントとは？
Webサイトのブレイクポイントとは、画面サイズが変化したときにデザインが切り替わるポイントのことです。
例えば、例えば「横が◯px以下になったら、スマホ用のデザインに切り替える」といったように、事前に決めておいた画面サイズでレイアウトを指定します。
その際に使う "◯px" がブレイクポイントです。
このブレイクポイントを設定することで、色々なデバイスでWebサイトを利用できるようになります。
レスポンシブデザインとブレイクポイントの関係
今、webサイトを閲覧するのに使うデバイスはPC、スマホ、並びにタブレット...と色々あります。手に取ったことがある方がほとんどだと思うのでわかると思いますが、それぞれ画面サイズや解像度が違います。
一つのデザインで全てのデバイスに対応することは困難で、それぞれのサイトに適切なサイズで表示できるようにしないと、読みづらかったり使いづらかったりします。それだけならまだしも、デザインが大きく崩れたりして使用できない機能が生まれてしまったりもします。
そうなると本末転倒ですよね。
そのため、Webサイト制作には「レスポンシブデザイン」と呼ばれる作業を施します。
レスポンシブデザインは、一つのWebサイトを、色々なデバイスの画面サイズに自動的に適応させる技術で、ブレイクポイントは、このレスポンシブデザインを実現するための重要な要素の一つです。ブレイクポイントを設定することで、各デバイスサイズに合わせたデザインにしてUIが保たれるようにします。
ブレイクポイント調査の目的
ProtoV5と呼ばれる新しい不動産サイトの基盤となるものに、ブレイクポイントを導入する予定です。そのため、現在、ブレイクポイントに関する調査を行っています。
このブレイクポイントは一定ではなく、トレンドがあります。
スマホやタブレットなどは年々新しいモデルが出ていますよね？
それに画面のサイズが一定ではなく、モデルが変わるごとに変化しているのは皆さんもご存知だと思います。最近だと折りたたみスマホなども出てきましたしね。そのため、「今の環境だとどういうサイズだと問題ないのか」を考慮しなければなりません。
そこで、そのトレンドや基準となる値などを調べ、まとめ上げるという仕事を任されているわけなのであります。
最新版の更新内容を既存サイトに反映
直近で対応していた課題はこちらの更新課題です。
この内容に関しては正直内容が濃すぎてまとめられない + 自分も理解しきれていない部分があるので深くは触れられませんが、個人的に感じたことをお話しします。
更新作業の概要
古いバージョンのプロトタイプを新しいバージョンに更新する作業に取り組んでいました。
物件王の不動産サイトは先程からちょくちょく出てくる「プロトタイプ」と呼ばれる基盤が元に成り立っています。そのため、そのプロトタイプに様々な仕組みが記述されているわけですが、その仕組みをより良いものにするため、日々更新されていっています。皆さんが使うアプリケーションにもアップデートがあるように。
ただ、旧バージョンのプロトタイプを使用して制作されているサイトは、更新が必要です。
スマホアプリのようにワンクリックで更新できればいいですが、開発を行っている側は、そんな簡単には行かないというわけで、新しいプロトタイプの内容を対応サイトに合わせて反映していく、という作業が今回の課題の正体です。
更新作業を通しての気づき
作業していて思ったのは、ややこしい記述が簡潔 + 読みやすくなっているなと感じました。
古いサイトの記述を見たときに、「これどう言う記述だ？」と迷子になることもしばしばありましたが、更新作業をしていると、変数やクラス名を使って記述を短くしていたり、データを儲けるところと、処理をするところをわかりやすく分けていたりして、バージョン更新って大事だな〜と感じました。
あとは、複数のディレクトリを一気に触ったので、ディレクトリの位置の勉強にもなりました。
「このファイルはあそこにある」とすぐ思い出せるようになっているものも増えてきたし、検証ツールを用いた作業も慣れてきた実感が湧きましたね。
本当に色々な学びがあったので、詳しくは次号でお話ししようと思います。少し難しい話なので、何となくでもわかりやすく読みやすいように書いていきます。
オウンドメディアのお話
振り返りの重要性と成長
皆様が今お読みいただいているこの記事ですが、実は、記事の元は社内で掲載しているものです。そのため、社内報告レポートのように制作した記事をオウンドメディア用に編集しているのです。
そこで、編集する際に改めて元の記事を読み返したりすると、「ここもっとこうした方が面白いな」とか「この部分はいい内容だな」とか、あとは結構ストレートにバァ〜っと書いている時が多いので、「攻めすぎか？これ？」とか思いながら読み返すことが多いです。
ただ、こうやって少しでも前のことを振り返れるのはいいことだなと思いました。
自分がどのくらい成長したかが可視化されるし、自信にも繋がったり、今の問題の解決の糸口が案外転がっていたりするのかなって思います。
言葉にすることの大切さ
オウンドメディアを書いていると、日記とかって大事なんだなと思います。
結局めんどくさくて書かないことが多いですけどね。
でも、ぜひみなさんにも日記等の書き物を書いてほしいな〜なんて思ったりします。
「これは絶対会社では言えない」みたいなことでもいいと思うし、どストレートすぎてどうなんだろう？と思うような言葉も使ってもいいと思います。もちろんどこかに掲載する場合は、考慮しなければいけません。
それを共有するかはまた別ですが、不適切かもしれない表現でも、ふと自分から出てきた言葉を書き出してみて、可視化させてあげることは大切なんじゃないかなと思います。
僕には創作活動の場があり、そこで発散できたりしますが、そういう趣味や活動を持っていない人は言葉にすることがオススメだと、オウンドメディアを書きながら思いました。
あとがき
いかがでしたでしょうか？
ちなみに、この記事は2ヶ月ほど前のお話をしているため季節感に若干のラグがあるので、実は11月のお話をしていたんです。
そんな11月ですが、少し個人的な話をすると、色々あった2024半ばが終わりその疲れがどっときた印象が多いです。
予定が詰まりに詰まっていた日々が無くなったことによる安堵もあると思いますが、疲労もかなりあったものの、一旦切り抜けることができましたね。
生きているだけで偉いので、頑張りすぎず、明日を迎えられるように1日1日を大切に過ごしていきましょう。