ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2016-05-31

[]横紙破り・亜種

横紙破りには、様々な「変種」や「次形態」が存在します。

脇役化(Sidelining)

脇役化は、横紙破りの仕事量や業務責任を軽くした形態の人物です。

ただし、脇役化によって大量の暇ができた横紙破りたちは、なお一層、問題発言に励むようになります。

田舎の情報化(Third-World lnformation Systems Troubles、第三世界の情報システムのトラブル)

田舎の情報化は、情報システムの変更に断固として反対する人のことです。

ほとんどの人が不満や不便を感じているにもかかわらず、決して変更しようとしません。なぜなら、田舎の情報化は、現状維持(status quo)から何らかの利益を得ているからです。

会社鮫(Corporate Shark)

会社鮫は、技術力より人間関係をあやつる能力で出世してきた古手の管理者です。今では会社鮫が技術者であるとは、社内の誰もが思っていません。

会社鮫は、技術能力や管理能力によってではなく、人を食って生きています。会社鮫はシステムを「いじくる」方法を知っており、技術的な問題に専念している人びとの間に厄介な政治的状況を延々と持ち込みます。

会社絞に対する最良の策は、会社絞にまったく近づかないことです。接近してきたら、逃げるようにします。なぜなら、接触したら必ず否定的な結果が生ずるからです。

ボーナス怪獣(Bonus Monster)

ボーナス怪獣は、ソフトウェア開発プロジェクトを安上がりに仕上げることによって、短期的な利益を得ようとする者です。

ボーナス怪獣は、社内の複数の組織をわざと競わせることによって、破壊的な結果をもたらすことがあります。

この問題は、ボーナスの制度を改善する、または臨時ボーナス制度を廃止することによって解決できます。ボーナス怪獣は会社鮫でもありますが、ボーナスが出るような結果をつねに追い求めている点で、単なる会社鮫よりもっとガツガツしています。

マッチポンプ(Firebrand、煽動者)

マッチポンプは、緊急事態を担造する人物です。

たとえば、マッチポンプが間違った指示をしたり妨害行為を働き、ソフトウェアの重要な部分が納期に間に合わなくなったりします。マッチポンプの目的は、そういう緊急事態をわざと作りだして、後で自分が会社を救ったヒーローになることです。

それに成功するためには、マッチポンプは自分で火を消さなければなりません。マッチポンプは自分に解決できそうな問題を発生させ、それを自らすべて取り除き、偽の成功へと導きます。

自意識過剰(Agomaniac)

自意識過剰は、自分が社内で最も重要で権威ある人間である、というイメージにこだわる人物です。「プリマドンナ」とも呼ばれます。

上級管理職が自意識過剰である場合の対策は、窓際に飾ることです。会議では、自意識過剰をほめ殺します。ただし、それが逆効果になって、自意識過剰にいよいよますます、ナルシシズムを発揮されてしまうこともあります。

口害病(Loose Cannon、止まらない大砲)

口害病は、性格が外向的すぎて、ほかの人や会社を困らせる人物です。口害病患者は、発見が容易です。集団の中にいると、すぐにしゃべりだし、その病状を派手に露呈します。

口害病の言動は、プロジェクトのイメージや士気に破壊的な影響を及ぼすことがあります。たとえば、情報を軽率に外部に漏らしたり、組織内の重要な役割関係に関して無神経だったりします。

口害病患者を最も効果的に扱う方法は、管理者に警告して、矯正的なインタビューを行ってもらうことです。

技術頑固(Technology Bigot)

技術頑固は、口害病の一種で、マーケテイングハイプ((marketing hype マーケテイングのためのこけおどし、一面的で派手な

フレーズ、特定技術の良い面だけを誇張的に敷約した記述や論調です。))をあたりにばらまき、ほかの見方を考慮することを拒絶する人物です。

たとえば、すべての情報技術が特定企業の技術をベースにするとか、分散オブジェクトを実装する正しい方法はCORBAしかない、と言い張る人です。「成功するだけではだめだ。ほかの連中が失敗しなくては」がモットーです。

縄張り死守(Territorial Corncob、縄張りに固執する文句屋)

組織の縄張りや技術の縄張りを守ろうと、防御的な振る舞いを示す人物です。

縄張り死守が、自分の縄張りを死守するのは、自分の能力に関する不安を拭いたいからです。お世辞や、弱さに対する態度で懐柔できる場合が多いです。

御馳走をちらつかせることによって、諌めようとしてはいけません。縄張り死守は、縄張り内で新たな機会や権力の匂いを嘆ぎ取ると、ますます自分の領土にしがみつきます。

突然横紙破り(Corncobs out of the Woodwork、急に文句屋になる人びと)

