注意：このエントリーはたぶん広告です。話半分に、、、

前回書きましたが、というショップを始めました。
開始からそろそろ一か月がたとうかどうかというところです。

デザインを変えたり、リスティング広告をしたりといろいろ試しています。

今のところ、正直に言って黒字にはなってはいませんが、売上が0ではないというのが せめてもの救いです。

実はこの仕事を始めるまで恥ずかしながら
「ベッドリネンは白(無地)だろ！」
と思っていました。

具体的な名前は出しませんが、 5000円以下で買えるような通販なり、量販店（？）なりでベッドリネンを買いに行くとなんというか、色がついているほうがしょぼいんですよ。
貧乏くさいというか。。。

だったら白のほうがましと思っていました。

視野が狭かったです。はい。
この仕事を始めるにあたって、伊勢丹とかに行ってみると、良いベッドカバーってたくさんあります。

ラルフローレンみたいに高価なベッドリネンじゃなくても、もうちょっと安め？で良いものがあるんですね。

とはいえ、インターネットで検索してみると、そんなに良さそうなものもなかったので、だったら初めて見てもよいかなと、思ったわけです。

というわけで、始めた瞬間に商品を失敬したわけですが、部屋の色彩が変わりますね。
今、住んでいるところは、お世辞にもきれいと言えるような ところではないのですが、（大家さん、ごめんなさい） なんちゅうか、高級感が出てしまいましたよ。

なめてましたけど、布団カバーの見える面積って広いので部屋の印象を大きく変えてしまいますね。お客さんに見せる部屋でないのが残念です。

というわけで寝るのも楽しい感じです。

同じ柄は一週間で飽きますけどね。
毎日楽しい感じにするにはお金がいくらあっても足りないなーと思ってしまったり。

おそらくこのページをご覧になる方は9割以上が男性です。
興味がない方も多いかと思いますが、そんな方にこそ、一度、デパートなどで見てみていただけたらと思います。

意外に良いですよ。

PS
残念ながらうちのサイトは女性向けですけど、良かったらのぞいてみてください。

いつもお世話になっております。
私事ではありますが、ネット通販を始めました。

初めての社員がまさかエンジニアではなくMDさん？（というよりなんでも屋さん）となるとは思いもよらなかったですが、そういう人と組むことにしました。

やはり通販にかかわるシステムにたずさわる以上、自分で売ってみないことにはお客様のニーズ、いや苦労を本当には理解できないだろうというところが出発点です。

とはいえ、商売である以上、お客様をないがしろにすることはできませんので、本気でやってくれる人と組むのが良いと思ったので専任の人にお願いすることにしました。
(もちろん予算の範囲でやってくれる人です)

ゆくゆくは会社を分けれるまで成長してくれたらいいなと思います。
失敗したところで、それも経験として本業のお客様のお役にたてればそれでよいです。

商材はベッドリネンです。

大きな投資ができないので商材が少ないのが残念ですが、 予算の中で良いものを選んでもらったなと手前みそながら思います。ご高覧あれ。

http://piccolo-stagno.jp/

よかったら、リンク先のいいね！をぽちっとお願いします。良くなければ、、、仕方ありません。
ご意見、いただけると嬉しいです。

さて、本業はシステム屋さんですので、ちょっとだけシステムのお話をすると、EC-CUBDEでとりあえずは構築しました。
EC-CUBEはフリーでありながら、それなりに機能がそろっているところが良いですね。
blogなどでは散々な言われようですが、構成が比較的単純なので、それなりのエンジニアならば、カスタマイズが楽にできるのが長所だと思います。
(それゆえ、粗も目立つのでしょうが、、、)

また、進展があったらご報告します。

今日はエンジニアとスムーズに会話をするために気を付けておいたほうがよいことを書きます。

すべての人に通用するテクニックではありませんが、ちょっとエンジニアのことを知っていただけたらと思います。

会話の始まり

エンジニアというのはとても特殊な仕事で、勤務時間中にあまりほかの人と会話をしません。

「おはようございます」と「お先に失礼します」
で事足りる日も多いです。

だからというわけではないのですが、会話が苦手です。といいますか、会話慣れしていません。
まったく口を開かないのに口を開くと止まらないのがエンジニアです。
会話というのは本来はキャッチボールなのですが、 それができるのはお互いが相手を理解しようとしている場合や、十分理解してもらっていると実感できる場合だけです。

