システムに暮らす人々
システム構築にもいろいろと役割分担がある。これをにかぽ風にまとめてみたいと思う。
開発作業には設計、開発、テストの大きく分けて３ステージがあるが、これらの工程に加え、さらに上流の分析工程や、システムカットオーバー後の運用フェーズも含めて開発サイクルと呼ぶ。と思う・・・。これらの工程を水が上から下に流れるように順番にこなしていく方法をウォーターフォール型の開発と呼び、設計、開発を繰り返しながら作り上げていく方法をスパイラル方式の開発と呼ぶ。その他の開発手法もあるが、この２パターンが一般的で、最近はスパイラル方式がよいとされている。試作品を何度も確認してもらってから、本格的に作る方法だが、試作品を作るのも結構骨が折れるということはあまり考慮されていない。でも、本格的に作ったプログラムを何度も作り直すよりはマシかな。
システムの開発に携わる人は、テスト工程か開発工程に最初は見習いで入り、徐々に上流工程へと昇っていくのが一般的だ。突然上流工程に舞い降りてくるどこから来たのかわからない要領のいい輩も大勢いるが、そういうのには使えないやつが多い。開発がどういうものであるかを知らないため、開発者たちからは馬鹿にされるし、そもそも開発工数を見積もることさえできないはずだ。余程の業務知識がないとシステム開発の場では敬われないと思う。たたき上げの刑事軍団と本庁から来たキャリアの警部補の関係がこれかな、と勝手に想像したりする。
運用は開発と切り分けられている。金融機関に対しては金融庁が運用と開発は別の担当者を置くようにとわざわざガイドラインに提示しているくらいだ。開発者が運用まで行えるとなると、システムに不正を行いやすいというのがその理由だが、これは理想の姿であり、小さな組織ではそんなことは言ってられない。金融庁のガイドラインにも小さなところでは無理だろうねぇ、と書いてある。だが、大企業では運用の専任化が可能で、運用部や運用課なんてのがある。運用歴１０年なんて人もいるが、運用暮らしが長いと、開発者のバグで夜間に実行されるプログラムがとまるたびに睡眠を妨害されることが積み重なり、開発者を心の底から憎むようになる。私が新人の頃に「このプログラム作ったヤツ出て来い」と運用課の先輩に怒鳴られたことがある。怖えーよ、あんたら。人間誰しもミスはするもんっすよ・・・。
開発サイクルを管理する作業が開発管理だ。開発管理は分析からテストまでの全工程を管理する場合もあるし、開発工程以降の工程を管理する場合もある。大企業のＩＴ部門は開発管理だけを行う場合が多いが、この業種も開発工程の経験がないとなかなか勤まらない。開発会社の言いなりになってしまっている大企業のＩＴ管理者の姿は見ていてあまりにも悲しい・・・。おっさん、こんなのにいくら払ってんだよ・・・。涙さえ誘う。
プロジェクトマネージャは、こういった開発工程も含めたプロジェクト全体をマネージする。プロジェクトマネージャには必ずしも開発経験が必要とは限らない。開発サイドに優秀なプロジェクトリーダーを手駒に持てば問題ないからだ。ただ残念なことに、開発サイドに優秀なプロジェクトリーダーはあまり多く存在しない。むしろ、こんなのできないっすよ、とプロジェクト推進よりも自分や自分の配下の負荷を下げることに邁進する開発プロジェクトリーダーが大半を占める。彼らの嘘の抗弁を論破できないプロマネは、日に日にやつれて行く。か、顔が土色になってますよ・・・。
コンサルタントはシステム提案を行い、そのシステムを導入するまでの方法を紹介する役割を担う。口さえ上手ければ勤まる。悪質な営業マン風にボロ儲けすることもできるが、客を殺してしまっては長く生き血を吸えないので、客を生かさず殺さず夢見させるのがよいとされている。ただ、最近は客も賢くなってきて、コンサルタント業務のみを依頼することは少なくなってきた。ちなみに、コンサルタントは他の工程に従事する全員から嫌われている。金だけ持って行きやがって・・・。こんなの出来るかよ、アホ！
絵を見せて、絵描きを紹介するのがコンサルで、絵を描くための材料やキャンバスの調達を指示し、描き方を現場で指導するのがプロマネ、絵の完成度合いを常に確認するのが開発管理、絵を描くのが開発者、描かれた絵の維持管理が運用という役割分担になると言って間違いないんじゃないかな。これに加えて、絵の内容を説明するサポート部隊なども関わってくるが、サポート部隊の悲哀は別の機会に紹介する。ちなみに私はコンサル業務以外の部分を１７年、コンサル業務を延べ３ヶ月やってます。
開発作業には設計、開発、テストの大きく分けて３ステージがあるが、これらの工程に加え、さらに上流の分析工程や、システムカットオーバー後の運用フェーズも含めて開発サイクルと呼ぶ。と思う・・・。これらの工程を水が上から下に流れるように順番にこなしていく方法をウォーターフォール型の開発と呼び、設計、開発を繰り返しながら作り上げていく方法をスパイラル方式の開発と呼ぶ。その他の開発手法もあるが、この２パターンが一般的で、最近はスパイラル方式がよいとされている。試作品を何度も確認してもらってから、本格的に作る方法だが、試作品を作るのも結構骨が折れるということはあまり考慮されていない。でも、本格的に作ったプログラムを何度も作り直すよりはマシかな。
システムの開発に携わる人は、テスト工程か開発工程に最初は見習いで入り、徐々に上流工程へと昇っていくのが一般的だ。突然上流工程に舞い降りてくるどこから来たのかわからない要領のいい輩も大勢いるが、そういうのには使えないやつが多い。開発がどういうものであるかを知らないため、開発者たちからは馬鹿にされるし、そもそも開発工数を見積もることさえできないはずだ。余程の業務知識がないとシステム開発の場では敬われないと思う。たたき上げの刑事軍団と本庁から来たキャリアの警部補の関係がこれかな、と勝手に想像したりする。
運用は開発と切り分けられている。金融機関に対しては金融庁が運用と開発は別の担当者を置くようにとわざわざガイドラインに提示しているくらいだ。開発者が運用まで行えるとなると、システムに不正を行いやすいというのがその理由だが、これは理想の姿であり、小さな組織ではそんなことは言ってられない。金融庁のガイドラインにも小さなところでは無理だろうねぇ、と書いてある。だが、大企業では運用の専任化が可能で、運用部や運用課なんてのがある。運用歴１０年なんて人もいるが、運用暮らしが長いと、開発者のバグで夜間に実行されるプログラムがとまるたびに睡眠を妨害されることが積み重なり、開発者を心の底から憎むようになる。私が新人の頃に「このプログラム作ったヤツ出て来い」と運用課の先輩に怒鳴られたことがある。怖えーよ、あんたら。人間誰しもミスはするもんっすよ・・・。
開発サイクルを管理する作業が開発管理だ。開発管理は分析からテストまでの全工程を管理する場合もあるし、開発工程以降の工程を管理する場合もある。大企業のＩＴ部門は開発管理だけを行う場合が多いが、この業種も開発工程の経験がないとなかなか勤まらない。開発会社の言いなりになってしまっている大企業のＩＴ管理者の姿は見ていてあまりにも悲しい・・・。おっさん、こんなのにいくら払ってんだよ・・・。涙さえ誘う。
プロジェクトマネージャは、こういった開発工程も含めたプロジェクト全体をマネージする。プロジェクトマネージャには必ずしも開発経験が必要とは限らない。開発サイドに優秀なプロジェクトリーダーを手駒に持てば問題ないからだ。ただ残念なことに、開発サイドに優秀なプロジェクトリーダーはあまり多く存在しない。むしろ、こんなのできないっすよ、とプロジェクト推進よりも自分や自分の配下の負荷を下げることに邁進する開発プロジェクトリーダーが大半を占める。彼らの嘘の抗弁を論破できないプロマネは、日に日にやつれて行く。か、顔が土色になってますよ・・・。
コンサルタントはシステム提案を行い、そのシステムを導入するまでの方法を紹介する役割を担う。口さえ上手ければ勤まる。悪質な営業マン風にボロ儲けすることもできるが、客を殺してしまっては長く生き血を吸えないので、客を生かさず殺さず夢見させるのがよいとされている。ただ、最近は客も賢くなってきて、コンサルタント業務のみを依頼することは少なくなってきた。ちなみに、コンサルタントは他の工程に従事する全員から嫌われている。金だけ持って行きやがって・・・。こんなの出来るかよ、アホ！
絵を見せて、絵描きを紹介するのがコンサルで、絵を描くための材料やキャンバスの調達を指示し、描き方を現場で指導するのがプロマネ、絵の完成度合いを常に確認するのが開発管理、絵を描くのが開発者、描かれた絵の維持管理が運用という役割分担になると言って間違いないんじゃないかな。これに加えて、絵の内容を説明するサポート部隊なども関わってくるが、サポート部隊の悲哀は別の機会に紹介する。ちなみに私はコンサル業務以外の部分を１７年、コンサル業務を延べ３ヶ月やってます。