前々から思っている事なんですが、サイトの制作ってクライアントの要望させ満たせば（本来それが目的）どんな言語を使うか、フレームワークはどれにするか否か？又は、CMSを使うか否かなど、まぁ、どっちゃでも良い事なんだけどね。と・・・。
今回は、小規模サイトの提案を薦める上で大事な要素を考えてみます。
（１）プラットフォームの種別（運用費用を左右）
（２）ステップ数（納期に関わる）
（３）ドキュメントの管理（拡張性への対応）
（４）パフォーマンス（レスポンスの速さ）
（５）サポート（保守性）
この５つを基にクライアントと開発側の都合を考えてみます。
（１）プラットフォームの種別
昨今、クラウドなるものが流行になっています。AWS(Amazon)、Azure(MS)、GCP(Google)などが有名どころの様です。個人的にはAWSしか使った事はありません、環境構築では融通が利きますが、慣れてないと使いかたを理解するだけで大変だと思います。レンタル共有サーバーの様に半ば電話で問い合わせながらとも行きません。一々、メールなどでの問い合わせとなり、専門性が高く大きな企業向けの様な気がします。
（２）ステップ数
開発言語を何にするのか？これには、適したものがある筈です。バックエンドの開発では、RubyやPerl、個人的にはPHPでのものも多く作りましたが、総体的にフレームワークやCMSでの場合、イニシャルのステップ数は多くなります。使いまわす場合を考えれば別です。先々の展開により選択するとよいでしょう。
（３）ドキュメントの管理
ほぼ、開発会社任せなのが現状です。逆にここを握っている事が開発元の版権を保つことにも繋がり、生涯における継続案件の受注をもたらせています。そもそもドキュメントアンリの考え方自体が変わってきた気がします。一昔の様なシステムレベルのものでは無く、機能別のパッケージ化されたもので管理されています。車や電化製品と同じで不具合があれば買い替えるイメージですね。
（４）パフォーマンス
昨今、CMSやフレームワークの台頭が目立ちます。大体、これらはPHPをオブジェクト化（お店をモール化した様なものです）しています。八百屋さんの店先で「大根下さい」と言えば、「はいはい、何本にする？」「寒くなったねぇ、おでん？」など直ぐに声が返ってきますよね。ところが、オブジェクトと言うのは「いつものお客さん、あぁ、あれね」「だったら、おでんは皆さんこれが美味しいよ」と決まっるパターンには速いんですが、好みの違いを個別にするなんて事になると複雑になり、難しくなってしまいます。
（５）サポート
多岐にわたる複雑なものとしない。よくあるんですが、作った側も良く分からない？これってマジにあります。基本的にシステムは一人だけで作るわけじゃない、作りっぱなしもよくあります。「分かりやすくサポートできるものを提案する」これが大事かと思います。
自分としては、「発注者がやりたい事の意図を理解」して、その「想いを見える形にする」ための整理役を意識して務めたいとかんがえています。