会話というのは意識的にコントロールしようとしないと、次の3フェーズをたどることになります。

1. 恐怖心や億劫さでだんまりを決め込むフェーズ
2. 自分を知ってほしくて相手の反応に構わず話し続けるフェーズ
3. キャッチボールができるフェーズ

というわけで、会話ができるというのはかなり高度なんですね。
多くのエンジニアは2のあたりで止まってしまうので、絡みづらいなどと言われがちだったりします。

なので、ちゃんと話をする必要があるときは、長めに時間を取っておくのがよいかと思います。
会話に慣れさせてあげるというのが必要です。

そうしておいたほうが効率は良くなるし、あなたのことをより理解してくれると思いますよ。

話が分かりずらい

エンジニアの話は分かりづらいといわれます。
確かにそうなのですが、いろいろと理由があります。

エンジニアというのは、基本的には言われた仕事をする職種です。
こういうものを作ってくれと言われて作る仕事です。

ですから自分で作るものを決めることができないのです。
徹夜して作ろうが、ものすごく労力をかけていようが、オーダーした人が違うといえば違うのです。

ということは、エンジニアとしては無駄な労力をかけたくないですから、自然と正確に伝える必要性が出てくるわけですね。
オーダーした人にとってはしくみなんてどうでもいいのだけど、作る人はしくみを必死に説明します。
なぜかといえは、1と2なら3、5と4なら9という風に実例を挙げ続けるより足し算の仕方を教えたほうが速いし正確に伝わると思っているからです。

オーダーする人は全く聞いていないのに。
それで、いいよいいよと生返事をして、できあがってみたらあっさりと「違う！」なんて言っちゃったりしちゃうわけです。

その時作り直すのはエンジニアです。エンジニアの責任において作り直すのです。

こういった経験が積み重なると、エンジニアはより正確に伝えようとします。
そして専門外の人はより分からなくなります。あいつの話は分からん。と、こういうわけです。

出発点は、オーダーする側が自分の責任で伝えていないことです。伝わらなかったらエンジニアのせいにしていることです。
せめて責任を共有する形にしないといけません。
あいつは話が分からないやつだとか、あいつは仕事ができないとか、思っていませんか？

それではいつまでたっても溝は埋まりませんよ。

結局のところ

エンジニアを毛嫌いしたり、下に見たりするのは得策ではありません。
職種の違う仲間だという感覚が必要です。

エンジニアは偉そうにしているように見えますが、それは恐怖心からの場合がほとんどです。
とにかく安心させてあげてください。
そうすればきっとあなたのために最高の答えを出してくれるはずですよ。

最近、PMO(Project Management Officeほか、何種類かある)という言葉がはやり始め、導入している組織も多いことと思います。
ですが、多くの場合、PMOはプロジェクトマネージャの補佐として動いているのではないでしょうか。

位置づけ

以前、ポートフォリオの話を書きましたが、管理の仕方はいろいろあるにせよPMOは会社にあるソフトウェア資産というポートフォリオの価値を最大化させるというのが最も大きな目的となります。

通常、プロジェクトマネージャは自分の扱うプロジェクトの利益を最大化するために注力するものです。いわゆる個別最適化です。一方でPMOには複数のプロジェクトにまたがった最適化を行う責務があります。

人選

PMOは、ポートフォリオの価値に興味がある取締役を中心に組織するのが良いです。
PMOにはある程度の予算と権限、そして人的リソースが必要です。特に、人的リソースについては、一番良い人を当てることが大事です。

PMOはプロジェクトマネージャを指導する立場になる場合もありますから、プロジェクトマネージャから信頼されていなければいけません。どうでもよい人を当てると、すぐにプロジェクトマネージャの補佐的仕事をする組織になってしまいます。

とはいえ、プロジェクトの指揮官はプロジェクトマネージャなのですから、プロジェクトマネージャの最終的な判断を支持しなければいけません。でないと、うるさいだけの人になって、プロジェクトマネージャのやる気をそいでしまいます。

プロジェクトマネージャとの関係

プロジェクトマネージャは大きな責任を負っていますから、その負担を軽くしてあげることが大事です。プロジェクトがうまくいかないとき、単に責めるのは良くありません。一緒になって考えることが大事です。