横紙破りの言動が増幅した人物です。

プロジェクトの深刻な問題や、迫り来るレイオフなど、特別に困難でストレスの多い状況が生じると、一部の横紙破りたちはその言動を増幅します。

自分の方が進んでレイオフを志願して、逃げるのが得策です。

破壊工作屋(Saboteur)

破壊工作は、もうすぐ集団を去るため、自分の次の仕事を有利に運ぶために、業務環境に小細工を仕掛ける人のことです。

たとえば破壊工作屋は、積極的な引き抜き、噂、否定的な行動などを通じて、同僚がプロジェクトを脱けるよう仕向けます。

破壊工作屋は、自分がもうじき居なくなるというそぶりを見せないので、工作の早期発見と対策が難くなります。もし見つけられたら、業務環境に悪影響を及ぼさないように、迅速に排除すべきです。

出世主義者(Careerist)

出世主義者は破壊工作屋の変種であり、自分の技能を高め、今後の転職等を有利にするために技術を選ぶ人です。

たとえば、RDBMSの上にオブジェクトAPIをラップしたもので十分間に合う状況でも、純正のオブジェクト指向データベースを使ってオブジェクトのパーシステンスを実現しようと計画する技術アーキテクトです。

時代錯誤の人(Anachronist)

単に自分が理解できないから技術革新に抵抗する横紙破りです。

時代錯誤の人は、古い技術についてはよく知っており、新しい技術にはすべて反対します。効果的な対策は、徹底した教育です。

2016-05-30

[]横紙破り(Corncob)

横紙破り(Corncob、文句屋)

別名

  • 獅子身中の虫(Corporate Shark,会社鮫)
  • 口害病(Loose Cannon,止まらない大砲 = 問題発言常習者)

どういうこと?

破壊的な言動によって開発を邪魔する、扱いにくい人物がいます。これを「横紙破り」と呼びます。

横紙破りは、チームのメンバのこともあれば、横やりを入れることが好きな外部の上級管理者のこともあります。後者は、技術的、政治的、個人的など多岐にわたり、さまざまな手段を駆使して、チームを妨害します。

横紙破りは、技術よりも政治に関心があります。個人や組織のレベルで政治をもて遊ぶことの達人です。政治音痴で、技術にしか関心のない人ほど、横紙破りたちの策略に引っかかりやすくなります。

どうしてダメ?

横紙破りは、プロジェクトの重要な目的や重要不可欠な工程について合意せず、絶えずそれらを変えようとするために、プロジェクトが前に進みません。

横紙破りは、つねに反対意見を発言します。これが、実行性能や信頼性、マーケットシェアなど、一見真面目に心配しているフリをするので、なかなか止めることができません。

横紙破りは、強力な政治力を駆使します。議論が歪められて、技術的決定事項がまともな方向に進みません。政治的な力のせいで、システムの要件のスコープが頻繁に変わります。横紙破りが提言する「果てしない改善要求」に対応しているうちに、プロジェクトが自律性を失い、もっぱら反応的・受け身的になり、活力を失っていきます。

どうして起こる?

横紙破りの行動は、個人の性格に原因がある場合ありますが、本当の原因は、上司からの注目や今後の昇給の可能性など、人事評価とお金が絡む動機です。

管理職たちは、横紙破りの破壊的な言動を知っていますが、それを許容しています。しかも、なんとなく支持しているようでもあります。その言動がもたらすダメージに気づいていないか、対策に腰を上げることが面倒なのです。また、状況に関する管理職の知識は、横紙破りから注入された情報ので、問題が正確に伝わっていない場合もあります。

また、プロジェクトマネージャからみると、直接の部下でないことが多いので、制御が難しくなります。問題解決のための意思決定過程が明確に定義されていないのをいいことに、自分の権限領域を越えて、恣意的な介入を自由に行うことができています。

どうすれば?

対策は、「戦技のレベル」「戦術のレベル」「戦略のレベル」という複数のレベルで考えられます。どの場合も、治療の焦点となる患部は、破壊的な言動に対する管理者の態度です。

3つのレベルで管理者の支持を取り去ることにより、横紙破りは支持を失い、ソフトウェア開発チームは救われます。

戦技レベルの解決

戦技的な解決は、会議などの現場で即興的に採用されるアクションです。

まず、責任転嫁です。文句ばかり言う人に、指摘する問題にたいして、一定期間内に解決するための全責任を与えます。言い換えると、計画と決定の権限を転嫁するのです。

次に、問題を正式に議題化することです。多くの場合、横紙破りの意見は孤立しています。そこで効果的なのは、集団の利益に訴えることです。横紙破りが喧嘩腰で挑んできても、絶対に個人的な問題として対処してはいけません。問題をこじらせるだけです。意見を正式に会議の議題として取り上げ、その反対意見を全員で十分に議論し、議決によってそれを否決します。

