エンジニアは日々現場で学ぶ
開発現場で学べること
第6回　開発存続の危機で分かったSEに必要なスキル

クロノス 山野寛
2004/4/23

エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。

■本当に必要なスキルとは

　唐突だが、読者にお聞きしたい。

　「SEにとって本当に必要なスキルとは何ですか」

　読者の中には「情報技術に関する知識と設計能力」と答える人もいれば、「進ちょく管理能力とコミュニケーション能力」と答える人もいるだろう。しかし、この問いに対して明確な答えを持っている人は意外と少ないのではないかと筆者は想像している。その理由は、システム開発においてSEが任される役割は非常に広範囲であり、必要とされるスキルが多岐にわたるためである。

　一般的にSEとは、「業務要件の分析を行い、それを実現するための役割を担う、システム開発の中心となるエンジニア」という立場にいる技術者を指すようだが、この定義からはどのようなスキルが必要なのかを判断するのは難しい。以下参考までに、『若手SEのためのシステム設計の考え方』（ディー・アート刊　上野淳三、広田直俊、白井伸児著）という書籍から「SEに求められる知識と能力」を引用しておこう。

知識・能力 具体的な内容（太字は基礎的な項目） 知識 ・ 開発手法、システムライフサイクルに関する全般的な知識 ・ 設計手法に関する全般的な知識 ・ 販売、生産管理、経理などの業務知識 ・ ハードウェア、ソフトウェア、ネットワーク、データベースなど技術情報・製品に関する全般的な知識 ・ 分析手法、開発手法に関する全般的な知識 ・ プロジェクト管理に関する全般的な知識 専門能力 ・ 情報システムの設計 ・ 総合テストの実施、テスト結果の評価 ・ プログラム開発でのプログラマの指導 ・ 業務要件の分析、コミュニケーション・調整能力 管理能力 ・ 開発計画立案 ・ 進ちょく管理、スケジュール管理 ・ 品質管理、工程管理 ドキュメント作成能力 ・ 外部設計書・内部設計書の作成 ・ 総合テスト仕様の作成 ・ 本番移行仕様の作成

表1　SEに求められる知識と能力。『若手SEのためのシステム設計の考え方』（ディー・アート刊　上野淳三、広田直俊、白井伸児著）からの引用

　この一覧を見る限り、SEに必要とされるスキルはやはり想像以上に広い。このことからも、SEとはシステム全体にかかわる幅広い知識と経験を有し、技術だけにとどまらず、コミュニケーションスキルや文書作成スキルも兼ね備えたシステム開発のスペシャリストである、というのが一般的な見解のようだ。

　では、上記のスキルさえ備えていれば完ぺきなSEなのだろうか。筆者は過去にいくつかのシステム開発の現場でSEとして仕事をしてきたが、上記のように具体的な言葉で表現できるもの以外に、非常に重要で根本的なスキルが存在するように感じていた。実はいままでそのスキルを言葉にして表現するのは難しいと感じていたのだが、今回、ある経験から、それを

早期にリスクを察知し、その情報を必要とする人に的確に伝える（表現する）能力

と表現できるのではと思った。リスクを察知する能力は「危機管理能力」といわれるものだが、それを的確に伝える（表現する）という点がポイントである。では、なぜ筆者がそう思ったのか。今回はそのきっかけとなった出来事を紹介しよう。

■バッチ開発において

　私が開発に携わっているある企業の債務管理システムでは、債務の情報をWebでリアルタイムに更新するオンラインアプリケーションと、日次・月次のタイミングで夜間にデータを更新するバッチアプリケーションの2つの部分に分かれている。外部システムとのインターフェイスデータ作成や、銀行への伝送データ作成などの重要な処理の多くはバッチ処理によるものであり、筆者も主にこれらバッチプログラムの設計を行っている。

　現在でもバッチプログラムは、C言語やCOBOLで開発されることが多く、過去に筆者のかかわった現場でもそれ以外の言語を使用して開発したことは少ない。というのも、バッチ処理は夜間の定められた時間内に処理を完了させなければならないことがほとんどであり、実行速度に優れたC言語やCOBOLを採用する現場が多いからであろう。

　現在では多くの現場で使用されているJavaだが、コンパイラによって出力されたバイトコードを、インタプリタによって実行するアーキテクチャのため、C言語やCOBOLに比べると実行速度は遅く、パフォーマンスの懸念からもバッチ処理には向かないと考えられている。現在では、JIT（Just-In-Time）コンパイラなどによってJavaのパフォーマンス向上が図られているものの、やはりいまでも多くの実績があるC言語やCOBOLがバッチ開発の言語として採用されることが多いようである。

　しかし、今回の開発では、コンポーネントベースのアーキテクチャによって再利用性と生産性を向上させるという目的により、バッチプログラムでもJavaを採用することにした。今回のような大規模な開発ともなると、それぞれのプロジェクトで開発されたコンポーネントを共有できるというメリットは非常に大きいのである。

　通常バッチ開発を行う場合、クライアントから非機能要件として処理の制限時間が設定される。今回の開発では、全体として4時間以内に処理を完了させることが求められている。われわれは上記で述べたようにJavaで開発したバッチプログラムにパフォーマンスの懸念があることから、各反復の最終段階である結合テスト時にパフォーマンスの測定と評価を行うことにした。とはいっても、実際は開発段階に本番と同量のデータを用意することは困難であるため、ある一定数のデータで処理した結果を基に、本番での予想処理時間を計算し、全体として4時間以内に収まるかどうかを予想するのである。

