わたしの計画の立て方 （２）
こんばんは、10の12乗です。
うちの会社は残業が当たり前のようです。
まだ新人の我々は残業代が出ないので、比較的早く返してくれますが、
家が遠い私は、家では食って寝るだけになってて、
社会人とはそういうものなのかなと思い始めています。
さて、計画の立て方ですが、私も、なんちゃってSEさんと同類のにおいが
しますので、語れないのですが、自分がどう物事に取り組むかを
書いていきます。試験系について書いていこうと思います。
基本的にはネットでまず合格者の方の体験談や参考書を調べます。
その後に、大まかな日程を組みます。
私の場合、がちがちに計画を組んでしまうとやる気が起きなかったりするので、
大まかに立てます。
具体的には、ものすごくゆとりのある日程を組みます。
この日までにここまで終わらせるという具合です。
そして試験に臨むわけですが、成功確立は半々です。
私の場合、怠け者の極みですので、まずは「やる」と言うことを
目標にやっていきます。
そして失敗したらそれを次に活かします。
多少の下地も出来ますし、挑戦し続けたりはしてます。
大概、絶対的勉強時間の不足の不足なんですがね（笑）
うちの会社は残業が当たり前のようです。
まだ新人の我々は残業代が出ないので、比較的早く返してくれますが、
家が遠い私は、家では食って寝るだけになってて、
社会人とはそういうものなのかなと思い始めています。
さて、計画の立て方ですが、私も、なんちゃってSEさんと同類のにおいが
しますので、語れないのですが、自分がどう物事に取り組むかを
書いていきます。試験系について書いていこうと思います。
基本的にはネットでまず合格者の方の体験談や参考書を調べます。
その後に、大まかな日程を組みます。
私の場合、がちがちに計画を組んでしまうとやる気が起きなかったりするので、
大まかに立てます。
具体的には、ものすごくゆとりのある日程を組みます。
この日までにここまで終わらせるという具合です。
そして試験に臨むわけですが、成功確立は半々です。
私の場合、怠け者の極みですので、まずは「やる」と言うことを
目標にやっていきます。
そして失敗したらそれを次に活かします。
多少の下地も出来ますし、挑戦し続けたりはしてます。
大概、絶対的勉強時間の不足の不足なんですがね（笑）
わたしの計画の立て方（１）
遅くなって申し訳ありません。
なんちゃってSEです。
前回の勉強会でプロジェクトマネジメントについて簡単に講義をしました。
その影響でしょうか、ブログのテーマがプロジェクトマネジメントに関係ありそうなものに。。。
ちなみにテキストはこれ↓を使いました。
「実務で役立つプロジェクトマネジメント」
（Curtis R. Cook著、翔泳社）
今回のテーマは「わたしの計画の立て方」です。
さて、困りましたね。。。
資格試験の勉強において、試験一週間前に慌てて詰め込みだすのがパターンとなっている私に、計画の立て方を語る権利などあるのでしょうか（笑）
うーん、手っ取り早く計画を作りたいなら、
BOSCARとWBSを作ればとりあえず骨組みはできると思います。
BOSCARとは、
Background（背景）…プロジェクトの背景。
Objective（目的）…プロジェクトの目的。
Scope（範囲）…プロジェクトの範囲。範囲外についても言及する。
Constraint（制約）…プロジェクト実行側が守る制約。期限、予算、リソースなど。
Assumption（前提）…プロジェクト依頼側が守ること。情報提供など。
Report（成果）…必要な成果物。
の頭文字をとったものです。
日経SYSTEMS 2008年1月号ではコミュニケーション・ツールとして紹介されていますが、
計画を立てる上でも役に立ちます。
上記を埋めれば、計画の基本部分はほぼできていることがわかると思います。
BOSCARができたら、それを元にしてWBS（Work Breakdown Structure）を作ります。
WBSは必要なタスクを洗い出し、各タスクを誰がやるのか、どの期間でやるのかを決めればいいです。
あとは、具体的にどのようにやっていくかを考えていけば計画が完成します。
では最後に簡単にBOSCARとWBSを作ってみます。
題材は「勉強会でのプロジェクトマネジメントの講習」にします（笑）
【BOSCAR】（※テキストとは「実務で役立つプロジェクトマネジメント」のことです。）
Background
勉強会でロジカルシンキング、マーケティング、プロジェクトマネジメントの勉強をすることになり、なんちゃってSEがプロジェクトマネジメントの講師をすることになった。
Objective
プロジェクトマネジメントを初めて学ぶ勉強会メンバーに、わかりやすい講習を提供する。
Scope
テキストに載っている項目が範囲。
テキストに載っていないやや高度な知識は範囲外。
Constraint
講習は5/30に行う。
講習の時間は45分。
Assumption
場所の確保はされている。
Report
講習、講習資料、講習概要書
【WBS】
タスク 担当 期間 成果物（あれば）
講習の概要を決める なんちゃってSE 5/24～5/24 講習概要書
情報収集をする なんちゃってSE 5/25～5/26 講習概要書
資料を作る なんちゃってSE 5/27～5/28 講習資料
本番想定練習をする なんちゃってSE 5/29～5/29
勉強会で講習をする なんちゃってSE 5/30～5/30
簡単に作ってみたので、突っ込みどころがあるかもしれません。。。
なんちゃってSEです。
前回の勉強会でプロジェクトマネジメントについて簡単に講義をしました。
その影響でしょうか、ブログのテーマがプロジェクトマネジメントに関係ありそうなものに。。。
ちなみにテキストはこれ↓を使いました。
「実務で役立つプロジェクトマネジメント」
（Curtis R. Cook著、翔泳社）
今回のテーマは「わたしの計画の立て方」です。
さて、困りましたね。。。
資格試験の勉強において、試験一週間前に慌てて詰め込みだすのがパターンとなっている私に、計画の立て方を語る権利などあるのでしょうか（笑）
うーん、手っ取り早く計画を作りたいなら、
BOSCARとWBSを作ればとりあえず骨組みはできると思います。
BOSCARとは、
Background（背景）…プロジェクトの背景。
Objective（目的）…プロジェクトの目的。
Scope（範囲）…プロジェクトの範囲。範囲外についても言及する。
Constraint（制約）…プロジェクト実行側が守る制約。期限、予算、リソースなど。
Assumption（前提）…プロジェクト依頼側が守ること。情報提供など。
Report（成果）…必要な成果物。
の頭文字をとったものです。
日経SYSTEMS 2008年1月号ではコミュニケーション・ツールとして紹介されていますが、
計画を立てる上でも役に立ちます。
上記を埋めれば、計画の基本部分はほぼできていることがわかると思います。
BOSCARができたら、それを元にしてWBS（Work Breakdown Structure）を作ります。
WBSは必要なタスクを洗い出し、各タスクを誰がやるのか、どの期間でやるのかを決めればいいです。
あとは、具体的にどのようにやっていくかを考えていけば計画が完成します。
では最後に簡単にBOSCARとWBSを作ってみます。
題材は「勉強会でのプロジェクトマネジメントの講習」にします（笑）
【BOSCAR】（※テキストとは「実務で役立つプロジェクトマネジメント」のことです。）
Background
勉強会でロジカルシンキング、マーケティング、プロジェクトマネジメントの勉強をすることになり、なんちゃってSEがプロジェクトマネジメントの講師をすることになった。
Objective
プロジェクトマネジメントを初めて学ぶ勉強会メンバーに、わかりやすい講習を提供する。
Scope
テキストに載っている項目が範囲。
テキストに載っていないやや高度な知識は範囲外。
Constraint
講習は5/30に行う。
講習の時間は45分。
Assumption
場所の確保はされている。
Report
講習、講習資料、講習概要書
【WBS】
タスク 担当 期間 成果物（あれば）
講習の概要を決める なんちゃってSE 5/24～5/24 講習概要書
情報収集をする なんちゃってSE 5/25～5/26 講習概要書
資料を作る なんちゃってSE 5/27～5/28 講習資料
本番想定練習をする なんちゃってSE 5/29～5/29
勉強会で講習をする なんちゃってSE 5/30～5/30
簡単に作ってみたので、突っ込みどころがあるかもしれません。。。
身近なプロジェクトマネジメント例 （５）
こんばんは、ズッキーです。
最近、嫁さんにUMLをレクチャーしています。
レクチャーした後は、なんだかすごく眠い感じなのですが、寝る前の体操って感じです。
さて、今回のテーマ「身近なプロジェクトマネジメント例」です。
マネジメントといえるかどうかは、わかりませんが、現在、携わっている組み込み開発ビジネスについて書きたいと思います。
現在、会社で組み込み開発をやろうということで調査、及びビジネスパートナーの開拓をしています。
構成メンバーは4人です（役職1人、営業1人、調査・開発2人）。
私は、調査・開発担当です。
当プロジェクト開始時、私は他の開発プロジェクトをプロジェクトリーダーをやっていたので、こちらの組み込みプロジェクトには、あまりパワーを入れていませんでした。しかし、組み込みプロジェクト２～３か月後、このプロジェクトが頓挫しました。
それはなぜか？
●プロジェクトスケジュールが、現場（調査・開発）スケジュールと同じであったこと。
●行き当たりばったりの方向性であったこと。（具体的な方向性がなかったこと）
そこで、私は意思決定方式をトップダウンから、ボトムアップに変更するように提案しました。
つまり、上司から指示を受けるのではなく、現場からプロジェクトの方向性を提案することにしました。
最初は、トップダウンの意思決定でいいかと思います。しかし、現場を動かすフェーズやプロジェクトのリーダーがただの管理者で現場を何も知らない場合には、ボトムアップの意思決定が効果的だと思います。
第一に現場のモチベーションが上がります。
また、当初、役員から受けた指示（組み込み開発ビジネスの開拓）を現場が実践できる具体的な目標に落とし込んでいきました。そうすることで、自分たちの中で漠然としていた方向性を一つの方向に向けることができました。
そして、スケジュールを組み直しました。そのスケジュールでは、１か月単位でのプロジェクト判断会を行うようにしました。この定例では、ビジネスの方向性の検討や、このプロジェクト自体を続けるかどうかなどを判断を下すものです。
しかし、スケジュールを組みなおして、さあ再スタートだ！という矢先に、我々現場が所属している部から他の作業が入りまくりました。そのうち、組み込み開発ビジネスを推進する部に所属している役職（プロジェクトリーダー）も弱気になってしまい、「できるだけ今の業務に専念して欲しい。」という有様でした。
現在でも、組み込みプロジェクトは何とか生きていますが、風前の灯です。
このプロジェクトの最大の失敗は、異なる２つの部でメンバーを構成したことです。
（役職、営業は新しく立ち上がった部、我々、調査・開発は既存の部）
プロジェクト開始時は、互いの部でプロジェクトを推進することにコミットしていましたが、
時間が経過するにつれて、そのコミットはなかったかのようになりました。
部が違うことで、一番大変なのは現場です。
こういうプロジェクトは、雲行き怪しいことが多々ありますので、皆さんの参考にでもしてください。
最近、嫁さんにUMLをレクチャーしています。
レクチャーした後は、なんだかすごく眠い感じなのですが、寝る前の体操って感じです。
さて、今回のテーマ「身近なプロジェクトマネジメント例」です。
マネジメントといえるかどうかは、わかりませんが、現在、携わっている組み込み開発ビジネスについて書きたいと思います。
現在、会社で組み込み開発をやろうということで調査、及びビジネスパートナーの開拓をしています。
構成メンバーは4人です（役職1人、営業1人、調査・開発2人）。
私は、調査・開発担当です。
当プロジェクト開始時、私は他の開発プロジェクトをプロジェクトリーダーをやっていたので、こちらの組み込みプロジェクトには、あまりパワーを入れていませんでした。しかし、組み込みプロジェクト２～３か月後、このプロジェクトが頓挫しました。
それはなぜか？
●プロジェクトスケジュールが、現場（調査・開発）スケジュールと同じであったこと。
●行き当たりばったりの方向性であったこと。（具体的な方向性がなかったこと）
そこで、私は意思決定方式をトップダウンから、ボトムアップに変更するように提案しました。
つまり、上司から指示を受けるのではなく、現場からプロジェクトの方向性を提案することにしました。
最初は、トップダウンの意思決定でいいかと思います。しかし、現場を動かすフェーズやプロジェクトのリーダーがただの管理者で現場を何も知らない場合には、ボトムアップの意思決定が効果的だと思います。
第一に現場のモチベーションが上がります。
また、当初、役員から受けた指示（組み込み開発ビジネスの開拓）を現場が実践できる具体的な目標に落とし込んでいきました。そうすることで、自分たちの中で漠然としていた方向性を一つの方向に向けることができました。
そして、スケジュールを組み直しました。そのスケジュールでは、１か月単位でのプロジェクト判断会を行うようにしました。この定例では、ビジネスの方向性の検討や、このプロジェクト自体を続けるかどうかなどを判断を下すものです。
しかし、スケジュールを組みなおして、さあ再スタートだ！という矢先に、我々現場が所属している部から他の作業が入りまくりました。そのうち、組み込み開発ビジネスを推進する部に所属している役職（プロジェクトリーダー）も弱気になってしまい、「できるだけ今の業務に専念して欲しい。」という有様でした。
現在でも、組み込みプロジェクトは何とか生きていますが、風前の灯です。
このプロジェクトの最大の失敗は、異なる２つの部でメンバーを構成したことです。
（役職、営業は新しく立ち上がった部、我々、調査・開発は既存の部）
プロジェクト開始時は、互いの部でプロジェクトを推進することにコミットしていましたが、
時間が経過するにつれて、そのコミットはなかったかのようになりました。
部が違うことで、一番大変なのは現場です。
こういうプロジェクトは、雲行き怪しいことが多々ありますので、皆さんの参考にでもしてください。
身近なプロジェクトマネジメント例 （４）
いまち～です、knbnw。
昨日アップの予定でしたが、深夜残業で持ち越してしまいました、ごめんなさい。
先月の頭に長めの休みを取って海外旅行してきました。
リフレッシュは必要ですね！！！
********
身近なプロジェクトマネジメント例ということですが、
なにがいいか考えた末、会社などでの飲み会の幹事をよくやっているので、これにしてみます。
もりぞーさんの記事より引用しますが、、、、
（１）始まりと終わりがある
（２）測定可能な目標がある
（３）特定の解決策が必要
（４）早急に対応する必要がある
（５）調整の必要がある
（１）呼びかけから飲み会の終了・精算までありますね。
きっちり精算できていることが必要です。
（２）測定可能な目標、、、、難しいですが、各自の予算でのやりくりですかね。
（３）特定の解決策が必要；いいお店を探して、メニューを考えます。
必要なら、飲み放題がいいか、飲み放題が不要か。
（４）大体、飲み会の実施まで日がないことが多いので、早急に対応する必要があります。
（５）日程や予算の調整が必要です。
特に予算は参加者の満足度にかかわりますので、設定が難しいです。
特にスケジュール管理が重要ですが、どうしようもない場合は主役「歓送迎対象者など」を優先します。
ある程度は参加できない人がいても仕方ありません。
次いで、コスト管理が重要になります。
これは仕事でもそうですが、必要な原料が財源で賄えるか。
飲み会の場合は利益は出る必要はありませんが、損失を出さないことが重要です。
参加者の平均年齢によって食事の量をある程度予想します。
若手が多い場合は量とにかくを、ベテランが多い場合は品数を多くして量は少なめ。
ベテランが多い場合は量よりも味を重視します。
お店選びが特に重要な解決策ですね。
費用の負担割合の設定は、仕事なら出資比率に置き換えることが出来ますね。
幹部職を多めに、それ以外の人たちにはちょっと少なめに。
参加者の家族状況もある程度考慮すると、どれくらいの金額が出せそうか予想できます。
既婚者多めの場合は安めにするとか。
おおよそ、一般参加者の出費が５０００円を越えてくると、
よほど美味しい料理でないと満足してもらえません。
幹部職の場合は７０００円～１万円かな。
既婚者が多いグループの場合は３０００，６０００くらいですか（安っ！）。
昨年の忘年会での結果ですが、、、、
予算；幹部職５人，８千円、一般人12人，５千円、派遣社員3人，３千円
参加率；９５％（２０人中１９人，欠席者は一般人）
飲み放題設定あり１５００円、料理９品４０００円（計；５５００円/人）
クーポン利用あり５％OFF
かかった費用；５５００×１９人×（5%割引）→99,275円
各員の集合時間がまちまちになってしまい、開始時刻前に少し飲む（別料金）ことが発生。
→生ビール500円×７人→3,500円
費用合計；102,775円
各員からの会費合計；104,000円
よって、差額1,225円が残り、これを二次会の費用の一部に充てました。
幹事は損失を被ることなく、カード立替によってポイントをもらいました（これを報酬とします）。
参加者の満足度は、料理の味はそこそこ、量は９品で十分でした。
飲み放題の設定については、呑み助がたくさんいた結果、
単品で頼んだ場合に平均３０００円程度飲んだことが分かりました。
参加率の高さが際立って、上司の印象もよく終了しました。
マネジメントは人の調整が一番です。飲み会もそうですね。
昨日アップの予定でしたが、深夜残業で持ち越してしまいました、ごめんなさい。
先月の頭に長めの休みを取って海外旅行してきました。
リフレッシュは必要ですね！！！
********
身近なプロジェクトマネジメント例ということですが、
なにがいいか考えた末、会社などでの飲み会の幹事をよくやっているので、これにしてみます。
もりぞーさんの記事より引用しますが、、、、
（１）始まりと終わりがある
（２）測定可能な目標がある
（３）特定の解決策が必要
（４）早急に対応する必要がある
（５）調整の必要がある
（１）呼びかけから飲み会の終了・精算までありますね。
きっちり精算できていることが必要です。
（２）測定可能な目標、、、、難しいですが、各自の予算でのやりくりですかね。
（３）特定の解決策が必要；いいお店を探して、メニューを考えます。
必要なら、飲み放題がいいか、飲み放題が不要か。
（４）大体、飲み会の実施まで日がないことが多いので、早急に対応する必要があります。
（５）日程や予算の調整が必要です。
特に予算は参加者の満足度にかかわりますので、設定が難しいです。
特にスケジュール管理が重要ですが、どうしようもない場合は主役「歓送迎対象者など」を優先します。
ある程度は参加できない人がいても仕方ありません。
次いで、コスト管理が重要になります。
これは仕事でもそうですが、必要な原料が財源で賄えるか。
飲み会の場合は利益は出る必要はありませんが、損失を出さないことが重要です。
参加者の平均年齢によって食事の量をある程度予想します。
若手が多い場合は量とにかくを、ベテランが多い場合は品数を多くして量は少なめ。
ベテランが多い場合は量よりも味を重視します。
お店選びが特に重要な解決策ですね。
費用の負担割合の設定は、仕事なら出資比率に置き換えることが出来ますね。
幹部職を多めに、それ以外の人たちにはちょっと少なめに。
参加者の家族状況もある程度考慮すると、どれくらいの金額が出せそうか予想できます。
既婚者多めの場合は安めにするとか。
おおよそ、一般参加者の出費が５０００円を越えてくると、
よほど美味しい料理でないと満足してもらえません。
幹部職の場合は７０００円～１万円かな。
既婚者が多いグループの場合は３０００，６０００くらいですか（安っ！）。
昨年の忘年会での結果ですが、、、、
予算；幹部職５人，８千円、一般人12人，５千円、派遣社員3人，３千円
参加率；９５％（２０人中１９人，欠席者は一般人）
飲み放題設定あり１５００円、料理９品４０００円（計；５５００円/人）
クーポン利用あり５％OFF
かかった費用；５５００×１９人×（5%割引）→99,275円
各員の集合時間がまちまちになってしまい、開始時刻前に少し飲む（別料金）ことが発生。
→生ビール500円×７人→3,500円
費用合計；102,775円
各員からの会費合計；104,000円
よって、差額1,225円が残り、これを二次会の費用の一部に充てました。
幹事は損失を被ることなく、カード立替によってポイントをもらいました（これを報酬とします）。
参加者の満足度は、料理の味はそこそこ、量は９品で十分でした。
飲み放題の設定については、呑み助がたくさんいた結果、
単品で頼んだ場合に平均３０００円程度飲んだことが分かりました。
参加率の高さが際立って、上司の印象もよく終了しました。
マネジメントは人の調整が一番です。飲み会もそうですね。
身近なプロジェクトマネジメント例 （３）
遅くなってしまいました。やましです。
身近なプロジェクトマネジメントと言う事で
「ブログのアクセスアップ」の話をしようと思います。
題材にするのは私が書いてるブログです。
↓↓↓↓↓↓
【知的財産 やってみなはれ】
訪問者がブログ更新日ベースで１日６０人程だった頃から
現在の９０人近くまで増えた経緯を説明しながら
プロジェクトマネジメントについて考えていきたいと思います。
もりぞーさんも書いているプロジェクトの要件に
（２）測定可能な目標がある、とあります。
プロジェクトマネジメントと言うのは最初に計画を立てることよりも
微修正を繰り返しながら前に進んでいくのが肝だと思っているので
最後のゴールだけでなく途中経過の把握のための測定はとても重要視しています。
１．アクセスアップにつながりそうな対策案を立てる（出来るだけ複数）
２．対策案の中で優先順位を付ける
３．対策案を実践し、アクセス数の測定をする
これをグルグル回して、アクセスの上下を確認しながら
良いものだけを取り入れて少しずつアクセスを上げていきました。
対策案を立てる時のポイントですが
「全体的にアクセスアップを…」だと漠然とした案しか出ないので
「どんな読者を増やすか」を明確にターゲッティングして
その対象者に届くような具体的な対策案を考えるようにしました。
例えばですが
■ブログを見てる人の分類
・知財（特許）の仕事をしてる人
・特許に興味がある技術者
■ブログへのアクセス方法の分類
・ランキングサイトなどを定期的に見ている人
・Googleなどで調べものをしていた一見さん
それぞれのアクセスを増やすための対策案を考えて優先順位を付けて
実際に対策をしてアクセスの確認をする、これの繰り返しです。
一例ですが、技術系の読者を増やしたくて、
ブログ村の登録カテゴリを「法務・知財」から「技術・工学」に変えました。
知財系のアクセスをキープしつつ技術者が増えるのが理想ですが
知財系があまりに減るようであればカテゴリを戻すと思います。
ランキングサイトなどからの集客に関しては
知財系で集客力のある「パテントサロン」の特性を考慮して
（更新順に前に表示される＆更新後２日だけ「New」表示）
更新のタイミングを色々変えながら試しました。
平日見てる人が多いと思ったので「月、水、金」にしてたのですが
試行錯誤の結果「日、火、木」が良いという結論に至りました。
（平日に加えて会社が始まる前の日曜の夜も見てると思われます）
分類の仕方も「測定可能」な分類にしておくことで
行った対策の効果があったかが確認しやすくなります。
定期訪問者か一見さんかはリンク元のアクセス解析をすれば分かります。
知財関係か技術者かの切り分けはブログにアンケートを載せました。
アンケートは１０人強しか集まりませんでしたが
訪問者が知財関係者に偏っていると知るには十分でした。
予算（お金）はかけない、限られた資源（無料で提供されたツール）だけで
対策の効果を計るために意味のある測定が出来るか、が腕の見せ所です。
（結果が出るまで実際に対策を打ち続ける行動力ももちろん大事です）
お金もツールも無いから無理、と諦めるのではなく
手元にある資源で最善を尽くすのがマネジメントと思います。
気付いたら長文になってしまって恐縮ですが、参考になれば幸いです。
身近なプロジェクトマネジメントと言う事で
「ブログのアクセスアップ」の話をしようと思います。
題材にするのは私が書いてるブログです。
↓↓↓↓↓↓
【知的財産 やってみなはれ】
訪問者がブログ更新日ベースで１日６０人程だった頃から
現在の９０人近くまで増えた経緯を説明しながら
プロジェクトマネジメントについて考えていきたいと思います。
もりぞーさんも書いているプロジェクトの要件に
（２）測定可能な目標がある、とあります。
プロジェクトマネジメントと言うのは最初に計画を立てることよりも
微修正を繰り返しながら前に進んでいくのが肝だと思っているので
最後のゴールだけでなく途中経過の把握のための測定はとても重要視しています。
１．アクセスアップにつながりそうな対策案を立てる（出来るだけ複数）
２．対策案の中で優先順位を付ける
３．対策案を実践し、アクセス数の測定をする
これをグルグル回して、アクセスの上下を確認しながら
良いものだけを取り入れて少しずつアクセスを上げていきました。
対策案を立てる時のポイントですが
「全体的にアクセスアップを…」だと漠然とした案しか出ないので
「どんな読者を増やすか」を明確にターゲッティングして
その対象者に届くような具体的な対策案を考えるようにしました。
例えばですが
■ブログを見てる人の分類
・知財（特許）の仕事をしてる人
・特許に興味がある技術者
■ブログへのアクセス方法の分類
・ランキングサイトなどを定期的に見ている人
・Googleなどで調べものをしていた一見さん
それぞれのアクセスを増やすための対策案を考えて優先順位を付けて
実際に対策をしてアクセスの確認をする、これの繰り返しです。
一例ですが、技術系の読者を増やしたくて、
ブログ村の登録カテゴリを「法務・知財」から「技術・工学」に変えました。
知財系のアクセスをキープしつつ技術者が増えるのが理想ですが
知財系があまりに減るようであればカテゴリを戻すと思います。
ランキングサイトなどからの集客に関しては
知財系で集客力のある「パテントサロン」の特性を考慮して
（更新順に前に表示される＆更新後２日だけ「New」表示）
更新のタイミングを色々変えながら試しました。
平日見てる人が多いと思ったので「月、水、金」にしてたのですが
試行錯誤の結果「日、火、木」が良いという結論に至りました。
（平日に加えて会社が始まる前の日曜の夜も見てると思われます）
分類の仕方も「測定可能」な分類にしておくことで
行った対策の効果があったかが確認しやすくなります。
定期訪問者か一見さんかはリンク元のアクセス解析をすれば分かります。
知財関係か技術者かの切り分けはブログにアンケートを載せました。
アンケートは１０人強しか集まりませんでしたが
訪問者が知財関係者に偏っていると知るには十分でした。
予算（お金）はかけない、限られた資源（無料で提供されたツール）だけで
対策の効果を計るために意味のある測定が出来るか、が腕の見せ所です。
（結果が出るまで実際に対策を打ち続ける行動力ももちろん大事です）
お金もツールも無いから無理、と諦めるのではなく
手元にある資源で最善を尽くすのがマネジメントと思います。
気付いたら長文になってしまって恐縮ですが、参考になれば幸いです。