まとめるとは？/ マイワン
[ 1397] プロジェクトマネジメントスキル 実践養成講座（1）
[引用サイト] http://jibun.atmarkit.co.jp/lskill01/rensai/pm01/pm01.html
|
エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント（PM）のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。 そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェクトマネージャを目指す方はもちろん、すでにプロジェクトマネージャとして活躍されている方にも、「知識」としてではなく現場で使える「スキル」を磨くうえで役立てていただければ幸いである。 プロジェクトマネージャとは、何をする人だろうか。あなたの身近にいるプロジェクトマネージャを、ちょっと想像してみてほしい。 一般に「プロジェクト」とは、何らかの目的の達成を目指して、一定期間に行われる活動のことをいう。目的の大小や期間の長短は関係ない。会計システムの導入も、Webページの制作も、プロジェクトという意味では同じである。仕事に限らず、受験や就職、結婚や出産といった人生のイベントすべてがプロジェクトであるという人もいる。そういう意味では、あなたはすでに何らかのプロジェクトを手掛けた経験を持っているはずだ。あなたの身近にいるプロジェクトマネージャは、あなたよりほんの少し複雑で、ほんの少しリスクの高いプロジェクトを手掛けているにすぎない。 では、その人は普段どんな仕事をしているだろうか。プロジェクトの進ちょくの管理、顧客やユーザーとの折衝、人件費や費用の管理、要員の確保と配置、関係者への報告……。数え上げればきりがないほど、種々雑多な仕事が思い浮かんでくるに違いない。 プロジェクトには目的があり、期限があるという点で、決まった作業を繰り返す「ルーチンワーク」とは異なる。中には、期間が数年にわたるような長期のプロジェクトもあるだろう。そういったプロジェクトの中にいると、ルーチンワークをこなしているような感覚に陥ってしまうことがあるかもしれない。しかし、あなたの気付かない間にも、プロジェクトの状況は刻々と変化している。期限に向かって、1日1日が費やされているのである。こうした中で、プロジェクトマネージャはプロジェクトを成功に導くために、「必要なことすべて」を行うのである。 しかし、「必要なことすべて」を思いつくまま漫然とやっていては、労力も無駄だし、抜けや漏れが生じる。「必要なこと」をやらなかったばかりに、後になって「本来やらなくてもよかったこと」までやる羽目になってしまうこともある。そこで本稿では、プロジェクトマネージャがプロジェクトを成功に導くためにやるべき「必要なこと」に焦点を当て、ケーススタディ方式で紹介していくことにしよう。 例えば、あなたがあるプロジェクトに参画することになったとしよう。その初日に、マネージャからプロジェクトのオリエンテーションがあるということで、あなたは打ち合わせに出席することになった。さて、ここでタイプの異なる2人のマネージャが登場する。 さて、あなたは矢見雲マネージャのプロジェクトと、出来杉マネージャのプロジェクト、どちらに参加したいだろうか。 いきなりプロジェクトに投げ込まれ、右も左も分からないような状態に陥ることを望む人はいないだろう。やる気が起きるわけがない。プロジェクトにメンバーを新規で配属する際には、できるだけ明確にプロジェクトの重要事項、すなわち目的と期限、リスクと期待役割について説明しておくべきだ。 重要なのは、この動機づけをプロジェクト全体で一貫した形で行い、使命感を共有することだ。こうすることによって、細かい指示を与えなくても各自が状況に応じて適切に判断を下せるようになる。大きなプロジェクトであれば、新人向けの説明資料をひとまとめにしておくとよいだろう。プロジェクト開始時の企画書や提案書、計画書などを抜粋して、バインダーに綴じるなり、ファイルサーバの所定の場所に置くだけでよい。これだけの作業と、ちょっとした配慮だけで、新規にプロジェクトに参加するメンバーの不安を解消し、同じ方向に気持ちを向けさせることができる。 プロジェクトによっては、最初からスコープが流動的だったり、スケジュールが確定していなかったりすることがある。筆者の経験上、そのような場合は包み隠さず情報を公開した方がよい結果を生むことが多い。「ここまでは決まっているが、ここから先は決まっていない。最悪の場合、こういう事態に発展するケースが考えられる」というように、メンバーとリスクを共有して初めて、プロジェクトに一体感が生まれるのではないだろうか。 ちなみに、スカイライトコンサルティングでは、プロジェクトマネージャは新規のメンバーに対してプロジェクトの内容を説明することが義務付けられている。説明すべき事項が記載されたチェックリストは社員にも開示されているので、詳細に知りたいと思ったら、進んで説明を求めることができるようになっている。 さて、オリエンテーションも終わり、あなたはいよいよプロジェクトメンバーとして作業を開始したとしよう。しかし、これまでの経験とは異なり、プロジェクトの進め方やコミュニケーションなど、勝手が違うことに戸惑いを覚えてしまった。周りのメンバーも同じように感じているようだ。そこで、あなたはマネージャに相談することにした。 「そこで作業の進め方やコミュニケーションについての案を私から説明するので、みんなからも意見があればそこで出してもらって、このプロジェクトのやり方を決めよう」 いくら優秀なメンバーが入り、適切に動機付けされたといっても、日々の具体的な作業がどのように進められていくかが決まっていなければ、足並みはそろわない。結果としてチームのパフォーマンスを引き出すことはできない。 プロジェクトマネージャは、個人の持っているパフォーマンスを、チームとして最大限に引き出すことができるよう、「円滑に連携」させる仕掛けをつくる必要がある。それが、「キックオフミーティング」に代表される、チームビルディングのためのイベントである。 キックオフミーティングでは、前項で取り上げたプロジェクトの重要事項の説明をさらに詳しく行うとともに、次のようなトピックについて説明しよう。 これによって日々の作業をどう進めていくか、ほかのメンバーとどのように協調すべきなのかが明確になる。特に会議体については、顧客や協力会社など、外部メンバーとの重要な接点であると同時に、何らかの意思決定の場でもあり、大変重要です。プロジェクト計画時にきちんと定義しておくべきであることはいうまでもないが、運営面で形骸化してしまわないよう、キックオフミーティングの場などでその位置付けを再確認し、メンバーの理解を高めておく必要がある。 さらに、出来杉マネージャが最後に「歓迎会」の開催を提案していたように、プロジェクトマネージャは次のような点にも配慮すべきだろう。 一見、仕事には直接関係ないことのようにも思えるが、プロジェクトの初期段階でメンバー同士がお互いに打ち解けた関係になっておくことは、非常に重要だ。欧米では、プロジェクトに限らずセミナーやワークショップなどでも「アイスブレーキング」といって簡単なゲームをやってリラックスした雰囲気を短時間で作ってしまうことが多い。日本では酒席をもうけることが一般的だが、やり方に関係なく共通しているのは、「お互いを知り仲よくなる」ことではないだろうか。それによって相手を気遣い、円満にコミュニケーションをしていく素地が出来上がる。 最後にもう一点、メンバーとのコミュニケーションは双方向でなければならない。プロジェクトマネージャは、自分のやり方を一方的に押し付けるのではなく、メンバーから意見を吸い上げる姿勢を持つことが大事である。これは、何もメンバーの意見すべてを尊重しろといっているのではなく、「現場に問題が生じたときに、速やかに情報を吸い上げる」環境をつくることが大事だということだ。 よく、食事時などにプロジェクトや上司の陰口をたたくような光景が見らることがあるが、これはあまり褒められたことではない。そういう場合は、得てしてプロジェクト内のコミュニケーションがうまくいっていない。メンバーが現場の問題や不満を抱え込まずに、素直に相談できる環境をつくることによって、初めてプロジェクトのリスクをコントロールできるようになるといえる。 あなたがプロジェクトについてから1カ月が経過した。プロジェクトにも慣れ、忙しい日が続いている。しかし、作業を進めるにつれ、チーム内では仕様に関する課題が目立ってきて、遅れが出てきた。そんなある日のチームミーティングで……。 実際にプロジェクトが進んでいくと、目的を達成するまでの道のりは決して平たんではなく、さまざまな阻害要因が発生する。プロジェクトマネージャは、これらの阻害要因を取り除きゴールへ導くことが求められる。これらの阻害要因は、PMBOKの定義に合わせると、以下の要素（エリア）に分類される。 次回以降は、これらの各エリアに対して、実際のプロジェクトに見られるシチュエーションとPMBOKなどが書かれているPM上のテクニックを織り交ぜながら解説していきたいと思う。 スカイライトコンサルティング シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。 ＠IT自分戦略研究所トップ｜スキル創造研究室トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 1398] スタイルシートを分けて管理する方法をまとめる - 2xup.org
[引用サイト] http://2xup.org/log/2006/10/17-2115
|
スタイルシートを書く時のガイドラインでは、セットフォーマットルールや、プロパティの出現順序についてまとめました。そちらで用意したガイドラインだけでも、簡単な管理は可能なのですが、現在、2xup のリニューアルを進めていて、ちょうど各々用意した CSS の分割をどのように整えていこうかと考えていました。今回はそのリニューアル作業の一環として、サイトで管理する CSS ファイルをどのように分けるか、現状の考えをメモすることにしてみました。リニューアルをきっかけにまとめましたが、この方法はスタイルを適用する HTML がどんなものか。また、目的によってファイルの数は若干変化する可能性はありますが、この分け方や構成は様々なサイトで流用できるのではないかと考えています。 スタイルシートを分けて管理する理由というのは、人それぞれだと思いますが、ほとんどの方があてはまるのが管理効率の向上ではないでしょうか。例えば、フォントの指定に関する CSS ファイルの場合、ファイルを別にしておくと後でフォントの指定を変更したい場合、長い CSS ファイルからどこに対象のセレクタがあるのか、ぐりぐりスクロールして探したりしなくても、フォントの指定のみを行っている CSS ファイルを編集すれば良いわけです。また、リニューアルなどに伴い、大きくフォントの指定を変更したい場合は、いくつか指定パターンの違うフォント用 CSS ファイルを用意しておけば、そのファイルを入れ替えるだけで変更することができます。 それだけではなく、作成したいウェブサイトの仕様にあわせて分けたスタイルシートを選択し、合体ロボットのように組み合わせれば、ウェブサイト構築のほとんどの作業ステップをスキップできるということも実現できますね。つまり、自分用スタイルシートライブラリを作成するような感じでしょうか。組み合わせ方法によっては、様々な用途に向けたスタイルシートファイルの作成が可能になりますね。 リニューアル中の 2xup を例に、スタイルシートをどのように分けているか実際にまとめてみます。ディレクトリ構造なども明示しておきますが、実際には変更になるかもしれません。 テーマごとディレクトリに含まれるデザインに関するスタイルシートや、そのテーマで利用される画像を格納するディレクトリを含むディレクトリ。基本的にデザインのリニューアルはこのディレクトリ内のみで完了する。 ブラウザによって微妙な違いのある、各要素のデフォルトスタイルの差異を無くすとともに、再定義する CSS ファイル。僕自身が CSS でデザインを初めて以来、足したり引いたりしており現在に至。通称ぬかみそ けっこう多く見えますが、実際にサイトを構成する際に選択する CSS ファイルは、最低5個で可能なので、問題ナッスウィング? しかも個人サイトの利用なのに、こんなに管理面を重視せんでも！という声も聞こえてきそうですが、こうして効率化を計るのもスタイルシートを理解する良い勉強になるはずだ！と自分を催眠にかけてやってみます。 うまく CSS ファイルを分けることができても、それをどう HTML に反映させるか。うまく読み込ませないとリニューアル時に設定した目的 (こちらはリニューアル後にでも詳細を) が達成できない可能性だってあります。今回の場合は以下のようにしました。 これらのスタイルシート (themeディレクトリはのぞくかもしれません) と、このスタイルを適用する基本 XHTML ファイルは、共有しようと考えています。共有することで、スタイルシートを書く時のガイドラインの時のように、たくさんの方からのフィードバックを得られて知識を深めることができるかもしれないし、誰かがこれを元に効率よくサイトを構築・管理できるきっかけになるかもしれませんね。こうした共有はいくつもハックを知るよりもきっと得るものが多いのではないかと考えています。また、今回から subversion によるバーション管理もおこなっているので、簡単に最新版や少し前のバージョンのものが手に入るようにしようと考えています。 ボクも以前より一つのHTMLをもとに、ユーザが複数のレイアウトCSSを選んで切り替えられるサイトをつくりたいと思っていました！ 比較的、柔軟に使えるようにファイル構成を考えたのですが、これだとファイル数が多くなってしまうのが少し難点です。でも、モジュール・フレームワーク化しておくと再利用が便利ですね。 最近は、便利だけど無駄な規則集合が増えてしまうので、最終的に必要な箇所を抜き出して再構成してしまうのが良いかな、と思ってます。 私もファイルの数はやはりずっと課題となりそうです。修正項目へのアクセススピードを上げるには、やはりファイルの分割をどうやるかが大きなポイントになると思うのですが、それを意識しすぎてファイル数が多くなってしまう事を気にしています。 ぜひ、mixi という参加ユーザーしかみれない場所ではなく、ご自身のポートフォリオなどで共有してみるのも良いかもしれませんね。 kennsu さんのコーディングに関する考えも拝見しました。個人サイトではなかなか複数人での管理を実践できませんが、普段から意識していると良いですね。 デザイン気に入ってくださってありがとうございます。僕も今のデザインは嫌いでないので、すこし残してみたいとかんがえています。 |
マイワンのサイトです。