一方で冷静な視線で、プロジェクトマネージャを評価することは大事です。特にプロジェクトマネージャがプロジェクトの状況を理解しているかどうかは重要なポイントです。
プロジェクトをコントロールしたうえでの遅延は、先が予測できるので大きな問題ではありません。
反対にたった今、遅延がなくてもプロジェクトの先が読めないというのであれば、すぐに手を打たないと大変なことになります。
プロジェクトの状況を聞いたときに、リスクや体制、進捗などをすらすら答えられるかどうかで大体はわかると思います。

そうそう、プロジェクトをやめるという判断はプロジェクトマネージャにはできません。
これはPMOの最も大事な仕事のひとつです。

最後に

いろいろ書きましたが、最後に。
標準化だなんだといったところを、PMOが行うことは多いのですが、莫大な工数がかかるので中途半端になるのがオチです。
明確に解決したい課題がない限り、やめておくべきでしょう。

そもそも、PMOはマネジメントの専門家であって、ソフトウェア工学の専門家ではありません。
どう作るかについてはソフトウェアアーキテクトに任せておくのが良いと思います。

それに、そんなことをしている暇もないくらい、PMOは忙しいですよ。

僕がこの仕事に対してどのようなイメージを持っているかについて、簡単に触れようかと思います。

ソフトウェアアーキテクトの主な仕事はソフトウェアとその開発プロセスの設計です。

ソフトウェアアーキテクトは、今のところ、おおよそ工業的という言葉からは程遠いソフトウェア開発において、成果物のすべてを見通すことを要求されている仕事だと思います。

木を見て森を見ずというのは慎むべきですが、森ばかり見ていてはソフトウェアは出来上がりません。木を見ながら森のバランスをとる人が必要です。
なぜなら成果物は木であり、その集合体である森なのですから。

よく難解なソフトウェアを設計して、うまくいかなければ周りがついてこれなかったからだと言ってしまう人を見かけますが、本来のソフトウェアアーキテクトなら、開発体制を見て現実的な設計をするでしょう。

ソフトウェアアーキテクトの仕事の良し悪しは、成果物が要求どおり動いたかどうかで判断されてしまいがちです。
それも確かに大事ですが、長期的に判断されるべき要素が多いのも事実です。
成果物となるソフトウェアが運用・保守・改修を通して、安定してサービスを提供できたかどうかはとても重要なことです。動けば良い、というわけではありません。

以上、自戒もこめて。

外出時にデータ通信を使いたいと思ってモバイルブロードバンドをさがしていました。

そんな中で、DoCoMoのXi(クロッシー)というサービスが目を引いたので思わず契約してしまいました。
このサービスは昨年12月からスタートしたもので、良くわかりませんがLTEという分類だそうです。
通常であればイー・モバイルかWiMAXあたりを選ぶ方が多いのではないかと思いますので、これらと比較する形でご紹介します。

提供エリア

イー・モバイルもWiMAXも全国の主要都市はほぼカバーしていることを考えると、一般的にはこのあたりでよいかなという感じもあります。
一方でXiは始まったばかりのサービスなのでエリアは首都圏に限られます。

その代わりといってはなんですが、Xiによる通信が行えない場合、FOMAで通信できます。これを含めるととんでもなく広いエリアをカバーすることになります。

回線スピード

WiMAXは使ったことがありません。イー・モバイルも最近の42Mbpsのは使ったことがありません。数Mbpsのイー・モバイルとくらべると格段に速いです。

というか、使っている感覚としては、家の光回線でWebを見ているのと区別ないくらい早いです。

というかですね。Windows Updateがさくっと裏側で走るので恐ろしいです。後で書きますが従量課金ですので、気を付けておかないとすぐに5GBを超えてしまいます。

通信品質

正直、比べようがないのですが周波数帯でいうと、DoCoMoやイー・モバイルが1.5～2GHz帯を使っているのに対して、WiMAXは2.5GHz帯を使っています。一般的には建物内など障害物が多い場所ではWiMAXは繋がりにくいということになります。

実際のところ、使いたい場所でつながるかどうかなので何とも言えませんけど、DoCoMoが1.5GHz帯を使い始めたころmovaと違って切れやすく、周波数帯って大事なんだなあと実感したのを思い出します。

あとはイメージでしかありませんが、天下のDoCoMo様は屋内アンテナの設置数が多いせいか高層階でも比較的つながりやすい気がします。
また、さっきも書きましたがFOMAが使えるのでまったく通信できないというケースは主要都市に限ればほとんどないのではないかと思います。

