ぬるい部分があるとは思いますが、まあ例なので許してください。

大手ベンダーならもっとガチっとしたドキュメントを作成すると思うのですが。

大切なのは以下がイメージできるかどうかです

　・ゴールまでのステップをタスクとして挙げる

　・成果物を定義する

　・タスク一つ一つの工数を見積もる

内容としては、

準備して、設計して、実装して、テストというお決まりの流れです。

運用に備えて手順書を作成しているのが特徴的かもしれません。

今回は移行ではなく、新規リリースと言う事で移行に工数は取っていません。

尚、システムの開発～リリースという大きな流れから言えば、一部分に相当します。

私の担当はインフラ部分と言う事です。

インフラ系の環境の設計・構築作業はこじんまりとしていて、

開発系ほどヘビーでもなく、且つ仕様変更ラッシュとか

ウザイ事が少ないので非常に楽しく、個人的には気に入っています。

（年齢的に手を動かす事が許されなくなってきているのが残念ですが…。）

今日のアクション：

「タスク挙げと工数見積もりをイメージする」

システムやっていない人にとっては呪文にしか見えないか…。

開発案件というのは手順の相場が決まっていて、
以下の要素を考慮すればほぼ漏れがなくなります。

　・準備
　・設計
　・開発
　・実装
　・テスト設計
　・テスト（ユーザテスト）
　・移行・リリース
　・ドキュメント整備

これをベースにタスクの漏れや、特殊作業が無いかを
見直したりします。

後は挙げたタスクをざっと見直してみましょう。
スタートからゴールにつながっているでしょうか？
途中の階段が抜けたりしていないでしょうか？

次に階段一段一段を上る時間を考えます。
これが工数見積です。
正直、何年経ってもこの練習をしてこなかったため、
作業見積が出来ない人が居たりします。

これは本当に訓練ですから、自信が無いのであれば、
今日から初めて、実績値を取って経験値を増やすしかないです。

自分がかかると思う時間の3倍は時間をとりましょう。
準備、作業、レビュー、フィードバックなんてしていると、
すぐに3倍の時間が過ぎます。

正直世間相場的な見積と、自分の実力的な見積の2つは
把握しておいた方が良いです。

可能であれば自分の実力にあった見積を作成する事をお勧めします。
でないと、どうしても無理が出ますから。

最後に、自分なりに仕上がったら、第三者の目である、
上司や先輩にレビューしてもらいましょう。

　・スタートからゴールの道順はOKか？
　・抜けているタスクは無いか？
　・見積の根拠は説得力のあるものか？

以上のような切り口で見積を見てもらいましょう。
意見は部分的に取り入れたりすれば、貴方の仕事に他人の
ノウハウが活きてきます。

上司や先輩を上手く使うとはこういう事を言います。

本日のアクション：
「タスク挙げと作業見積の練習をし、上司・先輩を上手く使う」

まあ、不確定要素も含んでましたから識者のレビューで
不安要素が減ったと考えれば儲けです。

こんなのが作業開始してから出ると泣けますからね。本当に。

今日の関係者会議で判明したのですが、
今回のシステムリリースでは

「利用している技術要素のバージョンアップ」

を含んでいるとの事でした。
（いわゆる、『聞いてないよ～』という話です。）

サーバの1台はメッセージ・キューイングという機構を
使っているのですが、メジャーバージョンをアップさせるという事で、
新しいサーバを立てるのですが、他の稼働中のシステムも
こちらの新しいバージョンの機構を利用すると。

システムリリース時には足並みそろえて切り替えたいと。

事前検証や、移行スケジュール等もまだ検討されていない
という事で、追加作業が必要という事になりました。
2月末までに環境をという所もちょっとずれてきそうです。

まだ全体スケジュールやコストは調整中という事で、
漏れは吸収できそうです。素晴らしい。
リスクは早めに発見する必要があります。
今日の打合せは非常に助かりました。

今回はWebsphereとMQというIBM製の商品を利用するのですが、
ここらのノウハウを私は持っていない（違う部署が持っている）。
今から経験を積ませてもらうという事で、リスクが見えていなかった
という感じです。監視やログローテーションに関しても、
過去のスクリプト等が使えるか怪しいらしく、
見積ももう少し見直す必要が有りそうです。

