サイト構築への１１個の(勝手な)提言
サイトってどうやって作るんだろう？を考えたとき、
システム工学的には・・とか、
いまいまのフロー的には・・とか
エイヤッ、オリャーってできるよ・・とか、
設計書と詳細設計つくっておいて・・とか、
いろいろまちまちでどこから手をつけなければいけないのか
まったくだれも教えてくれない・・
自分もいつも手探りで迷惑掛けたり掛けられたりで、悩むことは多いです。
そういう意味で手順書的なものがあったほうがいいのかな？
と思い書いていたら、そもそも考え方の相違とか思い違い、
任かせっきり任せられっきりな、人と人との関係値が重要なんじゃないかなと
いうところに行き着きました。
そこで、10個くらい提言を考えてみようと書き綴ってみたら、11個出てきた次第。
偏見も少々入りつつあるのでタイトルには「勝手」とつけさせていただいて
逃げ場も用意しつつ、企画者、設計者、開発者、運用者の考えの隙間を
埋める役に立てれば・・と切におもいます。
１：やりたいことを決めましょう
大枠でも詳細でもどちらでもいいです
まずは明確なるモデルを考えましょう
漠然としていてはなにも出来ないです。
２：機能を羅列するのはやめましょう
機能名１つでも、さまざまな考え方や見せ方があります
そんな機能名を羅列するより、どういうことをしたいか、どうやってユーザが使って欲しいかを考えて
ストーリ立てしましょう。流れがあれば用件定義はすこぶるしやすくなります
３：機能の詳細から話すのはやめたほうがいいです
機能設計する際は大枠から考えていき、ディティールは極力後にしたほうが
話が広がって面白いものが出来ると思います。
もちろん、イメージが付きやすいのでディティールから話をしがちですが
はじめからディティールの話をするとその世界観にとらわれてしまいがちです。
形はひとつではないです。大きな考えから作っていくことを念頭に進めていくのが
みんなが面白くできる秘訣かも
４：運用のことも少し考えておきましょう
リリース後に何とかすればいいや というのがおおよそなのですが
運用を考えてないシステムは概ね、後に思いっきり稼動がかかるということです。
初めのうちから運用は考えられないかもしれないですが、
まずは、おおよその流れ（フレームワークといいます）をつくり、間あいだを埋めていくことで
全体フローや運用イメージが出来上がっていくものです。
フレームワーク作りは初めはあまりマクロに考えずに、シンプルにトントントンと大枠のフレームをつくり
徐々に詳細に落としていきましょう。
５：機能用件決めは設計・開発と一緒に行いましょう
考えた機能は実現できるか、どれだけ開発工数がかかるかはなかなか見えないものです。
その見えないものに対して期日をきることは本来難しいのですが、
どうもシステム開発慣習でそれがまかり通っているのが現状です。
ので、出来る限り、画面やシステムフローを手書きでもいいですから書いてみて
実現したいことを極力詳細にアピールをするようにしましょう。
絵があると、設計者や開発者も話がしやすく、逆にこうしたほうがもっと使いやすいよとか
どこどこはこういう風に実現してますよとか、これくらいのものなら工数はこれくらいでここまで行くともう少しかかるね
などといった情報も入ってくるでしょうから、いろいろ取り入れながら作りこんでいくといいですし、
もっといいものができるとおもいますよ。
６：やりたいことの重要度と優先順位を決めましょう
リリース時にはすべての機能を用意したいと思うもの。
でも、おおよそ、期日やリリースの日時が決められているかと思います。
多くの時間があれば何とかなるかと思うのですが、おおよそぱっつんぱっつんな状況でしょう。
そのぱっつんぱっつんな中にすべてを組み込んでしまうとすべてがずれ込むかの可能性は
すごく高くなり、残念ながらバグも多く発生するものです。
また、実のところ、用意した機能にも８：２の法則が働き、１０の機能を用意したとしても
ユーザはおおよそ２，３の機能しか使わないんだそうです。
であれば、リリース時には必ず必要な機能、キラーコンテンツ・機能、あったら便利かもな機能というような
重要度と優先順位を決めましょう。
その決めにしたがってリリースに間に合うものから優先的に開発を行い、あったらいいなな機能は
リリース後に開発するという余裕を持たせることは重要です。
それに、 リリース時に多くのユーザが訪れるより、この先に訪れるユーザのほうが
多いでしょうから、ユーザには「新機能が追加されました！」といったアピールの仕方もできて
リリース後に機能追加したり、
ユーザの動きに合わせて追加機能を検討しなおすことも出来るので 意外とメリットが多いこともあります。
７：リリースはこまめに・・
開発を外部に発注したり、内部で開発したりと構築していく環境もスキームもまちまちですが
極力、開発途中でもある程度動くものを作り、依頼者や設計者に見てもらいながら
進めていくことをオススメします。
世の中ではこのような手法を「アジャイル開発」といいます。
アジャイル開発を知っている人はたぶん「アジャイルは大規模開発には向かない」というと思いますが
今ではその大規模開発でのアジャイル開発でもはすごくよい成果（納期、工数、バグの削減）が出ているという
事例がありますので、ぜひ取り組みべき。
ただし、リリースのテンポも発注者の負担にならないようにすることが重要で
期日を決めて集中して途中バージョンをリリースすることと、
ある程度動くものをリリースするようにしてください。
出しすぎると発注者も飽きてしまって「まだ触っていない」という状況にもなりますし、
あまりにも開発途中だと、「動かないものを触らせるな」ということにもなりかねないです。
アジャイルの目的は「実際動かしてみると違和感や考えの差異がある」ところを埋めることが
重要な目的なので、最後の最後にリリースして「これ違う」を防いだり「よくわからんけどこんなかんじかな？」と
設計書の行間を無理やり読んだり結果NGだったを防ぐことにあります。
また、途中バージョンでさわってもらうことでも、開発者では出せないようバグをさくっと出してくれたりしますので
テストも進められます。
開発する側も発注する側も少し労力を使いますが、最後の最後に手戻り発生して期日が間に合わない悪夢をおもえば
たいした労力ではないと思います。
あと、綿密な体制が組めることで、開発側・発注側のコミュニケーションが円滑になって
もっといいものが 出来るようになることもあるってことも最後に付け加えておきます
８：正直になる
見積もりや計画をすることはプロジェクトを進める上で重要なことですが
お互い「できるわけないだろう」「たぶん出来ないだろう」なんて考えのの上で計画することには
絶対に意味がない。
計画をするうえで、正直に出来ること出来ないことをきちん（ここが重要）と話し、お互いが無理な条件を
突きつけあわないようにすることが初めの一歩かもしれません。
時にはNOをいえるように。。
９：キャパシティ、スケールのお見積もりを・・・
ここ最近のライトな開発は、「まずは動けばいい」というところから始まってるように思えます。
それも正しいのですが、そのひとまずで物事が動いてしまう原因に、キャパシティの見積もりが出来ない
のが大きな要因だと思います。
どれだけのユーザが使いそう？どの機能がメインに使われそう？今後のユーザやデータの増え方は？
見積もる箇所は多くあり、見積もり方もある意味まちまちです。終いにはやってみないとわからない・・
と開き直られ、いざオープンしてみて遅い、重い、動かないと連呼するでしょう。
発注側に問題があるように思えますが、請負側のヒアリング能力にも問題のような気がします。
そのヒアリングの仕方も、直接的なもので、発注側も正確に見積もれないものを聞かれても
答えられないパターンが多く、先のパターンに結局は陥ります。そうではなく、
どのような目的のサイトでライバルは？、流入元はあるのか？あった場合はそのサイトのキャパはどれほどか？
今後の計画や数値推移はどれほどを考えているか？ハードにやミドルかけられる予算と初期に用意する機器のスペックは？・・
と観点を直接的にみるのではなく、周辺に存在する見える情報、数値を拾い起していけば、
作ろうとしているサイトのキャパシティがみえ、今後のスケール計画も立てられると思います。
１０：いざというときにはスケールアウトできるように設計しておきましょう
いろいろがんばって作ってきたにもかかわらず、リリースしてみて思い通りなパフォーマンスが出ないのは
あると思います。多いのは、プログラムの問題ではなくてハードウエアやミドルウエアの限界になってしまう
という例。もちろんチューニングをすることで速度を上げていくことは可能だと思いますが、
今すぐという要求には絶対にこたえられません。。
残念ながら、、そのあたりは発注者は理解と覚悟をしておくべきことです。というのは
運用していく上で考えることは、ハードウエア、ミドルウエアの準備をピーク時に設定できないからです。
普段は単位時間あたりｎ人のユーザが利用するが、ピーク時にはこの10倍きたとすると
じゃあ、用意する機材はそのピーク時に設定して大掛かりな構成にしておけばいいのかもしれませんが
ぶっちゃけ、あたるか外れるかはわからないサービスにそんな大げさな投資は出来るわけがありませんし、
そもそも原資も・・
なので、おおよそスモールスタートという名の最小スペックで構成をして、明けてみたらオーバーキャパシティで
動かないことになるものです。。
でも、今の時代は、オーバーキャパシティ分を事前に機器を用意しなくても必要に応じてクラウドを使って
スケールアウトさせることが可能になりました。
システム設計者や開発者はいざというときのパフォーマンスアップの方法をスケールアウトという形で
クラウドを利用できるように構築しておくのがこの時代のシステム設計だと思います。
また、リリース時にチューニングが甘くて現状では少々厳しい際にも、初期は大目のスケールで運用し、
チューニング次第で減らしていくという考えにもクラウドを利用するのはすごく建設的だと思います。
２，３年前ならいざ知らず、このご時勢、スケールが足りないから、、という言い訳は難しくなってると
考えて設計・開発をするようにしましょう。
１１：だれしもが協力を
自分は企画者だからシステムのことはわからない、自分は開発を受けた側だからビジネスのことは関係ない
・・役割が明確になっていると、自分の仕事に手一杯になりがちで、周りのことが見えない・わからないのは
ある意味誰もが悪いわけではありません。
しかし、作り上げていくことをしていくメンバーであれば、いまやっていることについては
包み隠さず話し、オープンにされた情報はがんばって聞く努力を全員でやっていくべきだと考えます。
伝わらないから話さない、理解できないから聞いても意味がない、、とは思わすに、
伝える力、聞く力を養って、やっていること、状況をみんなで把握していきましょう。
そうすることで、問題が起きたとしても解決する方法をみんなで出し合えたり、影響範囲の洗い出しも
しやすくなり、リソース配分などの変更もしやすくなると思います。
ある意味、立ち上げを経験することはそうそうあるわけでもないですし、行われていることへの全体把握を
できるチャンスもそうそうないことです。
苦労は買ってでもしろ、、とまでは言いませんが、みんなで作り上げていくということをやっていけば
先の10個の勝手な提言なんてなくても達成できることなんじゃないでしょうか
最後に、
ぇーと、初めにも書きましたが、10個考えると進めていたら11個になったわけですが、
始めるにあたって目標を決めてそれを達成させるという考えを持てば案外出来るものです。
ちょっと厳し目でも目標を立ててがんばることを勉強できたかも
