第15回 プログラミング学校 | プログラミング学校 | GUARDIANアカデミー | 初期無料のサブスク型ホームページ制作｜7万実績のWEB戦略とAIで成果を出す | 初期無料のサブスク型ホームページ制作｜7万実績のWEB戦略とAIで成果を出す

ものづくりにおいて、最も重要な事は、コンセプトを明確にすることです。

ひらめき、創力、不可能を可能にする、思いつき、発想転換、etc…だと思われていますが、一言で言語化する事が出来ます。

→「複数問題を一気に解決するもである」

直ぐに解決しなければならない「問題」以外にも、出来れば解決したい「課題」と言い換える事が出来る。

クライアントからオーダーや、我々が為すべき事「課題解決」である事が多い。
例：今より問い合わせ数を増やしたい
（=問い合わせがない事ないけど、少ない事を課題と感じている。など）

システムソリューション。さまざまな物事、ビジネス、サービスにおける問題、課題を解決するためコンピュータシステム、また、サービス総称。

wikiより

ソリューション、という言葉を使って自社製品を紹介しているケースはとても多く、そもそも、よくよく考えれば、コンピューターソフトウェアという、娯楽用システムを除き、ほぼ全てのシステムは必ず何らかの課題を解決するために存在している。

電卓であっても、「暗算だと間違えるし遅いから、正確に早く計算したい」という課題を解決するものと考える事が出来る。

望む結果を明らかにする事。

まずこれがなければ何も始まりません。この時点では、決して「どのようにする」が焦点になっていけません。重要なのは「どういう結果を望むか」です。つまり、ゴールを明確にする事です。

※この時点で方法論に焦点を当てちゃう人、めちゃくちゃ多いです。発注者からしたら「専門的な事わかんないから良い感じにやってよ。」となりますし、ゴールが不明瞭のまま進むとずれた設計が出来上がります。

ずれ角度が大きいほど致命的な結果になります。1メートル以上離れた点と現在値の点の角度を小さな分度器で測って線を引く、というのを想像してみてください。適当にやるとめちゃくちゃずれますが、それと同じ事が発生します。

線を引いてから角度を測ってください。現在値から目的地まで線を引き、あらゆる事を、その線を軸として進めてください。

これが「もづくり掟」で一番言いたかった事です。

望む結果を阻害する要因を、 問題や課題に転換する（今日一番言いたいのココ）

例えば、「問い合わせ数を増やしたい」という望みがあった場合、今のままで問い合わせが少ない、という状態であり、解決すべき課題と考えられるわけです。

さらに、何故問い合わせが少ないのか、というのを考えると、そもそも集客が少ないのが問題であったり、コンバージョン率が低いのが問題 だったり、離脱率が高かったり、そもそも商材自体を魅力的にアピールできていない、という感じでいくつかより小さな問題に分割できたりします。

一つ問題を明らかにし、解決策を考えて、また別の問題が見つかる事もあるでしょう。そうすると、それらを両立するためにどうすればいいか、という解決策を考えるようになります。いくつかある問題を一気に解決できる対策が、 アイディアというものであると考えられます。

例えば、絵を描くという事に当てめると、漠然と自由に感性だけでお絵かきするのと、モチーフを決めて描きながら分析、修正を重て仕上げていく、くらいの違いが出てくると思います。

目標を達成するため指標として課題を設定し、それを解決するという意識で設計を進めるです。

これまでに得た知識、経験を総動員する事。

いくら課題が明確になったところで、解決するための知識がなければ解決する事が出来ません。
殆どの場合、基礎的な知識が最も重要になります。
プログラミングでいえば、プログラミング言語構文であったり、データベース基礎知識です。
基礎を深く理解するのは思いほか大変です。が、基礎を深く理解すれするほど、応用が効くようになり、難しい局面でも良いアイディアが生まれる可能性が圧倒的に高まります。
スポーツや格闘技フォームみたいなものです。基礎的な動きを徹底的に鍛えている人ほど強いずです。

課題を適切に設定し、自ら知識を組み合わせ、解決策を考える事。

課題と、自身の持つ知識が重なる領域が、自身が提示できるソリューションとなります。

課題：アーティクル記事を出力する際に、パーツ毎に必要な入力項目が微妙に異なり、あらゆるパターンに対応するために、想定される全ての入力項目を予め設定しておく必要がある。結果として、アーティクル入力項目が巨大化し、新しい要望が出るたびに入力項目を増やす必要があり、管理・運用も超大変でYさんが泣いた。

知識：OWLetパーツの基本的な仕組み、OWLetのアーティクルの基本的な仕組み、レボリューション仕様。

アイディア：使用されるパーツ毎に必要な入力項目を定義できるようにし、設置されているパーツだけで入力項目を動的生成する。

解決できた問題：

・必要最小限の入力項目だけでアーティクルを構成できるようになった。

・新しい入力項目が増えたとしても、作業が必要なパーツ側の設定のみであり、管理運用をそれほど意識しなくてもよくなった。

課題：HTMLとCSSが分離した管理手法の場合、CSSがパーツを跨って影響しあい、表示崩れの原因となる。複雑な機能や特殊な機能を持つパーツはシステム開発が必要で高コスト。再利用性が低く、資産化が難しい。

知識：HTML、CSS、PHP、OWLデータベース構、アーティクルや問い合わせフォームの入力項目設定。

アイディア：入力項目を設定可能とし、 HTML/CSS/Javascript/データを一つのパーツに纏める。また、 UUIDという仕組みを用いて、環境を跨いで一意にパーツを特定できるようにする

解決できた問題： 表示崩れが無くなり、CSSの記述に気を使う必要が無くなった。再利用性が格段に上がった。環境を跨いでエクスポートとイ ンポートが出来るようになり、ポータビリティが格段に上がった。それにより、レボリューションやSKIP等のエコシステムの開発を可能とした。

業界的に特に決まったルールというもなく、Googleで探してもベストプラクティスは見つからな いと思います。（基本設計書や詳細設計書という、 誰も本物を見たことが無いような一人歩きした言葉は山ほど見つかります。）

単純に、見る人が理解できるように努めて書きま しょう。

画面設計と、画面内要素を操作した時の挙動に ついて解説を入れる、という書き方がおそらく誰が見ても分かりやすい設計書になると思います。