問題解決能力とは「理解力」と「意識力」と「実行力」

はじめに

理解力

例えば右や左、つまりメインの「横」にあるべきサイドメニューが何故かメインの「下」に移動してしまった場合。これがいわゆる カラム落ち と呼ばれる状態ですけれども、これはあきらかに何らかの作用によって生じている レイアウト上の問題 です。

ところがこれが仮に レスポンシブデザインテンプレート だとします。レスポンシブデザインの場合はブラウズサイズによって段組み(レイアウト)が意図的に変更されますから、一定の条件下ではカラムが下にあるのが正常です。一定条件とはこの場合「ブラウズサイズ」ですね。横幅が狭くなればカラムは下に「落ちる」のではなく「移動, 並べ替え」が行われます。ということはこれはそもそも「問題」には当たりません。

ここで大事なのは 理解力 です。自身が使用しているテンプレートの特性を理解できているか、ということですね。理解をしていなければ「落ちた落ちた」と騒ぐはめになります。

またあるいは、何かしらの問題に対し修正作業を行ったとします。その作業について 何故・何のためその作業を行うのか をわかってやるのとただ言われたからやるのとでは全然違います。「何故」を理解できていれば類似の諸問題に応用し、対処することが可能ですが、理解できていなければ同じことを何度も調べたり第三者に繰り返し尋ねることになります。もっと言えば類似の問題を類似だと気づくことも難しいかもしれません。

具体例を上げると例えば
「Aページで『ID名 #xxx が重複しています』というエラーがたくさん出ます。」と質問をしたとします。
「ID名はページ内で1つしか使ってはいけないので、id="xxx" を class="xxx" に変更してください。」と返ってきたとします。下線部位が「理由の説明」ですね。続いて「作業の説明」です。理由の説明をしっかり理解できるかどうかです。多くの方は「作業の説明」の方に意識を向けてしまいます。すると
「今度はBページで 『ID名 #yyy が重複しています』というエラーが出ます。何をすれば良いですか？」
「いやだからさっきidからclassに変えろって言ったじゃん。それ全く同じ内容の質問じゃん。」と。

意識力

例えば某の啓蒙記事を読んだとします。自身が当てはまるかどうかを客観的に判断できるかどうか。これも能力です。例えば「font要素を使うのはやめようよ」という啓蒙記事だとします。そこで「あれ？私ってfont要素を使っているのかな？それとも使っていないのかな？」と思い起こしたり、実際に調べたりするのか。それとも読んで「へー。そうなんだ。」で終わってしまうのか。意識力 が有るか無いかです。

で、実際に何かが起きたときに「あぁ、あのとき読んだアレか。なんでちゃんと読まなかったんだろう。」となるわけです。

実行力

では例に出した「font要素の利用」に自身が該当していると気づいているとしましょう。そこで「じゃあ今日書く記事から気をつけよう」となるのか「そのうちにまとめてやるからとりあえず今はいいや」で1年2年経過してしまうのか。これが 実行力 です。

「まだやらなくて良いや」で済ませてしまった問題が時を経て修正必須要件になってしまったとします。すぐに実行した人の修正量とずるずる引き伸ばした人の修正量のどちらが多いか、ということです。

序章のまとめ

とまぁ、こんなことを書いてますが 言うは易し なんですよね。なので目くじら立てたり見下すようなことは致しません(笑)
そもそも It's only a blog. たかがブログ なんですよ。ブログ書くのにそんなに苦労したくないですよね ^^;

ですからなんとなく「ブログを綺麗に管理したいなぁ」なんて気持ちになったらその事始めとして読んでもらえれば、という思いで書いています。

htmlの正確性とバリデーション

正しい(or 正しくない)html と言うとき、2つの意味があります。

• syntax --- シンタックス, 構文
• semantics --- セマンティクス, 意味

syntaxというのは 構文 のことです。例えば日本語でも「今日 は 暑いですね。」は正しいですが「今日 が 暑いですね。」とは言いませんよね。後者は構文的におかしな文章です。

semanticsというのは 意味 のことです。「今日 は 暑いですね。」と「今日 も 暑いですね。」では意味が違いますよね。意味的にはどちらも有り得ますがどちらがより正しい文章なのかは文脈による、という感じです。

syntax

<h1>音楽と平和について
歴史的事実を見ても音楽と平和には深い関わりがあります。音楽とは人の心を繋ぐツールです。

<h1>音楽と平和について</h1>
歴史的事実を見ても音楽と平和には深い関わりがあります。音楽とは人の心を繋ぐツールです。

前者は終了タグの </h1> がありません。これは 構文エラー です。これでは「見出し」に該当する文章がどこで終わっているのかわかりませんし、視覚的にも影響が出ます。htmlバリデータ(検証ツール)で検査できるのはsyntaxについて です。

semantics

<p>買い物リスト</p>
<p>りんご</p>
<p>オレンジ</p>
<p>にんじん</p>

<p>買い物リスト</p>
<ul>
<li>りんご</li>
<li>オレンジ</li>
<li>にんじん</li>
</ul>

書いてある内容は同じなんですが、前者は全て p要素 でマークアップされており、後者は ul要素 になっています。お買い物のメモリストでしょうかね。この場合は文字通り「リスト」の意味を持つul要素を用いるのがより適切・的確です。

