スイーツ（笑）と呼ばないで!!
|
| |||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
11/24/00:09 [PR] |
09/01/17:37 クライアントの担当者は何をもって評価されるのか。さて、今日はクライアント企業の人事考課制度とそれに合わせた営業戦略について話をしたいと思います。 我々がいるシステム開発業界のクライアントは、ほとんどが個人ではなく法人であり組織体であることがほとんどです。 つまり、実際に一緒にお仕事をさせていただくのは、その組織のいわゆる”中の人”です。 数人のチームの場合もあれば、1人の担当者のこともあります。 私は営業先に言って話をしている時、 「この担当者は何をもって評価されるんだろう」 と考えることがよくあります。 ざっくり言ってしまえば、どの会社でも「仕事をうまくやる」ことが評価される条件だとは思いますが、 これが実はかなり曖昧な基準だと思っています。 例えば、500万円の案件の見積もりを、300万円に値切ることに成功したらその担当者は評価されるでしょうか。 おそらく一瞬は時の人になれます。「よくそんなに値切れたなー、すごいなー」と。 ただ、その値切った200万円はその担当者のポケットに入るわけでありません。 さて、実際に大幅に値切ったプロジェクトが開始されるとどんなことが起こるでしょうか。 必ず起こるとは言い切れませんが、最終的に”安物買いの銭失い”になることも多々あるかと思います。 その時に一番苦労をし評価が下がるのは誰でしょうか? その担当者ですね。 そんな経験をした担当者が次に別のプロジェクトを発注する時、どんなことを考えるでしょうか。 上の承認がとれないほど高い見積もりは困るけど、承認が通るのであればどんなに高くても構わない、そんなことを考えるようになるケースも多いです。 つまり、発注価格が高くて、組織は嬉しくなくても、その担当者の懐は一切痛みません。 それよりも、トラブルなく万事がうまくいく方が、担当者のメリットは大きいのです。 値切り名人の名声は一瞬ですが、日々の安心した毎日とプロジェクト自体の成功の利益は長期間持続するものです。 そんな担当者が相手であればアピールするのは価格ではなく安心です。 「安心してください。納期までに、ちゃんと御社で許容できる品質レベルのものを、最初に約束した予算で、制作して納品します」 このアピールの方が価格を下げることよりも、しっかり担当者の心をつかむことができるはずです。 ちなみに、熟練の担当者になると、プロジェクトによって、使い捨ての業者と、勝負業者を使い分けるようになってきます。 もろちん、世の中には、真逆のケースもあります。 どれだけ値切ることができたか、で担当者が評価される会社もあります。 たまに、業者への発注の際にはすごく細かく審査して価格を下げるわりには、 炎上したプロジェクトの対応に追われる担当者の残業代や、 そのことでクライアント企業のお客様に迷惑をかけたことで失われる信用の価値には無関心というケースもあります。 よく観察してみると、最終的な価格が低いかどうかよりも、 値切り幅が大きいかどうかを重視しているケースなども稀にあります。 世の中、いろんな会社がありますね。 交渉の相手が、聡明なオーナー社長であれば、むしろ話はシンプルです。 そのプロジェクトの費用対効果にフォーカスして話をすることができます。 同様に、個人の評価よりも、会社にとっての利益を考える担当者も、 オーナー社長と同じようなロジックで話をすることが可能です。 皆そうだったらとても良いのですが、 残念ながら現実は様々です。 昔、家庭教師のアルバイトをしたことがありました。 サービスの費用負担をする親と、サービスを享受する子供。 クライアント企業と、その担当者。 両者の関係でもなんだか似たようなところがありますね。 最後に大事なことを一応書いておくと、 これはあくまで営業的なとっかかりだけの話です。 実際に納品するシステムは、やはりそのクライアント担当者個人のものではありませんので、 その企業、あるいは、その企業のお客様といった、より多くの幸せを考えて作成しなければなりません。 そこを妥協しちゃうとシステム開発という仕事が嫌いになってしまいますからね。
PR
|
07/20/13:45 その案件は本気でとりに行くべきかどうか?ある日会社にシステム開発を依頼したいという一本の電話がかかってきました。
案件にもいろんな種類があります。 電話を受けたあなたの頭にはこんな疑問が湧いていることでしょう。 その案件は本気でとりに行くべきかどうか? まず、大前提を書いておきます。 答えは 「はい。本気でとりに行くべきです。当たり前です。 せっかく弊社に興味をもってご連絡いただいた貴重なお客様です。 なんとかして気持ちに応える(結果として受注する)ための最大限の努力をするのは当たり前です。」 さあ、以上の当たり前の結論を先に書いておいて、ここから仮の話をいたします。 もし、超売れっ子になり、お客様が長蛇の列をなすようになったら、その時はどうしても選択しなければなりません。 その時どのように判断すれば良いでしょうか? 今日はファイブフォース分析というのをご紹介します。 マイケル・E・ポーターの名著「競争の戦略」で紹介されている分析方法ですね。 本来は産業構造を分析して、その分野に進出するかどうかなどを判断するためのものです。 規模は全然違いますが、それを案件を取りに行くべきかどうかという問題に応用してみます。 ファイブフォースとは以下の5つを指します。 記憶を頼りに書くので、正確な表現ではないかもしれません。 1.新規参入者の脅威 2.代替品の脅威 3.買い手の交渉力 4.売り手の交渉力 5.競合他社との関係 このうち上の2つは外部要因、下の3つは内部要因とか言われます。 さて、ここで具体例を挙げて考えてみましょう。 ECサイトをフルスクラッチで構築したいという案件だったとします。 1.新規参入者の脅威 まず、この案件にたいする参入障壁がどの程度か考えます。 ECサイトであれば、カート機能など少なくとも動的なページを出力する必要があります。 よって、プログラムを扱えるかどうか、という参入障壁があり、静的なページしか作れないWebコーダーなどは参入できません。 また、クレジットカードの決済が必須であれば、何かしらの方法で決済の仕組みを取り込める技術が必要です。 逆に、発注はメールフォームでOKとかであれば、参入障壁は下がりますね。 2.代替品の脅威 今回、ECサイトをフルスクラッチで構築したいということですが、場合によっては、楽天に出店するだけだったり、そもそもオークションサイトなど既存のサービスの利用で目的を達成できる可能性もあります。そういった代替品について考えてみます。 また、フルスクラッチではなくオープンソースのインストールだけでECサイトを作る業者のサービスも代替品と言えます。 3.買い手の競争力 例えば、クライアントが何度もECサイトを立ち上げている経験やITリテラシーがあり、また、東京などの大都会で、多数の業者から見積もりをとれる状況などあれであれば、買い手の交渉力は高く、弊社としては高い単価では通しにくいと言えます。また、逆に、クライアントが僻地に存在し、開発会社など近くにひとつもないような状況であれば、買い手の交渉力は低く、高い単価でも通る可能性が高いです。 4.売り手の交渉力 これは、つまりPGの調達の話です。例えば、その案件の要件として特殊な開発言語を使用することが明示されているとします。そうすると、なかなかPGを見つけることが難しいです。そのような場合は、売り手の交渉力が高く、コストを下げることが難しいと言えます。逆に、PHPなど開発者人口が多い言語を選べるのであれば、売り手の交渉力は低く、コストを下げやすいと言えます。 5.競合他社との関係 例えば、クラウドワークスのような、多数の競合と敵対するのか、3社コンペなどのように最初から絞られた中での戦いなのか、などについて考える必要があります。競争が激しい方が、コストもかかり、利益も上げにくいことになります。情報があれば、コンペ相手が、バッケージメーカーなのスクラッチ開発会社なのかにより戦い方を変えたりします。 以上が「ECサイトをフルスクラッチで構築」という案件についてファイブフォース分析をしようとした場合の観点の一例です。 競争が激しくなく、自社が競争優位に立てる案件を選ぶのが良いです。 参入する前の戦略的なフェーズで選択を間違わなければ、参入後の戦術レベルのところで苦労をすることは減ります。 戦略レベルの失敗は、なかなか、戦術レベルで取り戻すことは難しいです。 さて、最後に大事な前提のおさらいです。 これは、あくまで、お客様が長蛇の列をなしていてどうしても選ばなければならないとき、という仮定の話です。 現実で選り好みをすると・・きっと、社長に怒られます(笑)
|
10/30/12:01 失敗から学ぶとは生きているといろいろと失敗をする。 未来の成功のためには失敗から学ぶことが重要だ。 プログラミングの話で言えば、バグとかイケてない書き方なんかは失敗と言えるだろう。 たまに、 「私は自分が書いたソースコードとか間違いとかあればどんどん突っ込んでもらいたいですね」 というような言葉を耳にする。 この言葉は、実はこの言葉を発する前にどのくらい努力をしたのかで解釈が変わってくる。 例えば、時間がないからと場当たり的に書き、そのコードを見せた後で、このセリフを言ったらどうだろうか?自分でも100点とは思っていないコードだ。 そこでツッコミが入っても、一瞬ムカっとすることはあっても、たいして悔しくない。自分の中で言い訳もできるから。 でも、その失敗からはあまり多くは学べない。 失敗から大事なことを学ぶためには、大前提として、本気で取り組むことが重要だ。 自分の中で極限まで力を尽くし、もう今の自分ではこれが作り出せる最高のものだ、というところまでやりつくす。 そこで初めて「これでもダメなところがあれば教えてください」と謙虚になれる。 そこまで本気でやったものに実際にツッコミが入ればとても悔しいし憤りも感じるかもしれない。 でも、それを乗り越えるからこそ次のステージにいけるものである。 本気でやって、それを叩きのめされるから良いのである。 本気でやっていないものを世に出して、ツッコまれまくるのは良くない。 いつしか失敗することになれてしまう。気軽に間違いを起こすことになる。 それでは成長スピードは鈍化してしまう。 失敗から学びたいと思うなら、プライドが必要だ。 プロとして中途半端なものは世に出すまい、というプライドが。 とはいえ、納期と予算の制約をきちんと守ることは最低限必要なので、 芸術家みたいにはいかないけどね。
|
08/19/19:11 プログラミングの時間配分についてもし、
全く知らないフレームワークを使って、 100時間で、 粒度や難易度が同じレベルの独立した10個の機能を開発する、 というシチュエーションになったら、 あなたはどのように時間を配分しますか? 私だったら・・・ ◎第1段階 5時間 一番オーソドックスな1つの機能について、 とりあえず動くものを作る。 ◎第2段階 55時間 第一段階で作ったソースをひたすらリファクタリングする。 ◎第3段階 30時間 第2段階で蓄積されたノウハウを使って、 一気に残り9個の機能を開発する。 ◎第4段階 10時間 最初のリファクタリングで蓄積されず、 残り9個の機能の開発で蓄積されたノウハウを生かして、 全体をリファクタリングする。 と使う。 中には、100時間を10個の機能で均等割してスケジュールを立てる人もいるかもしれない。 でも、それは非効率だし、そもそもできあがったものの品質が一定ではない。 おそらく、最初の頃のものは品質がとてつもなく悪く、 最後の頃のものの品質もちょっと悪い。 でも、上に書いたやり方であれば、 少なくとも100時間を使って出せる最高の品質で、 全ての機能について実装ができる。 ただ、このやり方を実践するには、 最初の60時間で1つの機能しか出来上がらないことに対して、 理解がありその後の追い込みを信じてくれるプロジエクトマネージャーと顧客の存在が前提だ。 私がプロジェクトマネージャーとして案件を担当する時、 極力、毎週1回の定例の実装完了部分のデモ、という形式の約束をさけるのはこのためだ。 もちろん、リスクを前倒しで解決するために、 画面だけの紙芝居的なプロトタイプを使用してイメージの確認をしたり、ということは行う。 今回の話はあくまで実装デモの話。 できるだけ効率的な開発ができるよう不必要なチェックを排除することも大事なPMのお仕事だと思う。
|
01/29/01:23 一口にSEとは言うけれど・・私の仕事はプロジェクト・マネジメント。 でも、自己紹介の時に、プロジェクト・マネージャーと名乗ることはほぼない。 なぜならば、自己紹介の時に、その相手と関係するプロジエクトが始まっていることはまずないから。 だから、自己紹介の時は、「システムエンジニア」、いわゆるSEと名乗ることがほとんどだ。 ただ、このSEという言葉、和製英語とは言わないまでも、非常に幅広い意味を持つ言葉だ。 会社によってかなり意味合いが違うといえる。 そして、仮に与えられている役割が同じようなものだとしても、 その仕事の進め方やポリシーは千差万別である。 私にはSEになって以来、ずっと思っている理想のSE像というのがある。 それは、一言でいうと ウエディングプランナーのようなSE だ。 たいていの人は一生に一回しか結婚はしない。 その一生に一回の晴れ舞台を演出するのがウエディングプランナーだ。 新郎新婦の希望や予算などを聞き、 数ある選択肢や組み合わせの中から最高のプランを提案する。 私たちが今仕事として多く手がけている業務システムの開発も、 実はその会社にとっては一世一代のイベントであることがほとんどだ。 業務システムなんて、一度作ったらそうそう作りなおすものではない。 そんな大事な機会に、自分たちの会社を選び発注してくれたわけだ。 その気持に応えられるSEになりたい。 ユーザーに喜ばれて、ユーザーを幸せにするシステムを作りたい。 そんなことを考えて日々仕事に向き合ってはいるけれど、 なかなか、思ったようにうまくはできないなーと思う今日この頃。 もっと、もっと、頑張っていきたい。
|