DISCOVER TO DELIVER : ユーザーの本質的価値をDISCOVER(発見)しDELIVER(届ける)する新たな方法
Agile2012で参加したセッションの中で、個人的にもヒットだったThe Product Partnership: Using Structured Conversations to Deliver Value（直訳：プロダクトとの友好的な協力関係）。セッション内容は、DISCOVER TO DELIVERという発売前の本を題材に著者であるMary GormanとEllen GottesdienerがWork Shopを行いました。
先日(2012/9/25)、ついにそのDISCOVER TO DELIVERが一般発売されたので、ご紹介させていただきます。※もちろん本は全編英語ですw
参考リンク
- DISCOVER TO DELIVER : Book Web Site ※ここから購入できます
- 著者であるEllenのBlog
About "DISCOVER TO DELIVER"
DISCOVER TO DELIVERでは、価値を見つけて届けるまでの過程をステップで説明しています。
ポイントをまとめると、
- ユーザーを中心におく
- 会話することが重要
- ストーリーやバックログ
- Discover (発見) と Deliver (届ける) を繰り返す
- 繰り返してユーザーにとっての本質的なプロダクトの価値を導きだしていく
こんな感じです。
本で紹介されているプロダクトのコンセプトや価値を探求していく各ステップは、フレームワークのような使い方ができると思います。
以下のAgile2012のセッションレポートにもありますが、ちょうどインセプションデッキとストーリーの間をカバーするような内容になっているため、プロダクトオーナーに近い仕事の方にはぜひ読んでいただきたい内容です。
（著者であるMary & Ellen with @uedayoさん）
私はセッションを受けて内容がとても面白かったので、会場内で事前販売していた本を購入しました。本は、写真の壁に貼ってあるようなイラストが多く、英語は得意でない私でもイメージがわくので読み進めることができています。
Agile2012のセッションの反響や発売後のTwitterを見ている限り、アメリカでも注目の本・手法の一つです。今後名前を聞くようになるかもしれません。
P.S.
せっかくいち早く輸入できたので、もうちょっと内容を理解して日本で紹介できるといいなーと思ってます。もしご興味がある方はぜひコメントやShareをお願いします。きっとやる気が出てきますw
Experience Visionをはじめてきた #devlove
DevLove主催のExperience Visionのはじめかたに参加してきました。
#devlove えくすぺりえんすびじょんをまなびにきたよ！ (@ 株式会社 KDDIウェブコミュニケーションズ (KDDI Web Communications Inc.) w/ 5 others) 4sq.com/Rkerem
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012なぜ参加したか
ユーザーから見たら、開発もマーケティングも営業もビジネスも関係なくサービス提供者に過ぎません。
私はこれまでどちらかというと開発者としての視点でサービスづくりに携わってきましたが、最近になってようやくサービス提供者としての視点で何ができるのかを課題に感じるようになりました。
Agile・Scrum・User Story Mapping・Lean Startupなど最先端の考え方／プロセスにおいてもビジネスと開発の関係性は常に語られていますが、まだ私の中では腹落ちしていない部分があり、私のようなぺーぺーに何ができるのかを見つけるヒントを探しに参加してきました。
What is Exeperience Vision
EXPERIENCE VISIONの共著者のお一人である山崎和彦先生にご講演いただきました。
エクスペリエンス・ビジョン |
EXPERIENCE VISIONは、こんな本！！
- ビジョン提案型デザイン手法の本
- 7月に発売されたばかり
- 5年かけてWork Shopや実践をまとめられている
- すぐに実践（Work Shop）できるテンプレートがダウンロードできる
- 具体的な事例紹介入り
- 略してえびちゃんえび本 ※山崎先生公認
以下のリンクが参考になります。
講演レポート
以下ご講演のポイントをまとめさせていただきます。
詳細な内容は以下リンクを参考にして下さい。
- 当日のTime line (togetter)
- 「Experience Vison のはじめかた」に参加してきました。 (via @takigawa401さん)
- DevLOVE エクスペリエンス・ビジョンのはじめかた NAVERまとめ
What is Exeperience Vision
まずはExperience Visionの概要をご説明いただきました。
- 5年間かけてWork Shopの成果や経験をまとめたもの
- Product Designはそこら中で言われているが世界を見てもあまり教科書が無い
- 世にある多くの方法論はそれだけで世界が変わるかのように書かれがち
- 世の中にあるよい手法はなんでも取り入れて、ないものは作るスタイル
- 目の前の仕事に追われがちだが、もう少し遠くを見て本当にユーザーにとって大事なことはなにかを考えてしっかりと戦略を立てる
- プロジェクトの目標立ての部分をもう少し大事にする
- ビジョン提案型デザインの大まかなイメージ
- 人間中心設計に基づくビジョン提案型デザイン手法
- これまではユーザーへのヒアリングや要求からプロダクトを作ることが多かったが、ユーザーの価値に基づいてエンジニアやデザイナーから提案していく
- ユーザーを中心に置き、ユーザーの潜在的なニーズを形にしていく
- 一度上（価値）に登るのが特徴
- 一度上に登ることで全体を見る
- Change Gameのことを考える
- Change Game：既に効率化されている大企業と同じ土俵で戦わない
- EXPERIENCE VISIONの中で紹介されているテンプレート
- ビジネスモデル・キャンバス(※)に似ている
- 全体を見ることはできるというのはとても大事
※Business Model Generationで紹介されているフレームワーク : 参考リンク
Exeperience Visionのはじめ方
Experience Visionの中でも構造化シナリオを中心に少し掘り下げていただきました。
- 役割に関わらずビジョン提案やサービス構築に主低的に貢献することが求められている
- ユーザーにとっての本質的な価値を導きだし、そこに体験や経験を提供すること
- 結果からくる問題解決とは別に、本質的な価値にアプローチする手法
- 問題解決型デザイン
- 提案型デザイン★
- 前者はたくさん本があるのでExperience Visonでは後者に特化している
- 人間中心設計をイノベーションにもっと使って行く
- 異文化の人と一緒にやらないとイノベーションは起こせない
- 技術、マーケティング、デザイナー、ビジネス・・・いろんなストロングポイントを持った人達が協力することで何かが生まれるという発想が大事
- 基本的なアプローチ方法
- フレームワークの全体像
- 本質的欲求を理解するためのいろんな方法
- ユーザー視点とビジネス視点の二つの視点
- 仕様書はモノや動きしか書いていないが、シナリオはモノとそれをどう使うかを表す
- シナリオは日本語がわかれば誰でもわかるので、異なる役割の人達がコラボレーションする際の共通言語になる
- 理解できるということは、コラボレーションができるということ
- シナリオごとに評価を繰り返す
- リリースしてからではなくシナリオの時点でユーザーのことを考えているのかを評価
- シナリオそれぞれの種類の特徴と評価項目
- 構造化シナリオの特徴まとめ
- ユーザー視点での評価について
- それぞれのシナリオで評価のし方を変えていく
- ビジネス視点での評価について
- よくみる計画書には製品とビジネスのことしか書いていない
- どう進めるかについては戦略（担当が別だ）だと言われてしまいがちだが、それでは新しいものが生まれない
- 目標設定を高く持つことが大事
QA
QAの中のポイントだけまとめます。
Q. 調査をしているが信頼してもらえない。どう乗り越えたらよいか？
まとめ
お恥ずかしいことに「Experience Visionのはじめかた」というタイトルにかまけて予習をさぼってしまってましたが、これはちゃんと読まねばならん！とさっそく手に入れました。
えびちゃん購入 #devlove エクスペリエンス・ビジョン [楽天] r10.to/hJcBbW #rbooks twitter.com/TAKAKING22/sta…
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012感想については講演中のTweetにすべて表れています。
Experience Visionまだ聴いてる途中だけど、これ最近感じていた課題の解決のヒントになる気がしてきた！かゆいところ。 #devlove
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012個人的に今日の話を聞けて、Lean Startup、UX、Agile、UCDとかがつながってきた！ #devlove
— takao.oyobeさん (@TAKAKING22) 9月 27, 2012これまでいろいろなことに興味を持って勉強をして現場活動につなげてきましたが、だからこそ今回Experience Visionの話をきっかけにいろんなものがつながる想いがしました。
冒頭に書いた通り、AgileやScrumやLean Startupなど個々で足りない・腑に落ちない部分がありました。山崎先生がおっしゃったようにビジネスや開発を通して価値提供という大きな範囲でみたら、たった一つの考え方でうまくいくことは難しいです。プロセスや方法論自体も目的を達成するためにいろいろなものを素早く小さく試して評価して、いいものを組み合わせていけばよいと思います。
Experience Visionの内容についてはもちろんまだわからないところが多いです。
しかし、サービス提供者としてユーザーの本質的な価値にアプローチすることが本当に大事なことだと改めて思いました。開発やビジネスやデザイナーというユーザー視点ではない分割は忘れて、自分に何ができるのかを考えてみたいと思います。
|
エクスペリエンス・ビジョン |
まずは本を読んで素振りからはじめますか！
アジャイルとウォーターフォールについて本気出して考えてみる
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。
ウォーターフォール（以下WF）はよくDisらr・・・アジャイルと比較されます。
私もアジャイル開発を知るまでそうではない開発を経験したことがありますが、おそらくそれらはWF開発をしていたわけではなく、WFのようななにかに過ぎなかったと思います。
だから、ちゃんとしたWFについても勉強したいなーと考えていたのでとてもいい機会になりました。
株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。
詳細については下記SlideShareをぜひご覧ください。
WFの原点に関わる流れ
- 1970年 Managing the Development of Software Systems via Winston Royce
WFの本質が書かれている論文。 - 1985年 米国防総省の規格書「DOD-STD-2167」★
Royceの論文を参考に米国防総省がPRJの進め方をまとめた規格書。
これがWFの原点と言われている。
手戻りは絶対だめ！！と述べている。
⇒追記：手戻りがだめと明記されたのは1988年発表の2167A版（原田さんありがとうございます）
1995年のレポートで、この方法によるPRJの約75%が失敗もしくはうまく適用できずに終わっていると報告されている（※参照） - 1994年 上記の改訂版「MIL-STG-498」
繰り返し型開発 - 2010年 CMU/SEI「Considerations for Using Agile in DoD Acquisition」
アジャイルを用いた調達やこれからの導入を促す趣旨のレポート
※このあたりのことをまとめているIPAレポートがあった ので載せておきます。
米国におけるアジャイル・ソフトウェア開発の動向 via 渡辺弘美さん
WFの本質となった論文の概要
- 1970年 Managing the Development of Software Systems via Winston Royce
- 一番シンプルな開発モデル
- 小規模で自らが利用するソフトウェア開発には十分かつ合理的
- しかし大規模なシステム開発ではうまくいかない
- 実際のPRJでは追加工程が要求される（管理コストによるオーバーヘッドなど）
- 一方通行でうまくいくわけがない
- 手戻りは存在するがあくまで想定内（1つ手前の工程まで）におさめる
- 顧客を巻き込むことの大切さ
- ソフトウェア開発はシンプルなモデルのような簡単なものではない
要点まとめ：
1970年の論文だが今でも多く使われているWFの本質が述べられている。WFでは手戻りは絶対だめという風潮があるが、これはWFの原点となった「DOD-STD-2167」で手戻りはあってはいけないものとされているからである。しかし、Royceの論文では手戻りがあることを前提としていて、その手戻りを想定内におさめることが大事だ述べている。
当然この論文がそのまま開発に活かせるものではないが、それまで体系的にPRJの進め方をまとめられていなかった中で初の取り組みであった。
WFとAgile
- 問題解決 ＝ 要求、アウトプット
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 解決手段 ＝ 要求を満たすための方法
- 解決手段における前提的 ＝ 良い方法は既存でそこに近づける
- 解決手段における前提的 ＝ PRJの中で決めて行く
WFの難しい点
- 初期の要求がなかなか確定しない場合
- 後の工程になって要求が変更になる場合
- 事前に予見しきれない技術的課題
- リスク管理とその運用の難しさ
- コミュニケーションの質の悪化
- 官僚的な追加作業
アジャイルとWFの使い分け
要点まとめ：
アジャイルとWFはそれぞれに前提条件・向き／不向きが異なる。そのため、現状やプロジェクトの特性を正しく理解して適正をみる必要がある。
どちらがいい／悪いではなく、概念やプロセスを理解してそれを活かせるように現場現場で適用して行くことが重要である。
我々の仕事（ソフトウェア開発もアジャイル開発もWF開発も）はそんなに簡単なものではない。
スパイラルとアジャイルの違い
- スパイラルとは小さなWFの連続
- スパイラル→渦を描きながら最終的には真ん中に収束して行くイメージ
- アジャイル→ぐるぐるまわりながら中心ですら適切な場所に移動していくイメージ
- 収束を前提とするかしないかの違い
まとめ
今回の勉強会を通して感じたことは、
"WF（ウォーターフォール）とAgile"とか"WFとWFでないもの"っていうよりも、なんでもないもの大半で一部のWFとAgileって感じのイメージ。
— takao.oyobeさん (@TAKAKING22) 9月 25, 2012やっぱり神懸かり的なウォーターフォールによる成功体験は、プロジェクトマネジメント視点ではしてやったりな気がするなー
— takao.oyobeさん (@TAKAKING22) 9月 25, 2012です。
少しこのあたりの話になると盲信的に、
「アジャイル最高！」
「WFはだめだ！」
「WFでないとだめだ！」
となってしまっているケースをよく見ます。
しかし、アジャイルもWFもあくまで目的を達成するための選択肢に過ぎず、どちらがいい／悪いという議論は無意味な気がしています。
それよりも、
- 自分たち（プロジェクト、チーム、環境、状況）を理解して今何が必要なのかを見極められるようになること
- それによって結果を出すこと
こそが重要であることを忘れてはいけません。
・・・という前提で、きちんとWFできる状況を考えてみると、
- ゴールが明確であること
- 状況／環境がコントラブルであること
- プロダクトがコントラブルであること
- 要求の出し手／プロダクトの作り手が機能できること
- 関係者のコミュニケーションが良好であること
- 上記全てがPRJの終了まで継続すること
これらの条件が必要かなと思います。
うーん難易度が高い！！
でも一度はキレイに滝を滑り降りたい！！
なんて野望を胸に抱きました。
【SME26】 達人出版会よりサムライ・エピソードが発売されました
本日 2012年9月14日、達人出版会さんよりサムライエピソードが発売されました。
サムライエピソードとは、日本のアジャイラー総勢26名が現場で経験した成功・失敗を生々しく綴ったライブログとも言える一冊です。
実際の体験をリアルに綴っているので、日本のアジャイルな現場でどんな戦い（？）や修行が繰り広げられているのかを知ることができます。How To本とはまた違った気づきを得ることができるかもしれません。
今まさに現場で挑戦している方や興味を持っている方にはぜひ読んでいただきたい一冊です。
私も一つの章を執筆させていただきました。
明日のXP祭り2012で発表させていただく内容も一部含んでいますが、私も例にもれなく現場での体験をもとに書かせていただきました。
※ちなみにSME26は勝手に私が言っているだけで正式なグループ名でもなければ、どこからの劇場で活動しているわけではありません。
とりまとめをしてくださった@HIROCASTERさんが中心となって、勉強会などで有志を募って集まった26名のサムライ達です。
今回本ができあがるまではGitやFacebookを使ってやりとりをするという面白いプロセスを踏んでいたりします。
達人出版会さんなので電子書籍での販売です。
Kobo Touchなんかで見るといいんじゃないかなー（ステマ）。
【参考リンク】
電子ブック楽天＜kobo＞ kobo Touch 【販売：楽天kobo】【今なら送料無料】 |
XP祭り2012で「How to change our world ～楽天の開発現場からのアジャイル改善事例～」を発表します #xpjug
いよいよ明日、XP祭り2012 ~ソーシャルチェンジ！~が開催されます。
XP祭り初参加でいきなり1枠セッションを持たせてもらうという幸せものですが、精一杯楽しんできたいと思います。
A-7 How to change our world ～楽天の開発現場からのアジャイル改善事例～【講演】
我々をとりまく世界は、日々大きく変化をしています。変化を抱擁して現実とのギャップを埋めていかなければならない我々の開発現場では、アジャイル開発の必要性がますます高まっています。そのニーズに呼応するかのように、最近のアジャイル界隈のホットトピックは、マネジメントやビジネスなど大きな分野へと広がっています。
このセッションでは、そんなアジャイルムーブメントの原点である開発現場にフォーカスを当てます。楽天という大きな組織の中でアジャイル1周年を迎えた１エンジニアが、開発現場のリアルをご紹介させていただきます。
What is Agile
アジャイルを知ってから1年間の開発現場のリアルを追います。
How to change our world
1ヶ月間でチームがどう変化したのか実例をご紹介します
今回のXP祭りのテーマは、ソーシャルチェンジ！
この1年間は、私も現場もまさにチェンジ！の連続でした。
実際の開発現場の話を中心にしていますので、アジャイルに興味がある・無しに関わらず楽しんでいただける内容だと思います。
興味を持って勉強会に行き初めて約一年、ずっと参加したかったXP祭りで発表をさせていただくことは私にとって集大成となります。
また、Agile2012に一緒に参加させていただいた伊藤さんが、A-5 一歩＝∞ ～Agile2012参加報告～【講演】という発表をします。個人的にも楽しみですが、Agile2012の雰囲気を味わいたい方はぜひご参加ください。
明日、皆さんにお会いできることを楽しみにしています！
学び方を学んできたよ！ #devlove
毎度お世話になっているDevLove主催の学び方を学ぶ～オブジェクト指向の設計と実装を学ぶ～に参加してきました。
"学ぶ"と聞くと学生時代の印象が強いですが、
私は社会人3年目の今が人生で一番学んでいる気がします。
勉強会に参加したり、本を読んだり、実際に体験したり、私たちのまわりにはとにかくたくさんの学ぶ機会があります。特に私たちのような技術職は学ぶことこそが仕事と言っても過言でないほどのInputとそこからくるOutputによって対価を得ています。
それでか学ぶ機会が多いにも関わらず、よく考えると学んだことはあっても学び方を学んだことはなかったです。
これはひょっとしたらとってももったいないことをしているのでは？と思い、今回参加してきました。
#devlove 学んでもらい方を学びたいなー
— takao.oyobeさん (@TAKAKING22) 9月 12, 2012そして、ついでにせっかくなので自分だけでなくもっとまわりを巻き込んで、
学んでもらうコツも学びたいなーなんて思ったりも。
学習パターン
学習パターンは、一言で言うならば学び方のコツを抽出したものです。
学ぶという行為自体が抽象的でヒトに依存しているように思われがちであるため、他人の効率的な学び方を流用することがされにくかった。しかし、その学び方をパターン化して名前をつけることで他人が認識できるようになりました。
この学習パターンは、始めは学生の学び方の支援を目的として井庭先生と有志の学生によって作られたものが起源です。その後もそのPRJは続いていて、半年に1冊くらいのペースでいろんな学習パターンがまとめられているそうです。
# 上記のサイトにPDFであがっているものもあるのでぜひご覧下さい!!
最初は学生向けに配布したものでしたが、Web公開していたところソフトウェア業界を中心に一気に盛り上がったそうです。
とても興味深かったのが実際に学習パターンを作成して行く過程です。
その一連の過程を1000倍速でまとめられた動画があり、様子がとても伝わります。
誰もが使えるパターンにするために、ある特定の経験からパターン化するのではなく、全体からkj法などを利用して細かい部分に落としていく作業を行っているため1つ1つのパターンが作られるまでに多くの時間が使われているそうです。
学び方を学ぶということ
学習パターンはマニュアルではありません。マニュアルではないので、その通りにやればうまくいくという単純なものではないのです。
状況に合わせてパターンを選択して組み合わせることが大切です。ゼロベースではないので学びの初心者でも洗練されたやり方を参考に効率的な学びが実現できます。
難しく聞こえますが、自然と誰もがやっていることなのかなと思いました。
最初はやり方がわからなかった仕事も、先輩に教えてもらったり先輩の仕事を見て盗みながら、自分の中のパターンを増やしていってどんどん効率的にしていきます。その自然にやっていることを体系立ててまとめておくことで、どんな状況でも効率的に学ぶ手助けをしてくれるものだと理解しました。
前述のとおり学びの多い私たちは、とりわけ学び方を学ぶといいことが多いですね！
面白かったことがいくつかあったので簡単にまとめます。
Writers Workshop
やっぱり井庭先生のブログを読めば一発なのでリンクを貼らせていただきます。
簡単にまとめると、著者以外のヒトが集まって題材となるコンテンツについてディスカッションするワークショップ。著者の意図やまとめ方についてポジティブにディスカッションする。その間著者は発言してはならない。
書き手も読み手を意識して書くようになるし、読み手も本気で理解しようとするので面白いワークショップだと思いました。
学習パターン実践編
また、井庭先生の後に学習パターン実践編として発表された増田さんのお話もとても面白かったのでご紹介させていただきます。
学習パターンを、実際のオブジェクト指向での設計／実装の話と結びつけて話されており、エンジニアは必見です！！
参考図書もたくさん紹介していただきました。
現場に生かす
今日お話を聞きながら現場ですぐに生かしたいことがちらほら思い浮かびました。
#devlove 個人的なTryだけど、ストーリーの書き方のパターンをつくってみよーっと
— takao.oyobeさん (@TAKAKING22) 9月 12, 2012最近の私のチームのホットなトピックがストーリーの書き方についてです。
自分達が書いてきたストーリーやWebや本に転がっている実例がたくさんあるので、パターンにまとめてみたら面白そうな気がしています。
#devlove 「Writers Workdshop」同じように他人が書いたコードや要件定義を、他人が説明する（書いた本人は発言禁止）レビューとか面白いんじゃないか
— takao.oyobeさん (@TAKAKING22) 9月 12, 2012上記で説明したWriters Workdshopもコードレビューや要件定義や設計フェーズでやってみたら多くの気づきがあるレビューになると思いました。
このあたりやってみたら別途ブログで紹介させていただこうと思います。
今回題材となった学習パターンを体験的に学ぶことができる「学びの対話ワークショップ」を近々DevLoveで企画して下さるとのこと。そうでなくても自分達でやってみたいと思います。
踊る大捜査線にみた組織論
組織論なんて大々しく書いていますが、単に土曜日プレミアムで踊る大捜査線THE MOVIE 2を久しぶりに見て感動しただけです。
映画の紹介を改めてする必要は無いかもしれませんが少しだけ。
フジテレビのテレビドラマ「踊る大捜査線」の劇場版第二作目である本作。2003年7月19日に公開されると同時に大ヒットをし、2012年現在においても邦画の実写映画としては最高の興行収入を記録しています。
踊る大捜査線では全作を通して現場と組織上層部の葛藤が描かれていますが、本作では特に色濃く物語の真相に関わっていたように感じました。
ということで、映画の中で出てきた名言と共に、私のようなぺーぺーが考える組織に触れてみます。
”リーダーが優秀なら組織も悪くない
犯人グループが犯行に及んだ原因の一つに、現代の中央集権型の組織構造に嫌気がさしたことが挙げられます。そのため彼らは上下にのびていく組織ではなく、各々の判断で動く横にのびる新しい組織を作って犯行に及びました。そんな彼らに対して青島刑事が放った台詞です。
どちらの組織がいいのかは私にはわかりません。
しかし、どんな組織にいようと中にいる１人１人のヒトが何より大事であることには変わらないと思います。私はこの言葉並びの意味自体よりも、青島刑事がリーダー（室井さん）を心から信頼していることが表れていることに感動を覚えました。リーダーであろうとなかろうと、組織の中にいる１人１人のヒトの重要性と、自分もその１人であることを忘れていはいけないと思います。
- 最終的に力を発揮するのは個人 (via tsuyok)
なんとなくですが最近読ませていただいた上記のエントリーが思い浮かびました。
"One for All"は日本人は得意ですが、"All for One"も忘れてはならないと思います。
”現場の君たちを信じる
室井さんが捜査本部の指揮をとることになった際、全捜査官に向けて発した台詞です。
任せられる方はもちろんですが、それ以上に任せる方は勇気がいります。私が彼の部下であったら、この言葉をもらったら余計なことを考えずに正しいと思うことができる気がします。
室井さんが来る前の本部の管理官のように管理することでマネジメント（うまくいかせる）しがちですが、一方で室井さんのように任せるマネジメントもあります。
どちらかしか選択肢を持たないのではなく、さまざまな状況の変化にあわせて任せるところは任せて締めるところは締めるような器用なマネジメントが現代には求められているのかもしれません。
”責任をとる、それが私の仕事だ！
現場を信頼した捜査を行った結果、上層部から釘を刺された室井さんが上層部に対して発した言葉です。
この言葉を聞いて私の上司がある席でふと話した言葉を思い出しました。
私はものをつくることはできない。
だから、ものをつくることのできるメンバーを尊敬している。
私ができることは彼らを信頼することと責任をとることだけよ。
目から鱗です。
”警察を・・・任せたぞ
実は本作が和久さん役のいかりや長介さんの遺作となりました。そしてこのシーンは、映画のそしていかりやさんのラストシーンとなりました。
直接的に描かれることはなかったですが、和久さんも若かりし頃は組織の上層部と戦いながら自分の信念を貫いていたようでした。自分にとって一番大事な信念を任せることができる後輩を育ったことは彼の残した成果の一つと言っていいでしょう。
組織において教育は大事な要素の一つです。我々のようなものづくりに近い職業に撮っては、ノウハウやスキルだけでなく、想いや信念といったメンタル面の教育こそが最大の課題でしょう。
生意気にも組織について書かせていただきました。
しかし、その生意気な我々も組織の一員であり、次代の組織を担っていく存在でもあります。役割を気にすることなく、本当にいいものを追い求めて意見をぶつけ合うことが組織にとっても重要なのかもしれません。
おまけ
以前勉強会でも生意気な発表をさせていただいていました。
こんな本もありました。
踊る大捜査線に学ぶ組織論入門 |
