40も近くなると、忘れてしまうことも多くなる。
でも、今日の出来事はちょっと胸に刻みたい。
そして、受託開発ではない「お客さんと一緒にシステムを作る試み」の一つの区切りなので、
それをまとめておきたいので書いている。
今日は、うちのdot3（旧WPS）の導入先のお客さんが、
情報誌の誌面リニューアル、WEBサイト公開にこぎつけたので
出版記念パーティをするからおいでと声をかけていただいていた日。
サーバ移行もあったので前入り、後入りで総勢4人。
パーティは総勢80人ぐらい。
海が見える素晴らしいロケーション。
が、しかし、、、
花火を打ち上げる予定があったけれども、
午後から降り出した雨が開始早々いっそう激しくなり、
海はおろか外の景色も見えないような状況で、
これは無理だなと。。。
5年ぐらいのお付き合いの会社さんで、
1年ぐらい前、このリニューアルにかけて当時使っていたWPSを廃止して、
自社開発でやろうかなと。でもまだ迷っているので、ちょっと何ができるか
相談したいんだが、、、というお話をいただいた。
WPSもその頃には、安定期を超え、
次のPA^N（WPSを柔軟な仕組みに切り替えたもの）へと
開発フェーズも移り、さらに練り直しをはかろうかというところだった。
その間、僕らは営業というものが
社内で確立していないことを言い訳にしてしまっているが、
既存のお客さんへのレビューなどほとんどしてこなかった。
だから、新しいものを見せたとき、
「それだよ！なんで教えてくれなかったんだ！」
というような、お叱りでもあり感嘆でもある言葉をいただいた。
しかし、僕たちの見せる技術は、海外では当たり前であっても、
日本国内ではかなり先駆的な技術。
大手であれば、必ずNoと言われる。
そんな知らない技術は、採用できない、
まずは外部設計と、詳細設計がないと受け入れられない、などなど。
技術なんて日々変わっていくものだ。
余計な時間をかけるだけ、日本はどんどん遅れていく。
Web入稿、自動組版やWEBサイト連携という仕組みなので、
入稿したものが出ればいいし、その他付随する機能は、
どんどん付けて、いらなければ外せばいい。
そもそも、お客さんが思う範囲、言われたことしか開発できないなら、
その大元のアイディアはお客さんにあるわけで、
開発者ではない。ただのコードがかけるプログラマ。
お客さんが言うことを覆せとは言わないが、その先を考えて、
いいものを提供する、お客さんがどういおうがそれを説得するだけの力を持つのが、
開発者という立場じゃないだろうか。
ここで、いつも問題となるのが日本の確固たるシステム開発におけるビジネススタイル。
「最初に明確な要件定義とそれに基づく見積もりありき。」
「設計書が全部そろってから開発開始」
これだけビジネスのスピードが速く、技術の進歩も早いなかで、
最初に決めることへのリスクがどれだけ高いかというのは、
多分、開発という行為を「価値」にかえて売るのではなく、
開発した「もの」を売る商社的な人たちには分からない。
そこで、やってみたのが、
「お客さんと一緒にシステムを作る」試み。
今思えば、よく納得してくれたなと思う。
現在では、数本このようなプロジェクトが社内で走っているが、
1年前というつい最近でもまだ認知されるものではなかった。
世の中がアジャイルという手法に取り憑かれ始めた頃だったと思う。
その主な内容は、
・システムリリース、サービスインが納品ではなく、
プロジェクトの開始から月額決めた金額をいただく。
・短期間で区切って進める。
・お客さんからも開発メンバーを出してもらう。サーバ構築、プログラミングを覚えてもらう。
・要望の変更、追加は随時受け付ける。もちろんこちらからも企画を出す。
・金額の範囲内で、動かせる人員、工数が出るので、そこで出来ることを基本として優先順位を決めて動かす。
・ハードウェア、サーバ構築は、スタートアップとしては小さくしておいて、システムがベータ版になるぐらいで導入検討を行う。
・設計書は書かない。動くもので確認して、さらに進めていく。
つまり、両社で納得しながら順番に進めましょうという試み。
アウトソースというよりは、業務提携に近い。
うちからは、アーキテクト、サーバ、プログラム、サポートに関わる専門知識を持つ人間が、
それぞれの役割を、そして、お客さんも開発を投げっぱなしではなく、分からなくてもそこに加わる。
僕らが、やっていくうちに業務を理解できてくるのと同様、
お客さんも僕たちの世界を垣間見る。
そうすることで、あーそういうことか、とか、
ここは自分たちで決めないと先に進まないな、とか
意外と大変だ、これはプロの力を借りないと無理だなとか、
意外と簡単だ、これなら自分もできるなとか、
そういうことが見えてくる。
あんときああ言ったじゃないか、というのがプロジェクトが炎上するときの発火地点。
言った言わないになるのは、「最初に明確な要件定義とそれに基づく見積もりありき」に
全員が縛られるから。そこがあるから、という頭にどうしてもなってしまう。
見積もり段階で、点の技術検証はとれていても、複雑に絡み合う機能になった場合に、
その立証は、動かしてみないと実際のところできない。出来るはずがない。
それが言えない状況がシステム開発にはよくあることだと思う。
納得するというのは、お互いの気持ちを理解する、これが重要だと思う。
そうすれば、柔軟な方向転換が可能になる。
そうやって、お客さんと一緒に、
何でも言い合えるチームというのを確立することで、
開発側も今すべきこと、この先にすべきことが見えて、
意見を言うことができるようになる。
これがパートナーシップに基づいたビジネスだと思う。
といいつつも、、、
すべてが順調に行ったわけではない。
技術コンサル的な位置付けもある中で、お金をもらっている以上、
中途半端なことはできないから、今までよりもさらに
リサーチと検証を注意深く重ねなければいけないこと、
手法の柔軟さから、お客さんの方が決めかねるシーンがあったり、
最初の思惑と違うことが出てきたり、
いや、やっぱりちゃんと決めた上で動かさないといけないんじゃないかという意見が出たり、
今回はなかったけれど、人の問題や、外部要因（震災の影響とか）も入ってくれば、
柔軟でなければ、なんともならない。
プロジェクトがストップしてしまうことが、一番の痛手であって、
大抵の場合、拘りを捨てれば前に進める。
そういう中で、右往左往、試行錯誤しながらも、
無事出版され、WEBサイトも公開され、終わってはないが、
一段落したところで、振り返ってみると、
今後を占う良い事例になったんじゃないかと思う。
それが良かったかどうかは、
こういった場で、関わった人たちが一堂に介し、労をねぎらい、
次への意気込みを語り合うことで確かめられる。
ビジネスである以上、お金ももちろん大事だけれども、
それを生み出す人たちが、同じ方向を向いていないと、何も生み出せない。
そうしなければ単発の意味のないものに終わるだろう。
パーティは、来賓の方のご挨拶や、スタッフの紹介が終わったところで、
いつの間にか雨がすっかりあがっていた。
そして、予定通り（なのかな）花火が打ち上がった。
花火大会でみる花火とは違って、ここにいる人たちのためだけの花火ってのは、
感動もひとしお。
うちの人たちも、時には技術的な面、気持ち的な面で叱責を受けながらも、
夜遅くまで、土日問わずやっていたときもあっただろうし、お客さんの方も、
リニューアルっていう不安の中で、営業の人も制作の人も、
毎晩遅くなってもあきらめずにがんばっていた人たちがいっぱいる。
でも、こうやって一つの結果を出すことができたというのは、
力を合わせれば、あきらめなければ、やればできるっていう証明。
そりゃあ涙も出ます。
開発メンバーの他にもうちには制作もいるわけで、
この話は今苦しんでいる制作にもちかえってやりたいと強く思った次第。
僕たちがやっている開発や制作というのは、縁の下の力持ち的な部分が大きい。
時にその存在を忘れられることもある。
WEBサイトやアプリは華やかにレビューされるが、
そこにデータを渡す仕組みを開発することや、
リスクを考えたサーバ構築や、
コンテンツを作るという作業自体には、あまりスポットがあてられない。
いや、これは見えない世界だから仕方ない。
出版物やサイトが正常にできあがって当たり前。
当たり前を当たり前のようにやる。
それでも、ちょっと悔しかったな。
華々しいことを期待するわけじゃない。
もっと自分たちが認めてもらえるように、
それを個人ではなく、チームとして、会社として認めてもらえるようになりたい。
ここで、自己満足してる場合じゃない。
もっともっとできることがいっぱいある自分たちだからこそ、
それを発揮して、今度は自分たちのためだけの花火をあげてみたい、
と思った一日でした。
来月また行くことになりそうなので、
がんばれば道がひらけるんだという勇気をもらったこと、
この感謝の気持ちを忘れないようにしよう。
あいかわらずぐだぐだなブログだけど、
そろそろちゃんと書き始める。
ということで、4時やん。。。寝よう。。。
0 件のコメント:
コメントを投稿