次に、 質問をすることです。横紙破りが陵昧で難解な言葉を駆使したときには、その言葉の意味を質問します。伝聞証拠を用いて何かを断言したときには、主張の具体的な証拠の提出と、自身の立場の明確化を求めます。

戦術レベルの解決

戦術レベルの解決は、部課など比較的狭い範囲で、オフラインで行います。

まず、矯正的インタビューです。管理者がその人物と個人的に面談して、言動の社内的な影響について説明します。インタビューの目的は、問題に気づいてもらうことであり、また、言動を今後どう変えるかについての合意に達することです。

次に、友好的な転職斡旋です。人材スカウト業の人に、横紙破りの人を紹介することによって、円満退社を促進します。

戦略レベルの解決

戦略レベルの解決は、長期的であり、全社的な範囲に及びます。

まず、横紙破り集団を作ることです。横紙破りを全員、同一のグループへ配転します。そうすると横紙破り同士の聞での抗争が始まります。各人が管理者のところへやってきて、ああいう厄介者と一緒に仕事をするのは嫌だ、と言いだします。その機会をつかまえて管理者は、「あなたもほかの人たちからは厄介者と思われているんですよ」と説明します。それが自覚と自己改善につながります。

次に、窓際をあてがうことです。管理職が横紙破りの場合は、部下が一人もいない部署を作って、そこに配転します。これらの管理職はやがて「暗黙の通達」を受け取り、引退するかまたは他社に転職します。

最後に、組織から外すことです。その人物をチームや業務環境から強制的に排除する以外、ほかに適切な方法がない場合もあります。


2016-05-27

[]取り越し苦労(Fear of Success)

取り越し苦労(Fear of Success)

どういうこと?

プロジェクトがいよいよ成功で終わりそうなのに、土壇場になって奇妙な現象が起きることがあります。一部の人びとが「何かを間違えてはいないだろうか」と過剰に心配し始めるのです。これを「取り越し苦労」と呼びます。

どうしてダメ?

心配を誰かが口にすると、チームメンバ全員に心配が伝染します。そして、それらの心配に対処しようとして、不合理な決定がなされたり、不適当な行動を起こしたりします。

さらに、そういう不安に満ちた雰囲気がチームの外部にも悪影響を及ぼし、製品そのものに対する疑念が世間に広まることもあります。

どうして起こる?

一般的に、集団の行動力学は、複数の段階を経て大きくなり、プロジェクトや作業の開始後1週間も経つと、その姿がはっきり認識できるようになります。

第一段階は、集団の中でお互いがお互いを受け入れる段階です。

第二段階は、人間関係が形成され、個人が集団内の役割を認識し、組織内の公式の役割と自分で決めた非公式な役割の両方を引き受けます。これが、チームづくりの重要な要素です。

第三段階になると、実際の仕事の中で、個人の性格に起因するさまざまな問題が起きることがあります。

第四段階は、プロジェクトの終了間際です。プロジェクトの完了は、集団の解散を意味するので、プロジェクトの終了が近づくにつれて、個人の性格上の問題がこれまでより顕著に露呈してきます。

最後の段階では、プロジェクトの結果、製品の将来のライフサイクル、および集団の今後の活動に対する不安が、直接的にではなく別の形でしばしば表現されます。つまり、人びとは奇妙なことをし始めるのです。

どうすれば?

管理者は、プロジェクトの終わり近くで、成功を宣言します。

実際の成果が不確かであっても、宣言は明確にします。チームが、自分たちが達成したことの意義と、開発の過程で学んだことを、はっきり自覚することが重要です。管理者は、その自覚を促進援助しなければなりません。

成功宣言は、終結に伴う性格的な問題を緩和し、組織への忠誠心を維持し、将来のプロジェクトへの積極的な取り組みを推進します。プロをプロとして認め称賛することは、チームメンバの精神を大きく高揚させます。

2016-05-26

[]計画倒れ(Death By Planning)

計画倒れ(Death By Planning)

別名

  • 箱入り娘(Glass Case Plan、ガラスケース計画)
  • 微細主義(Detailitis Plan、細部こだわりすぎ計画)

どういうこと?

多くのプロジェクトが、計画過剰によって失敗します。これを「計画倒れ」と呼びます。計画過剰は、神経質すぎる費用管理や労働評価の結果として生じます。

計画過剰には、2つのタイプがあります。それらは、「箱入り娘(Glass Case Plan、ガラスケース計画)*1」と「微細主義(Detailitis Plan、細部こだわりすぎ計画)」です。「箱入り娘」は「微細主義」のサブセットで、プロジェクトがスタートしたら計画過剰は止まります。「微細主義」では、計画過剰がプロジェクトの終了まで続きます。

