無料ブログはココログ

« 2013年9月 | トップページ | 2013年11月 »

[#agile #TiDD] 「リーン開発の現場」を読んで その3 - チケット駆動開発にあてはめる -

「リーン開発の現場」を読んでいると、プロジェクトがドンドン改善されていきます。それは、興奮する著者の話を飲み屋で聞いているように圧倒され、本当にプロジェクトに入ってミーティングに出ているような臨場感を感じます。

具体的な記述なので、すぐに実施できるように思ってしまいますが、前の記事で書いたように非常に多くの要素が組み合わされていて、さらっと読むだけでは構造がすこしわかりにくく感じます。

幸い日本語版の付録にはカンバンボードの解説がありますので、全体像がわかり易くなっています。この記事ではカンバンボードの解説を元に、Redmineでのチケット駆動開発にあてはめてみます。きっと、まだ見えていない特徴が見えてくると思います。

試行の目的

この試行はモデリングです。モデリングとは現実を単純化する事で可視化し、伝え、教え、議論し、改善する、ことを可能にします。

逆に同じ例題を言語でモデル化すると、その言語の特性も見えてきます。

一つ前の記事では、cshという言語を用いて「リーン開発の現場」の内容をモデル化しました。その結果、カンバンボードに含まれる構造が考え易くなったほか、cshの限界も見えてきました。

XPとチケット

かつて、共著者の@akipiiさんらとXPJUG関西でチケット駆動開発の議論していた頃、チケットをタスクカードと考えるとわかり易いのではないかと、アイデアを出しました。

タスクカードはその貼られる位置で、Ready、Doing、Doneと開発の状態を変えます。それはチケットのステータスと同じです。

タスクカードがチケットなら、タスクボードはチケット一覧です。タスクボードは全員で見る一覧になりますが、チケットなら個人別のいちらんやマイルストーンごとのロードマップとして見ることができます。

タスクカードをチケットにマッピングしたことで、チケット駆動開発の概念は大きく整理されました。意識せず、XPの言葉でチケット駆動開発をモデリングしていたのでしょう。

カンバンボードはチケットのステータスだけではない

「リーン開発の現場」のカンバンボードは、タスクボードのステータスが増えたように見えますが、それだけではありません。

1) エピックと呼ばれる大きめの仕様を表すカードが左に置かれ、それがアイデア、企画、定義に変わっていきます。

2) 準備できたものは小さな機能カードに分割されて、優先度の高いものとそうでないものに分けて並べられます。そして順に開発され、システムテストが可能な状態になります。

3) 最後に、システムテスト、受け入れテストと行われ、本番にリリースされます。途中の受け入れテストは時間がかかるので、今週分、来週分、実行中と分けられます。

この構造は全体が一つのタスクボードとは考えにくいものです。XPでのストーリボード、機能単位のタスクカードを貼るタスクボード、そしてテストボードとでも言うべきものが横に繋がった形になっています。

それぞれのボードをよく見ると、Ready、Doing、Doneに近い形になっています。大きく異なるのは、改善が進むに従ってステータスが増減する事です。特に待ち行列の領域を変化させることは、この本の改善ポイントの一つになっています。

さらに、ある状態の領域を狭くする事で同時実行が制限され、 WIP(仕掛り)制限が実現されています。

Redmineにあてはめてみる

Redmineで実現する場合、考えないと行けない事は以下の4点です。

  • エピックカードから機能カードなど、カードの分割
  • ステータスの増減
  • 一覧性と順序付け
  • WIP制限

では、これらを順に見ていきましょう。

エピックカードと機能カード

エピックカードと機能カードを、ストーリカードとタスクカードと考えると、Backlogsプラグインのように、概念的にはチケットの親子関係になります。しかし、親が閉じられなくなるので、後のチケットをブロッキングしていると考えるべきでしょう。

こうすると、どのエピックカードがどの機能カードに分割されたかをトレースできるようになります。これはタスクボードとテストボードの関係も同じです。関連チケットを相互に確認できますので、この点はカンバンボードより便利かもしれません。
(10月29日一部修正)

ステータスの増減

