クラウド座談会に参加して

昨日は、八子知礼さんのクラウド座談会に参加した。

テーマは、震災とクラウド。
震災時に、被災者のためにクラウドサービスを立ち上げた企業のプレゼン。
本業がある中、自ら進んで、サービスを立ち上げたことがすばらしかった。

ただ、被災地の方にとって使えるものかと言われれば、問題山積だ。

今回の大地震が起きる前に、大地震が起きた時にあるといいクラウドサービスについて考えていた人は、どれくらいいるだろうか。

今回の大地震を教訓に、危機管理のマネジメントを含めて、あったらいいクラウドサービスを準備しておくといいのでは？と思った。

例えば、救援物資のSCM。
できるだけシンプルな形でデータを予め設計しておく。
大事なのは、「どこに何がどれくらい不足しているのか、どこから、何をどれくらい提供するのか。今、救援物資がどんな状態か。」
といったところか。
状態は、できるだけシンプルに分類する。状態遷移もできるだけシンプルに。

もう一つの課題は、紙からネットへの転記の問題。これは、クラウド以前からの問題だ。もし、紙をカメラで撮影し、クラウドソーシングで、データ入力する仕組みを作れればうまくいくのでは？と思った。問題は、現地からカメラで画像をネットで送れるのか…データ入力したら、現地が要求しているスピードに間に合うのかが分からない。

世界では一年に一回くらい大災害が起こっている。今回の大地震を教訓にこれをパッケージ化するのは、ありかもしれない。

被災地の復興に関しては、被災地の強みをまず考える。それを軸に復興計画を立てるのが良いのでは？と思った。
被災地の強みとして、真っ先に思いつくのは、農業、水産業。
これらを大規模化して集約する。
農業、漁業人口自体は少ないが、加工、販売まで含めると、それなりの数の雇用を生み出せるはず。
特に、漁業は衛星管理、保存技術などを上手く利用して海外に輸出する。最近の日本の冷凍技術は、人間の臓器を冷凍して移植できるレベルのものが量産可能だ。
世界中で健康志向が強まっている中、保存技術にブランドをかけて日本から販売する。
日本の大手企業が、企業イメージアップも考慮に入れた上で、その食品をネットなどのさまざまなメディアでプロモーションする。

正直、テーマが広大すぎて抽象的な話となってしまった感じは否めないが、自分ならこうするという真剣に考える訓練になったのでは？と思った。

最後に、参加された方、素晴らしい会をありがとうございました。

生産性の前提

今日、改めて、なぜ先日リリースしたシステムの生産性が悪かったのか、打ち合わせがあった。

お偉方はソースコードのSTEP数でしか判断できないので止むを得ないが、STEP数に含めるものの前提が違うのに、ある指標を使って生産性を測るのは勘弁して欲しい。
今回は、一部ソースコードを自動生成した。

今回のプロジェクトに限って、その分を規模として認めてもらえない。
自動生成すればする程、生産性が下がることになる。そんな馬鹿な話があるかと思ってしまう。

過去の指標を参考にするのは構わないが、前提が違うものを参考にされてはたまったもんじゃない。

クラウド時代は、システムで実現できることを基準とすべきで、ソースコードのSTEP数で、判断すべきでない。そもそも、生産性を計測すること自体、意味の無いことになっているのではないか。

プロダクトアウトの考え方で、システムを作るのはもう終わりにしたい。

チームでの振り返り結果

今月初めに納品したプロジェクトチームの振り返り。自分の考えを申し上げたが、情けない回答が返ってきた。

何が情けなかったか。

 

一点目は、「お客さまの言われたとおりのシステムを作っていればよい」ということを言われたことだ。確かに、お客さまの要望は大事だ。しかし、お客さまにも予算があり、何から何までお客さまのご要望に応えていたらビジネスとして成り立たない。

今回、自分がどうしても納得のいかない余分な機能があった。開発規模は少ないが、難易度は高い。試験パターンが複雑で工数が膨らむので、自組織としてはコストがかかる。お客さまの業務に必ずしも必要だとは思えない。しかも、この機能を開発することで品質が悪くなると確信できる。保守時にシステムを改変したい場合、余分なコストがかかる。

本当に、これがお客さまのためになるのか...

 

また、「見積もりに制約条件をつけたらどうか」という問いに対して、上司は「競合他社に取られる」と言う。確かに、競合他社を意識する必要はある。それ以上に、お客さまのシステムを知っている自社のアドバンテージを意識したい。私がお客さまの立場だったら、「何でもできます」という姿勢は、かえって何も考えていないのではないかと疑う。具体的な言葉で説明できないエンジニアでないと信用できない。

 

品質を上げるために「このドキュメントも必要だよね。」とか「このタスクも必要だよね。」とか、管理するために「この項目も必要だよね。」など、様々な意見が飛び交った。そりゃ、お金と時間が沢山あれば、先ほど書いたことも全部できるさ。でも、限られた時間で本当に、こんなことまでできるの？と言いたくなる。所詮、他人ごとなのだと思った。

 

もちろん、周りの意見を聞いて改善せきる点も多々あった。

ただ、コスト削減が中心で、新たに価値を提供するという観点では、何の改善もみられなかった。お客さまの業務改善まで踏み込まなくてよい、あるいは、そこまで踏み込む必要はないという上司の言葉に対し、非常に悔しく思った。これでは、永遠にお客さまの奴隷だ。だから悔しかった。こんな会社、組織のスタンスでお客さまと付き合いたくない。