ともかく、今回は早めの関係者レビューが効きました。
とてもラッキーでした。

今日のアクション：
「リスクは早めに表面化して、対策を打つ」

　・タスクの洗い出し
　・必要工数の算出

が必要という事だったのですが、
説明しようとして以下の要素が足りない事に気付きました（笑）
考える習慣というのが大切です。ドンマイです。

　・目的の明示化
　・現状の把握

タスクを洗おうかと思ったのですが、
ギャップが見えてないので、タスクが出ません！

もちろん、先月末に開発側の担当者と話しをして、
把握はできています。
システムの用途は企業秘密なのでここでは触れません。
キーになる部分だけは設計時に自ずと分かりますので。
今回の私の作業の目的は以下のとおりです。

「某システム（以下Gシステム）の
　本番稼動環境を2月末までに用意し、
　3月末に問題なくシステムリリースを実施する」

更に上記だけのモヤッとした要件を、
切り口を持つことで明確化していきます。

　何時？　⇒　2月末までに
　何処？　⇒　データセンターに
　誰が？　⇒　私が（又は委任された者が）
　何を？　⇒　システムに必要なサーバを

　どのように？　⇒　システム本番稼動できる状態で

更に深堀していきます。

「何時？」には間に合うのか？
　というのはタスクが挙がらないと判断付かないです。
　タスク挙げ＞工数見積＞人員アサイン＞クリティカルパス確認
　という作業が必要です。
　当面の締切は2月末と分かっているので、一旦放置。

「何処？」今サーバがデータセンターに無いという事なので、
　買うか、どっかから持ってくる必要が有ります。
　今回は金が無いという事でサーバは余分なものを確保済み。
　データセンターに責任を明確化し、
　『確実に』送ってもらうところがポイントです。

「誰が？」人員割り当て状況の確認が必要です。
　暇人がいるかな？いなければ私か…（涙）

「何を？」対象のサーバなのですが、今回は3台利用する事が
　分かっていています。2台は他の場所から持ってきて、
　1台は既存のものを利用すると決まっていました。

「どのように？」と言う部分でサーバのＯＳは
　再インストールする事に成っていますので、
　設計が必要になってきます。ＯＳ部分は何ＧＢで、
　バックアップには何ＧＢ必要でーとか考える訳です。
　2台のサーバは、ほぼゼロから構築、1台は既存環境を
　そのまま利用しますので、設定作業のみです。

ここらが分かってくれば必要なタスクが見えてきます。
次回は実際に挙がったタスクと工数算出部分を見てみましょう。

本日の作業：
「モヤッとした要件を切り口を持つことで明確化する」

5W1Hってのを考えた人は天才ですね。

私の居る職場での「費用見積」は「作業見積」を実施して、
工数に人月単価をかけるだけのシンプルなものです。
今回は必要なソフトウェアもあったので、初期費用として
追加しておきました。

前回の続き的な話になるわけですが、

「費用見積」に必要な「作業見積」はスケジュールを
作成する際の通過ポイントとなります。
「作業見積」と言う事は必要なタスクをすべて洗い出し、
かかる工数を算出し、積み上げる必要があるからです。

スケジュールの作成では、「作業見積」をベースに
締め切りや人員配置を考慮し、具体的なスケジュールに
落とす事が出来ます…が、それはとりあえず置いといて、
「作業見積」です。必要な作業は以下の2点です。

　・タスクの洗い出し
　・必要工数の算出

とりあえず、この2つが倒せればおのずと情報は出ます。

・タスクの洗い出し
　タスクを洗い出すには現状とゴールを把握し、
　そのギャップを埋めるためのステップを設定します。
　ステップは業務の単位、および自分が倒せる塊単位で
　タスクとして把握できるようにします。

・必要工数の算出
　自分の倒せる単位の塊に対して必要な時間を見積ます。
　この作業は出来ない人が多いのですが、最初は誰も出来ません。
　何度も繰り返し見積る事で、感覚を養っていきます。

　初めての人は作業にかかる時間を見積もって3倍にして、
　時間を確保しておきましょう。
　事前準備、先輩へのレビュー、ドキュメント作成などを
　考慮すると、大抵時間が足りなくなってきます。