ステータスが増減することは、ステータスをすべてのプロジェクトで共有するRedmineには難しい問題です。

要求、開発、テストとトラッカー(チケットの種類)をわけると、ステータスは共通化できるかもしれません。しかし、ある程度の数のプロジェクトをこなさないと、安定するかどうかわかりません。

そこで考えられるのは、ワークフローとは関係がなくなりますが、サブステータスを示す属性を用意する事です。これは、カスタムフィールドでも実現できますが、カスタムクエリを個々に用意しないいけないでしょう。

もし、カテゴリが使われていないなら、サマリーで集計できますので、便利かもしれません。

一覧性と順序付け

しかし、一覧(クエリまたはレポート)を考慮すると、Redmineはいまひとつです。カンバンボードがステータスによって横方向に進むところが、チケットの一覧では縦方向の流れになってしまうのは許せると思うのですが、カンバンボードの縦方向の情報が表現できなくなってしまいます。

タスクボードの縦方向では、今週分と来週分など順序付けされています。これはチケットの優先順位と考えられます。チケットのステータス、サブステータス、優先度の3つのソートキーで並べると良いでしょう。

リリースの区切りはバージョンを指定すると、ロードマップで管理できます(11/7追記)。

WIP制限の与え方

RedmineにWIP制限の機能はありません。

ステータス・サブステータスごとのチケット数を数える必要があります。ステータスとカテゴリは、サマリーで総数を見る事ができますので、手動であればWIPを監視する事ができます。

できれば自動で、ステータス変更時に制限、あるいは、警告されるような仕組みが望まれます。より簡単な方法としてはWIP制限の確認が容易なカスタムクエリを用意する方法もあります。

まとめ

このように、制限はあるもののRedmineでも一通りは表現できそうです。また、Redmineであれば、さらに前後の制約を与えたり、ワークフローの管理もできます。

しかし、カンバンボードに比べると一覧性が悪く、WIP制限もスマートではありません。チケットを一覧で見ているなら、通常のチケット駆動開発と大差ありません。タスクボードのように視認性・操作性を高めたbacklogsプラグイン(リンク先はかおるんダイアリー)のようなプラグインが待たれます。

逆に言うと、全体を通して見える一覧性によって、プロジェクト全体で情報共有できることや、WIP制限が自然に行えること、さらには、ステータスの増減が容易なことが、「リーン開発の現場」で使われているタスクボードの特徴と言えるでしょう。

このように、Redmineの利用を想定してモデリングすることで、プロジェクトの特性と開発法の特性を知ることができました。これらの特徴を考慮するなら、よりふさわしいプロセスを実施する事ができるでしょう。

ソフトウェア工学の研究では現場のデータが公開困難である事が、大きな課題になっています。「リーン開発の現場」のような赤裸々な事例が公開され、共有されることで、ソフトウェア工学が大きく進化することを期待しています。

「リーン開発の現場」は、大学の先生方にもぜひ読んでいただきたい一冊です。


