災害時のSocial Mediaの威力

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

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

やりたいこと

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

社内失業 - 企業に捨てられた正社員 を読んで

今日、書店にふらっと行ったら、一冊の本に目が留まった。

「社内失業 - 企業に捨てられた正社員」
そう、「社内失業」自分もそれに近い経験したよなぁ、1年弱くらい。

私も、ある火を吹いた超問題プロジェクトで、プロジェクトリーダとしてヘルプで入ったが、問題を収束できず大失敗をしてしまった。その後、しばらく仕事が少ない状態が続いた。

リーマンショックがきっかけでIT予算がシビアになり、客先で仕事が少ない状態だった。
これを気にリストラに遭った人、待機社員となった人（特に当時の新入社員）も少なくない。

何とか現状を打破する手段の一つとして「twitter」を始めたのがきっかけで、社外の様々な方からいろいろ教えていただくといった思わぬ副産物をいただいたが...

また、上司に生意気と思われても様々な提案をした。ほとんどスルーされたが...
それが今、成果となっている。

今は、あるプロジェクトの開発リーダをやっている。そのプロジェクトには新入社員（女性）が１人いる。
もちろん、新入社員の育成は自分のタスクの一つ。
節目節目でゴールを伝えている。決して甘やかすつもりはない。
予算ギリギリで新人を教育する余裕はない。その状況もきっちり伝えた上で、新入社員に仕事を割り当てている。もちろん、欲を言えばきりがない（新入社員も３年目くらいの社員と人件費上はそれほど変わらない）が、彼女はよくやってくれていると思う。

ただ、書籍を読んで感じたのは、現状の問題提起がほとんどで解決策にもっとページを割いて欲しかった。社内失業をどう乗り越えたのか。そういった事例があれば、掲載していただきたかった。
また、社内失業という立場にある人同士で、何かコミュニティを創るのもありかもしれない。
決して傷の舐め合いではなく、お互いの現状を把握してアドバイスをしつつ解決する。
同じ立場の人だからこそ、何か知恵を共有することで解決策が見つかると思います。

そういった場を提供できればいいなぁと思いました。

技術力って言うけれど...

今年度の下期が始まって１ヶ月が過ぎた。
以前、ブログで自分の仕事の価値について書いたが、はっきり言って自分のプロジェクトは価格競争に巻き込まれている。
そう、お客さまに提案するだけのウリがないのだ。

上司の下期のプレゼン資料に「技術力がない」「提案力がない」「リスクを積みすぎている」という指摘があった。
正直、抽象的すぎる。各階層の社員のゴールの設定が甘いのだ。
例えば、「技術力がない」というのは、具体的に何をどこまでやれば充分なのか分かりやすいゴールがない。「提案力」も然り。「リスク」も具体的にどの部分がリスクでそれを減らすにはどのような方法が必要か誰も解決策を見出そうとしない。

と言って、上司を批判していても先に進まないので、今の自分のプロジェクトから強みとなるもの、最近の技術トレンドから具体的な目標値をドキュメントにして上司に提出しようと思った。
そうすれば、上司も新規のお客さまに何か提案できるかもしれない。

仮に、上司に受け容れられないなら、社外でその技術を必要としている人を探してもいい。
お客様が何を望んでいるのかを知るには、自分の今やっていることから強み、ウリを抽出し、お客様に役に立ちそうなことを見つけるというのも充分にアリだと考える。

というわけで、明日（いや今日）はパワーポイントで提案資料を作成する。

facebookをちょっといじってみた。

今日で10月も終わりです。

今日、仕事の息抜きにfacebookをいじってました。
今までfacebookは、ほとんどやっていません。
ただ、facebookでもやっていたことがあります。それは、友達の承認。
実際にお会いした人はできるだけ早い段階で承認するようにしている。
今日改めてfacebookのfriendsの数を数えてみたら50人を超えていた。
facebookで友達承認した人は、今年の初めまでは全く知らなかった人がほとんどです。
twitterで知り合った人がほとんどです。
去年までと比較すると50人の方と知り合うということは信じられない世の中です。
本当に。
もちろん、直接お会いした方でfacebookをやられていない方もいらっしゃいます。

そういう意味では、様々な方から刺激を受けました。
私がお会いする方は、私より人生経験がある方ばかりで、私の想いや悩みを親身になって聞いていただきました。普段の仕事で学ぶ以外の大事なことを教えていただきました。

今年の前半は、コミュニケーションにカオスを起こせた年だと思っています。来年になると、Social Mediaが既に普及しているため、負の面が誇張されるのではないでしょうか。そんな中、トラブルも無くSocial Mediaで出会った人と楽しく過ごせているのは繋がったみなさまのお陰です。

来年は、twitterでゆるく繋がった方とより信頼を形成していく時期なのかなぁと思っています。かといって、特別何かをするということではなく、今までと同じペースでゆるくお付き合いさせていただこうと思っています。

今までお会いした方でfacebookをやってらっしゃる方、このアカウントにfriends申請していただけると助かります。

今後ともよろしくお願いします。

自分の仕事の価値

最近、仕事が忙しい。なぜ忙しいのか。
お客様の要望と自組織で把握している要望のギャップが激しいため、調整に時間がかかる、または見積りに差が出ているためだ。
契約してしまった以上、契約で曖昧なところはお客様の言い分を聞かざるを得ないケースがほとんどである。

大概は、そのお客さまの言い分は、自分達の無料の稼働となってしまう場合が多い。
特に技術的なことに関する見積りは、管理職には分からない。だからツライ。
自組織で使用実績のないパッケージやフレームワークを使ったら工数＆コストを削減できるということでお客様に見積りを出す。
見積りを出す際の根拠も何もないからお客様に値切られて契約する。

そうなったらたまったもんじゃない。ほとんど皆無に等しい工数で、スケジュールを守る必要が出てくる。お客さまには、レビュー時に使用するパッケージやフレームワークに関する様々な質問を受け、その結果、パッケージやフレームワークを調査する稼働だけでなく、それらの使用方法に関するドキュメント作成に関する稼働が想定以上にかかってしまう。

そうなると、自分の仕事の価値はほぼ０となる。
必要な作業だが、その部分の作業に対する対価は０なのだ。

確かに、見積りをした管理職に見積り観点が抜けて赤字になってしまうことは問題である。
だからといって管理職を責めているわけではない。
通常、システム受託開発をしている企業の管理職は技術に疎い人が多い。
技術者自身が、自分の仕事がお客様の業務を遂行するために必要な工程であるならば、正々堂々と自分の仕事の価値を主張して見積りにその部分を加えなければいけない。

ソフトウェア受託開発業界は、仕事が降ってくる時代は終わった。
技術者が、お客様からヒアリングして費用対効果のある技術とそれにかかる価値を主張しなければ、今後は貧乏になるだけではなく、モチベーションも下がり、結果幸せな人生を送れないのではないか。
もちろん、一部の会社はそれが組織だって出来ている。そういう企業にいる人は（初期メンバー以外は）楽をさせてもらっていると思う。

ただ、嘆いていても仕方がない。
まずは、自分の仕事でお客様にどのような価値を与えられるのかを説明する。
そのためには、お客様からのヒアリングだ！