Simple is Beautiful このページをアンテナに追加 RSSフィード

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2009/03/16 (月)

[]マーケティング意識は基本スキル?

「はじめての課長の教科書」および「あたらしい戦略の教科書」の2冊を書評させて頂いた酒井穣さんのブログ”NED-WLT”にて大変わかりやすいマーケティングの基本+応用編についての投稿”顧客のクラス分けと、マーケティング戦略”が掲載されたので、興味深く読ませて頂いた。

マーケティングを仕事として携わっていないポジションだとしても、自分の働く会社や自分の取り扱う製品もしくはサービス、競合他社との違いなどについては把握しておくべきだろう。そしてそうしたことを把握する上で、マーケティングの基本を知っておくことはとても役に立つ。

顧客のクラス分けについての紹介に使われているこの絵だけでも、知っているのと知らないのでは大きな違いだろう。

各階層の位置付けについては、ソースを参照下さい。

しかし、このエントリーが秀逸なのはそこでおわらないところ。各階層のあいだにある「壁」について、議論をさらに深めているところが読み応えがあります。

一度購入してくれた新規顧客がリピーターになるための間にある壁「期待の管理」をはじめとして、各階層の間にある壁についての解説はエンジニアだろうと総務担当だろうと読む価値があると思います。

2008/11/02 (日)

[]プリかポストか、はたまた…

技術職の醍醐味は技術を提供する現場に居ることです。しかし同じような組織に属していても、案件に対して「提案」として関わるのか、「設計・構築」として関わるのかは大きな違いがあります。

テクニカルを極めたい、という意味では実際に形にする「設計・構築」のフェーズに携わることは重要です。実際にどのようにして設計した構成をパラメータシートに落とし込んでいき、そして現場において実際に設定するのか、具体的な設定の勘所を把握していることは最前線を身をもって把握するという意味でも必要なことであると言えます。

しかし、より経験が問われるのは「提案」フェーズに携わることかもしれません。数多くの実績や経験など、いわゆる場数を踏んできたからこそ価値ある提案ができる立場となることができるといえます。

そのように考えると、ステップとしては「設計・構築」を担当する立場から「提案」をする立場へ、という流れがステップアップと言えそうですが、そのステップは次第に現場のノウハウやスキルから遠ざかる流れであるとも言えるところが悩ましいところです。

ベースの部分でしっかりとした土台を築いていれば、提案に必要なテクニカルな情報を判断する程度であれば問題はないでしょう。個別の詳細な部分についてはそれを担当している者にちょっと確認すれば充分だという考え方もできます。いつまでも現場にかじりついていることも1つのやり方だとは思いますが、それでは自分の携わった案件でしか自分の価値を提供することができません。

テクニカル、という拘りはありますのでマーケティングに両足を突っ込んでしまうつもりはありませんが、それでも次第に二足のわらじ的に現場とそれ以外の比重という意味では、現場の比重は次第に少なくなっていくことは仕方がないことでもあり、そうなることこそが自分にとってのステップアップであるのであれば価値があることなのだと思います。

2008/10/31 (金)

[]無事帰国

ござる言葉もおしまいでござる!

f:id:tamagogohan28:20081025172242j:image

蒙古斑が見えているずいぶんなセクシーショットだな(^_^;)

2008/10/26 (日)

[]ネットは使えたのでござる

どこにいるかは色々な事情があって秘密でござるが、こんな風景のところにいるでござる。

f:id:takaochan:20081026164702j:image

なんで私は「ござる」口調なのかわからないでござる…。

[]しばし国外逃亡でござる

更新できるかはわからないのでござる

f:id:tamagogohan28:20081024103727j:image

2008/06/19 (木)

[]ITってひとくくりですが…

仕事柄、色々な会社のIT/情報システムの部署をみていると、けっこう会社によってそれぞれです。同じように、人もまたそれぞれ。まぁ別にそれはいいのですが、ITといえども人次第だなぁと思うわけです。なんとかは使いよう、といいますが、ITもまた同じ。同じシステムをつくるのであっても、どの部分を重視するのか、どの部分を妥協するのか、ベンダーとどうつき合うのか、そして自分たちでどこまで面倒を見るか。まさに千差万別といったかんじ。

ベンダーに完全にロックインされているパターンもあれば、可能な限り自分たちで取り組むパターンもあります。人も、技術的な興味を強く持って、何でも知りたい・さわってみたいというタイプの人もいれば、決裁権を握ってあとは「良きに計らえ」的なタイプの人もいます。

別にどういうパターンがよいとか悪いとか言いたいわけではありません。会社のスタイルや予算規模、体制にIT/情報システムを率いる人の考えがマッチしているのであれば何の問題もないわけです。

とはいえ、私としては、もちろん心の中では積極的につき合っていきたいお客さんとビジネスライクにスパッと済ませたい(^_^;)お客さんを区分けしているわけですけれどもね。

2008/05/23 (金)

[]結局、オリジナルを視てさわっていじるに限る。

どんな仕事にしても、いくら理屈や理論を学んだところで、オリジナルを実際にさわってみて得られる経験値に勝るものはないだろう。一歩外から見ていると不思議だったり、納得できなかったりしたことが、オリジナルをさわると途端に腑に落ちたり、素直に理解できたりする。

ここ数日は現場で同僚が作成したスクリプトをベースにお客様仕様への修正と動作テストを実施。初めてさわってみたときは、スクリプトの外側しか理解できていない状態だったので、「こうすればこうなる」レベルの把握しかできていなかったが、やっぱり自分でゴリゴリ視てさわってテストをすると、「なぜこうなっているのか」レベルで把握できるようになる。そして、「こうしたらよりよいのではないか」とか、「ここにはこういう問題があるな」などといったさらに一歩前進させられるようなイメージが湧き出したら、それはそのオリジナルを十分に理解したと言っても良いのではないかと思う。

ということで、このスクリプトにはある条件では動作に問題が出る場合があることがわかり、色々と「こうしたらよいのではないか」とか、「こういうバージョンを作ってみたらどうか」などと思いついて現場でもちょっと試してみたのだが、やはり現場レベルで突貫で作ってもいい結果にはならないし、基本的にスクリプトであっても大きく標準から逸脱してしまうと後々困ることになるわけで、修正案は今後に生かすことにして素直に導入。

もちろん、今後に向けてオリジナル自体をよりよいものに進化させるべく、少々もともとの作成者に属人化していたスクリプトを真の標準仕様にすべくちょっとドキュメント周りも整理せねば。

2008/04/09 (水)

[]ゲーム機いらない(でもたまにはやりたいけど)

もーですね、ゲーム機なんかよりも面白いことがたくさんあるわけですよ、はい。

好きなことを勉強している方がよっぽど面白かったりします、子供の頃にはそんなこと想像も出来なかったけどね。