初めてマネージャーをやるときに、やってしまいがちなのが管理しすぎて管理できていないという失敗です。

あれやこれやと自分のやり方をすべて相手に強制するのは、まあファーストフード店のバイトの管理ならいざしらず、頭脳労働においてはいいことはありません。

ストレスになるだけです。

頭脳労働というのは、細かい部分では作業者本人に意思決定をしてもらわないといけないのです。
いちいち、細かく指示しすぎると、上っ面の作業をされてしまいます。

もちろん、何をやっていいかわからなくて手が止まっている人には、やるべきことを示唆してあげることは大事です。
ですが、目的もなくこれ以外のやり方はNGとしてしまうのは問題です。

大事なことは「使ってよいリソース」と「成果」について合意することです。
使ってよいリソースは、お金だったり、マシンだったり、その人の時間だったり、期限だったりしますね。
それらを最適に配分して成果を出してもらわないといけないのです。

そこを外して細かく指示をしすぎると、「それは聞いていません」と言われてしまうのがオチです。
あるいはそれすら言ってもらえず、「あの人は気分で指示をする」なんて陰口を言われてしまったり。

そうならないためにも、成果については正確に共有するように努めましょう。

たとえば、初めて一緒に仕事をするプログラマーに指示をするなら、

　要件はこれです。
　この辺りは要件が詰まっていないかもしれないのでいっしょに考えてほしいです。
　実装から単体試験の仕様書作成と実施まで行ってください。
　単体試験のガイドラインはこれです。
　最終期限は今週末ですが木曜日中に終わるようにしてください。
　帰宅前に、どの程度できているのか、わからないことはないかを聞くので用意しておいてください。

という風に、成果については事細かに言うのがよいでしょう。

間違っても事細かに指示するのは手順ではないですよ。

まあ、若くしてマネージャーになった人にありがちなことですが、そういう人は大体、まじめですね。仕事が大好きです。
それは良いことなのですが、仕事が好きなあまり、最善でなければ許せなくなってしまうんですね。

結果として、最善と信じることを、部下にも信じてほしくて説得してしまうわけです。

これは絶対にいけません。

人にはそれぞれ、考え方というものがありますから、それを曲げさせてはいけません。
マネージャーがやってよいのは決定することだけです。

決定内容に従って業務を遂行する義務が部下にはあるわけですから、それで十分ではありませんか。
相手の考えを曲げさせる必要はないのです。

あなたは、部下より優越的な立場にあるのですから、考えを曲げさせることはできるかもしれません。
ですが、それを気持ちよく思う人なんていません。
あなただってそうですよね。

ただ、決定すればよいのです。
「あなたの言うことには一面で正しさがありますが、今回はこうしようと決定しました。ご協力ください。」
という風に、あるいは今回はこうしたいんです。でもいいです。

間違っても、
「あなたの考え方は間違ってる。これこれ、こういう理由です。」
なんて言わないことです。

相手を貶めても何もいいことはありません。
人として敬意を払いましょう。

気づけば40才も過ぎ去ろうとしています。
どれほど読んでくれる人がいるのかはわかりませんが、20代後半の若いエンジニアに向けて、自分の失敗を踏まえてマネジメントについていろいろ書いてみようかと思います。

僕はつい最近まで、ほんの5年前くらいですかね。
技術力が高い人がマネジメントをやるのが良いと本気で思っていました。
良いマネージャーになるために技術を磨く？みたいな。

もちろんそれは違うのですが、技術に自信があるとその事実がなかなか認められないんですね。

まあ、そんなわけで、これからリーダーやマネージャーになろうとしている人のために、いろいろと不定期で書いていこうかと思います。

マネジメントカテゴリを作りました。

たまにチェックしてみてくださいね。

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

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

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

今のところ、正直に言って黒字にはなってはいませんが、売上が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ですとかアーキテクチャ変えていてはノウハウもたまりません。
反復できない開発プロセスでは、いつも行き当たりばったりの結果しか得られません。

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

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

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

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

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