ITに関する質問や依頼を、知り合いの方や、そのまた知り合いの方からいただいて、毎日ありがたい日々を過ごしているユゲタです。
会社からの相談から、個人的なモノも様々ですが、相談ランキングは次の通りです。
1. ITでこんな事できる？（作れる？）
2. ホームページ作ってくれる？
3. こんなシステムいくらで作れるんだい？
正直、会社の売上につながるものは、ごく僅かなんですが、お話させていただけるだけでも有り難い感じです。
だって、こうしてブログとしてのネタになるんですから・・・あ、情報はちゃんと伏せさせてもらってますよwww。
そんな相談毎をたくさん聞いているとある一定の法則が有ることに気が付きました。
ITがちょっとだけわかる人からの依頼
ITの相談をする人は、プログラミングの話をしたり、技術的な質問ではなく、そもそもITが苦手な人が多いというのも特徴です。
中には、プログラミング学習していて、ある程度理解出来てますよレベルの人は、
「この質問、こーやったらできますよね？」
という様な何故か上から目線満載で話を勧めてくるタイプが多いようです。
こうしたITがちょっとだけわかる人の依頼を受けて、個人的にあまりいい結末ではなかった経験について備忘録しておきます。
何故か詳細仕様が曖昧に決められてしまう
その人は、とある会社のIT部門の責任者で、以前にセミナーで名刺交換したことから、何度か一緒に飲みに行った事がある友人です。
最近自分でwebサイトを構築する勉強を初めて、頻繁に学習についての質問をチャットなどでしてくるような関係だったんですよね。
会社のとあるシステムを作って欲しいと依頼されて、短気対応でできそうだったので、快く受け入れて開発に着手しました。
最初にどういうシステムを作るのかという説明をする打ち合わせで、何故かデータベーステーブルのカラム情報が出てきて、
「こういうモノを作りたい」
という話からスタートしたんです。
それ自体は非常にわかりやすく良かったんですが、見た目仕様とデータベース仕様が事前に決められている状態からスタートして、
結果的に、目的を聞くと、思考手順は正直逆なような気がして、結果的に最終仕様を作るのをそれらの構造に合わせるようにプログラミング設計をして、少し遠回りした感じで工数が少し無駄に増えてしまいました。
スケジュールが仕様が決まる前から決まっている
最も恐ろしかったのは、仕様が決まる前から、ゴールが決まってしまっていた事なんですね。
当初の話では、「なるはやなんだけど、ベストエフォート（可能な限りの努力スピード）でいいよ」という話だったんですが、
初回の打ち合わせで、「○月○日までに完了」という事がコミットされていました。
国内のIT開発会社のいたるところで、こうした事が起きている話はよく聞きますが、使う人の気分によって仕様がコロコロ変わるIT業界は、
向上などのベルトコンベア生産でもない限り、決められた日程で作業完了を遂行するなんてことはまず不可能に近いでしょう。
よく、「○日で完成」と行っているのは、バッファを積み上げまくった結果、このぐらいなら問題ないだろうというスケジュールにしているケースが多いんですよね。
それでも、締切に間に合わないケースの方が多いようですが・・・www
そして、どんな機能が必要で、運用体制などの検討も出来ていない状態で、ゴールの日程だけが決まったという会議が終幕しました。
言われた通りのモノを作った結果・・・
個人的な、裏技などを駆使して、初回に言われた通りのデータベース構成で、提示された通りのユーザーインターフェイスで、ゴール期日の1週間前に無事に完成して、
あとは、テストをして納品チェックをしてもらうだけという状態になり、色々と情報をテキストにまとめて、システムの添え物として同じく納品物として送り、残すは不具合対応をするだけという状態に落ち着きました。
まあ、その後想像はしていたんですが、「やっぱりココ使いづらいから、全く別のデザインに変更して」と言ってきて、実はここからゴールまでの1週間がかなり修羅場になったんですよ。
多くの開発で、開発遅延が多いのは、この「やっぱり・・・」という、先出しをした人が、後出しジャンケンをしてしまうルール無視の状態が横行しているからだということを改めて認識しました。
あとがき
仕様に関して、色々と考えてしまうのは、エンジニアの特徴なので、この依頼者の人の立場に立ってみて、こうした人達はどういうシステム依頼をすればいいのかという事を考えてみました。
まず最初に仕様検討をする事に期間を取り、後ほどやっぱり・・・と言わないために仕様を固める事に一番時間を費やすことを頭に置くと良いでしょう。
モックアップと称したモノを作って、触り心地、機能に抜け漏れがないかの確認を行い、最後にそれらを整えるための期間を加えたスケジュールを構築すればいいんですよね。
どうしてもゴール日程を先に決めてしまう組織が多い日本がIT後進国なのが少し理解できる内容なのかもしれませんね。
それらは、ディレクションという役割になり、ディレクターという立場の人をキチンと設置している会社さんもありますが、ディレクターという役割が存在していない会社でスケジュールに厳しいという組織は、実は要注意と言うふうに個人的に考えています。
ちなみに、ITにちょっとだけ詳しいという人で、細かな技術仕様はエンジニアに聞かないと分からないという組織構造の会社さん、かなりの確率でこのヤバめに当てはまるかもしれません。
別に悪口を言っているわけではなく、体制を見直すキッカケになると幸いです。
