Information Technology Tips

今回、紹介する本は「 ハーバード流 ボス養成講座 優れたリーダーの3要素 」です。 私は正直「ハーバード流○○」「マッキンゼー流××」「Google流△△」などのようにいわゆる、一流と呼ばれる組織の名前を追加して、「ハロー効果(ある対象を評価をする時に、それが持つ顕著な特徴に引きずられて、他の特徴についての評価が歪められる現象のこと[Wikipediaより引用])」により買わせようとするマーケティング手法に対しては苦々しく思っています。本書もマーケティング戦略のためか、邦訳版の題名と原著の題名には大分乖離があります。原著の題名はシンプルに「Being the Boss: The 3 Imperatives for Becoming a Great Leader」、直訳すると「ボス(上司)になる : 偉大なリーダーになるための3つの必須事項」になるかと思います。 題名で売りたいだけの本で中身は薄っぺらいのかなと思い、本書を購入する気は余りなかったのですが、他の方の書評を見て購入に踏み切りました。内容は非常に実践的で濃いものですので、お勧めです！逆に題名に「ハーバード流」とか安っぽくなるのでつけない方がよい気がします。 翻訳そのものに関しては、ビジネス書の翻訳でよく見かける村井章子さんの訳だけあって、非常に読みやすいです。本書で最も読みづらかったのは、各章の導入部分で物語風に書かれている部分の登場人物の名前です。私は英米人の名前には馴染みが薄く、誰が何の役職なのかすぐに理解できなくなってしまいました。例えばブレンダ・ボールドウィン、レイ・サンチェス、ジャック・キャビットなどが登場します。日本人向けであれば、鈴木、山田、田中とかに置き換えて読むと理解が早まるのではないかと思いました。 さて肝心の内容です。本書は会社の中核を担う中間層のリーダーたち向けの本になります。彼らに求められる3つの要素(3 imperatives)として本書は 自分をマネジメントする 人脈をマネジメントする チームをマネジメントする を挙げています。単に並べただけですと抽象的ですが、各要素ごとに分量を割いて深く掘り下げて書かれています。 「2. 人脈をマネジメントする」の部分では「上司」「組織」「影響力」、「3. チームをマネジメントする」の部分では「将来像」...

マイケル・ポーターは「Competitive Advantage (競争優位)」「Five Forces」で有名な経営戦略研究の第一人者です。私も以前から興味があり名著「競争の戦略」を読んでみようと思っていたのですが、書店に行って、あまりの本の分量の多さ (+価格の高さ)に購入を諦めていました。 もっと手軽に読めそうな本はということで、以下のポーターの論文集のような「競争戦略論I」「競争戦略論II」本は購入したのですが、いまいち(私のレベルの)実務では実感に乏しく、あまり深く読んで理解することができませんでした。 そんな中でようやく見つけたのが本書「 [エッセンシャル版] マイケル・ポーターの競争戦略 」になります。結論から言いますと、本書が私にとっては最も理解しやすかったです。 本書は、ポーターの経営・競争戦略の理論の本質を、ポーターと長年仕事を共にしてきたジョアン・マグレッタが要約し解説する形で書かれています。 原著は「 Understanding Michael Porter: The Essential Guide to Competition and Strategy 」になります。 今回の邦訳の題名は意訳感はないので改めて訳すほどではないですが、私の拙い英語で直訳すると「マイケル・ポーターを理解する: 競争と戦略の必須ガイド」になるでしょうか。余談ですが「Essential Guide」は「エッセンシャルガイド」のカタカナで訳 してしまってもよいかも知れません、日本語でぴったり来る言葉が見つかりませんでした。そもそも「Guide」は「ガイド」と訳すしかないような気がします。 さて本の内容です。正直あまり期待していなかったのですが、ポーターの競争戦略の要点がしっかりまとめられており、「なるほど」「面白い」と感じながら読み進めることができました。また、ポーターの理論へのよくある批判に対する反論や解説も記されており、ポーターの理論を俯瞰的に理解することができました。 私が、本書でまず気づかされたのは「競争に勝つ」という言葉に対する意味のとり方です。我々は「競争に勝つ」というとどうしても「最高を目指す」「一番になる」「相手を打ち負かす」というような行動をとりがちですが、ポーターは「最高を目指すべきではない」と言...

