最高にスマートなプロジェクトを目指せ！

リーダーシップを実現するＫＫＤ

「ＫＫＤではダメ」というコトバを聞いたことはありますか？
ＫＫＤは「経験」「勘」「度胸」です。
ここで言っているＫＫＤはほぼイコール、「闇雲に」とか「根拠なく強気に」「無鉄砲な」という意味で使われているようです。
しかしあえて反論させていただこうと思います。

その経験は成功の経験が含まれているか？
経験そのものについて失敗、成功いずれにしてもよく分析したか？
　失敗の経験ばかりである上に、その失敗の要因をしっかりと分析もしていない経験で良いはずはありません。
　まずは成功の経験をベースに考えるべきだと思いますが、失敗の経験でも、しっかりと分析し、対応策がある、あるいは常に注意を払って次に反映されていると言う状況は作れるはずですし、実際それによって成功していきます。

　以上、問題は内容と扱いであって、経験は極めて重要であることは疑いようもありません。

　「勘」も失敗の体験ばかりでは良い方向に働きようもありませんが、業務システム開発においても、対象を徹底的に調査してアタマにつっこんでいれば、周囲の人が気づけないような改善案や問題点だけではなく、「すぐに説明はつかないけど、何かしらおかしい」とか「これならいけそう」という、まさに「勘」としか言えないような事が見えてきたりします。

「勘」が働くぐらい情報収集や議論を重ねなければならないということです。

　そして、上記ＫＫ含め確信を持てるプロセスなどがあれば、周囲から見れば無謀に見えてしまうような進め方でも、充分安心して前進できると思います。

　準備を重ねてＫＫがあれば、「ここで言わないとヤバイ」とか「これがキモだ」など、必要に迫られていることが見えますので、「度胸」は本来発揮すべきタイミングを逃さずに発揮できるでしょう。

リーダーシップは「確信」から

　業務システム開発のプロジェクト・マネジャーとして仕事を進めて行くということは、チームメンバーだけでなく、一次契約者、顧客の皆さんとの共同作業になります。
　実際にシステムを作っていくのは私含めプロジェクト・チーム・メンバーですから、最終的には与えられた制約の中で、我々開発チームが「現実に作る事ができる進め方」を考え出し、チームメンバーだけではなく、一次契約者、顧客の皆さんには、プロとしてこちら側が提示する進め方に「（実は）従って」いただかなければなりません。
　プロジェクト・マネジャーの役割を成功裡に終えるには、どうしてもリーダーシップの要素が必要になります。
　一般的なリーダーという柄ではない私が、どうやってそのあたりを実現できたのかを考えてみたところ、最も重要なのは「確信を持てるプランがあった」ということでした。
　起こりえる問題についても可能な限り考え尽くしているので、たいていの場合はすぐにリカバリーできるという確信も持てるようにしてきましたし、確信が持てないところは、その理由と共にあらかじめ明確にし、確信が持てるところまで持って行くにはどうすればよいかについて確信を持って伝えてきました。
　他にもっと良い代替案でもあれば別ですが、目の前にある「上手くいきそうなプラン」に従うのは普通の事と思います。
　そして恐らくは、その確信が影響して、安心感を持てる振る舞いになると言うことこともあるのではないかと思います。

「リーダーシップがない」って？

　ニュースを見ていると政治家、特に総理大臣の「リーダーシップがない」というコトバを良く耳にします。
　それでは、「リーダーシップとは何か」ですが、Wikipedia では「多くの人を一人の人に従わせる（その技術や才能）」とか、「統率」の事といったような説明になっています。
　この説明からすると、「リーダーシップがない」とは、「周囲の人たちに言うことを聞かせられない」とか「統率ができない」ということであって、「リーダーシップ」そのものには、具体的な実現方法についての意味はなさそうです。

　ですから「リーダーシップがない」と言った場合に、具体的に何かのスキルがヘタだとか、知識を持っていないといったような事を指しているのではないということになります。
　実際の使われ方を見ても、漠然と「あいつは能力がない」と明確な根拠もなく他人を攻めたい時に使われているように感じます。
　そして「リーダーシップがない」という批判に、「たしかにリーダーシップが発揮できそう」「そのままやってみたらいいかも」と感じる様な、具体的な代替案やロジックがセットで提示されているのを見たことはありません。

