第12回例会報告
3月23日、システムイニシアティブ研究会の第12回例会が開催されました。
今回は「偽者は要らない、本物のSEだけが企業を救う」というタイトルで、情報システム基盤コンサルタントの青木明雄さんにご講演いただきました。青木さんは、もとはOSの開発などを経験したエンジニア。その後、業務知識を持たない銀行、不動産業などの企業の情報システムを企画、開発されてきました。情報システム部門で、自らシステムを開発したり、システムベンダーと協働したり、人材教育を行ってきた経験から、SEとして必要なことを10個のポイントでお話しくださいました。
1．SEの技術力
- プログラマを長年経験したからSEではない。システムは業務を実現するもの。SEはシステム以外でも理解しないといけないことが多い。
- また、ディスクのI/Oなどの基本的なコンピュータ技術の理解も必要。使用率○％を「それでいい」という判断軸は？ 部品の中でやっていることを理解しているか？
- システムが動く環境を理解し、統制する。開発と運用はきちんと分ける。作り込みでは、開発の過程を見える化すること。文書でも誤字・脱字があるように、一定の量のプログラムには不具合がある。
どの程度の割合で出るかを把握しておき、単体テストなど、単純なことを「漏れなくきっちりやる」「ベテランにもやらせる」こと。
2．全体構想とサブシステム
- システムは、その会社がやっている仕事をコンピュータで行うのだから、システムの全体構造は、その会社のやっている仕事を洗い出して整理する必要がある。業務整理ができ、システム化する際には、組織とあわせてみてシステムを分割する。
- サブシステム化、連動、システムアウトソースなどは、拡張性や信頼性、性能確保のためにやるべき。
- システム間で密結合しないことが肝心。
- システムというのはコンピュータでやるところだけではない。事務をどうするか、どういうところを人間がやるのか、そこも含めてシステム。現場を巻き込むこと。
3．プロジェクトの規模と体制
- 規模に応じた体制をつくる。経験から、10人の体制、30人の体制、と同じ形をつくって増やしていけるのは100人まで。100人を超えると違う発想。管理を入れないといけない。300人を超えるとさらに別のしかけが必要。
- リーダーがボトルネックになる場合もある。その場合は早めにに配置を変える。能力が高い人なので、別のところで貢献してもらう。
4．自社開発とパッケージ導入
- 一連の業務の一体化を重視するのであれば、自社開発。独立した業務であれば、パッケージでもいい。カスタマイズは極力行わない。
- 自社システムの場合はメンテしながら長期に使うことを考えて、ポータビリティを確保すること。パッケージは保守費用が必要。
5．部分最適でなく全体最適
- 全体をよく見て考えること。部分部分で議論して「安い方で」と言われてもそれが本当にいいかを考えること。
- 何を達成するしかけにするのかを意識すること。全体としてみて「本当にいるのか」を問うてみる。
- システムはできるだけ長く使うこと。安いもので5年に1回作り直すよりも、長く使って徐々にメンテナンスをしなくてよくなれば、トータルでは安くなる。
- ソフトウェアベンダーがずっと存続するとも限らない。特別なことを依頼すると後が大変。生産性は悪く見えても、普通の技術で、他のベンダーでも対応できるような技術を選ぶこと。
- 長期的展望をもった基盤の設計をすること。OSがバージョンアップするとその上の業務システムの一部を修正しないといけなくなる。今年は2つ、来年は3つと、別々にバージョンアップすると大変。できるだけ基盤のところでその変更を吸収するように作る。
6．シンプル・イズ・ベスト
- 機能が同じものをシンプルに使うこと。後から「これがいいから」と別のものを追加してつぎはぎで使うと、バージョンアップの作業もつぎはぎになる。1つのものを使って保守契約も1本化するなど、トータルのコストを考えること。
7．システム要員の育成
- 技術は経験。知識はあくまでも知識。「こういうものをえます」「他の人が2年かかるところを1年半でやりました」といっても評価は定まらない。数年たって、バージョンアップで苦労したり、性能が悪くなったりということもあり得る。そういうことをSEは見ないといけない。開発、運用、バージョンアップまでさせること。
- 何でも「作る」からやらせるのではなくて、会社として「パッケージを使う」という方針をもっているのであれば、パッケージの見極め方を教えるなど、内容は違う。自分の仕事、しっかりしたベンダーの仕事を見せること。
8．事務とシステムは車の両輪
- 事務の整理は基本。
- SEは御用聞きではだめ。その人の仕事を楽にするのがSEではない。現場に喜んでもらいたいので、さっさと受け入れる人がいるが、全体の流れをみること。
- 何でもかんでもシステムでやるのではなく、事務との分担。事務でやれていたのをシステム化するには、意外とコストがかかる。
9．ドキュメンテーション
- まずは業務処理をきちんと書くこと。その中でシステム化すべきことと、事務とすることを考える。
- システムがなくなっても、そのドキュメントは次に使えるし、他の担当が理解できる。
10．新技術への取り組み
- 忙しさを理由に勉強しない人、本業をさしおいてセミナーばかり行く人、どちらも問題。
最後に、青木さんは「ちゃんとよくできているシステムは美しい。美しいと思われるシステムをつくろう。そのために自分なりに技術を身につけていこう。」とSEへのエールを送られました。
ファシリテータの田口さんの「1年間SIAで事例ベースでやってきたことを総括していただいた感じ」というコメントのとおり、講演後のディスカッションは、幅広いテーマでの議論となりました。
ユーザー企業のシステム部門のSEに求められる技術力とは？
- 会社のシステムを最後までお守りするのはユーザーであって、ベンダーではない。ベンダーがいなくても、システムの維持ができるだけの技術力。
- 自分たちでつくらないとしても、作り方、作るときの標準化・ルール、なぜそうなっているのかということを理解できること。
- 処理性能、リソースなど、システムのベースの部分に関する理解
「これらがあると、ベンダーに対して『いい質問』ができるようになり、その回答の評価・判断ができる。そういう技術を身につけることが重要だ」と青木さんが答えられました。
つまるところ、コスト。
10個の要素の中で、あえてどれが大事かを挙げるとすると、「全体最適」と「シンプルイズベスト」とか。
全体最適を考えないで物事を進めると、全部会社のお金に跳ね返る。システムだけでなく、システム部門だけでなく、会社全体を考える。
シンプルさを大事にするのも、システムライフを通してみたときのトータルでのコストで考えてのことだそうです。
共通言語は「業務」
「業務全体を把握するには、どうすればいい？」という質問に対して、青木さんはご自身の経験をお話くださいました。青木さんは業務知識の全くなかった銀行でのシステムづくりの際に、現場に半年間机を置かせてもらい、「いまなにやったの？」「担当は誰？」と逐一聞いて、業務を細かく紙に書いていったそうです。「現場もシステムをわかるべきだ」という意見もありますが、青木さんは異なるお考えをお持ちです。「業務を共通言語として、共通の用語で理解する。それさえできれば、どういうシステムにするかはスムーズに決まるし、事務とシステムで仕事を分担できたりもする」と、経験に裏打ちされたお言葉。そのために、詳細な（業務の）用語集も整備するそうです。
業務を書き出す作業は非常に時間がかかりますが、そのドキュメントはシステムがなくなっても残るもの。「次の財産になるような仕事のしかたをすることが大事」というお話に、SEだけでなく、すべての仕事に通じる本質的なことを教えていただいたな、と感じました。
最後に、木内会長の総評がありました。コンピュータが企業に入ってきて50年ほど。その間、基本的なアーキテクチャは変わっていないし、一方でビジネスのアーキテクチャも変わっていない。ということは「やるべきことは変わっていない」ということ。今日は「やるべきこと」をお話いただいた。企業は今それをサボっている。いきなりシステム化の話をして、いきなり要件定義に入ったりしているが、その前の会社の業務の可視化とデータの可視化が重要なのだ。
今回は、ユーザーがやるべきことを、再確認した例会となりました。
吉田太栄（システムイニシアティブ研究会事務局）