金額

今は、キャンペーン期間中なので4,935円で使い放題なのですが、1年後からは5GBまで6,510円、それ以降は2GB毎に2,625円という恐ろしい金額です。
ちなみにイーモバイルが2年契約で4,580円、WiMAXなら1年契約で3,880円といった感じでかなり差があります。

で、どれを選ぼう？

結局のところ、どれを選ぶかといえば、当たり前ですが目的によります。

家で有線ネットワークの代わりに使うのであれば、従量課金しかないXiはありえないです。
使えるかどうかの確認は必要でしょうけど、通信速度からいってWiMAXが最有力でしょう。

そこそこ繋がってくれて、そこそこ速いという無難な線を求めるなら、イー・モバイルだと思います。値段もそこそこでいい感じです。

とにかく繋がりさえすれば速さは気にしないというのであれば、FOMAのデータ通信の契約が良いと思います。値段はXiほど高くないですし、固定料金の契約もあります。回線スピードもメールをやり取りするくらいなら問題ないです。
いろいろな場所へ出張する方には、こちらのほうがお勧めです。

首都圏では快適に、でもどこへいっても繋がってほしい、金ならあるという人ならXiがいいんじゃないかと思います。
実際のところどこででも使えるというのは、仕事で利用する人にとっては魅力なのではと思います。
(ちなみに僕はチキンなので転送量5GBでリミッターをかけてます)

以上、ご参考まで。

前回、パッケージベンダーということに限ってお話ししたのですが、実はパッケージベンダーというのは、そういった取り組みは十分にされていると思います。

むしろ中小のSIベンダー(ソフトウェアハウスとも)のほうが積極的に考えていく必要があります。

といいますのも、案件の話があってからどうするか決めてその場で新しいものを作ってという積み重ねのないスタイルではコストがかかりすぎますし、スピード感でもパッケージベンダーに勝てません。
あるいは、「実は、公開しているわけではないんですけどパッケージソリューションはあって、だからパッケージと比較しても安くて導入スピードでも引けを取らないんです。」なんていうトークまで必要だったりします。

そもそもですが、お客さんが言っているからJavaですとか、.Netですとかアーキテクチャ変えていてはノウハウもたまりません。
反復できない開発プロセスでは、いつも行き当たりばったりの結果しか得られません。

ですからパッケージベンダーでなくでもポートフォリオを作ってみることは有用でしょう。
営業段階から自社の強み、得意としているところを営業と握っておくこと。
逆に強みとしてほしいところを引き出していくという会話が必要だと思います。

それができればあとは開発側の仕事です。
ポートフォリオをもとに、それぞれのドキュメント形式、開発フロー、テスト工数、問題発生時の対処フローなどを決めます。

外向けの見積もりは、機能別の工数なのでしょうが、内部的には開発プロセスが異なる以上、部分によってコストスタック・開発リスクが違ってきます。

体制も、コアに近いところはプロパー・使い捨て部分は外注というように分かれていくでしょう。

そうした細かい改善の積み重ねが、品質を上げつつ利益を押し上げていくのだと思います。

最近、仕事がなかったのですがパッケージベンダー2社様(1社は仲介です)からお声掛けいただきました。ありがとうございます。困っているのでほんとにありがたいです。

というわけで、以前、パッケージベンダー(というかASPベンダー?)の開発プロセス改善に携わった時に感じたことを書きます。

巷にはプロダクトポートフォリオマネジメントという言葉があるらしく、僕は専門外ですが以下に説明があります。
http://www.atmarkit.co.jp/aig/04biz/ppm.html

今回、この整理の仕方を業務パッケージベンダーにおける開発に置き換えた場合について考えてみたいと思います。

とりあえずは、今回のために評価するための軸を決めます。業務パッケージについて回る宿命は顧客別カスタマイズです。

ほとんどすべてのパッケージはそのままでは導入できませんので、パッケージかお客さんのどちらかを変えなければいけません。通常は、パッケージのほうですけどね。

ただ、一様にカスタマイズが発生するわけではなく、濃淡があるのが普通です。

一方、パッケージベンダーが追いかけなければいけないのは、ビジネスモデルの変化です。
やはり、顧客はパッケージベンダーに対して豊富なノウハウと同時にスピード感を期待しますから、変化への対応力は大事になってきます。