今日紹介する書籍は、「 なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント 」です。   こちらの書籍は、2000年に出版された「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」の邦訳になります。   「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」の邦訳は既に、下記の2回刊行されています。 「 変われる会社、変われない会社―知識と行動が矛盾する経営 」2000年 「 実行力不全 」2005年 私は、「なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント」を購入した後、別の本だと勘違いして「実行力不全」を取り寄せてまで買ってしまいました。どこかで読んだことがある内容だなぁと思いながら読んでいて、同じ内容の本だと気がつきました。 「なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント」の最後のページにも、過去に刊行された本を改題、修正したものだと書いてありました。 目次の見出しなど、細かいところに翻訳の差異がありますが、内容はほぼ変わりませんので、上記紹介した3冊のいずれかを購入すれば問題ないかと思います。 邦訳版は3回刊行されいぇいますが、毎回書名がずいぶん違います。原著の題名「The Knowing-Doing Gap: How Smart Companies Turn Knowledge into Action」は、私の拙い英語力で直球に訳すと 「知っていることと実行することの壁: どうやってかしこい会社は知識を行動に変えるか」 みたいな感じでしょうか。  さて、内容ですが、このあたりはそれなりの規模の組織に所属したことのある人であれば、「あるある！」と思うことが多い内容なのではないかと思います。 意思決定ばかりで行動はおあずけ プレゼンテーションの準備に時間もエネルギーも奪われる 実行すべきことの文書づくりに熱中する 計画しただけで行動した気になる 社訓を掲げて行動のかわりにする うーん。耳の痛い言葉が並んでいます。 特に印象に残ったと...

皆さんはジェフリー・フェファーをご存知でしょうか。 ジェフリー・フェファーは、アメリカの組織行動学者でスタンフォード経営大学院の教授をされている方です。 「パワー」「影響力」「組織行動」などのキーワードが個人的にしっくりくる方かなと思っています。理想よりも現実に即した著作を多く発表しており、彼の著作は会社で行きぬく上で非常に参考にさせてもらっています。 そんな彼の著作の中で最近邦訳された「 悪いやつほど出世する 」を紹介したいと思います。 原著は「Leadership BS: Fixing Workplaces and Careers One Truth at a Time」(Jeffrey Pfeffer)なので、直訳すると「リーダーシップのウソ: 一度に職場とキャリアを改善する1つの真実」になるかと思います。  BSの意味がいまいちわからなかったのですが、私はスラングの「Bull Shit = 牛の糞 」と取って、「デタラメ」「ウソ」という訳にしました。あと副題の「Fixing Workplaces and Careers One Truth at a Time」の部分は本著作中で、これまでさまざまなリーダーシップ論が提唱されてきたが、いつも正しいわけではない(=半分正しい)というような主張をしていたので、「Fixing Workplaces and Careers One Truth at a Time (一度に職場とキャリアを改善する1つの真実)」みたいなそんなものはないよ、といっているのではないかと個人的には理解しています。 さて、内容ですが、端的にいうと、「リーダーシップの書籍や講座で述べている理想論は捨てなさい、とまでは行かないまでも、全部鵜呑みにするな」ということだと思います。 章ごとのタイトルを、私が気になったもののみ抜粋して並べただけですが、本書の主張は、たとえば以下のような感じです。 大繁盛のリーダー教育産業 にもかかわらず、職場は不満だらけ 悪いリーダーははびこり、名リーダーはほとんどいない 熱心にリーダー研修を受けた人ほどキケン リーダーは「社員第一」ではなく「わが身第一」 リーダーに信頼はいらない、そして私たちはだまされやすい ...

今日紹介する書籍はジョセフ・L. バダラッコの「 静かなリーダーシップ 」です。 原題は「 Leading Quietly: An Unorthodox Guide to Doing the Right Thing 」です。 直訳すると「静かに導く: 正統的でないやり方で正しいことをする」にでもなるでしょうか。「An Unorthodox Guide to Doing the Right Thing」の部分がちょっと訳しづらいです。「Unorthodox」の部分は、異端とかそういう意味ではなく、本文をよく読むとわかるのですが、「一般に言われている正統的な動機や方法とは異なった」という意味です。   一般大衆は、リーダーの目だった英雄的な行動に感動し、無意識のうちにリーダーにそういった行動を求めている節があると著者は述べています。 本書では様々な実例を通して、著者のいう「静かなリーダーシップ」とはどのようなものなのかがわかってくると思います。 私がもっとも共感したのは、第二章の「行動はさまざまな動機に基づく」です。我々はヒーローの自己犠牲の話にどうしても感動してしまいますが、実際には、自分の保身、組織の規律の維持、昇進・昇給の機会を掴む、など複雑で様々な動機が絡み合って人間は行動を起こしています。組織で昇進したいという動機だけでは、組織は良くなるとは思えませんが、それがなければ他のライバルとの競争に打ち勝つこともできず、何も成し遂げることができないのも事実だと思います。本書では人間や環境は複雑なものだと認め「複雑でさまざまな動機が静かなリーダーシップのカギになる」と述べています。 「健全な利己主義の感覚」は「静かなリーダーシップ」を実践する上では、大事なものだと述べられています。 私自身の経験と照らし合わせても、純粋な自己の欲求と倫理観のバランスを上手く取れたときに本当に良い結果が生み出されていると思います。 著者の提唱する「静かなリーダーシップ」こそ組織で働く人たちにとって、「正しいことをする」現実的な方法なのだと思います。 私もマネジメント、リーダーシップ関連の本は多く読んできましたが、理想論を語るだけでなく、現実に即しているという意味で、この本は非常にお薦めです。

