2018年03月06日

なぜ運用系SEは必要なのか


初めての方はこちらを「はじめに

以前、以下の様な記事を見かけました。
極言暴論スペシャル! - 「昇給なしで成長もできない」、 客先常駐SEの境遇はつらい:ITpro
有料会員向けなので冒頭の部分しか読めませんがそれでも保守のSEの予算削減の話などが分かります。今回はソフトウェアという製品を展開する上で運用に関わる人達の存在はどういう意味を持つのか、そのあたりを掘り下げてみたいと思います。

運用系SE


そもそもSEとは何でしょうか。
System Engineerの略だという事は皆さんご存じだとは思います。しかしこの言葉には明確な定義が無いので色々な使われ方をしているようです。一般の人がSEと言う時などは「コンピューターに関連する技術者」位の緩やかな使い方をしているような気がします。ここでも緩く全体像という意味でSEを使いたいと思いますが、タイトルの「運用系SE」というのはここでの呼び名なので説明したいと思います。
まず、ものを作るという内容を大枠で分類してみます。すると以下の様な分け方が出来ると思います。
 企画:作るものを決める
 開発:作る
 運用:作ったものを使う
各境界を厳密に定めるのは難しい事です。それぞれの現場で様々なプロセスや組織形態があり境界も様々です。例えば家電にせよ車にせよ形のある商品ならばその外観は企画(デザイナー)によって決定され、開発の役割はまさしく作る事がメインになると思いますが、ソフトウェアの場合は企画は要件に留まり開発の一環として多くの仕様が決められたりします。
この様に境界は様々なのですが今回のテーマは運用部分についてなのでここでは開発と運用の境界を納品と定めておきます。(納品はどのタイミングなのかという話はこれまた厳密には色々あるとは思います)運用系SEというのはこの大枠の分類の運用部分を担当するSEの事を指して名付けました。
なぜ呼び方を定義するのかというと、この部分はプロセス的には保守フェーズと呼ばれたり、テスト時の仮稼働に対応して本稼働と呼ばれたりやはり色々な呼び方があるようでもあり、更にこの部分での作業の種類としてシステムの管理等を行う「運用」と障害対応等の「保守」という事が一般的にあるので両方をまとめた概念として「運用系」という言葉を新たに使いました。先程の外部の記事のSEはこの運用系の保守を担当するSEの話のようですね。

運用部分の特徴


納品後に更に運用という要素があるのは一般的な商品に比べるとかなり特徴的な部分だと思います。具体的に比べて明らかにしてみたいと思います。
まず一般的な商品の中でも明らかに違うのは個人向けの商品です。
店に行って個人が購入する事ができるテレビだったり冷蔵庫だったりの事です。こういう商品で納品後つまり購入後にある要素としては問い合わせ窓口があります。窓口で購入した商品の相談や質問に答えてくれますね。また、壊れた場合には修理窓口のようなものがあり修理もしてくれます。ただしソフトウェア商品の場合は別です。家電量販店の棚に箱で置いてあるようないわゆるパッケージソフトと呼ばれる個人向けのソフトウェアの場合には壊れた(バグった)といっても修理をしてくれる訳ではありません。
次に企業向けの商品ではどうでしょう。
例えばコピー機等では上記の問い合わせや修理といった他に定期的に来てメンテナンスしてくれたりもします。

それではシステムの場合はどうでしょう。システムの場合も問い合わせ窓口はありますしパッケージソフトでは行わない修理(障害対応)も行います。またコピー機のメンテナンスの様に運用状況をチェックしたり性能的なチューニング等も行ったりします。この様に項目だけ見ると他の商品とあまり差が無いようにも思えます。しかしパッケージソフトやコピー機の運用部分のウエイトはシステムの運用部分のウエイトとは大きく違います。
前者では何かが起きた時とか一月に一度程度のものです。それに対してシステムの場合は冒頭の外部サイトの記事の様に客先に常駐する様な事もあります。(「客先常駐SE」という言い回しはただの派遣業務についても使われるようですが、ここではシステム納品後のお守をする為に常駐する形態の事です)両者の違いの原因は極端に言えばパッケージソフト等は納品時点で完成品なのに対してシステムの場合は納品後の運用を通じて初めて完成品になるからだと言えます。例えば性能的なチューニングは運用を通じてより最適なものになる可能性がありますし、運用開始時には様々な予想外のトラブルが起きる場合もあります。また実際に多くのユーザーが使い始める事で色々と使いにくい点が浮き彫りになる事もあります。もっと言えば運用に深く関わる立場であれば場合によっては「完成しない」とも言えるかもしれません。なぜなら顧客の持つ予算の範囲内で常に新たな改善提案をし続ける様な事もあるからです。こうなるとシステムは常に進化し続けて完成しないと言えなくもありません。いずれにせよパッケージソフト等とは大きく違う事は明らかです。

運用系SEの意味合い