[#agile] 「リーン開発の現場」を読んで その2 - パイプラインとスケールアップ -

前の記事では、リーンソフトウェア開発とTPSの関係を書きましたが、今回は「リーン開発の現場」にでてくるプロセスのパターンを中心にリーンを説明したいと思います。

プロセスのパターンはcsh的なスクリプトでモデル化して説明します(いまどきならbashでしょうけど、4.2BSD世代な人なのと、cshの方がわかり易いだろうとの判断です)。

ウォーターフォール、スクラム、リーン

ウォーターフォールというのは、各工程ごとに成果物を完成させて作業を進めます。

A < IN > x
B < x > y
C < y >  OUT

このようにすると、aの途中に間違いがあって、それがOUTを確認している最中に見つかると、Aを修正して初めからやり直さないと行けません。

このような手戻りはムダですので、XPやスクラムでは全体をいくつかに分けて、順番に実行します。

for each i ( in1 in2 in3 in4)
     abc >> OUT
end

バックアップをとっておけば、途中で問題が見つかった際にそこだけやり直せますし、繰り返し期間ごとに集中と休息のリズムを感じる事ができます。

しかし、システム的に考えると起動終了のオーバーヘッドが大きいですし、多能工が必要になり、処理量の増大方法にも限界がありそうです。そこで、リーン開発では

A | B | C

のようにパイプラインで並行処理をします。このようにすると、起動終了のオーバーヘッドがなくなり、A,B,Cは専門性を活かせます。出力は随時確認できますが、

CTRL-Z

で処理を一時停止したり

CTRL-C

で中断したくなるでしょう。そのためにはA,B,Cの協調が必要なので、ミーティングが行われます。

スケールさせる

パイプラインで処理をする場合にはいくつかの方法があります。簡単なのは

A | B| C | D| E

とパイプライン処理を増やす方法です。多段になりすぎて管理しにくい場合、

A | BC | DE

のBCやDEを別のスクリプトにして階層構造を実現します(階層構造は繰り返し処理でも実現できますね)。

これらは全体のスループットをあげていませんので、並列性を高めたい場合もあるでしょう。

A & B

cshだと中間ファイルをつくらないと入力を2分岐できませんが、カンバンボードでは必要なところで並列度をあげる事ができます。

WIP制限

並列度が高いとうまく処理できない場合もあるでしょう。いったんまとめて、優先度順に処理します。

(A & B) | C | D

具体例ではこんな感じですね(cshではjob番号が邪魔しますし、bashでは面白くないですが、、)。

( echo "aaa\nbbb\nccc" &  echo "AAA\nBBB\nCCC" ) | sort | cat -n | pr

括弧で出力が一つにまとめられ、sortで優先順位に並べられ、cat -n で番号が付けられます。

この処理では、処理間のパイプラインに小さいバッファがあり、処理が可能な分が引き取られています。

また、sortの後では、優先度の順に処理され、優先度の低いものは後で処理されます。

sortとcatは1行ずつの処理であり、同時処理(仕掛り)数を制限しています。これはマルチタスクを避けて、後続の処理に負担をかけないWIP制限になっています。

最後のprはページ単位の出力です。今週のリリース予定、来週のリリース予定など、機能を一定の単位に区切ってリリースします(11/7追記)。

考えるプロセス

プロセスプログラミングの提唱者であるオスター・ワイルの有名な言葉「 ソフトウェアプロセスもまたプログラムである」を感じていただけたでしょうか?このようにプロセスは色々と工夫できます。

CMMの普及に大きく貢献し、後に形骸化の危険性を説かれた故坂本氏は、開発標準をわざと薄く作られたそうです。そして開発者達にどのように実践すべきかを考えるように言われていたそうです。

ソフトウェア開発は複雑で難しい作業です。リーン開発はその開発を可視化するもののあまり単純化しません。どちらかと言うと、複雑で難しい処理の優先度や並列度を良く考えて、より最適に開発できるようにします。

そのようなプロセスは一度に実現できるものではありません。開発に関わる人たちで、工夫しながら一つずつ積み上げて実現していくものです。

最前線からのメッセージ

「リーン開発の現場」には上に挙げたようなプロセスの構成要素が示されています。プロジェクトが進むにつれ、工夫によってカンバンボードは成長し、洗練していきます。

カンバンボードはプロジェクトを見える化するだけでなく、プロジェクトの関係者達の成長も示しています。

翻訳者のお一人である藤原さんのスライドにもそのような様子を見る事ができます。

書籍では、より大規模で階層的な開発の様子が描かれています。それは、著者のヘンリック氏が最前線で戦いながら「俺たちはこうやったぜ、次は君たちの番だ!」と言っているようです。

次の記事ではチケット駆動開発でリーン開発の実現方法を考えてみる予定です。

このエントリーをはてなブックマークに追加


[#agile] 「リーン開発の現場」を読んで その1 - 引き取り的な仕組み -

今年度上半期のイチオシの本は、スクラムの歴史を含めてわかり易く解説した「アジャイル開発とスクラム」と現場のイメージをわかせてくれた「SCRUM BOOT CAMP THE BOOK」でした。下半期のイチオシの本はその2冊の特徴を併せ持つ「 リーン開発の現場」でしょう。

リーンのムダのなさ

リーンとは「ムダのない」という意味です。リーンのルーツであるTPS(トヨタ生産方式)では、当時の大量生産との対比からジャスト・イン・タイムと呼ばれていました。

ジャスト・イン・タイムとは、今風に言うとオンデマンドと呼んでも良いかもしれません。必要なものを必要な分だけ開発し、ムダな在庫を減らす事でムダな工賃や倉庫が不要になります。

(このムダをソフトウェア開発で言うならば、ユーザビリティや性能、技術的な課題を確認せずに横展開してしまって生じる、大量の手戻りをイメージすると良いでしょう)。

TPSでそれを実現しているのは引き取りカンバンです。注文を受けて作られたカンバンを受け取って、その分だけ生産します。しかし、それだと需要に追いつかなくなるので最小在庫数を決めておき、新たな引き取りによってその分だけ作ります。

また、一度に大量にな単位(ロット)ごとに作ると、最大でその単位分の在庫が必要になりますので、作業ごとに同時に作る仕掛りの量(WIP)を決めます。究極は1個流しというやり方で、引き取りごとに1個ずつ作ります。

リーンソフトウェア開発のカンバンボード

リーンソフトウェア開発では、カンバンボードを用いてムダのない開発を行うものです。カンバンボードは仕様やタスクを書いたカードを貼るもので。開発の状況を可視化すると共に作業開始に制約を与えます。

カンバンボード全体は、カードが生産計画に基づく生産ラインである生産指示(仕掛け)カンバンのように動きますが、以下のような点で必要な分だけ作業する引き取りカンバンの様なオンデマンドの特性を持ちます。

  • 仕様は順序づけられて流される
  • 並列に配置されたバッファに優先順位を付ける(優先順位の低いものは暇な時に作業することで平準化する)
  • 同時に作業される量を制限する(WIP制限)

このようにする事で、一度に作りはじめてしまうのではなく、必要なものを優先的に開発し、後回しにした方が良いものは後から開発されるようにします。決定を遅らせる事ができるのです。

「リーン開発の現場」の新しさ

「リーン開発の現場」を読んでいると、このような理論的な背景が具体化されている様子を感じられます。読まれていなければ上記の内容は、すぐにはわからないかもしれません。しかし、200ページもないこの本を読めば、著者らのプロジェクトを追体験することができ、より具体的に知る事ができます。

そんな類を見ない本ですので、下半期で一番におすすめしたいと思っています。

次は「リーン開発の現場」に出てくるプロセスのパターンを説明する予定です。


成長に必要なのは「失敗」ではなく「挑戦」

子供はたくさんの失敗を経験しながら成長する。

これはそのとおりだろう。ただし、失敗には成長する失敗と成長しない失敗がある。

子供を見ていると、道路脇のブロックを平均台のようにしている事がある。また、砂場で山にトンネルを開けて、失敗しては気が済むまで繰り返している事がある。

これはモンテッソーリ教育の本に出てくる敏感期の例である。子供は、あることに興味を持つと、自らの限界を試すように、何度も何度も繰り返すのだ。

やがて子供はそのことに習熟しである程度できるようになると共に限界を知る。そして興味を失う。

その時点で子供は自らの能力を知り、失敗しなくなる。できることしかしないからで、できそうにない時は誰かに助けを求めるだろう。

さて、失敗を繰り返す大人には言い訳をする人が多い。その感想や言い訳を聞いていると、先ほどの子供との違いがいくつか見出せる。

  • 挑戦していない
  • 守りに入っている
  • 仕方なしにやっている
  • そんなもんだと思っている
  • 良かった点を見出せていない
  • 再発明を繰り返す
  • 自信を失っている

このような態度だと、何度失敗しても改善されない。成長させるには、失敗させるのではなく、興味の持って挑戦をさせることが必要で、そのためには、まず仕事に興味を持たせる事が重要ではないだろうか。

そう考える私が、チケット駆動開発に興味を持つのは、挑戦を支援してくれるからかもしれない。



[#TiDD] 次世代のプロセスとしてのチケット駆動開発

先日のSPI Japan 2013から、チケット駆動開発が示すべきものが見えてきました。
それは、 次世代のプロセスとしてのチケット駆動開発です。

日本では、プロセスのトレンドが、QC、CMM、アジャイル、と移り変わっていきました。順を追いながら説明します。

QC => CMM レベル3

日本では、QC活動をはじめとして、それぞれの現場で改善によって部分最適が進められていました。その後、組織による全体最適として標準プロセスをベースにした改善活動が行われました。

このCMMブームの時には、レベル3シンドロームという言葉があり、組織が標準化されると、そこにとどまってしまい、最適化されない組織になってしまう状況を示していまし た。

これは、レベル3達成のために「標準に従う」という単純なゴールが与えられることによって、それ以外の改善について考えなくなるからではないかと思います。その結果、レベル5による全体最適に至らず、全体主義的な組織になってしまいました。

CMM レベル3 => アジャイル

そして、次に注目されたのがアジャイル開発です。組織的な全体最適に全体主義の危険性が伴ったので、ボトムアップに自律的な組織作りをするようになりました。

オブジェクト指向のように各チームに分散し、各々が自律的に改善するようになりました。そして必要なところでチーム間の協調に必要なインタフェースが取られるようになりました。

QCには7つ道具のような分析ツールがありましたが、アジャイルでは実践するためのプラクティスがあり、より標準化された部分最適が行われました。

しかし、チーム間の協調によって大規模開発への工夫が多く行われるものの、組織的な支援が行いにくくなりました。アナログな要素が多くなったからです。

アジャイル => 未来

アジャイル開発でも一定のチーム間の協調はありましたが、組織全体をうまく協調させるには、それなりの仕組みが必要だと思います。

つまり分散から分散協調システムへの移行です。組織的な協調システムには背骨のような柔軟さが必要で、チケット+バージョン管理+CI+(クラウド)が、今のところ近いと考えています。

チケット駆動会開発の様な方法は昔からあると言われたりしますが、全体主義的なトップダウンですること、自律的なボトムアップで導入され、他のツールと連携してプロジェクトの柔軟な背骨になること、という違いがあると思います。

この背骨は、内部の協調に方向性を与えると共に、外部との協調も可能にします。

自律協調プロセスの背骨としてのチケット駆動開発

組織的な支援を行うには、定性的な情報だけでなく定量的な情報、つまりメトリクスが必要になります。

しかし、その収集はなかなか難しく、トップダウンに集めようとしても、形骸化してしまったり、ごまかしが生まれる可能性があります。

2003年頃から文科省の産官学連携プロジェクトとしてEPM(Empirical Project Monitor)というものの研究開発に関わっていました(その後、IPAの支援で発展し、現在のEPM-Xにつながります。スライドはIPAの公募で開発していた頃のもの)。

書籍「チケット駆動開発」でも紹介しましたが、EPMはバージョン管理、障害管理、メーリングリストの履歴からメトリクスを収集する環境です。開発をしている状況を分析する事で、多くの開発者への負担が少なく、当時の先進的なツールの利用で、開発の効率化も図れました。

しかし、残念ながらあまり普及しませんでした。それは、導入をトップダウンに進めたこと、また、当時は各ツールが独立していて導入も大変で、Redmineやtracほど、便利ではなかったので、サーバー管理が負担に感じられたからだと考えています。

チケット駆動開発でコミュニケーションの背骨ができる

SPI Japan 2013の古石さんの発表にもありましたが、チケット駆動開発では情報にチケット番号というキーが与えられ、番号で会話されるようになります。

障害管理と同じような番号をキーとした会話で、それが、課題、仕様、 タスク、に拡張されます。これはJenkinsなど外部ツールとの連携でも同じです。様々なツールをチケット連携した柔軟なプロジェクトが作られ、それぞれの整理された情報にキーが与えられます。

このように整理された情報で、プロジェクト内だけでなくプロジェクト外とのコミュニケーションが容易になります。強制されたメトリクスではなく、開発で必要な情報がそのまま、組織からの支援のメトリクスとして使えるようになるのです。

自律協調の実現

チケット駆動開発によって、アジャイル開発におけるオブジェクトであるチームに、チケットというインタフェースが作られました。今後の課題は、全体最適に向けた事例の蓄積とパターン化だと思っています。

これから、チケット駆動開発で未来が開かれようとしているのです。


[#TiDD] チケット駆動開発によるプロセス改善(事例) -SPI Japan 2013 -

SPI Japan 2013で発表させていただきました。

「チケット駆動開発によるプロセス改善 - 現場重視、管理重視、それとも情報共有重視 -」と題して、これまでの事例から現場を考えたチケット駆動開発の必要性を話しました。

セッションの発表

同じセッションでは、共同プログラム委員長でもあるSRAの古石さんは小規模プロジェクトでのチケット駆動のお話。tracの画面やデータの関係を示しながら、わかり易く説明されました。

パナソニックの林さんは外国へのODM(Original Design Manufacturing)のお話で、ODM先に常駐していても発生した様々なトラブルをお話しされました。外国の方が外国の特性を率直に語られていて興味深かったです。

東芝の田村さんはホフステードの文化的次元を用いて、オフショアで発生した事例を分析・改善されていました。知っている人には当たり前の知識かもしれませんが、分析対象を絞るとき、分析時、対策時に使っている点が興味深かったです。改善率も定量的に計測されていて、さすがです。

クロージグパネル

クロージグパネルは「“「共感」” ・・・ 心が動くとき、行動は変わる!~開発におけるツールの有効な活用方法~」というタイトルでツールのお話をされました。

議論の中では

 Toolは「使う」のではなく、「使われる」ぐらいが良い。

と言う言葉が出てきました。ツールの思い(設計思想)を活かしましょう、と理解しました。

なかなか面白い議論だったのですが、イマイチ乗れませんでした。一つには形式検証やリバースツールなどと、チケット駆動開発で使われるITS、バージョン管理ツール、CIツールが同時に議論されたからかもしれません。

チケット駆動開発的なところは深く議論したいものの、知らないか避けているのか、あるいは、わかっていない人が反論でもなく、別のツールのずれた意見を重ねられると、深い議論をする気になりませんでした。

チケット駆動開発を伝える難しさ

ここがチケット駆動開発の難しいところです。基本的な話をするとわかっている人はつまらないし、深い話だけするとやった事のない人は理解できません。チケット駆動開発のリズムやテンポ、安心感すごさがうまく伝わらないのです。

これまでシェルスクリプトでやってきた人にRubyの良さを伝えたり、MS-DOSのベテランにUNIXの良さを伝えたり、そんな、限界のある物をそれなりに使う事が良いと思う人に、色々できる物を上手に工夫する醍醐味を伝えるような苦しみです。

現場と共に

チケット駆動開発をうまく回すには、標準化から入るのではなく、問題の対策から入るようなアプローチが必要だと思います。SPI Japanは元々SEPG Japanで組織プロセスの改善の人たちの集まりで、どことなく組織的なアプローチが前提になっていた事も乗れなかった理由だったのかもしれません。

チケット駆動開発は現場から生まれて普及しました。現場の諸処の事情に工夫するからうまく使える面があるからです。「組織から」ではなく「現場と共に」がとても大切だと思っているからです。

おわりに

3日間のうちの1日だけの参加でしたが、色々と考える機会になった1日でした。

チケット駆動開発のすごさを伝えるには、まだまだ工夫が必要かも知れません。今後も機会があるごとに、工夫して伝えていきたいと思います。

なお、発表資料のうち、公開可能な物はJaspicのサイトで公開される様です。


坊やだからさ

私も若い頃は「イマドキの若い奴は」なんて言われていたと思います。それが世代ごとに「新人類」とか「ゆとり」とか表現は変わりましたが、年寄りから見ると「青い」ところが気になるか、批判されてきたものです。

そのように「年寄り」と思われるとわかっているのですが、最近の知名度やお金を重視する傾向には、自己中心的な下品さがあり、何とも言えない「もやもや」した思いがありました。それが社会だとか、資本主義だとか、わからなくもありません。しかし、なんでもあり、とか、それが唯一の考え方や生き方だ、というような姿勢はどうもいただけません。

とはいえ、頑固親父のように怒るほどの余力もなく、ストレスを感じていました。そして、ようやくその気持ちを整理する方法が見つかりました。

それは「 坊やだからさ」と思う事です。これはガンダムに出てくるシャアの有名な言葉です(解説)。特定の偏った考えに捕われて、冷静な判断ができないのは「若さ」なのでしょう。

ふりかえれば、私も若い頃はマイ・ブームに必死になり、そればっかりやっていて、人に迷惑をかけてしまったこともあった様にも思います。

それは、モンテッソーリ教育でいうところの敏感期で、その人にとって大切な学習の機会なのかもしれません。そう思うと、若さがうらやましくもあり、

「とことんやれ〜!」

と応援したくもなるのでした。


技術者とブランド

「ブランド戦略」という言葉があまり好きではありません。

人はブランドに憧れてモノを買う。モノを買ってもらうためにはブランド力が必要だ!人を惹きつける発表をして、名前を売り、人脈を利用してビジネスを大きくする。

確かにそう言うやり方がある事は否定しませんし、結果的にそうなる事もあるでしょう。しかし、ブランド作りを手段とするのは、技術者ではなく商売人だと思います。

スターバックスのあり方

スタバはなぜ値下げやテレビCMをしない?高いブランド力構築の戦略を元CEOに聞く」という記事を読んで色々と考えさせられました。

「ブランドというのは、お客様とのある種の約束」

うまく説明して、良いように思ってもらって、仕事が取れれば儲けもの、そんな考えはありません。安く作って高く売れば利益が大きくなりますが、本来いただくべき適切な利益をえるべく、真摯に約束を果たし続けることでブランドが築かれるということでしょう。

「ミッションを愚直に一所懸命行えば、それがブランドになるようにしなければいけない」

前の記事「 技術者とビジネス」で書きましたが、全ての人にカリスマ性が必要でなく、各々の得意なところで力を発揮すれば良いのだと思います。ミッションの実現がブランドを築く、そういう場を提供するのが「会社」の役目なのだと思いました。

技術者のブランド

技術者のブランドも同じではないでしょうか?

ブランドが目的でなく、顧客や社会に対するミッションがあり、その結果として得られるのがブランドだと思います。

こういう技術者でいたいというあり方、あるいは、社会との関わり方、スタバ流の表現で言うなら約束が自分のブランドだとするなら、社会と約束したミッションの達成が自分のブランドになるのだと思います。

究極のブランド戦略は、自分が自分らしくある事だと思うのです。

技術者とビジネス

AgileTourOsaka2013の基調講演「アジャイルマーケティングがより良い製品を届ける」( Chris Kruppa氏)
を聞かせていただきました。

私のポジションは技術者で、正直なところマーケティングはそれほど興味はないのですが、新規ビジネスでのアジャイル開発が多い事、技術者の真摯な態度が最も良い営業になるとの思いもあること、そして初めて聞く言葉なので知っておきたかった事から参加しました。

How (Agile) Marketing helps to deliver better products from Chris Kruppa

講演はインタラクティブにすすめられ、私もコメントや質問をさせていただきました。

アジャイルマーケティングとはマーケティングをリーンキャンパス(ビジネスキャンパス)とスクラムで回す方法です。

特に私が重要だと思ってコメントしたのは、リーンキャンパスの自分達の強みを知るという点です。マーケティングは1番になるためではなく、ビジネスを成立させる事が目的だからです。

質問とその回答で興味深かったのは、リーダーシップについてです。アジャイルではチーム力が重視されるが海外の大企業はカリスマを持つリーダーが居たのではないか?との質問に、彼らにも仲間がいたと言う回答です。

アップルのスティーブ・ジョブズにはスティーブ・ウォズニアック、マイクロソフトのビル・ゲイツにはポール・アレン、googleはラリー・ペイジとセルゲイ・ブリン、facebookのマーク・ザッカーバーグにも当初は友人たちが居ました。

チームの各々の長所を生かし、チームが顧客に対して最大限に能力を発揮した時にビジネスは成功するのだと思いました。

« 2013年9月 | トップページ | 2013年11月 »