自分のことをとりあえず棚にあげまくりますが。上の記事は前貼ったやつと同じです。
今までよく「お前ら少しくらい脳みそ使え」ということをよく言ってたのですが、最近それがちょっとずれていたことに気づきました。
基本的にどの人も自分より頭いい気はしますし、実際会社やってたり具体的な行動を起こしていたりと、おそらく私よりよほど優秀であるような気はします。
より適切にいえば「具体的にimplementしよう」ということなんだなと気づきました。
バイトでも何でも最近一番苦労することは、空気を読むことだったりします。
はらじゅんがKYだという説はとりあえずほっておくとして、特に比較的詳しいプログラミングとかシステムに関して考えてみたいなと思います。
まずいただく注文のほとんどが曖昧としてます。(ほとんどのものは過去形ですが)
曖昧としてて誰も相手にしてくれないので自分のところに来るという予感が一時期してたくらいに曖昧です。
ひどいときは「超画期的なものがほしいんだ(なんだそれ?)」という人も出てきたりするわけですが・・・
ほとんどはまったくもってよく考えられていないか、考えただけで形に落としていないかのどちらかなので、大体アイディアが沸きそうな似たようなサイトを教えてあげたり、具体的に最近はこういうことが流行ってるとか教えることがあります。
実はほとんど多くの問題は、システムで実現可能である場合が多いです。はっきりいってしまえばコストがん無視すればできないことはそんなにありません。
より適切にいえば、実現不可能なことを思いつくほど斬新な人がいないとか、勝手に不可能だと思って忘れてしまうという感じで、ほとんど耳に入ってくる段階で合理的に実現可能になっていることが多いです。
おそらくまったく実現不能なことというのは、元々詳しい人がネタで言うとか、最先端の研究をしてるとか、そういう系なくらいだと思います。
さて、その状況で問題が発生します。実に多くの問題が発生するのですが、そのうちおもいつくものをいくつか。
時と場合によって2,3日質問項目考えてきくんですが、なかなかすぐ答えを得ることができなかったりします。そこで空気読む必要が発生するのですが、ここが大変難しいです。事務的な言い方をすれば要求仕様を固めるとかいうかもしれないです。
しかし、これは多くの場合「具体的に考える」作業をすることによって、簡単に発見することができます。プロトタイプ作る技能を持ってる人はそれでいいと思いますし、なくても合理的に考える根性さえあればなんとかなります。ビジネスプラン書くことができるのならきっと問題はないでしょう。
具体的なケースを考えて見ます。
ケース1:具体的な利用ケースを考えましょう(google miniとか
これは、単に話題にのぼっただけなので実際そういう使いかたしてるわけじゃないんですが。
試験的にgoogle miniを買った企業がありました。一番安い5万ドキュメントのサーバです。
google miniを使って、webから大量に取ってきたドキュメントを検索させてみようというような話をちょろっとしてたのですが、この段階ですでに計画が破綻しています。
webから情報をとってくる場合、対象にもよりますがサイトあたり数百~千件程度がデフォルトです。多いときは万くらいはあるのですが50回クローリングしてきたらもうgoogle miniでは扱えなくなりますね。
このケースの場合明らかに50回以上はクローリングするうえ、すでに数万件は一サイトで埋まることが確定していたので、結果的にこの段階で破綻してます。
はらじゅんひとりで扱ってる文字情報だけでも万はあるので、いかに小規模な組織であったとしても5万は少ない気がするのが感覚値でもあったりします。
こんなのは買う前に確認すればすむだけですね。
(どちらかというとgoogle mini使ってみるのが目的だったのと、他の用途にも使ってるようなのでOKなのですが)
ケース2:根本的に帯域足りてないよそれというパターン
なんかwebサーバの負荷が高くてサイトが落ちるとかいうお問い合わせがきました。正直負荷分散とかやったことないし、やるにしても単純にコピー作って専用の機械入れることくらいしかできないのですが。
ただ話を聞いてるうちに、根本的に回線スペックが足りてないことが発覚しました。
だいたい1トランザクションあたり80KBのデータをやり取りするwebサーバで、一時間あたりmax10万アクセスという話だったのでちょちょいと計算。
80KB*8bit*100000アクセス/3600秒 = 17Mbps
回線が10Mbpsという話だったので、理論的に限界超えてます。ファンタスティック。
サーバの負荷というよりは、単に回線が無理なだけだったようです。こういうのは確かにうっかり忘れそうなポイントではありますが・・・というか、そもそもwebサーバ落ちてないんじゃない疑惑とかもあったんですが、そこはなぞですね。
これも気づくのは確かに厄介ではありますが、気づけば計算は単純なので難しくはないでしょう。
ケース3:どういう人間がそれを使うのか?
これは非常に苦労しまくった話ですね。これでシステム開発やめる決心したといっても過言ではありません。動作面ではまったく問題ないのですが、利用ケースについてまったく考えられていませんでした。
たとえばそれがwebサイトだったとしても、使うのは一般の人だけではありません。たとえばサイトを管理する人は管理しなくちゃいけません。
神級の開発者がいる場合は別ですが、小さいプログラムであっても他人の書いたコードを理解することはなかなか容易ではありません。
多くの場合は管理するためのソリューションが必要とされます。
すると、いろいろ確認しなくちゃいけないことが出てくるんですが、特に業務フローについてはよく把握する必要があります。これは客観的に便利であることとかどうでもよくて、相手の会社がどういうルールなのかという話です。なんにしても、こちらの便利をごり押しするのであれば、業務フローのコンサルごとやって教育までやらなくてはいけません。
簡単に言えば、どういう手順でいつ集計作業がされるのかや、サイトからの問い合わせは誰が処理するのかとか、めんどくさいのだと営業の人とのからみとか色々出てきます。
とても壮大なストーリーがそこには待っています。
もはやここまでくると、それ相応に複雑なので、思いつきだけでやるのとかは危険極まりないです。
なので、それなりに具体的な文書にして客観的に無理がないことを確認することが必要です。
しかしこれはUMLなんていう変体言語で記述しろとか言うわけではありません。あれは開発者同士の共通言語として意味のブレがないように設計されてるだけで、具体的にシステム構築上有利な点があるわけではありません。
(すくなくとも俺はそう感じたという話。ただ意味がぶれない分確実なコミュニケーションが取れるというのはあると思う)
どんな書きかたしてもいいので、とりあえず書き出して過不足がないかを確認するというのが一番大切であり、絵のできは小学生の落書き級でも何の問題もありません。
まぁ読めないのはアレですが・・・・
まとめ
話が若干発散しました。いいたかったことは・・・・
はい。
企画書ないと相手にしてくれないのが大人というもの(偏見?)な気はしますが、なんとなく気持ちはわかります。
はらじゅんは話とかだけでも聞きますが、文書化が一度もなされてないアイディアは突っ込みどころが多すぎて、会話がまったく有益でない場合があります。
というわけで、今日もいろんなものを書いています。
冒頭のリンクではこれとは似てるようで違う観点からideaを具体化することの重要性を説いています。
Leave a reply