重量級プロセスで形式重視な案件をやってきたSI屋と、スピードと変化への対応を重視で軽量級なプロセスを使ってきたWeb屋が、不況な世の中で仕事をコンバートしようとした時の注意点(;´Д｀)
自分は今日から仕事始めなのですが、まあ、世の中の状況も絡めて少し。
この不況の中、SI屋、Web屋の仕事も減ってくるわけですが。
SI屋の金融・製造方面の影響はこれから目立ってくるでしょうし、組み込みとか、メーカー系にぶら下がっている所は、去年のうちから既に人減らしが始まっていたりしますが(;´Д｀)
っで、人が帰されたり、新規の仕事が取れなくなってくると、やる仕事をコンバートしていこう〜なんて話になったりします(・ω・)
今まで官庁系や金融系の業務をやっていたSI屋が、Web 2.0的な仕事に手を出してみたり、逆に、Web屋が仕事が取れなくなってきて、大手SI屋の下請けを始めたりとか。
技術面では似たような事をやっているので、コンバート可能だと考えやすいですが、そう単純な話でもなくて。
テクニカルな部分については重なるところもありますが、考え方を変える必要のある部分もあったりして、この辺の事は前にも少し触れていますが(・ω・)
テクニカルな事とは別に、意志決定の仕方や見積もり、お金の稼ぎ方なんかでも違う部分があったりして。
その辺を認識していないと危険ですよ!!( ﾟдﾟ)、っというわけで、ありがちな話を少し。
プロセス
いわゆるSI系の案件と、Web系の案件では考え方に大きく違う部分があると思っていて。
それは何かというと、スピード感というか。
Web系の案件ではスピードと変化への対応が最も重要で優先度が高くて。
その為には無駄な事はやらない、結果重視、プロセスも軽量化という感があるのに対して。
SI系の案件の場合、品質が最も重要、その為にプロセスも重量化、形式的な作業も給料のうち、っという考え方があると思ったり(・ω・)
リスクに対する考え方も、軽量級プロセスの場合はリスクドリブンでより主体的にリスクを潰しにいきますが。
重量級プロセスの場合、スコープを明確化することでリスクの責任回避をしたりしますよね。*1
っで、案件によってこの辺の考え方の違いがあることを認識しておかないと、リスクを全部押しつけられたり、後になって不明確だった部分の責任を取らされたりということもあるので、気をつけましょうねということで(´Д｀)
見積もり
っで、その辺の違いをあまり意識せずに見積もりを行ってしまうと、想定外の作業で工数を喰ったり、目的に対して必要以上に工数をかけて赤字になったりという危険がありますよ、っというのが今日のメインなお話(・ω・)
「形式重視な仕事」をメインでやってきた人達が「スピードと変化への対応を重視な仕事」をやる場合、目的に対して必要以上に工数をかけてしまって赤字になるというパターンが良くあります(;´Д｀)
大規模な案件の中で作業者をやっていると、形式的にやっている作業も給料のうちというわけで、その作業が本質的に必要なものかどうかを考えなくなるきらいがあったりするからですね(・ω・)
その感覚でスピード重視の案件をやってしまうと、本質的に必要の無い作業に無駄な工数をかけて赤字になってしまうので、スピード重視の案件ではまず最終的な動くシステムをイメージして、その為に必要な作業のみをやるようにする必要がありますネ(・∀・)
あるいは、上流工程(笑)分の工数を積み過ぎて、金額が高くなって仕事を取れないっていうパターンの方が多いかな(ﾟдﾟ)？
っで、それとは逆に「スピードと変化への対応を重視な仕事」をメインでやってきた人達が「形式重視な仕事」をやる場合、想定外の作業が発生してトラブルというパターンが良くありますね(;´Д｀)
大規模案件の場合、生産性よりも作業の定型化、均質化、形式化で仕事を進めようとします。
そこを理解せずに、今までの自分達のやりかたを基準にして見積もってしまうと、必要とされる作業に漏れが出てトラブってしまいます(´・ω・`)
今まで生産性やスピードを重視してきた人達が形式重視な仕事をやる場合、いっそ「誰も読まないドキュメントを書くのも給料のうち」みたいに割り切った方が精神衛生的には良いかもしれません(・ω・)
あと、想定外の作業によるリスクを回避するためには、レビューとかはフェーズの最後に1回やるのではなくて、ディレクションが間違っていないかを確認する為に、フェーズ内の複数のチェックポイントでやるようにしてください(´Д｀)
まあ、これまでと違うパターン(商流って言っても良いかも)の仕事をするときは、自分達のそれまでのやりかたを基準にするのではなく、顧客やプロセスなんかを良く判断して見積もる必要があるというお話です。*2
品質
ついでに品質についてもチョコっと(・ω・)
「品質」っていう言葉も、スピード重視な案件と形式重視な案件では意味が違ったりするので要注意デス。
スピードと変化への対応が重視な案件の場合、(変化に対応するため)スピードに最適化すると、必然的に品質もあがらざるを得ないという風な考えで、構成管理の改善やEoD、テスタビリティの向上の事を指していたりしますが(・∀・)
形式重視な案件の場合、フェーズゲートで要件をきちっと決めてこそ品質はあがるという幻想(?)をベースとするので、スピードと品質は相関関係ではなく逆相関になっていると考えている人も多いから注意が必要ですξ(`・3・)＜うぜーぜ
まとめ
とりあえず、利益(原価や粗利でも良い)を意識せずに仕事ができるのは小学生まで(#ﾟДﾟ)
っで、技術的には同じような事をやっているからといって、それだけでは単純に見積もりはできなくて。
必要とされるプロセスによって、案件ごとにその分をちゃんと増減した見積もりを作る必要があるよという、そんなお話ですた(・∀・)
あと、この辺は、発注側も気をつけるべき内容で、発注先が今までどちらの仕事をメインにしてきたのかを理解していないと、トラブルが発生した時に結局困るのは発注側なんでね(・ω・)