既になぜ運用系SEが必要なのかは感覚的に明らかなのだと思いますが、より掘り下げて考える為に、もしこの役割のSEが居なかったらどうなるかを考えてみます。話を分かり易くする為に仮に役割として問い合わせの回答と性能のチューニングに絞って考えてみます。
まず問い合わせに対して回答する人が居なかった場合にはどうなるでしょう。
回答する人が居ないからといってユーザーの問い合わせが無くなる訳ではありませんから何か対策を打つ必要があります。対策といっても回答する人が居ない訳ですからこれはもう問い合わせが出ないようにするしかありません。問い合わせが出ないようにするという事はユーザーが決して迷う事の無い操作性と機能に関して理解できない事が何一つ無いヘルプシステム等が必要になります。操作性はまだしもヘルプシステムについてはWatsonの様なAIが更に進化してコンシェルジュの様になってくれないと無理かもしれません。
性能のチューニングについてはどうでしょう。
これは単純に運用内容に従って自ら最高のパフォーマンスを出す様にチューニングする仕組みを確立すればいいという話かもしれません。そのようなものはまさしくDBMS(データベース)等がしのぎを削っている技術分野だったりします。

結局人が居ないからといってその役割が必要なくなる訳では無いので単純にソフトウェアで肩代わりするという事になります。つまり逆に言えば本来ソフトウェアでやるべき事をSEが肩代わりしていると言えます。

物と人の関係


問い合わせと性能のチューニングについてみましたが他の要素でも同様です。またSE以外の要素としてはものによってはユーザーの教育の為にセミナーやスクール等を用意する場合もあります。こういった要素でも全て同様と考える事が出来ます。
つまりテレビや冷蔵庫の様に納品時点でほぼ完結している商品ならばそれ以外に必要なパワーは限られますが、ソフトウェア(システム)ではそうは行かず<物>以外に周辺で多くの<人>のサポートが必要になるという訳です。この辺の関係を図にすると以下の様になります。

期待値


 
 


 
 


 
<ユーザー>
スキル
操作
<人>
運用
保守
<物>
ソフトウェア
文書

左側で示した高さはユーザーが期待するレベルです。ユーザーがこのソフトウェアを購入して成し遂げたい事の期待値です。それを高さで表しています。これに対して右側では物、人、ユーザーといった項目を積み上げてそのレベルを達成する事を表しています。各項目を説明すると以下の様になります。
 物:プログラムは勿論マニュアルやデータ等物の形で提供するもの
 人:保守やサポート等の人が提供するサービス
 ユーザー:ユーザー自身のスキルや操作の労力等
<物>と<人>は商品として提供するものですがそれにユーザー側のスキルや操作のパワー等が上乗せされて初めて目標のレベルを達成できることになります。正確にするために<ユーザー>も入れましたが、ここでの話は商品の構成要素である<物>と<人>についてです。
結局左の高さを実現するのに右側の各項目をどの様な割合にするかという事になります。なぜ<物>だけではなく<人>も必要なのかと言えば、先程まで見て来たようにプログラム等の<物>としてそのサービスを実現しようとするとより大変だからです。つまり作るよりも人がやった方がコストがかからないという事です。

従って<物>と<人>との割合は組織の開発能力と密接に関係します。つまり開発能力が高く<物>として提供できる高さが増えれば<人>の割合は減らせます。逆に開発能力が低いとその分<人>に頼らざるを得なくなります。例えば品質の悪いソフトウェアをリリースしてしまうとその後の火消しに大きなパワーを割かれるという事は誰しも経験している事では無いでしょうか。(ちなみに今回のテーマではありませんがこの図からは企画においてターゲットとするユーザー像を見誤ってしまい実際のユーザーの能力が想定より低かったりすれば<ユーザー>部分が低くなってしまい商品側が目標通りでも全体としては目標とするレベルは達成できない事が分かります)

人を削減してしまう理由


先程の図を見れば一目瞭然ですが左側の高さは変わる事はありませんからむやみやたらと<人>を削減したりはできません。しかし実際には経営的な責任者にとっては利益が出ない場合には確実な挽回策でもない限りは経費を削減するしかありません。そして経費と言えば人件費ですから<人>の部分が目を付けられる事になります。
しかしなぜ利益が出ないのかと言えば元々の原因は主には<物>つまりソフトウェアのレベルが低いので全体としての高さがユーザーの期待値に達していない事に他なりません。もし<人>部分の人員を削減したら誰が代わりを務めるかと言えば<物>部分を作っていた開発組織の人間にならざるを得ません。そうすると現行のレベルの低い<物>をバージョンアップして改善する様な事も出来なくなってきます。改善できなければ利益も見込めませんからその先どうなるかは火を見るよりも明らかです。

結局この様な場合は開発能力の低さが問題の根本的な原因と言えます。しかし更に遡ると企画段階で開発能力を見誤っていたのがそもそもの始まりとも言えます。つまりリリースをする遥か前からもう運命は決していたという事になります。酷い話になると開発に相談する事もなく営業が勝手な見積もりで案件を取って来たりします。こうなると開発能力を見誤るどころかそもそも見ていません。いずれにせよ"己を知らなかった"という事になるでしょうか。
"百戦危うい"のは言うまでもありません。

一覧


メニュー


記事を広める



posted by 善 at 22:04 | Comment(0) | 全般 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。