プロジェクトマネジメント データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > カテゴリー - プロジェクトマネジメント

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

パフォーマンス改善の際に困ること

プロジェクトにパフォーマンス改善で参画する際、ユーザーから指示されて困ること(特にSIerにとって困ること)があります。それは、「完璧にチューニングすること」という指示です。このとおりに言われることもありますが、大抵は、別の表現の形をとります。たとえば「全てのSQLの実行計画は最適になっているんだよね」とか、「網羅的にSQLをチューニングしてね」とか、「途方もない性能目標(超短いレスポンス)を達成できず、チューニングしてもチューニングしても終わらない」とか、「性能目標を決めていないのだから、ユーザーからの体感が遅い限り、チューニングが繰り返され、終わらない」とか、「新システムでは、現行システム以上の性能になるんだよね。(暗に全SQLと言っている)」という形があります。

●ルダバガの法則

ワインバーグの「コンサルタントの秘密」のP15に次のような記述があります。
食品売り場で、品物の置き場所が無く、場所を確保する(チューニングする)という話です。そのとき、若いワインバーグさんは、『「ルダバガ」という野菜が売れていないので、それをどかしましょう』と提案します。その提案は受け入れられ、良い気分になったワインバーグさんは、店員に「で、一番人気のない野菜は今度はなんだね」と言われるという話です。

本の中では、「第一番の問題を取り除くと、第二番が昇格する」という主旨で紹介されていますが、プロジェクトのチューニングにおいては、「それをやってはいけない(続けちゃいけない)」と思います。

●プロジェクトでは

「第一番の問題を取り除くと、第二番が昇格する」を繰り返したら、無限ループです。「期間と予算が決まっていて、目標を達成したら解散する」、収益を出すべきプロジェクトのチューニングでこれをやったら、期間はオーバーするし、経費は膨れるし、いいことありません。ROIが悪いと思うのです。
やはり、利益と収入のバランスを考えると、目標を決めて切り上げるのが正解だと思います。

●日本が得意な”改善”って?

でも、「改善を繰り返すのが日本の製造業の強みじゃないか。何が違うのだろう?」と思いました。これは、一度か、繰り返されるのか、の違いがあると思います。工場の現場では、生産は繰り返されます。つまり、改善をすれば、するだけ、将来の効果が大きくでてきます。そのため、改善すればするだけ、ROIのRはどんどん増えて行きます。
ITの世界でも、組織として「品質管理」や「運用」など、改善がぴったりしている業務は多々あります。

そういえば、「プロジェクト」って、定義からして「一度だけ」ですからね。

●まとめ

プロジェクト型では、目標を決めましょう。そして、きりのない作業は、目標を達成したら、終わりにしましょう。
スポンサーサイト

「時間」はひどいプロジェクトマネージャー

数回前に、デマルコの「アドレナリンジャンキー」について触れましたが、
今回もそのアドレナリンジャンキーからの内容です。

「[時間]に切り札を奪われる」というアンチパターンが載っています。
サブタイトルは「[時間]はひどいプロジェクトマネジャーである」です。

どんな良い手でも、直前になると手遅れになる、そういう話が書いてあります。現実には、早い段階では思い切った手を打たせてもらえないことが多いと思いますが、時間が経つにつれて、良い手の効果は薄れていきます。そういう意味で時間は”ひどい(悪い方の)”マネージャとも言えます。

普通、時間はあればあるだけ、無駄に使ってしまうのが人情というものだと思います。時間があれば、有休を取るでしょうし、定時に帰るし、ゆっくり検討することもできます。本ブログでも昔紹介した CCPM(クリティカルチェーンプロジェクトマネジメント)で私が好きな点は、この時間を有効に使う(マネージする)方法が紹介されていることです。興味のある人は読んでみてください。

そう言えば、CCPMの伝道師である、岸良さんが1月11日の朝日新聞の1ページ丸々使った記事になっていました。主に公共工事の改革として載っています。日本の未来のためにも、この調子でさらにうまく行くといいですね!

デスマーチプロジェクトでやってはいけないこと

「何とかするように」と命を受けてデスマーチプロジェクトに参加するPMやPMO、リーダーがいるかと思います。そのような人がやりたくなるのが「やり方を変えること」だと思います。

デスマーチをさらに酷くする落とし穴として、実は「やり方(開発手法やプロジェクト管理手法やツール)を変える」ことがあります。最近、デスマーチの第2版を読んでいて、ほぼ同じ記述があったので、昔の経験と合わせてちょっと書いてみます。

