置き去りにされたWordPressへの対処法

※大前提、WordPressはめちゃくちゃ高機能で便利なソリューションであるので、誤解なきようお願いいたします。

「お金が払う側も、お金を貰う側も幸せになる仕事」があたりまえになるように、ドロのような記事を投稿します

[おすすめ]

WordPress案件でエンジニアが"飛んだ"方におすすめ

  • さぁ、置き去りのWordPressを侵略しにいこう！

駆け出しエンジニアの方におすすめ

  • 【教訓】 誰も気分がよくならなかった案件から学ぶべきこと

[目次]

  • 「エンジニアが"飛んだ"！」って字面のチャットが休日に届く
  • さぁ、置き去りのWordPressを侵略しにいこう！
    • 1.FTP
    • 2.MySQL情報の取得
    • 3.WordPressログイン情報の取得
  • 【番外編】 前任者の"飛び"ポイントを考える
    • ① WordPressの仕組みを知らなかったんだろう編
    • ② 顧客とのコミュニケーションの仕方編
    • ③ 契約編
  • 【教訓】 誰も気分がよくならなかった案件から学ぶべきこと
    1. クライアントのニーズに寄り添って技術選定をし、必要以上にムダな機能を提供しないようにしよう！
    2. 「技術の再利用」の範囲を間違えないようにしよう！
    3. 自分が得意ではない技術はしっかりクライアントに伝えよう！
    4. コード "だけ" を書くのではなく、クライアントと認識を合わせる努力をしよう！
    5. お金はちゃんとしよう！

「エンジニアが"飛んだ"！」って字面のチャットが休日に届く

前置きです。皆様もこんな経験ありませんか？

友人「やばいーエンジニアが飛んで、案件どうしようもなくなった〜」 おれ「めんどくせー、どんな技術スタックなの？」 友人「ワードプレスー」 おれ「情報それだけ、、、？？ 力になれるかわからないけど、見せてみ」

ないよね普通w

私は副業などでワードプレスという提案をほぼしたことないので、ワードプレスに明るくないのを前提にすこし状況を開くところから作業をはじめました。

初めてのワードプレス楽しかったです（遠い目

さぁ、置き去りのWordPressを侵略しにいこう！

以下３つの流れでWordPressを空けにいきました。

1. FTP情報の取得

私の気持ち

「まずは… 各種ファイルやアセットの置いてあるサーバーへのアクセスをせねば！」

対処法

これは、メール履歴やチャット履歴から取得しました。流石にコレなかったらオワコンなのでは？

2. MySQL情報の取得

私の気持ち

「さぁ、WordPressのadmin画面とかあるけど… ユーザー名/パスワード 共にわからん！」 「…詰んだか？ いや、mysqlの情報さえわかれば、user情報ぐらいどっか持ってるだろ！」

対処法

FTPで中に入れました。色々調べたが ドメイン/wp-admin/wp-config.phpってとこに、データベースの情報を書くのが通例らしい。

// ** MySQL 設定 - この情報はホスティング先から入手してください。 ** //
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'database_name_here' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'username_here' );
/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL のホスト名 */
define( 'DB_HOST', 'localhost' );

引用 ： wp-config.php の編集 | WordPress.org 日本語

3. WordPressのアカウント情報の取得

私の気持ち

「 wp-config.php でMySQLの中覗けるようになった！（ご丁寧にphpMyAdminあるし♪）」 「どっかユーザー情報あるよな〜・・・わかりやすく wp-users ってテーブルあるじゃん…」 （「しらんやつのプライベートなメールアドレスっぽいもの残ってるなぁ…）

対処法

wp-usersってテーブルを見つけましたが、もちろんパスワードがまんま記載されているはずもなく。

ただ、MD5でハッシュ化していることは公式でも明示されているので、パスワード部分をMD5にして突っ込んじまえば問題なしです！

md5化したければ、こちらのサイト md5 Hash Generator