「箱入り娘」では、プロジェクトの開始時に作られた計画が、プロジェクトの正確な見取図であると信じ込まれ、最後までまったく修正されません。計画はその後まったくチェックされず、プロジェクトの進捗と共に、ますます不正確なものになっていきます。この錯誤は、進捗に関する正確な情報が入ってこないことによって、さらに重症化します。そういう情報は、大幅な納期遅れが確定的になった後にやっと、管理職の耳に届くのです。管理者は、計画に書かれている納期が現実の納期だと思い込みます。その納期は、あたかも管理者からの介入や管理なしで自動的に実現するかのように、現実逃避してしまうのです。

「微細主義」では、計画納期を確実に実現するために、上級開発者や管理職たちが絶えず計画の作成や計画の微修正に励み、それに基づいてプロジェクトに対し強い締めつけを維持しようとします。これは往々にして計画の階層化へと進化し、さらに一段と計画の微細さが増します。これだけ細かい計画を作れたんだから、プロジェクトの管理もうまくいっているにちがいない、という誤った自信を管理者に与えます。

どうしてダメ?

「箱入り娘」に陥ると、計画は無意味化し、いつ完了するのかもはや誰もわからなくなります。最悪、プロジェクトはキャンセルとなり、完成製品を発売できななくなります。また、このタイミングで貴重な人材が辞めたり、解雇されたりする場合もあります。

「微細主義」に陥ると、計画の修正が毎日のように行われ、それがまた明日以降の計画修正の原因を作ることになり、事態をどんどん悪化させます。ソフトウェアを作ることよりも、計画書を作ることが毎日の仕事の目的になります。管理者は、作業と経費をこれだけ厳密に管理しているのだから進捗は順調であるはずだ、と思い込みます。しかし実際には、計画の細かさと仕事の進捗の間に正の相関関係はありません。納期が何度も何度も延期され、ついにプロジェクトの失敗に至ります。

どうして起こる?

多くの組織文化において、詳細計画の作成はどのようなプロジェクトにも必要な活動であると見なされています。

この想定は、製造業では妥当ですが、ソフトウェアにとっては必ずしも適切ではありません。ソフトウェアプロジェクトは、その本質からして、未知の要素やカオス的な活動が多いからです。

どうすれば?

無理のない計画を立案し、適度な進捗管理を行います。

計画は、まず第ーに、何をいつ完成させるのかという点をしっかり明記します。製品全体と各部位の進捗確認スケジュール(いわゆるマイルストーン)も含めます。また、早期に無理のない形で立案することが不可欠です。それがないと、計画のその後の変更に関する管理も不可能になります。日程を予測するときには、ある程度の不確定要素をあらかじめ勘案しておきます。

進捗管理は、日程を毎週更新して、計画と管理の現実性を確保し、プロジェクトのリスクを低減します。計画に照らして工程をチェックするだけでなく、計画そのものを定期的に微調整します。これにより、さまざまな問題やリスク、納期遅延、納期前倒しなどに適切なタイミングで対応できるようになります。

*1:計画をガラスケースに大切におさめて大切に保管し、鑑賞・自画自賛するような態度のことです。

2016-05-25

[]文書化地獄

文書化地獄(Viewgraph Engineering)

どういうこと?

開発者がプレゼン資料などの作成に凝りすぎて、ソフトウェア開発への着手が遅れます。これを「文書化地獄」と呼びます。

どうしてダメ?

開発者はコードを書いてこそ、真価を発揮します。価値を最大化するためには、それ以外のことは、必要最小限度にとどめるべきです。

どうして起こる?

エンジニアには凝り性の人が多くいます。開発に直結しない絵や文章でも、やり始めると夢中になり、必要以上に良いものを作ろうとしてしまいます。

どうすれば?

開発者にプロトタイプの構築を命じます。開発者を、ソフトウェア開発に引き戻すのです。

プロトタイピングは段階的・漸進的な開発における重要な要素の一つです。紙の上の分析からはわかりえない、技術的な質問に答えてくれます。また、受け入れの検証での、いろいろなリスクを、あらかじめ軽減してくれます。新技術の学習曲線を短くすることにも役立ちます。

プロトタイプの2つの基本タイプは、「モックアップ」と「エンジニアリングプロトタイプ」です。

モックアップは、ユーザインターフェイスの外見と振る舞いをシミュレートするプロトタイプです。ユーザビリティに関するさまざまな問題を、事前に評価して解決します。

エンジニアリングプロトタイプは、技術や設計を確認するための、動作を含むプロトタイプです。アーキテクチャを確認したり、評価するために役立ちます。