もちろん、お客さまの業務改善まで踏み込むには、お客さまから信頼を得ていることが前提だ。今回は、私にとって初めてのお客さまであったため、まだ、業務改革案を出しても受け容れられないだろう。だが、お客さまに断られても提案はする。なぜ、この方法をとらないのですか？と。納得できる理由が無ければ、他に理由があるはずだ。

 

今回は、初めてお客さまのための自分の作品とよべるアーキテクチャを作成した。今どき、0ベースでスクラッチ開発するケースは少ない。フレームワークの選定から共通部分のアーキテクチャ、メンバーへの教育...さまざまなことを経験させていただいた。お客さまからの厳しい要求の中、納品できたことは、自分にとって次に繋がると確信が持てる。

 

次こそは、提案のチャンスをいただきたい。社内だろうが、社外だろうがどちらでもいい。自分を必要としてくれる人がいるなら、オファーをいただけるなら、ビジネスのゴールをヒアリングして、企画、アーキテクチャ策定段階から参画したい。

 

逆に、災害情報だけになってしまうtwitter

今回、自分のtwitterのタイムラインが災害の情報でほとんど埋まってしまい、他に必要な情報が得られないというちょっとツライ状況になっている人も多いのではないか。

今回、首都圏に住んでいる人で普段と同じように生活できている人も多い。もちろんそれは幸せなことであり感謝すべきことであるが、人それぞれ知りたいことがあるはずだ。

あらかじめ想像できたことだが、実際に体験してみると、自分が伝えたいことが地震関係のtweetでかき消されていうく感じがする。

だから、地震の話題が収まるまでtwitterを使用を控えます。使用したとしても、mentionくらいかなぁ。

 

今日も、仕事している私...いや、こんな時こそ、仕事が捗るからいい。そう思うようにしよう。

災害時のSocial Mediaの威力

昨日から、日本のインターネットのインフラは、改めて凄いと思った。 電話は通じなくても、ネットは通じる。 みな、携帯電話から情報を取得していた。 特に驚いたのが、twitterの情報伝播の速さだ。 災害時は、twitterをやっている人が、口頭で情報を伝える。twitterをやっていない人に驚く程伝わる。

日本人が冷静に行動できた理由の一つに、Social Mediaでうまく情報の取捨選択ができたことが挙げられるのではないか。

やりたいこと

プロジェクトが終わって、改めて自分がやりたいことを再確認した。

自分がやりたいことは、世の中に受け入れられるサービスを創りたい。
お客さまの要望を分析して自分で仕組みを考えて、新しいサービスを創りたい。
お客さまに喜んでいただくというより、無意識に当たり前のように使っていただけるものにしたい。

もう少し具体的に落とし込むと、お客さまの求めているモノを把握し、ソフトなりシステムに落とし込みたい。

今回のプロジェクトに参画して改めてそう思った。
また、現場のメンバーが新しい知恵を出し合って最高のモノを作りたいとも思った。

ただ、仕事をする以上、納期とコストという壁は、避けられない。
ただ、人月的な生活が送れなくなる状態だけは避けなければならない。

生産性とか人月商売、価格で勝負をする前に、価値で勝負したい。

恐らく、今週はプロジェクトの振り返りがあるだろう。
今の自分の軸と照らし合わせて、将来に向けて行動する。
振り返りが自分のターニングポイントだ。

プロジェクトをひと通り終えて

昨日、お客さまに納品した。ある意味、一区切りついた。
これから、お客さまが受け入れ試験を行うので正直油断はできないが、振り返りする上ではいいタイミングではないかと思った。

以下、気持ちを徒然と書いています。テクニカルな情報などは記載していませんので悪しからず。




今回のプロジェクトで自分の心に残った悔しい言葉がある。「生産性が悪い」という言葉だ。
プロダクトコードの規模の割には人手が掛かりすぎているという。
確かに数値だけ見れば、指摘の通り。
今回は、フレームワークや共通化を図って規模を少なくしてくださいというお客さまの要望があった。
共通化や抽象化をすることで、プログラムの難易度が上がる。
しかも、フレームワークを使用する、ソースコードを自動化するなどして規模を抑えた。
しかし、上司は自動化した部分も含めて規模として認めてくれなかった。
規模を減らすために努力した結果が「生産性が悪い」という言葉につながった。
非常に残念で悔しい。

規模を減らした結果、試験の工数が減るかどうかといったら何も工夫しなければ試験の工数は減らない。むしろ、単位規模あたりの試験工数は増える。
比較対象が、過去の非効率なたくさんのコードであるならなおさらだ。
徒競走する際に100メートル走と300メートル走でかかる時間が同じかどうか比較しているようなものだ。

規模が減ることに比例して工数を削減できるとは限らない。
開発現場を直視している人であれば理解してもらえるのだが、単純に集計した数字でしか物事を判断できないようでは、同じように社内で開発している人にとっては、先が思いやられる。
ただ、上から規模ではなく、工数を減らすための工夫を求められているのも確かだ。
工数を減らすために何をすべきか、これは自分にとっての新たな課題だ。

ただし、自分にとってたくさんの成果があったことも確かである。

・ リスクの高い新技術、アーキテクチャを採用したこと
その際にさまざまな数値を記録することができた。
新技術を導入する場合、何をどこまでする必要があるか分かった。

一番の成果は、自分にとってこのしんどいプロジェクトをやり遂げたこと。
そして、これからこの成果を元にさまざまなエンジニアの方と情報交換ができるのではないかと考えている。

これから、自分の策定したアーキテクチャを使用したプロジェクトの第二弾が始まる。
それは、今回リリースしたシステムとは別のプロジェクトだ。
ゴールデンウィークまでまた、家に帰らない日々が続く...