ネタつつき26－システム構築屋のお仕事
何か面白いネタは無いかと考えていたところ、自分自身が変ったケースである事を思い出しました。そこで、私がやってきたシステム構築屋（造語）とはどんな事をするのかについて書きます。
変わった事をしているのできっと面白い読み物になると思います。
先ずはシステム構築屋という名前の由来について説明します。この名称は、魚を売る人は魚屋、OSを作る人はOS屋（命名者：川合秀実氏）ならば、システムを一人で作る人はシステム屋さんかな？と考えて命名しました。それで何故わざわざ命名したのかといいますと、自分の職業が分からないからです。一見アーキテクトみたいですが、アーキテクトは全ての工程を自分でする事はありません。ソフトウェア工学的に言えば、一人でシステム構築をするのは好ましいとはいえないのです。それで、便宜上自分で名前をつけることにしたのです。さて、前置きは十分なので本題に入ります。
システム構築屋のお仕事は仕様書を作るところから始まります。具体的いいますと、依頼主とシステムについてのフリートークを行いながら要望を纏めて仕様書を作ります。私が会った大概のお客様は、情報処理技術について何も知らないので、何がシステムで可能なのかも知らない状態なので、エンドユーザーが望んでいる事を聞くしかありません。イメージ的には大体はこんな感じです・・・
こんな具合に、エンドユーザーから要望を間接的に聞きだしつつそれを仕様書として纏めます。文面では伝わり難いと思いますがこれが意外と大変です。エンドユーザーに加えて、依頼主の事も考えつつシステムを提案しなければならないからです。どこが難しいのかといいますと、エンドユーザーと依頼主の利害一致しないからです。依頼主は極力開発コストを上げる事を望み、エンドユーザーは逆にコストを下げる事を望みます。あと、依頼主が情報処理技術について知らないので、エンドユーザーから何をきいたらいいのか分からないから問題を複雑化します。ここまで読んだ人の中にはきっと、「じゃあお前がエンドユーザーから直接聞けばいい」と言うでしょうが、日本では看板が全てなのでエンドユーザーは私個人に発注をしません。例えそれで価格が100倍になろうともです。どうしてそのように考えるのかは私は知りませんが、エンドユーザーは情報処理技術について何も知りませんし、上司を説得する材料が要るのでしょう。その材料で一番簡単なのは看板だから、会社の利益よりも看板を重視するのでしょう。これは日本の企業体質が生んだ悲劇だと思います。
仕様書が出来たら次はシステム分析です。エンドユーザーの業務については私はド素人なので、業務について調べつつシステムを詳細に分析して仕様書の整合性を検討する必要があります。この段階では、何度も依頼主を通じてエンドユーザーから色々訊かねばなりません。これもまた大変な作業です。何故ならば、エンドユーザーはプロの常識を一々説明するのは好まないからです。よく「プロならば知っていて当然だろ？」と言われますが、私は情報処理技術者であってその業務の素人なのです。日本は意外とまだシステムというものの認識が薄く、エンドユーザーは情報処理技術（IT）を魔法だと考えているようです。
次の段階はシステム設計です。前の段階で得た分析結果を元に、情報処理技術を用いてどうやって実現するのかという部分を考えていきます。この段階では大量にドキュメントが作成されます。これが純粋にシステムに関するものだけならばいいのですが、情報処理技術を知らない依頼主がエンドユーザーに説明できるようになる書類を書かねばならないので非常に大変です。2度手間としかいいようがありません。ここで注意して欲しいのは人もシステムの一部だという事です。システム設計といっても機械だけを考えるのではありません。人がどのように動けばいいのかも含めて設計します。
次は実装段階です。私は場面に応じて複数言語を使えばいいと思うのですが、大半は言語を指定されます。何を基準に指定しているのかはよく分かりませんが、私の経験上拘る依頼主が多いです。おそらく確保できる人員と先入観で決めているのでしょう。この段階は意外と他の段階に比べたら簡単です。システム開発の難しさは人間関係にあるといっても過言では無いでしょう。
最後は運用段階です。この段階では、設計段階で作った運用マニュアルなどを用いて、依頼主がエンドユーザーに教育をしてシステムを動かします。よくシステムを実装すればおしまいだと勘違いしている人が居ますがそれは違います。運用段階に入ってからが本番なのです。依頼主が情報処理技術について知らない場合は特にそれが顕著です。エンドユーザーと依頼主との認識の違いが大量噴出して上手くいきません。これは私の実力不足から生じる問題なのでしょうが、運用を一発で成功した事は一度も無く必ずクレームが来ます（笑）その情報を元にシステムの改善を行います。
大まかに書くと以上です。これらの作業を3～6ヶ月で行います。既に察していると思いますが、デスマーチが前提のお仕事です。私はデスマーチ以外のプロジェクトを経験した事がありません（笑）懸命なる皆様はこんな職業は絶対にしないほうがよいでしょう。
先ずはシステム構築屋という名前の由来について説明します。この名称は、魚を売る人は魚屋、OSを作る人はOS屋（命名者：川合秀実氏）ならば、システムを一人で作る人はシステム屋さんかな？と考えて命名しました。それで何故わざわざ命名したのかといいますと、自分の職業が分からないからです。一見アーキテクトみたいですが、アーキテクトは全ての工程を自分でする事はありません。ソフトウェア工学的に言えば、一人でシステム構築をするのは好ましいとはいえないのです。それで、便宜上自分で名前をつけることにしたのです。さて、前置きは十分なので本題に入ります。
システム構築屋のお仕事は仕様書を作るところから始まります。具体的いいますと、依頼主とシステムについてのフリートークを行いながら要望を纏めて仕様書を作ります。私が会った大概のお客様は、情報処理技術について何も知らないので、何がシステムで可能なのかも知らない状態なので、エンドユーザーが望んでいる事を聞くしかありません。イメージ的には大体はこんな感じです・・・
私「エンドユーザーの業種は何ですか？」 依頼主「○○だ。」 私「会社の規模は？」 依頼主「大体従業員1000人ぐらいで全国に数点支社がある。」 （省略） 依頼主「どんなシステムを作ったら買うと思う？」 私「そうですね・・・先方は○○業種なので、 ○○業務に伴う煩雑な作業を減らすとかが望ましいかと・・・ 一度先方に要望を聞いてみては如何でしょうか？」
こんな具合に、エンドユーザーから要望を間接的に聞きだしつつそれを仕様書として纏めます。文面では伝わり難いと思いますがこれが意外と大変です。エンドユーザーに加えて、依頼主の事も考えつつシステムを提案しなければならないからです。どこが難しいのかといいますと、エンドユーザーと依頼主の利害一致しないからです。依頼主は極力開発コストを上げる事を望み、エンドユーザーは逆にコストを下げる事を望みます。あと、依頼主が情報処理技術について知らないので、エンドユーザーから何をきいたらいいのか分からないから問題を複雑化します。ここまで読んだ人の中にはきっと、「じゃあお前がエンドユーザーから直接聞けばいい」と言うでしょうが、日本では看板が全てなのでエンドユーザーは私個人に発注をしません。例えそれで価格が100倍になろうともです。どうしてそのように考えるのかは私は知りませんが、エンドユーザーは情報処理技術について何も知りませんし、上司を説得する材料が要るのでしょう。その材料で一番簡単なのは看板だから、会社の利益よりも看板を重視するのでしょう。これは日本の企業体質が生んだ悲劇だと思います。
仕様書が出来たら次はシステム分析です。エンドユーザーの業務については私はド素人なので、業務について調べつつシステムを詳細に分析して仕様書の整合性を検討する必要があります。この段階では、何度も依頼主を通じてエンドユーザーから色々訊かねばなりません。これもまた大変な作業です。何故ならば、エンドユーザーはプロの常識を一々説明するのは好まないからです。よく「プロならば知っていて当然だろ？」と言われますが、私は情報処理技術者であってその業務の素人なのです。日本は意外とまだシステムというものの認識が薄く、エンドユーザーは情報処理技術（IT）を魔法だと考えているようです。
次の段階はシステム設計です。前の段階で得た分析結果を元に、情報処理技術を用いてどうやって実現するのかという部分を考えていきます。この段階では大量にドキュメントが作成されます。これが純粋にシステムに関するものだけならばいいのですが、情報処理技術を知らない依頼主がエンドユーザーに説明できるようになる書類を書かねばならないので非常に大変です。2度手間としかいいようがありません。ここで注意して欲しいのは人もシステムの一部だという事です。システム設計といっても機械だけを考えるのではありません。人がどのように動けばいいのかも含めて設計します。
次は実装段階です。私は場面に応じて複数言語を使えばいいと思うのですが、大半は言語を指定されます。何を基準に指定しているのかはよく分かりませんが、私の経験上拘る依頼主が多いです。おそらく確保できる人員と先入観で決めているのでしょう。この段階は意外と他の段階に比べたら簡単です。システム開発の難しさは人間関係にあるといっても過言では無いでしょう。
最後は運用段階です。この段階では、設計段階で作った運用マニュアルなどを用いて、依頼主がエンドユーザーに教育をしてシステムを動かします。よくシステムを実装すればおしまいだと勘違いしている人が居ますがそれは違います。運用段階に入ってからが本番なのです。依頼主が情報処理技術について知らない場合は特にそれが顕著です。エンドユーザーと依頼主との認識の違いが大量噴出して上手くいきません。これは私の実力不足から生じる問題なのでしょうが、運用を一発で成功した事は一度も無く必ずクレームが来ます（笑）その情報を元にシステムの改善を行います。
大まかに書くと以上です。これらの作業を3～6ヶ月で行います。既に察していると思いますが、デスマーチが前提のお仕事です。私はデスマーチ以外のプロジェクトを経験した事がありません（笑）懸命なる皆様はこんな職業は絶対にしないほうがよいでしょう。
スポンサーサイト