では以下のような場合はどうでしょう。

<p>大学偏差値ランキング</p>
<ol>
<li>マサチューセッツ工科大学
<li>スタンフォード大学
<li>ハーバード大学
<li>カリフォルニア工科大学
<li>ケンブリッジ大学
</ol>

ul要素 は順序に特に意味は無いリスト、ol要素 は順序に意味のあるリストですから、ol要素の方がより的確といえます。

こういうのがsemanticsですね。htmlバリデータ(検証ツール)でsemanticsについて検査することはできません。AI技術が発達すればいずれは可能になるかもしれませんが、今のところ人間の意図を完全に汲み取ることはできません。

Google

SEOと言えばGoogleですね。Googleはよく「htmlが正しくなくとも 自社アルゴリズムで上手くやるから心配しなくて良いよ」といった発言をするんですが、これは主にsyntaxではなくsemanticsについて言ってます。

例えば以下のような内容。

昨日も今日も蒸し暑い。<strong>本当に嫌気がさします。</strong>

strong要素 というのは 意味の強調 に用いるマークアップですが、この文章の筆者はただ単に文字を太くするためだけに利用してしまいました。だとすると

昨日も今日も蒸し暑い。<span style="font-weight: bold;">本当に嫌気がさします。</span>

このようにCSSによる装飾(インラインCSS)で見た目だけを操作する方がより適切、という場面です。これもhtmlのsemanticsの観点から言えば「間違い」です。けれどもstrongタグがこういう誤った使い方をされるケースは非常に多いので、Googleは培ったアルゴリズムによってよきに計らってくれる、と。

ではこの場合はどうか。

昨日も今日も蒸し暑い。<strong>本当に嫌気がさします。

終了タグの </strong> がありませんね。これをGoogleが「間違っていても問題ない」とするかというと、YESとは言えません。後続にまだ文章が続いていた場合、どこまでをstrongの範囲とみなすか判断することができません。

つまり Googleの「間違いの許容」は主にsyntaxではなくsemanticsについて言っている んですね。この点を誤解してはいけません。

ブログ運営上「困る」と感じるのはsyntaxエラーの方

ブログ管理人が「困った」と感じるのはまずほとんどの場合がsyntax面です。htmlの構文エラーは 見た目に悪影響が現れる ことが多いためです。そのために私は平素から バリデートを行った方が良い とおすすめしています。

semanticsが間違っていても「文章が読めない」といったことはよほど起こりません。syntaxの間違いの場合はときとして「文章が読めない」は起こりえます。視覚に現れるので「困った、どうしよう」となるわけで。

実際にその「困りごと」が起きたときには兎にも角にも「htmlにその原因を探す」ことになります。そしてエラーが大量にある場合に原因の特定が果たして容易にできるかどうかです。

テンプレート製作者の立場、質問を受ける側の立場から現実的なことを言うと、エラーがほとんどない、あっても片手で足りる程度の場合はすぐに回答できるんですが、エラーがそれこそ50、100、ひどい場合は200を超えていることもあるんですが、そういった方の原因をすぐに特定できるかと言われれば 無理です。

私の場合でもみなさんの困りごとを検証する際まず最初に行うのはバリデートです。そして「エラーが多すぎてすぐには特定できない。明日にしよう」になることもあれば「これが原因だからすぐに知らせよう」となる場合も。結局大量のエラーを抱えている方に対しては お返事が遅くなる ことが多いです。手助けする側も使える時間が限られていますので、その限られた時間内にできるかどうかで後回しになることもあるわけです。

上手な質問の仕方

• 具体性
• 環境に関する情報(OS名, デバイス名, ブラウザ名など)を伝える
• 手を加えている場合はその内容を伝える
• 既に行った手順がある場合はその内容を伝える
• 独自表現だけで質問をしない

このあたりに気をつけて頂くと質疑応答が最小限で済みます。必要な情報が得られない場合には「xxxとyyyについてお答えください」という逆質問で1往復使ってしまいます。

非常に困る質問は「上の方にあるテキストが入っているボックスがおかしくなってしまいました。」とかそういうの(笑)
上記は「具体性に欠け + 環境情報もなく + 手を加えた内容を伝えず + 問題解決のために行った作業があるも伝えず + 独自表現によって質問をしている」という例です。例えばこれが
「ページ上部のナビゲーションの縦幅が大きくなってしまいました。カスタマイズでリンクをひとつ追加しています。CSSのxxxの部位を変更してみましたが解決できません。ブラウザはGoogle Chromeを利用しています。」とかならすぐに伝わります。これなら最短で解決策を導き出せるかもしれませんね。

専門用語がわからない、という場合には スクリーンショット を提示するなどもひとつの方法です。

まとめ

ここまで書いてきた内容についても「理解」をし「意識」をし「実行」をする。さすれば問題解決までの苦労を減らせるかもしれません。

不測の事態というのは必ず発生するものです。そのときにこの3つを実践している方とそうでない方とでは大きな差が出てきます。実践していればもしかしたら誰かに聞くというステップが不要になる可能性、つまり 自己解決の可能性が高くなる かもしれません。