デスマーチになっている以上、何かが悪いと思うのが人情です。でも、新たな何かを覚えたり、やり直しする時間は無いですよね。既に悪い状況下で、うまく回るようにするには、全員が合意するシンプルな方法を使うこと、課題をきちんと管理すること、誰かが軸となることだと思います。つまり、詰まっているところを流してあげることだと思います。

昔、PMOとしてデスマーチと呼ばれるプロジェクトに入ったとき、「プロジェクトマネジメントのガイドラインを揃えるのだ!」と新たな負荷を増やそうとしていた人がいましたが、逆効果ですよね(でしたね)。現場はそんなきれいなものを求めているわけではなく、混沌としていても効果がある方法、つまりシンプルな方法、うまく流れる方法を求めていると感じました。ある人が言っていたのですが、「途中から入るのであれば、課題管理をきちんとやること」と言っていました。私もやってみて思ったのは、「課題管理さえきちんとやれば、周りがついてくる」です(多少は出来たはずと信じてます)。誰かがきちんと軸となって、指示を出して、周りがついてくるようになれば、それで良いと思うのです。

結局は、余計な重荷は増やさず、周りの力を生かすことなんだと思います。デスマーチに途中から参加することになったら参考にしてもらえればと思います。つい、何かが悪いと思ったり、何かを変えたくなったりするものなので。

P.S. 当然、スコープ(範囲)を減らすことは王道ですよね。

「軸となる人」それと「ぶれない方針」

仕事やプロジェクトがうまく回らないとき、どう思いますか。それほど多くのプロジェクトを見てきたわけではありませんが、結局、「軸となる人」が必要なのだと思います

「この人に調整を頼む。その代り、私たちはその人の決定についていく」、そういう軸がないとプロジェクトって効率よく回りませんよね。そして、そのような人が出す「ぶれない方針」がどれだけ、現場の効率をアップさせるか、それをいくつか見てきました。

ある人が”軸”となるだけでは、その人が調整するまで現場は動きません。しかし、「ぶれない方針」があると、末端の人たちも、その方針に従って、自分たちで判断することができるのです。でも、これが朝令暮改の方針だったりすると大変です。「その方針についていくことが意味無いじゃん」と思って、現場が軽視してしまい、動かなかったりします(これはよくみられます)。

100点の詳細設計を時間をかけて作るのではなく、方針を出して進めればいいんだと思います。そして、できれば「方針だけはぶれないよう」にします。多少インプリやテストが大変でもぶれない。大きなプロジェクトになればなるほど、舵を切ってから船が動くまで(つまり末端メンバーが動くまで)時間がかかりますから。

PMの方には、「ぶれない方針」を出してもらえるとうれしいです。「ぶれない方針を出す”覚悟”」が必要のようです。僕が見た範囲で、一流のPMはこの”覚悟”や”度胸”があったように思います。僕はプロジェクトは人間修業だと思ってます。僕も精進します。はい。

「あれもこれも」と要望したり、「全員一致による責任回避」の文化

今回はちょっと変わったユーザー側プロマネ話です。これをしょうがないと思うか、他山の石にするか、なっとらん!と怒るか、へぇーと思うかは人によるかと思います。

「責任をとるのを極端に避ける」という文化により、帳票や画面が膨れ上がるお客様が居ます。責任を避ける=「要るかもしれないものは全部作る」になってしまうケースです。これが、担当者がどんどん異動するような組織だと最悪です。システムは引き継がれても、経緯までは引き継がれないため、良く分からないけど、既存の画面や帳票は残しておいて、さらにこんなのも・・・となりがちです。その結果、誰も使わない帳票が何百も・・・そしてSIerの追加開発(有償)は毎年続く・・・のだとか。
以上、守りに入りがちな一部公共系で聞いた話でした。

ある組合系組織において、「全員一致」が原則のシステム開発という話も聞いたことがあります。
「仕様を決めてください」と言って、SIerが迫っても「まだ全員が一致しない。だから待って」と言って決めない。そして数か月が過ぎる。SIerはお金をもらえるけど、システムはできない。じゃあ、ユーザー側が責任を問われるかというと、そこが「全員一致」の良いところ(!?)、誰も責任をとらされないのだそうです
#こういう文化の組織もあるんですね。

皆さんの周りにも変わった文化の組織があったりしませんか? 意外と、皆さんの会社の文化は世の中ではマイナーだったりするかもしれません!?
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。