■第1反復でのバッチパフォーマンス

　第1反復で製造したバッチのパフォーマンス測定を行った結果、ほぼすべてのバッチは設定された時間内に処理が完了できると判断できた。だが、ある1つのバッチだけは、本番での予想処理時間が数千時間にもなりそうなことが判明した。もちろん、数千時間もかかるプログラムなど使い物にはなるはずがない。

　しかし、私はこのバッチの処理が極端に遅い原因は、数万回もの繰り返し問い合わせを行うSQLにあると踏んでおり、データベースに索引を付与することで解決できるだろうと考えていた。そのため、多少の不安はあったが、この時点ではあまり気にしていなかった。当然前提として、データベースの索引はInsertのパフォーマンスを低下させるため、最後の反復時に全体として合理的でかつ効果的な索引を付与するのが得策であるという筆者の考えがあったのだ。

　このバッチのパフォーマンス測定をしていた場所の近くでプロジェクトマネージャ（PM）が作業をしていたため、私はこの処理に数千時間もかかるバッチの存在と原因を、PMは理解しているものと思い込んでいた。そして、私のこの「PMも当然理解しているだろう」という安直な思い込みが、後に大きな問題を引き起こすこととなる。

■開発存続の危機

　数日後、ふとしたことをきっかけに、PMとクライアントとの打ち合わせの中で「処理時間が数千時間にも及ぶバッチ」の話題が浮上し、大問題へと発展した。その打ち合わせ後、PMはわれわれを召集し、緊急ミーティングを行うこととなった。

PM　「どうしてこんな大きな問題を黙っていたんだ！」
私　「いえ、パフォーマンス測定時にこのバッチの話をしていたので、PMもご存じかと思っていたのですが……」
PM　「知っていたらこんな大問題にはならないんだよ！」
私　「すいません……。しかし、データベースの索引を付与すれば問題ないと思うのですが……」
PM　「自分たちの中だけで解決させるな！ われわれが処理に数千時間もかかるバッチを作っていると知ったら、クライアントは心配するに決まっているだろう！」

　事実、ミーティングの中でこの話が浮上した際に、クライアントは非常に不安を感じ、われわれの開発に対して不信感を持ったらしい。さらにはJavaでの開発を中止し、COBOLで再開発を行う案まで出してきたというのだ。最終的にわれわれは、このようなクライアントの不安を取り除くためにも、現段階で必要とされる索引をデータベースに付与し、再度パフォーマンス測定を行った結果、問題がないという事実をクライアントへ報告する方針を固め、一段落した。そして、ミーティングの最後にPMはわれわれに、次のようなことを告げた。

PM　「少しでも不安や危険を感じたらすぐに私に警鐘を鳴らして報告しなさい。自分たちは伝えたつもりでも案外伝わっていないことも多いのだから」

　私はこの言葉を聞いて、PMがわれわれに一番要求しているのは、「早期にリスクを察知し、それを確実に表現する」ことだと実感した。今回、処理が数千時間にも及ぶ測定結果が出た時点で、PMにその事実と原因、および対策を確実に伝えておくべきだった。そうすることにより、たとえその話がクライアントに伝わっても、PMから筋道の通った納得のいく説明をクライアントに対して行うことができただろう。当然ながら、クライアントを不安にさせることもなかったはずだ。

■リスクの察知と表現とは

　読者の皆さんはこのような経験はしたことはあるだろうか。意外に身近なところで同じ経験をしているのではないだろうか。

　例えばSEとして現場で働いている方々の中には、プログラマに対して次のような愚痴をこぼしたことはないだろうか。

　「仕様説明のときには『3日もあればできますよ』っていっていたのに、全然間に合わない……。スケジュールに間に合いそうにないのであれば、もっと早くいってほしいよなぁ」

　恐らく、SEの誰しもが経験したことがあるだろう。もちろん、スケジュールの遅れを早い段階から察知して、次の手を打つこともSEの仕事ではあるが、もしもプログラマから早い段階でスケジュールが遅れそうだという合図をもらえれば、リスケジュールを含めて対策を練るのは容易であり、非常にありがたいことだ。

　同じように、PMもSEに対して早い段階でのリスク察知とその合図がほしいと思っているに違いない。もしプログラムの製造が多少遅れるくらいのものであれば開発全体に与える影響は少ないであろう。しかし、将来問題になる可能性があるリスクを見逃してしまうことで、開発全体に多大なるダメージを与える可能性があることを常に意識しておかなければならない。

■SEに本当に必要なスキルとは

　今回の出来事で学んだ「早期にリスクを察知し、その情報を必要とする人に的確に伝える（表現する）能力」は冒頭で示した表1のどれにも当てはまらない。しかし、これはビジネスを行ううえで非常に重要なスキルだと筆者は考える。

　もし読者の中で筆者と同じように、表1に示したスキル以外で必要な「何か」を漠然と感じている方がいれば、それを暗黙知でなく、形式知にしていただきたい。意外にもそのように漠然とした思考の中にあるスキルこそが、SEとして本当に必要なスキルなのかもしれないからだ。

筆者プロフィール

山野寛（やまのひろし）●クロノスに勤務するシステム・アーキテクト。立命館大学理工学部 卒業。クライアント／サーバからWeb系システムを中心にいくつかの開発現場に参加し、ここ数年はJ2EEをメインとしたオブジェクト指向開発にアーキテクトとして設計から携わっているという。