　そういった攻められ方にあなたのお子さんが将来さらされるとしたらどうでしょうか？

　あなたがお子さんに「よりよく生きて欲しい」と考えたときに、この漠然とした攻められ方にさらされる可能性に対して何らかの回答を提示するべきなのではないでしょうか？

　日本人は世界的に見て、極めて高いポテンシャルを持っているようです。「読み書きソロバン」と昔よく耳にしましたが、高いリテラシー、きまじめさ、辛抱強さ、きめ細かさなど、様々な長所を持ち合わせています。
　ところが、リーダーシップやマネジメント力などについてはなぜかピンポイント的に腰砕けになってしまうという不思議な一面があります。
「子供に【早く】伝えたいマネジメント力」では、その要因などを（好き勝手に）考察しながら、この時代の閉塞感を打破していくために、今の大人達がまずどのように変わり、子供達に伝えていくにはどうすればよいかについて、（これまた勝手に）考え、書き並べてみようと思います。

激しい変化の時代に必要なのは、最初から上手く行く方法をゼロから作り出せること

　終身雇用が普通で、何かゆったりとしていた時代と違って、グローバル化の波の中、少し前までは考えもしなかったような事が短期間の間にいくつも起こっています。

　人生は変化の連続です。「変化が人生」です。
　組織も組織を構成する一人ひとりの個人も、変化の後から対応していくのではなく、いかに周囲の環境の変化を見極めて、どれだけ先回りして変化していくかと言うことが、生きていく上でとても重要になっています。

　変化に気づくためには日頃からの情報収集が重要です。

　現状を詳細に理解していなければ、最初は小さい「変化の兆候」に気づけない事になります。

　次には「どのように変化すればよいのか、そしてそのためのプロセスを自ら導き出せる」必要があります。

それは「前例がない中で『変化のプロセス』を創造する能力」です。

　さらに「変化に伴う大きな苦痛や、苦痛に追い打ちをかける様な一時的な効率低下に立ち向かっていける勇気」も必要になります。

　しかし、その勇気は「変化のプロセス」に確信を持つことができれば、自然に生まれてくると思っています。

　「できる」という見通しさえ立てば、自ずとモチベーションは高まります。

　「結局の所、やる気になるかどうかが才能」であるとすれば、「プロセスを創造することができること」は、子供達のあらゆる才能につながる可能性があるかも知れません。

　高度成長期の成功体験から抜け出せず、元々、大きな閉塞感の中にあった日本は、グローバル化の波の中、リーマンショック、そして大震災にみまわれ、もはや変わる事ができなければ明日がない、まさに崖っぷちの状況に陥ってしまいました。
　これまでの「税金の無駄遣いと言われながらも、その非効率さによって実現できていた広く国民へ向けた利益の再分配」とでも言うような島国ならではのしくみはずっと前に限界に来ていて、とうとう余力分もなくなってしまったようです。

　今、日本はプロジェクトマネジメントを必要としています。
　復興、そして日本再生へ向けて、様々な業界、業種で「ひとつひとつがWin-Winであり、かつ、最大効率を目指した思考力、実行力を実現し、積み重ねていかなければならない」状況にあります。
　子供達に先送りせず、今の大人達が責任をもってWin-Winの実現を重ねて行かなければならないと思う日々です。

なるべくコンサルタントを排除する！？

　プロジェクトマネジメントのプロフェッショナルとして、某公共団体のＣＩＯ補佐業務に関わる中で、ＩＴ調達に発注側（地方公共団体）のコンサルタントとして関与しています。

　コンサルタントの立場で関与していて初めて発言できるのですが、作る側として、過去発注側のコンサルタントをとてもジャマに感じていました（笑）。

　そんな経緯があって、正直、居心地が良いとはとても言えません。

　この業界に入りたての頃は全く思っていませんでしたが、様々な経験を経た現在では「そもそも実際にヘビーな開発そのものを現場の末端の立場で行った事がない人のそれらしい発言ほどやっかいなことはない」と思うようになってしまいました。