次回は今回私が仕事で作成した内容をベースに
もう少し細かいところを見て行きます。

今日のアクション：
「ゼロからタスクを洗い出し、淡々と費用を計算する」

複数のメンターのおかげで成長できたとは言え、
実際は苦労しながら修行していくしかなかった訳です。

デブンチョの業務クオリティが劇的に改善できた
要因の一つが、
「仕事を始める前に必ずスケジュールを立てる」
という意識が芽生えた事です。

「出来なかったのかよ！」
といわれると大変恥ずかしいのではありますが、
重要視していなかったので、仕方がありません。

というのは、正直、30年近い人生の中でまともに
スケジュールなんて立てた事は無かったのです（笑）。

もちろん今ではスケジュール立てないとダメということは
嫌と言うほど身にしみてます。

実はしっかりとしたスケジュールは色々な要素で
構成されていて、スケジュールを作れれば、
仕事の最初のヤマは超えているのでは？とさえ思えます。
そのぐらい私にとっては大きな発見でした。

尚、業務上のスケジュールなんて何処にでもあるし、
他人が作った作業スケジュールを見たこともあると思うんです。
では、スケジュールの良し悪しって分かりますか？
仮に自分が携わる場合、管理対象の場合は事前にリスクを
排除しておく事は責任範囲だと思います。

IT系では特にそうなのですが、以下の要素が見えていないと、
まずスケジュールを組む事が出来ません。

　・業務目的/ミッション
　・業務のポイント
　・構成タスク
　・成果物
　・各タスクにかかる工数
　・人・物・金・情報リソース
　・締め切り

しかし、上記が見えていない人が適当に作ったスケジュールも、
ぱっと見ではしっかり作られたモノと区別が付きません。
これがなかなか曲者です。

ですが、構成要素をしっかり理解したうえで、
上記の要素が考慮されていて、且つ、スケジュールに反映
されているのかを確認する事が可能なのです。

また、上記を考慮してスケジュールを作成してみてください。
スケジュールというのは、ここの構成要素を今の時点で
全て明確化して、予定を組むことに他なりません。
意外とスキルの必要な作業である事が分かるのです。

まずは2週間規模程度の小さなタスクからで良いので、
スケジュールを作成する練習してみましょう。

今日のアクション：
「業務着手まえにスケジュールを作成する」

明らかに言動からこの仕事を成功させようという空気が
感じられる人です。

そいう言う方は大抵、自分の責任範囲を超えて、
頼まれても居ないのに仕事に付加価値をつけてきてくれます。
もちろん仕事の質をよりよくするために。

この行動は新人だろうが、ベテランだろうが関係がありません。
新人には新人なりにできること、
ベテランにはベテランなりにできることがあります。

対極にあるのは、セクショナリズムや個人による責任範囲の限定です。
明らかに同僚が困っているのに、

「自分の担当ではないので…」とか
「それは貴方の責任でしょう…」とか
「境界線を崩して欲しく無いんだよね…」

とか萎える発言をします。こういう発言をする人たちは

『最終的に何を達成する事が自分達のミッションなのか』

というところに意識が行っていないと思うんです。

何事にも協力的で、その人が協力してくれるだけで、
とても心強いと思える人。居ないですよね？めったに。
居る人は幸せな環境だと思います。

もし居ないのであれば貴方がが実践してみてください。
居るのであれば、マネしてみてください。
頭一つ抜けますし、先に与える行為自体も、
驚く程のリターンを期待できます。

今日のアクション：
「自分の責任範囲を超えて＋αの仕事してみる」

じゃあ、次にやる事は「捨てる」事です。

結局私達は色々業務を持たされているのですが、
倒しきれない事が多かったりします。
余裕で倒せる人は良いですけどね。大抵多いです。

優先順位の高いタスクを倒す事に集中しましょう。
優先順位の低いタスクはあえて意識して捨ててみてください。
または、上司に断って別の人に振りましょう。

なんでやらないんだと聞かれたら、自信を持って

「優先順位の高いタスクを実施中だからです」

と答えましょう。それで問題があるのなら、
優先順位が間違っているという事ですよね。

「捨てる」には以下の3種類があります。

　・やる事自体を止める
　・上司に相談して別の人間をアサインする
　・開始時期を先送りする