自動テストのメリット 自動テストは「繰り返し」「誰でも」「手軽に」アプリケーションをテストできます。 この特徴によって、実際の開発プロセスでは、下記のメリットがあります。 1. 自分の予想していなかった部分が壊れていること(Regression)を検知できる 2. ケアレスミスを防げる 3. 他のエンジニアにも実装を頼みやすい システムに精通していないエンジニアに実装を頼んでも、適切な自動テストがあれば、ある程度の品質は保証できます。テストが失敗すれば、少なくとも使用からずれているといった問題は検知できます。さらに頼んだエンジニアのシステム設計理解も深まるという副次的なメリットも生まれます。自動テストが仕様書の代わりになるときもあります。 4. 自動テストが常に実行されているので、テスト対象のコードが動くという自信が持てる 5. コードの改善(リファクタリング)に取り組みやすくなる もちろん安全度100%ではないですが、なかったらとても安全に利ファクタリングはできません。特に入力と出力が明確でテストパターンが網羅されている場合、リファクタリングは非常に進めやすくなります。 自動テストのデメリット 自動テストは、このように品質のよいソフトウェアを開発する上で、非常に強力なツールです。しかし、大きな弱点も抱えています。筆者の経験をもとに列挙していきます。 1. テストコードの追加にコストがかかる テストコードの追加に際しても、テストデータの準備、設計、コーディングなどが必要になります。 2. 自動テストを構築するのにも技術力がいる テストコードを書くのも本番コードと同等(あるいはそれ以上)の技術力、設計力が要求されます。誰でも簡単にテストを追加可能な設計ができる、高速・安定したテストを組むことができるエンジニアが必要です。 3. テストコードの追加の優先度が下がりがちになる テストコードがなくてもアプリケーションは動いてしまうので、どうしても後回しになりがちです。どうしても本番のコード(テスト対象コード)の品質やバグFixが優先されてしまい、テストコード部分からカットされがちです。 4. チームでテストコードを書く文化がない 本番コードは、みんな頑張って書くのですが、テストコードはあまり書きたがらな...

はじめに 今日は、自動テストが威力を発揮する、ビジネス環境について考察したいと思います。 今までの筆者の経験から、筆者が重要だと思う「自動テストが威力を発揮するビジネス環境因子」を3つあげます。 コードベースに触るチームメンバーの人数が多い メンバーの入れ替わりが激しい コード変更を短期的に繰り返す 逆に言うと上記の3つに当てはまらない環境の場合、自動テストの導入の効果は薄いです。 つまり コードベースに触るチームメンバーの人数が少ない メンバーがほとんど入れ替われない 一度リリースしたら、コード変更はバグがあったときのみ (一回発注・納品型スタイル) の場合、自動テスト導入しても、効果は薄いと思われます。 以下、重要だと思う因子3つの根拠を記します。 3つの因子の根拠 1. コードベースに触るチームメンバーの人数が多い 当たり前ですが、関わるメンバーが多ければ多いほど。誰がどこを直したかをメンバー間で共有することは難しくなり、コードの変更管理コストも上昇していきます。Aという変更と別メンバーのBという変更が合わさったことによって、システムに矛盾した振る舞いを引き起こさせる可能性もあります。 そういった状況でも、自動テストがあれば、少なくとも現状のロジックが破壊された場合には検知してくれるので、メンバーが多くても安心して開発を進めることができます。 もちろん、対象のコードが自動テストでカバーされている + 正しいビジネスロジックのテストで網羅されているということが前提条件になります。 2. メンバーの入れ替わりが激しい メンバーの入れ替わりが激しい場合、各メンバーが保有している知識が断片的で、システム全体の知識を持っている人が少ない、あるいは全くいないということが考えられます。またメンバーの入れ替わり画激しいため、知識は容易に失われてしまう可能性も高いです。 自動テストがあれば、自分の変更が、思いがけないところでロジックを破壊していても検知できますので、安心です。 ただし、その入れ替わっていくメンバーには、そのメンバーの責任でテストを追加してもらうことが必須になります。あまり移動しないコアメンバーがいるのであれば、そのコアメンバーがテストコードを書くほうが望ましいです。コア...