というわけで２軸、とりあえずとったところで、名前を付けてみます。

使い捨て製品・・・変化も激しく、顧客ごとに違う要件が出てくる厄介な部分です。通常はあまりコストをかけずにお茶を濁したいところです。ドキュメント化もほどほどに、、、
ただし、もしかしたら差別化製品なのかもしれません。注意が必要です。

差別化製品・・・「工事進行基準対応！」とか聞こえのいいセールストークが出てきそうなこの部分は実験的でありながらも、精力的にお金を投下しないといけません。一番売りになる部分です。いずれそういったものはコア製品の次期バージョンに取り込まれていきます。

ラインナップ製品・・・あればいいけど、そんなに使うわけでもないような製品群です。お客さんの数が多ければ管理対象となりますが、余裕がなければ使い捨て製品と同じ位置づけです。すっぱり捨てるつもりでコストをかけるのをやめましょう。

コア製品・・・利益の源泉です。十分にテストされたコア製品は目立たないものの、堅牢性からシステムを使う人へ安心感を与えます。一方で、メンテナンスコストは下がりますから、ボロイです。
ただし、いずれ大規模バージョンアップが必要になりますので、ロードマップはお客さんと共有しておかなければいけません。

製品という言葉を使いましたが、通常、パッケージはこれらの複数の要素で構成されますのでコンポーネントと言い換えたほうがよりしっくりくるかもしれません。

一度、ふるいにかけてしまえば、それぞれについて同じ管理手法で対応していてはまずいというのがわかります。
必要とされるドキュメント量も違いますし、管理にかけられるコストも異なります。

投資回収の時期も違います。差別化製品などはコア製品へ取り込まれてから回収されます。
一方で使い捨て製品はその場で回収しなければ、回収時期がありません。

このポートフォリオを、営業・ビジネスアーキテクト・開発の３者が共有することで、より効率的なパッケージ開発ができるのではないかと思います。

・・・つづく・・・

友達のやっている会社のページを見てすごく興味の沸くサービスを見つけたのでご紹介します。

僕はもともと独立するまで、とある会社でプロジェクトマネージャをやっていました。
一日平均、2時間は数字作りなどの事務作業に追われていたのを良く覚えてます。

• EVMSとかで報告せいとか顧客からは言われるし
• 発注先の契約書やら支払いなどのステータスも管理しなきゃいかんし
• 他部署からはリソースを借りると振り替えだ何だといわれるし
• というかそれを見ながら、コスト管理なんてできないし
• それをエクセル＋VBAでやっていたもんだから、ファイル共有で失敗して上書きされたりと
• ていうか、俺、PMの仕事も半ばに、プログラムをがしがし書いてるし、、、、

まあ、ただでさえやらなきゃいかん仕事が多いのに、とにかく雑務がすごいんですよ。

とまあ、それはさておき、久々に友達の会社のページを見てたらそういったことを片付けてくれそうなサービスを見つけたわけです。
というか、すでに教えてもらってたわけですけど、、、改めてみると使ってみたいと思わせますね。
機能のカバレッジが心憎いです。

世の中にはこういうサービスがあるんですね。僕は不勉強なので意識してませんでした。
無駄な時間を使ってたなあと思います。

今はプロジェクトマネージャなんてやってないので必要はないけど、それでも触ってみたいです。

ZAC プロジェクト収支管理
http://www.oro.co.jp/zac/introduce/project.html

ZACはほかにもいろいろなコンポーネントがあるのですが、それは僕が当面は使うことはなさそうなので興味なしです。ごめんなさい。

なぜ、生産性の向上なのか。

よく言われているように、全人口に対する労働力人口の比率は減少し続けています。
以下、総務省統計局で公開されているデータをお借りしました。

このデータによれば、たったの5年間で労働力人口に対する65歳以上の人口比は6ポイント上がっています。割合にすれば13%程度の増加です。
あえて単純に考えれば、もし2005年と2010年の間で私たちの仕事の効率が変わらないとしたら、私たちは必要なものを13%我慢しなければならないことになります。

長期的にはもちろん自明のことなのですが、5年という短いスパンで見ればより具体的に近い将来迫ってくる危機を感じることができます。

私にできることは少ないかもしれませんが、システム開発を通して生産性の向上に寄与することで、この難局を乗り越えて行きたいと思います。