とにかく、
優先順位の低いタスクに時間を取られない事です。
時間は1秒たりとも割かないという意識が必要です。

今日のアクション：
「優先順位の低いタスクを捨てる」

もっとシンプルでも良いと思うのですが、

動きのあるものが分かるようにしています。

TODOリストの有効性は【こちら】をご覧ください。

私はチームのメンバー全員にTODOリストの記述と

シェアをお願いしていて、毎日メールが飛んでくるように

しています。ここ数日メンバーが何をしていたか追う事が

出来るようにしています。

TODOがリストされて、行動指針がはっきりしていれば

どんな形でも良いと思います。参考にされてください。

------------- TODO リスト---------------

○今日のスケジュール感
午前中は考える時間、午後は手を動かす時間。
○○案件の優先順位を上げて対応。
△△の件はボチボチ中間報告を入れる。
□□は残件を丁寧に倒していこう！

○現在動き中のTODOリスト(優先順位順）
-①-
・△△バックアップPJ
[未着]　-関係者に進捗状況の中間報告
[未着]　-インフラ環境構築設計・運用設計
　　　　　⇒Goサインが出次第着手
[着手]　-臨時予算申請
　　　　　⇒発注申請をかけた

-②-
・○○インフラ移管企画
[完了]　-キックオフプレゼン
　　　　　⇒顧客に対するプレゼンは完了
[未着]　-業務全体移管企画
　　　　　⇒プレゼンの簡易議事の作成と方針確認
　　　　　⇒ヒアリング結果からサーバ運用管理、PC管理等
　　　　　　全体的に丸投げしたい風な感じであった

-③-
・運用引継ぎ
[未着]　-月次メンテナンスアナウンス
　　　　　⇒引継ぎ資料作成
　　　　　⇒引継ぎ実施

-④-
・□□ファイルサーバ構築
[着手]　-設計
　　　　⇒残作業全般
[未着]　-社内レビュー
　　　　⇒準備するか…？生産性が無いし…。

-⑤-
・ISMS対応
[未着]　-審査内容メモリーダンプ
　　　　　⇒審査の質問内容や確認内容をダンプし、
　　　　　　来年の審査に備える

-⑥-

---- 今日はここまで

・サービスメニュー作成
[未着]　-情報共有
　　　　　　⇒説明会の実施準備
[未着]　-ＸＸメニューの周知
　　　　　　⇒ＸＸの開発部隊に連絡し、無駄の無い様に
　　　　　　⇒運用メンバーにも状況報告
[未着]　-改善プランシュミレート
　　　　　　⇒どのような改善でどのような費用になりそうか

・情報共有
[未着]　-週報作成
　　　　⇒そろそろ一回棚卸を

・メールのインシデント倒す（1日2回程度）
[継続]　チェック＆倒し

・チーム運営企画
[未着]　-溢れたタスク考慮

以上

では次のステップに移りましょう。
今日は棚卸した業務について更にブレイクダウンです。
不躾な質問ですみませんが、

『その業務って本当に必要な業務でしょうか？』

その業務は顧客のなんの役に立っているでしょうか？
その業務を止めたら一体どんな問題が起こるのでしょうか？
明確に回答することができますかね？

いや、以前会社に凄い人が居たですよ。実在系ですよ！
訳あってＡさんという方から業務を引き継ぐことになりました。

私：「Ａさん、この業務なんでやってるんですか？」

Ａ：「いや、Ｂさんがやれっていうから…。」

心の声：「おーっと、熱すぎじゃなーい？」
私：「では、作成しているこのデータは
　　　　　　　　具体的には誰が使ってるんですか？」

Ａ：「それは私には分からない。
　　　　　　　　Ｂさんに言われたからやってるだけだし…。」

心の声：「ドナドナドナ～ド～ナ～」
私：「はあ・・・」

ということで私は引継ぎした内容を「無駄かも知れない」と思い、
試しに数ヶ月放置してみました（笑）。どうなったと思います？
答えはお分かりですよね？

「そう、誰も何も困らなかったのです。」

貴方は会社にとって、どのような価値が生み出しているでしょうか？
この整合性って非常に重要だと思いますよ。

今日のアクション：
「業務の存在理由を明確にする」