参考 ： パスワードのリセット | WordPress.org 日本語

以下はぜんぜん読まなくてもいいと思いますｗw

【番外編】 前任者の"飛び"ポイントを考える

① WordPressの仕組みを知らなかったんだろう編

（要件現状）飛ぶ前に揉めてたSEO要件のまとめ

  1. ALL IN ONE SEO PACKAGE のバグを引いて、Googleに 「Undefined ｜ 会社概要」のようなインデックスをされていた （これは__リリース前にしっかり確認してほしかった__な〜）
  2. なぜかわからないが 「https://domain.hoge/ image1」などの謎のページ・予期しないページがたくさんGoogleにインデックスされていた （結論でいうと、こういうページが42件ほど存在していた）
  3. 2のようなページGoogleにバレるたびにURLをSearch Consoleから削除依頼を出していた

（結果１時的に削除されても、 ページ消さないと復活するやないか！！！noindex貼ってるわけじゃなし！！）

（システム現状）wp-post内にのこった情報

僕もあまりWordPressに明るくないのだが、 wp-post というテーブルの中身に関して、__他案件の使いまわしWordPressに残った不要レコード__が今案件に悪さをしていたようです。

  • WordPressの投稿データの種類
    • 固定ページ （draft/publish/trash）
    • 記事投稿　（draft/publish/trash）
    • 画像投稿・アタッチメント (inherit）

画像アタッチメントとして入っているレコードにより、画像投稿の分もURLも生成されていたっぽいです。

そしてindex.phpは以下

<?php get_header() ;?>

    index

<?php get_footer(); ?>

そんでもって、 https://domain/image1などが、__ヘッダーとフッターだけのページが生成されており、Googleのクローラーにバレてindexingされた__という顛末。

（システム対応）必要なページに利用されていないアタッチメントの削除

今回必要なページは固定ページのみでしたので、ソースコード全部点検しました。

<img src="<?php echo get_template_directory_uri(); ?>/img/service00.png" alt="サービスイメージ画像" class="hoge">

このタイプしかなかったので、まったくattachmentを利用していませんでした。

  1. 現在の wp-post のバックアップを取る
  2. 不要レコードの全削除
  3. 動作確認

これでOK。

（後処理） Search Consoleの侵略・ムダなインデックスの削除依頼

サーチコンソールのアカウントも置いてかなかったやん！

ということで、

  • DNSレコードからの所有権を新規で確認し、新しいアカウントに紐づけて侵入
  • インデックスされているムダページを削除依頼

② 顧客とのコミュニケーションの仕方編

  • すこし圧強めに返信返されてた（仕方ない部分もあるかもですね〜）
  • SEOでの不具合の状況を__ズラーッと文字のみで返信していて、認識あわせできてなさそう__

コミュニケーションの基本だとはおもうんですが、 __どうやったら相手の人はわかってくれるんだろうか？__と工夫することができずに、溝が広くなっていっている印象がありました。

③ 契約編

  • 状況だけをお伝えすると、__お金を振り込み終わった状態__でいなくなった
  • 契約でいうと、請負・準委任などの記述はなし、お金の払い方をみると請負のような手法でやってる（？確証なし

請負だとすると、瑕疵担保責任どうなるんだろう？ 準委任の場合、飛んだ日付と契約日が一緒なら問題ないのかな？ どちらにせよ明示されてなかったことが問題な気がしますね。

【教訓】 誰も気分がよくならなかった案件から学ぶべきこと

1.クライアントのニーズに寄り添って技術選定をし、必要以上にムダな機能を提供しないようにしよう！

__なんで、記事更新などの要件がなく静的ページメインの案件なのにWordPressという手段を選んだの？？__という感じでした

【今回の案件】

  • 静的ページで構成されるコーポレートサイト

【私が提案するとしたらこんな感じ】

  • ホスティングサーバーに静的ページをアップロード
  • 問い合わせ機能等が必要であれば、Firebase Functions等でライトに実現

今回、飛んでしまったエンジニアは結局、 使いまわしのWordPressを導入してしまい、__不必要な機能によって引き起こされた予期せぬ自体を解決できなかった__ということになります。

しっかりとクライアントの要望を叶えるための適切な技術選定をしましょう。

2.「技術の再利用」の範囲を間違えないようにしよう！

__なんで、今回の案件と関係ない記事データやユーザー情報が入っているの？？__という感じでした

前の案件のユーザー情報としてメールアドレスが入っていたのですが、正直__情報漏洩です__。

技術の再利用をする際に、以前構築したWordPress自体をコピーするのではなく、__手法のみを前の案件と同じように実施すればこんな事故になるはずない__です。

WordPressは新規で準備、いつもの方法でセッティング。サイトの動きやデザインなど以前作ったことがあるものがあれば再利用とかはありかもしれません。

再利用したほうがいい場所っていうのは少なからずあると思いますが、 再利用しては行けない場所、しないほうがいい場所っていうのが必ずあります。 ほんとに雑なコピー仕事はをしないほうがいいです。

3.自分が得意ではない技術はしっかりクライアントに伝えてもいいとおもう！

はい、飛んだ人のポートフォリオサイトを拝見させていただきました！

正直な感想から言うと、__Webデザイナーとして動きのあるサイトを作ることはできるが、エンジニアではないのでは？__と感じました。その理由は以下の記述からです

コラムやブログなど、更新が必要なサイトはWordPressをご提案しています。

その他は「ホームページ制作」「レスポンシブ対応」「コーディング」と抽象的なのに対し、何故かWordPressの部分だけ明確な手段の記載になっています。（他言語やソリューションは特に記述なし）

__その手段しか選べないっていう状態は、あまり得意ではないということの裏返し__だったりするので、無理せずに「サイトデザイン得意、システム構築は調査しながらの対応でもよき？」って言っちゃってもいいと思います。

相当課題解決に関して突破力に自信のある人でない限りは、不得意分野を明示していいと思います。

（成長のためには多少の背伸びは必要だとも理解してますけどね…） (それとも、手段明示したほうが売り込みやすいとかあるのかな…）

4.コード "だけ" を書くのではなく、クライアントと認識を合わせる努力をしよう！

今回の案件では、SEOの現状や対策についてのメールのやりとりが難易度が高そうに思えました。

そんな時に「ズラッと文字を並び立てると、伝わりづらいかな〜」とか相手の立場に立って考えて、

  • 「スクショを添付してみる」
  • 「パワポで簡単な絵をかいてみる」
  • 「文面だと温度感がつたわりづらいから電話しちゃう」

などの工夫をしてみても良かったのではないでしょうか？

エンジニアが実施している案件っていうのは、実現したい人がいて、それを実現する人がいて成り立つ__ものなので、他の職業の仕事と同じで"人"って部分は絶対に切り離せない__仕事です。認識齟齬を起こさないようにする努力はしたほうがいいと思います。

5.お金はちゃんとしよう！

受託・準委任などの知識は前提として

  • いつまでに
  • なにをしてもらって
  • いくらになる

っていう部分を意識して認識あわせをしましょう。4でも書いた通りですが、ここも認識あわせをする努力をしましょうね。仕事の完了条件っていうのが曖昧なことも多い印象なので。

いろいろと問題の多い案件をフォローした経験から、学びがあれば幸いと思いブログにしました。

私も認識合わせ苦手な方なので、ブログはなるべくパワポで絵を書いたりしていますので、ぜひ他の記事も読んでみてください。

【似たような題材の過去記事】

システム構築のご依頼はもちろんのこと、いまからシステム発注しようとおもっている方のお悩み相談等も受け付けております。

「お金が払う側も、お金を貰う側も幸せになる仕事」があたりまえになりますように…

Privacy Policy
© 2020 ~ Yuto Hongo