　これはコンサルタントという、いかにも能力が高そうな職業に対して、個人的に元々持っていた憧れと共に、期待が大きすぎていたことも悪く影響していると思います。

　いつしかコンサルタントら、実際に作るのではない人々の発言による、作る事に対して本質的にムダな事をいかに行わないようにして、開発プロジェクトのそもそもの目的や、個々のプロセスの品質に集中できるようにするか、ということがプロジェクト成功の為の重要な要素と思うようになっていました。

　公共団体、官庁等の調達は、上流工程と下流工程（上流と下流という呼び方自体に極めて強い違和感を覚えています）を別々の企業に 発注「しなければならない」ということになっているらしいのですが、それ自体がとても大きな国家レベルの損失を生み出していると思っています。

「全て」上流工程を行った者の責任とする

　というのも、業務分析などを直に行って、ユーザー側などといろいろと話しながら組み上げていったイメージや考え方を、その構築過程の多くを抜きにした結果としてのドキュメントなどで（例えばＲＦＰとか）、伝えきれるとは全く思えないのです。

　そして、説明能力の方を問わずに「聞く側が理解出来なければだめ」「理解出来ない[下の者］が悪い」という旧来の日本的な文化の中、「ＲＦＰがあるのに、それを読んで解らない方がわるい」と現実なりがちなのを極めて心外に思っています。

　「多くの場合、上位マネジメントから実作業者に説明しきれていない」とか、「ＲＦＰの品質そのものに問題がある」などのような議論を耳にすることは、なかなかありません。

　あるべき姿の実現を考えるのであれば、例えば業務システムを考えた場合には画面上の外見は全て詳細に定義して、後は機械的に作るだけという次元にするべきでしょう（ほとんどの上流工程実施者が、現実、ここまでできていませんし、やりかたをわからないと思います）。

　そして、できあがったモノが「使えない」のは、「ほぼ全て上流工程の企業の責任」となるＩＴ調達の進め方を実現出来ているべきです。

　この仕組みの上でさらに「上流工程の丸投げ」をしないで、現在、上流工程を受注している人々が経験を積んで行くようになれば、随分と日本のＩＴ業界の競争力も高まるのではないでしょうか？

　個人的に行ってきた私の進め方は、全て上流工程と設計活動（運用設計含む）を主体的に行った私、私の会社が全て責任を負うという考え方でした。

　「上流工程を行った者が（ほぼ全ての）責任を持つ」という意識だったからプロジェクト全体が成功できたのだと思っています。

　「実際に使えるモノ、運用にキチンと乗るモノ、を作るプロジェクト」なのですから...。

　建築業界のように強度計算、構造計算など、基準を明確に特定でき、第３者による監査もしやすく、できあがるものも確実に目に見えるものなのであれば、上流工程の成果物を確実に評価でき、確かに上流下流分離発注もあり得ますが、ソフトウェア開発においては、全く期待できません。

　作ろうとしているモノの特性を理解していない結果として、具現化が現実的ではない上流工程の成果物（要は使えない成果物）が大金を用いて生み出され、下流工程の少ない予算の中、「上流工程のやり直し＋本来の下流工程」が行われていると言う「関係者の中では半ば常識化した認識」が存在しているらしいのです（そしてそれを解っていながら、なかなか変えられない）。

　しばらくの間、現在行っている「ＣＩＯ補佐業務」、「業務システム開発プロジェクト診断業務」などを進める中で思うところを書いてみます。

　随分前になりますが、ある会社で営業的な仕事をしていた頃（本来はＭａｃ関係の修理でした）、ある県立大学の教授をされているお客様から、入札参加の要請をいただきました。

　具体的には、Sun と Domain の両方のワークステーションから Canonのレーザープリンターに印刷がしたいとのことでした。

　どちらかは失念してしまったのですが、調べてみると、一方はCanonプリンタ向けのドライバが存在しないとのことで、入札という行為そのものについてよくわからないながらも、それなりに必要なもの（プリンタ関連のプログラミングマニュアルなどの資料。研究室なので開発可能という考え）も含めて、見積りを作成し、新幹線に乗って入札に行きました。

　残念ながら入札には落ちてしまったのですが、その時「プリンタドライバが存在しない」事について、依頼主の教授にお伝えして耳にしたのが「何かが足らなくても、とにかく安い金額で通ってしまえば、その後、なんだかんだと膨らまされるし、結局は地元がとるんだよね」といったような事でした（本当にそうなのかは知りませんが...）。

　その時、話を聞いて、当時少し前のニュースであった「１円入札」を思い出しました。「なるほど、そう言う事か...」と。

　だからというわけでもなく、ただ機会がなかっただけなのですが、以来、入札に参加はしたことはありません。

　公共団体の入札とか購買といった活動に、最初に疑問を持った出来事でした。

　「１円入札」は今になって考えると、とても不愉快な話ですね。
　「何の為に」という考え方がすっかり抜け落ちているということが明白です。

　税金を使って発注を行う者として「評価をする（確かに難しい事ではあるのですが）」という事、その姿勢は一切考えないという意志表示に思えます。丸投げのつもりなのがハッキリと出ているように感じます（この値段でやれるって言うんだから、それでイイ）。

　業者側が組織としての体力など、自分たちの強みを活用するのは当然と言われればそれまでですが、元々そう言う事のために入札はあるのでしょうか？　それで調達は良くなったのでしょうか？

　現在はさすがに「１円入札」はないと思いますが、ではどれほど良くなっているのか、疑問は多くあります（ＲＦＰなどについての思うところはまた後日）。

　デミングの「品質コストは８５％がトップの直接の責任」が実際その通りである場合が多いことを考えると、政府の調達がもう少しあるべき姿を目指していれば、現在の日本のＩＴ業界の３Ｋ、７Ｋ状況は、大きく違ったものになっていたのではないかと思います。

　これから私自身、発注側として公共団体の調達に関わる事になりそうなのですが、後悔しないようにしたいと思います（そうすると、これまでのように無力感に襲われた挙げ句、抜けざるを得なくなるかもしれませんが...）。

久しぶりの投稿で恐縮です。
この２ヶ月半というもの、平日はほとんど関西にいます。

　当初は今年から始めた、プロジェクト診断サービスの一環で、「火噴きプロジェクトを少し見てみる」ということでした。

　実際に行ってみて驚いたのですが、よく見るとプロジェクトの目的とは全く逆の結果を生む状況で開発が進められていたのです。
　想定のアーキテクチャはほぼそのまま実現しているのですが、ほんのチョットした違いで、そのアーキテクチャによって生み出したかった結果とは全く逆の結果を生み出す活動になっていました。

　機会があれば詳細はお伝えできるようになると思いますが、いずれにしても上記の指摘をさせていただいた結果、プロジェクトは数ヶ月後の納期を待たず、すぐに中止となり、裁判となる方向なので、ここで詳細は書きません。

　本当に短期間でしたが、目に入った問題点を挙げると、「元請けプロジェクト・マネジャーと下請けとの間で［そもそも何の為のプロジェクトなのか？］という意志疎通ができていない」「ユーザーの業務、現場を誰一人しっかりと見ていない」つまり「成功の定義を明確にしていない（よくある［いままでと同じ］。しかし、どうだったらいままでと同じなのかは不明確のまま）」という、極めて単純かつ初歩的なことでした。「プロジェクトマネジメント不在」が原因です。

　折角の仕事が半月もしないうちになくなるところだったのですが、そこはＩＴ業界らしく、なし崩し的にＣＩＯ補佐業務で２ヶ月を超えるホテル暮らしがつづいています。
　ホテルもさすがにしんどくなってきたのですが、あと数ヶ月はつづきそうです...

７月１日、２日と、「SEのための業務分析」という研修を行いました。
これは、あるIT上場企業で４年ほど続けさせていただいているものです。

　ひとことで言うと、「現場に行ってもいないのに、あるいは顧客業務をチラっとしか見ていないのに、何か与えられた文書だけ見て、DFDやらかんやら、見栄えばっかりいいものを作るんじゃぁねぇぞ」「たとえば、税金使う官庁の仕事とかで、しっかりとした動くシステムを作らずに、結局誰も真剣にレビューしない、カサ上げだけの文書ばかりつくりやがったら、タダじゃおかねぇぞ」ということをニッコリ笑顔でお伝えしているヘンな研修です。ムカつく受講生も多いかも知れませんｗ。

　内容的には、「やさしい」「初心者向け」になると思います。
　しかし、ここでお伝えしている内容を本当に実現する事は経験上、至難の技でした。
そしてその事実こそが、多くの業務システム開発プロジェクトが成功しないと言われている要因だと思っています。

　多くの人々が、「内容の理解の簡単さ」と「その理解の実現度」に大きな乖離があることから目を背けている様に見えます。私はいくつかの業界、業種を経験しましたが、IT業界は特にそういう印象が強いです。
　そして頭で理解できている自分を「（実際にも）出来ている」「上位」だと思っている。学校ではほぼそうなりますが（理解＝出来ている）、実際のモノ作りでは違います。
　それは、楽器と音楽理論をおおよそ知識として知っていたとしても、いきなり生バンドに入ってアドリブ演奏などをすることはできないのに似ています。それどころか、適切なタイミングで適切な音をひとつ、鳴らすことすらできなかったりするものです。

　そんな訳で、元々自分たちの業務システム開発という仕事そのものも、たいして業務分析できていないかもしれないという事実なども含め、一定以上の強い意思を持って、効果的な現場見学やヒアリングなどの実現を目指せるように、業務分析のあるべき姿をよく考え、実現することがどれほど大切かということを、私なりにお伝えしています。

　その意味では、業務システム開発開発プロジェクトを長期に渡って行なってきてはいるが、「ひとりプロジェクト」や「何から何まで上手くいくプロジェクト」を経験したことがなかったり、「仕様変更は当たり前」などと考えている、ほとんどの業務システム開発の業界の人々が対象の「やさしい（しかし、実現は極めて難しい）」「ベテラン向け」研修とも思っています。
　研修というよりは、少し立ち止まって自分達の仕事を良く思い起こしてみる時間になれば、という感じですが、一応、技法というほどではない、実現のための細かなヒントはお伝えしているつもりです。

昨日、ある会社を訪問したあと、比較的近くにあった、アップルストア渋谷店に行ってみました。
４月に ebay を通じて入手した iPad Wi-Fi 64G に続き、２枚目？として、３G 64G を予約するためです。

これで３回目の予約です。
これまで、なんだかんだと２回ともダメでした。「アップル、嫌いになりそう」とか「銀座店とは、きっと相性が悪いんだ」などと考えながら、渋谷店に向かったのです。

ちょうど昨日は iPhone 4 の予約開始日でしたので、うまくすれば iPhone 4 の予約も一緒にと思っていましたが、予想どおり、 iPhone 4 の予約は長蛇の列。 iPad 3G の予約のみとしました。

平成元年に、渋谷にある Macintosh 専門店の店員として働いていた時期があります。
当時 Mac は、一通り揃えるにはどうしても１００万円を超える、マニア向けの商品と言ってもいい時代でした。
ですから、まさか当時の勤務先の近くにアップルストアなるものが開店し、しかも、コンピューター・オタクとは全く縁がなさそうな、オシャレな若者たちがアップル製品の「予約」に長蛇の列で並ぶ様になるとは、流石にカケラも想像しませんでした。

　私は、Mac用の知的生産ソフトウェアを使っていく中でそれらの開発者と会話を重ね、プロジェクトマネジメントを学んだ、という感触があります。
「WBS」は、アウトライン・プロセッサの「MORE」（開発元は「Living Video Text 社」この社名も好き）。
「プロジェクト・ネットワーク図」を実際に初めて作ったのは、丁度、iPad の iBooks と同じように、Macintosh 発売と同時に発売された、「Mac Project」でした。

　私にとって、プロジェクトマネジメントは、どこかアップルらしさを仕事の中で感じる手段でもあったと思っていて、今回勝手に自称「 ジョブズ チルドレン（Jobs's children） 」とさせていただきます。

　アップルストア前に並んでいる彼らの多くが、Steve Jobs のプロダクトを通じて、これから様々な事を学んで行くんだろうなと思うと、何となく嬉しくて、ニヤニヤしてしまいます。

でも、彼等はもう年代的には「ジョブズ の孫たち（ Jobs's grandchildren ）」かも知れませんね。