ITコンサルタント兼システムエンジニアの中原一行さんに、仕事の中で経験する負荷、そのときに考えていること、工夫していることなどについて、1時間お話をうかがいました。
お話は仕事の基本的な流れから始まり、中原さんの考えや工夫へと進んでいきます。全5回です。
大きく分けて2つ質問があります。
一つは中原さんが仕事している時に仕事を受けてから終わるまでの全体的な流れと、そこのなかでどんなステップがあって、どういうふうに見ていくのか。
もう一つはどんな仕事の場面でも共通していることとして、
何個かの仕事が平行して進んで行くときとか、物事が思ったのと違うルートを辿っているときに、
切り替えるとか、元に戻す段階があると思うんです。そういうとき、どうしているのか。
まず最初の質問からいきます。中原さんの仕事が「これで始まりました」ってなるのはなにからですか？
一つは中原さんが仕事している時に仕事を受けてから終わるまでの全体的な流れと、そこのなかでどんなステップがあって、どういうふうに見ていくのか。
もう一つはどんな仕事の場面でも共通していることとして、
何個かの仕事が平行して進んで行くときとか、物事が思ったのと違うルートを辿っているときに、
切り替えるとか、元に戻す段階があると思うんです。そういうとき、どうしているのか。
まず最初の質問からいきます。中原さんの仕事が「これで始まりました」ってなるのはなにからですか？
一番最初は電話もしくはメールで。仕事も・・・、どんなレベル？開発案件全体としてか、それとも専門的な作るだけとか。どっちの方がわかりやすい？
そうですね。じゃあ作るだけで。
作るだけっていうと、まずはフェーズがあって、お客さんとの調整とかあって、作るってなった場合は、スケジュールが最初。
スケジュールを作る。
で、スケジュールを作るにあたって、まずはお客さんの要求があるので、要求をまとめる。RFPってやつを作って、「この認識で間違いないですね」ってお客さんとにぎりますと。それで一回書面にして、そこで「間違いないですね」ってなったのを元に、スケジュールとどういう作業が発生するのか、工程、WBSってのを作る。
これってフォーマットがあるんですか？人によって違います？
極力細かい単位までタスクを細分化する。それがあることで漏れがないかとか、何を順番に作っていくのか。あとは作業だけじゃなくて、そのなかにお客さんが確認するタイミングを入れたりとか。こちらの作業とお客さんとのコミュニケーションを一緒に混ぜて図表にする。
作業だけじゃなくお客さんがどう関わるかのタイミングも入れておくんですね
そこまできちっとできれば、それに従って作っていったり。
スケジュールにそって進んで行く。
ただし、スケジュール通りに進むことはほぼないので。そこは常に用意はする。
ほぼないってのは、ここでは想定していなかったことも起こる？
まず複数の仕事が動いている。いろんなものにひっぱられるケースがある。それを見越してバッファー持って余分に時間をとっておく。これは2日でできますってなったら、お金は2日分だけだけど、期間は4日分とっておくとか。
ひっぱられても入れられるように。流れとしては最初段階は依頼がありましたよと。そこからスケジュール立てる段階があって、そこでRFPがあって。
スケジュール情報を落とし込んで。
両方でこういう順番でここまでやりましょうってなって動き出す。動いたあとも単体で動いているわけではないので、他のものから影響を受けたり与えたりする。スケジュール通りにいかないこともある。スケジュール通りにいくっていうのはどういう場合？
作業担当者を専任で完全に割り当てられた場合は、スケジュール通り。自分の仕事がなくなるとスケジュールが確実に動く。技術的にすでにやったことがあるとか比較的容易なことであれば。
やったことがある技術。専任の人がいるとやってることが他から影響しないんですね。
影響しないように専任をつける。やったことがあれば読めるからスケジュールの確度が高くなる。バッファーとならくても大丈夫。
一回通ったことがある道みたいな。中原さんの仕事は読めない仕事の方が多いんですね。じゃあ道を見つけたり作ったり。
ってのが多いかな。全体的には。
今2段階くらいあって。最初スケジューリング、それからやってる最中の調整があって、最終的には納品。
もしくは自分が手を動かす場合。仕事するときはマネジャーの人格と職人の人格を切り替えないとなかなか難しい。まずは枠組みを決めて、それにそってものをつくったりとか。それに集中した方がいいんで。
作っていく人格と管理する人格と。RFPは？
提案に対する要求。
WBSがあって、スケジュール。RFPをやるのってどのくらいの時間で？
RFPはお客さんの方でまとまってる場合もあるし、お客さん自身こういうことやりたいって相談あって何回か打ち合わせして、ほんとにこれでいいんです？とかこいうのがいいじゃって一緒に決めるパターンもある。RFPによって、実はシステムを作らない方がいいってのもあるし。あるものを利用した方がいいとか。市販のものをうまく利用した方がいい
わざわざ新しく開発する必要はない。
ちょっとコンサルに近いような。
開発か既存かって分かれ目がある。分かれる要素の判断基準は？
一番大きいのは、納期と予算。あとは、要望。だいたいどこの会社もできるだけいいものを安くって。現実的なところで、どこまでの期間とれますか、いくら予算ありますか。じゃなこっちの方がいいですよっていうのは。
自分が作れるものだけじゃなくて、周りにあるものの情報収集も必要。
世の中にどういうのがあって、類似サービス製品としてこういうのあるから、使った方がいいですよ。
情報収集ってできるものですか？忙しいとアンテナ張るの大変では？
なので情報収集するツール使ったり、RSSみたりとか、定期的に雑誌見たり。同業の人と話すのが一番手取り早いかもしれない。「こういうの知ってる？」ってのは、人から伝わるのが一番確実な情報かもしれない。
他の手段よりも。
たとえば今一緒に仕事している岡林とかだと、「最近こういうの出たね」、「なにそれ」って。同じ仕事しているからある程度フィルターが同じで、同じ感覚で。新しい情報を。「へー」って思ったのふると、「へー」って。
使っているフィルターが近い。このフィルターを持っている人かどうかが共有する場合の判断基準になってくるんですかね