広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。するためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。今よりも仕事が増えそうだ。給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。「給料が上がるわけじゃないないし、だったら面倒だから断ろう」このように考えるのがごく普通の判断というものだろう。彼に将来の夢があったならどうだろう。独立して社長になりたい。他社からスカウトが来るようなプロフェッショナルになりたい。そんな夢があったら、きっと判断は変わるに違いない。「将来独立するためには、この経験はプラスになる。自己成長のために是非やらせてもらいたい。」そのように答えが変わってくるだろう。小倉氏は組織人事のコンサルタントだったからこう書いているが、この話しはソフトウェアエンジニアにも全く同じように当てはまる。ソフトウェアの開発効率や品質を高めるためには、高度なスキルを学んだり、自動化のシステムを構築したり、アーキテクチャを見直したり、プロセスを組み直したりするため一時的に仕事量が増える。日々忙しいのなら、さらに忙しくなるということだ。ソフトウェアプロダクトライン(ソフトウェアの再利用戦略)もそうだが、最初に再利用資産を構築する際には通常の作業よりも1.5倍くらいは軽く工数も時間もかかる。それを乗り越えて「今やろう」と決断できなければ、その先開発が楽になることはない。エンドレスの悪循環が待ち構えている。エンジニア個人やプロジェクトにスキルアップや新しい取り組みを進言するとき、必ず聞かれるのは「それをやるとどれくらい工数や時間がかかるのか」だ。目先の損得だけで判断されると大抵は辞退される。エンジニアとしての将来の夢を語りたいのだが、なかなか自分自身がエンジニアとしてどう成長したいのかを頭に描いている人はいない。新人は夢があっていいのだけれど、職場に配置されて1年もたつと、夢を語らなくなる。上記の引用のように、夢のないエンジニアに仕事を任せても成長のスピードが遅い。Skill):自ら考え行動する力」の「どうせどうせ子ちゃん」や「評論家君」が多く、「問題解決キッズ」が少ないのだ。小倉氏は、『任せる技術』のなかで「世の中には、明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たないと思う。これまで3万人の管理職に研修や講演をしてきた僕の実感値では、1~2%がいいところだろう。よって、上司は部下が自分の人生のビジョンを描くお手伝いをする必要があり、そのためには定期的な面談が欠かせないと書いている。実際に部下と人生のビジョンについて面談するとわかることがある。それは何度質問を繰り返してもビジョンが見つからない部下がたくさんいるということだ。これまで彼らは「ベキ論」に縛られて生きてきた。「どうしたい?」「どうなりたい?」と聞かれるとうろたえてしまうのだ。「やりたいことが見つからない」。いう若者が増えているのだという。僕たちは彼らに対してどう接すればよいのだろうか?これまで言ってきたことと矛盾するようだが、僕はその場合は、ムリしてビジョンを描かなくてもいいと思う。今、目の前にある仕事に120%集中するよう導いてあげればいいのではないか。キャリア・ドリフト理論という考え方がある。キャリアはデザインするものではない。偶然に出会うものだ、という考え方だ。そのためには条件がある。今、目の前にある仕事に120%集中することだ。「自分には向いていないかもしれない・・・」などと言わずに、その仕事に集中するのだ。そのときに初めて偶然が、幸運が訪れる。「明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たない」というのは悲しいことだ。なっているのは、人生のビジョンを描く訓練をしてこなかったからだと自分は信じたい。「ベキ論」に縛られることなく、やりたいことをやるにはどうしたらいいのかを考え、実行し、ダメだったらなぜそうなったのかを反省するそれを繰り返していけば、人生のビジョンを描けるようになると思う。本当ならば、それを学生の時代に訓練しておいて欲しいのだが、その訓練をする機会もなく社会で出てしまった人達は大勢いる。上司は部下に仕事を任せなければいけない。■任せる、とういことは、自分の違うやり方に異を唱えないこと任せた以上は、自分と違うやり方を許容しなくれはならない。「そのやり方をすると後で必ず問題が起こるぞ。やっちゃった・・・」そう思ったとしても、部下のやり方に異を唱えてはいけないのだ。失敗することも含めて部下に経験させなくてはならない。それが本当の意味での任せる、ということなのだ。【引用終わり】もう一つ、重要な教訓。■相手に矢印を向ける人は成長しない先にお伝えした通り、上司が持っていた仕事を部下に任せると、部下には大きなストレス負荷がかかる。能力以上の仕事にチャレンジする部下は思い通りにならない仕事にイライラを感じるのだ。これを心理学の言葉では認知的不協和と呼ぶ。これは前にも説明したが、そのイライラを解消する時に常に選択肢は二つある。一つは自分に矢印を向ける方法。問題の原因を自分にあると考え、自分を変えることで問題を解決しようとするアプローチだ。これを選ぶ部下は成長していく。仕事を任せたかいがある、というものだ。一つの選択肢を選んだ場合はそうはいかない。それが他人に矢印を向けるという方法だ。「チームの目標達成率が低いのは、人員を補充してくれない人事部のせい」そうやって問題をすべて他人のせいにすることで自己正当化する。自分は悪くない、悪いのは他人だ、と言って必死に自分を守るのだ。当たり前にことではあるが、このタイプの人は成長しない。自分は変わる必要がない。すべては他人が悪いと思っているからだ。相手に矢印を向けずに、「自分に矢印を向ける」ように指導する、これが難しい。すればいいかを考えるのも自分の仕事だ。技術者教育2011-06-12「部下に任せないとダメだ」と考えさせられる一冊いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。最初の方だけしか読んでいないが、とても心に響いている。引用】そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。部下に教えられるほどにノウハウが整理体系化されていない。口べたであり、うまく部下に教えることができない。部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか?」という恐怖が強い。そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。「自分がいなくなったら?」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。聞くと返ってくる答えは2種類に大別される。1つ目は「今の仕事が自分には向いていない」というものだ。営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。あきらめて転職する、と言うのだ。僕はその2つを聞くたびにこう思う。「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。失敗が喉の渇きを引き起こすなぜ人は「任される」と育つのだろうか。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。うまくやるための方法という「水」を求めて「喉が渇く」のだ。様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。うまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。して全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。【引用終わり】この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。大規模プロジェクトでは自分の作ったソフトウェアに失敗(=バグ)があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。この本を読み進める必要がありそうだ。(Atom)組込みソフトウェア工房へようこそ本ブログサイトでは技術を磨き、組織を通じて顧客満足度を高めたいと考えるエンジニアを応援します。*注目の投稿ソフトウェアアーキテクチャとは何かを考える最近,協力会社に開発を任せていてソフトウェアの中身が分からず,意図した動きにならない(レスポンスが遅いとか,画面が思ったように遷移しないとか)という話を聞いた。,「ソフトウェアを継ぎ足し続けた結果,肥大化・複雑化して,原因を追及しにくい不具合が発生して困っている。「最初に読んで欲しいこと。英和対訳版が手元に届いた。こだわっている理由を書こうと思う。自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2~3年待った方がよいと考えるようになってきた。機能安全に群がる商魂...安全を売りにするな!安全を食いものにするな!最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。』(渡辺健介著)という本を読んだ。いつものように、まえがきを紹介したいと思う。壁に直面したとき、自分の...レクサスのパワーステアリング不具合の原因分析についてトヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。リスク分析、リスクアセスメントについての話題である。イントロダクションを読む自分は組織内で次の(2)の立ち位置にいる。プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。日経もの...自己紹介sakai1987年よりクリティカルデバイスのソフトウェア開発に従事する。16bitのワンチップマイコンを使った信号処理、リアルタイム組込みシステムの開発を行い、商品の仕様立案からソフトウェア開発のプロセス管理、プロジェクトマネージメント、安全性・信頼性の検証、保守、ソフトウェア技術者教育など組込みシステム開発に関する幅広い領域を経験する。オブジェクト指向設計やプロダクトライン戦略を商品開発に生かすことも試みる。商品開発を常にアーキテクトの視点から分析し、「具体から抽象へ」というアプローチにこだわる。)に、2011年より組込みソフトウェアギルドに参加している。