Information Technology Tips

今日紹介する書籍は、「 なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント 」です。   こちらの書籍は、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. メンバーの入れ替わりが激しい メンバーの入れ替わりが激しい場合、各メンバーが保有している知識が断片的で、システム全体の知識を持っている人が少ない、あるいは全くいないということが考えられます。またメンバーの入れ替わり画激しいため、知識は容易に失われてしまう可能性も高いです。 自動テストがあれば、自分の変更が、思いがけないところでロジックを破壊していても検知できますので、安心です。 ただし、その入れ替わっていくメンバーには、そのメンバーの責任でテストを追加してもらうことが必須になります。あまり移動しないコアメンバーがいるのであれば、そのコアメンバーがテストコードを書くほうが望ましいです。コア

最近BDD (Behavior-driven Development) についてエンジニア仲間で話題になったので、記事を書こうと思い立ちました。 結論から言うと、筆者は、BDDには懐疑的な立場です。 BDDとは(あくまで筆者の理解) BDD (Behavior-driven Development)は、 ビジネス側が書いたシナリオ(誰が、どんなとき、どの条件で、どうしする)や仕様をもとに、コンピュータで実行可能なテストを自動生成し、システム側がそのテストを通るようにシステム開発をしていく方法です。ビジネス側がBehaviorを書く際の言語は、ビジネス側でもできるだけ理解できる自然言語風の、BDD専用言語です。 BDDのメリットは、 ビジネス側の仕様記述から、システムテストを作成できるので、ビジネス側の望んでいるシステムを素早く正確につくれる ビジネス側の仕様変更がダイレクトにシステムテストに反映されるので、仕様変更にも強い ことかと思います(筆者の理解)。 筆者がBDDを支持しない理由 １番目の理由は、そもそもビジネス側の期待している振る舞い (Behavior) 自体が曖昧で、それを論理的に整合性のある仕様に落とし込むことが、システム開発で最も困難な場合が多いと感じるからです。 ビジネス側の期待している振る舞いが簡潔で、論理的であればあるほとプログラムとして記述しやすくなるはずなので、その場合は、システム側だけのTDD (Test Driven Development) 方式で開発を進められると思います。 BDDの記述方法も所詮は論理記述の一種なので、それが綺麗に書ける人はそもそも、エンジニアとしての才能があるので、普通に綺麗な仕様を書ける場合が多いのではないでしょうか。 ２番目の理由はBDDの記述言語です。 自然言語風にするのはいいのですが、自然言語に近づければ近づけるほど、論理の矛盾や文法チェックが必要になり意味解釈が面倒になると思います（自然言語処理が簡単であれば、自然言語処理という研究分野は存在しないはず）。 もちろんBDDの記述言語はプログラム言語を自然言語風にしたシナリオ記述言語なので、意味解釈の面で問題が出ることはないと思います。 しかしそうすると、BDDの記述言語には表現に制約があり、最終

Value of reducing code Reducing amount of code is one of the MOST REQUIRED & IMPORTANT skill in real software development workplace, especially in team based software development. Most of the case, reducing code is much more valuable than writing code! Why doesn't any computer science teach this MOST important skill! Let me point out benefits of reducing code: The less code makes programmer be the easy to understand project! The amount of code they should read is lesser! Fledgling developer easy to understand! You don't have to write much test code! Complexity should tend to be lower! Code duplication tends to be less! Prevent regression! You can only care about code which really lively works! Put it all together, These benefits finally leads "Improve code maintainability" and "Reduce maintenance cost" . I mention just in case - reducing code doesn't mean you should merge a few "for loop" lines into single line. My pri