SEsite_top_title TEP_Logo TEP_animation_gif
menu_site menu_whatsnew menu_sejob menu_qa menu_textbook menu_comment menu_english menu_essay menu_lifestyle menu_link menu_registration menu_bbs
 SEの35歳の壁〜その乗り越え方〜NEWSEの心得SEの仕事SEの仕事詳細システム構築業務知識獲得ソフト業界ソフト裏話

    visitors since November 11, 2001


筆者小林健三からの特別のご案内:
筆者の著作「SEの35歳の壁」〜その乗り越え方〜が4月25日にソフト・リサーチ・センターから出版されました。
あの有名なアマゾンのサイトで、下記の書物のレビューが掲載されています。また、日経コンピュータの書評欄にも掲載されました。
アマゾンのサイトで、これらのコメントをご覧になれます。
アマゾンのサイトでご購入になると、送料が無料です。

業務知識獲得手法
(上級者向け)

初回投稿2001年5月13日
最終更新:2003年9月27日

関連のあるサイトは下記の通りです:

 

第1版投稿:1999年6月15日
最終更新:2001年5月13日

ここでは,

  1. 業務知識とは?なぜ,業務知識が必要か?

  2. それでは,どのようにして業務知識を獲得すればよいか

  3. どのようにしてシステムを構築すればいいのか?

について,ちょっと長くなりますが,順番に述べます。これは,ある読者からの質問がヒントで,そうそう,そんなこともまとめにゃ,と考えていたので,それに答える形でまとめてみました。


質問とは,下記のような内容です。(無断引用をお許し下さい)

  1. 私は、SEの派遣を主体にしている会社の営業をやっているもので、SE出身でもプログラマ出身でもないため、現在いろいろと勉強しております。

  2. しかし、今年の新人教育も任されていまして、新人研修の際、業務知識をどのような内容で行えば、新人にとって解りやすいものになるか困っているのです。と言いますのは、派遣先には様々な機種・OSが有り、一概に説明できない。新人研修をさせる為、まず第一歩として、私は業務知識についてどのように解釈し、どのように理解させていけば良いのか?


システムエンジニアなんていやな商売ですよね。そもそもシステムというのは,どういうものなのですか。ここん所が良く分からないのに,それを扱うエンジニアなんて。「SE」なんて称号を貰ってもひとつも嬉しくない。まあ,これについては私が無料で提供しているpdfファイルなどを読んでいただくとして,コンピュータを含もうが,含まなかろうが,複合した要素を組み合わせて,それぞれの要素の合計よりもより効果のある,すなわち「シナジー効果のある」構成物をシステムと云ったり,ある目的を実現するために,種々な要素を組み合わせて構成したもののことを云ったりで,何やら分からない事だらけですね。

でも,今はやりのPC(パソコン)は,どう考えてもそれ一台で独立して存在するようなときはシステムとは云いませんよね。でも,ネットワークで繋がってしまうと,色んなことが出来るようになってきます。そうすると,一台のパソコンとは全く違った様相を呈するようになるわけですね。

そこで,このパソコンを連結したもの(システムと云いましょうか)をどのようなものとして作ればいいのか,と考えただけでも,業務知識と関係があり,業務に貢献するためにシステムが存在するのだな,と言うことが分かると思います。ですから,業務知識を獲得しなければ,自分の環境と全く違った顧客に対して,その顧客の業務に役立つようなパソコンのシステムなんて作れないわけですね。ですから,このようなシステムが作られる目的というのと直接関係するのが,「業務知識」であり,システムを構築するにはこの業界の「業務知識」が必要であるわけですね。しかし,「業務知識」が分かったからと言ってすぐにその業務に貢献できるシステムが構築できるわけではないのです。だって,[パソコンがない]今でもちゃんと[か,ちゃんとでないか知りませんが,一応は]業務は遂行できているわけですから,わざわざ高い金を出してパソコンシステムを導入するからには,何かもっと貢献でき,お客が「感激する」ものがないといけないわけですよね。

だから,システムを構築するには,「業務知識」があるだけでは駄目で,これから,「問題点」,「目標・狙い」を探り出し,そして「解決策」を考え,それに沿ってシステムを構築してゆくことになります。

それでは順番に説明をさせていただきます。

  • 業務知識とは?なぜ,業務知識が必要か?
    • 自分たちはシステムエンジニアだから,システムを作るという観点でお話をさせていただきます。そうすると,業務知識とは,対象とするシステムが動作している環境全般に関する知識となります。そのシステムは,そのシステムが置かれている環境と種々なかかわり合いを持ちます。その例として,次の4つを挙げることが出来ます。

      1. 最も簡単な場合は,環境からはデータを採取するだけで,環境に対しては影響を与えない場合です。非常に複雑な構造を持つシステムであっても,機器に組み込まれているようなシステムはこれに相当します。最も簡単な例としては,もう古いかもしれないけど,入力するパルスの数だけ決められた角度回転する「パルスモータ」などがこれに相当します。オープンループで要求機能を満たすのは,仲々困難で,環境(摩擦)の大小により応答が異なるので,1パルスでどれだけ回転するかを前もって決めておき,必要とするパルス数を発信します。また,LSIなどもこれに相当するのかな?



        このようなシステムで話が済めば問題がないのですが。まるで,マイクロソフトの提供するOSと Office みたいな物ですね。あてがいぶちで,利用者は単にそれを用いて,自分の好きでない「統合ソフト」を使わされる....と言うわけです。


      2. 第2は,環境へ制御出力を与え,環境はこれに対して応答し,総合的にある種の機能,性能を達成します。通常の閉ループの制御システムなどがこれに相当します。



        少なくとも,コンピュータはこれであって欲しいですね。我々の作るシステムは,これ以上であって欲しい。それでも,環境が単純な系であれば,コントローラであるシステムの設計は簡単ですが,ちょっと複雑になると,このシステムを記述する「仕様書」だけで膨大なものになります。



      3. 第3は,2の種類に対し,環境自体が変化をもたらし,これに応じてシステムの対応が変化するシステムです。最終的に,環境におけるシステムの挙動が当初の目標に合致するかを確認する必要があります。このような例としては,経営管理システム,生産管理システムなどを想定すればわかりやすいのではないでしょうか。



        大型のコンピュータを用いて実施しているような業務系のシステムでは,このようなシステムになるのではないでしょうか。すなわち,環境が刻々と変化し,その変化に対応して,システムが表示する画面が変化する。それに基づいてまた入力が変化してゆく。....(筆者はこのようなシステムを余り扱ったことが無いので,余り的確な表現が出来ないのが残念です。)

      4. これは完全に環境と一体となったシステムで,最新のGUIを用いた情報処理システムなどがこれに相当するのではないでしょうか。環境とシステムのインタフェースは,CRT等を通したマンマシンインタフェースが主たるものであり,これに対するユーザサイドの応答も,CRTへの表示の出方によって変化して行くものです。このようなシステムでは,総合的な機能,性能が問題になってくるので,利用者である人間が,その端末をどのように操作するかを明確に規定しないと,問題が発生します。そのため,マンマシンを特にシミュレーションするツールが存在し,有効に活用でき,それによって実システムが出来上がる前にシステムの動作を確認することが可能となります



        最新鋭のゲームソフトなどはこのような形式ではないでしょうか。ロールプレイングゲームなどというのは,一体どのような仕様書を書くのでしょうかね。私には全然わかりません。それとも,演劇のシナリオみたいな物があって,あらゆる場面を想定して自由に移動できるようになっているのでしょうか。

        古い人間には,CADなどのソフトがこのような構成になっているような気がします。しかし,CADシステムを製作した(人を見た)こともありますが,それがどのような仕様書になっているのかわかりませんでした。

    • 上で述べたように,システムの種別によって環境とのかかわり合いの強いものから弱いものまで各種のシステムがあることがわかります。いずれにせよ,システムはそれが置かれる環境に関して十分な知識が無いと成り立たないことがわかります。

    • そして,上記の種類により,環境に関する知識も程度が異なってきます。たとえば4の例では,はっきりと云って,システムそのものを利用して,環境(この場合はユーザ)がどのような業務を実施するのかまで知悉する必要があります。上記の1の例では,それほど知識は必要としません。入力に関する知識と出力に関する知識があれば十分でしょう。

    これで,なぜ業務知識が必要かおわかりになったと思います。それでは,続いて,どのようにして業務知識を獲得してゆくか,について経験から述べさせていただきましょう。

    • 業務知識の獲得は簡単か?

      • はっきり申して,業務知識はその業務に直接携わるか,もしくは,その業務を担当している人と長期にわたって情報を交換して,このような経験に基づく以外方法は有りません。もちろん,産業能率大学で各種の業務知識に関する教育を提供しておりますが,その教育は非常に高価で,業種対応で業務知識は異なっております。ですから,必要とする業務ごとにこの講座を受講して業務知識を蓄積してゆく必要があります。


      • 我々も,一度製造業に関する業務知識の講座を受講した経験が有りますが,講師は50歳代の経験者で,その業界に長期にわたって携わってきた豊富な経験を持った人であったと記憶しております。その人が,他の業務についての業務知識を持っているわけではありません。ですから,産業能率大学は,各業種ごとに専門家を雇って,その専門講師として派遣をしているわけです。その講師自身も,教育をもっぱらの仕事に異動すると,反対に業界の業務から遠ざかってしまうので,業務に関する知識も古いものになってしまいます。このようなことを考えると,業務知識を獲得することが如何に困難な業務であるかがわかると思います。

      • 私自身も,製造業を中心として,鉄鋼業に集中してコンピュータシステムを構築してきましたが,私の知識が,たとえば銀行のオンラインシステム構築に役立つかと言えば,NOでしょうね。全く異なる知識ですから。 また,社内の情報システム構築を担当している人間と,私のような制御システムを構築して来た人間とは,業務知識に関する内容も異なってくるでしょう。私は,発注業務,支払い業務,受注,工程管理,納品,決済に関する業務はほとんど経験が無く,このようなシステムを構築することは出来ないでしょう。しかし,システムを構築する一般的な手法が有ると考えて,少ない経験ですが,ホームページにそのノウハウの一部を公開して皆さまに多少とも御役に立てばと,考えている次第です。もちろん,公開している内容は極めて限定された内容ですが。

    • どのようにして業務知識を獲得すればよいか。

      • それでは,本題に入りましょう。どのようにして業務知識を獲得すればよいか。もちろん,最適な方法は,実際にその業務を長期にわたって実際に担当することです。しかし,そのようなことをしていると,人生はSEではなく,業務担当の専門家になってしまって,業務改善を実現するためのシステムを構築するために生まれてきたSEにはなれませんね。もちろん,上記のように,産業能率大学に通って,業務の専門家に,一から教育をしてもらうのも一つの手でしょう。


      • しかし,本ページの本論からはそれてしまいますので,筆者が以前,AIシステム,エキスパートシステムの構築業務に携わっていた経験を元に,業務知識を獲得する方法を説明しましょう。残念なことに,10年前のAIフィーバーも既に過去のものであり,今エキスパートシステムなど話題にも上がりませんので,エキスパートシステムとはどのようなものかを御存知の無い方が居られるかも知れませんので,少し説明しましょう。

      エキスパートシステムとは:
      エキスパートシステムは,人間が実施している「人間にしか出来ないような業務」をコンピュータがルールと言う形でソフトウエア化して,コンピュータの中で実現するシステムのことを指します。

      • ですから,エキスパートシステムを構築するためには,人間が実施している業務内容を聴取して,これを文書化するなりして,ルール化し,コンピュータ内に構築をする必要が有ります。そのため,業務を実施している人間(担当者)に対して知識獲得という(SEの)業務を実施し,これで得られた業務をルールの形に変換して,あらゆる場合を尽くし,これを元にエキスパートシステムを構築します。これで,この業務を担当している人間を代行することが可能となるコンピュータが出来上がるのです。しかし,実際は,人間の行っている業務というものは,定型的な業務は既に情報処理システムでバックアップ作業は実現されてしまっているので,一般的に,人間である業務担当者が実施している内容というのは,定型業務+非定型業務であり,担当者が得々と説明してくれる内容は,常に,この非定型業務に関する業務知識を説明することになります。(これが,業務担当者の生き甲斐であり,わざわざ我々が聴取することになると,定型業務ではなく,非定型業務を話すべきだ,と言う気持ちになるのでしょう。)


        でも,エキスパートシステムでは,業務の改善は出来ません。そして,業務の内容聴取が非常に困難で,時間がかかるため,このような人間にしか出来ない業務(非定形業務と云いますが)をコンピュータ化することが不可能と判断され,それ以降,余り話題に上がらなかったのでしょう。

        しかし,業務内容を聴取する手法として,このときに開発した手法は大変に役立つものでした。 その内,全面的にHP上に公開したいと考えて居ります。通信教育も可能と考えています。(資料は有ります。希望の方は小林までお問い合わせ下さい。)

      1. 先ず,業務実施者に面談し,どのような出力を出しているかをリストアップしてもらいます。主にな帳票ですが,今では,出力画面が多数を占めているでしょう。そして,これをリストアップし,項目を全て洗い出します。
      2. この内容をDB化するために,この項もくすべてに対して定義をしてゆきます。既にDB化されておれば,このDB仕様書をもらって,この業務は省略する事が可能です。
      3. 次いで,別の業務担当者でしょうが,どのような入力画面,帳票を使用して,どのような項目を入力しているかを,これも全て洗い出します。同様に,DB仕様書を作成します。
      4. 人間は,必ず誤りを起こすものです。この人間が入力した内容が,間違っていないことを保証するためには,各種の項目間の相互確認が必要です。これを自分で想定するか,業務担当者に聴取して,全ての項目に対する整合性のチェックを行う方式を確認します。
      5. これで,入力と出力が揃うわけですが,これを繋ぐロジックが必要です。どのようにしてこれを導き出すかが重要です。以前担当した業務では,工程設計業務が有りました。注文が入力で,製造順が出力になります。これにさらに,納期や優先順,ペナルティ,設備と製品,工程の対応など各種の関係があり,最終的に製造順(これを工程と云いますが)が出力されるのです。また,あるフロアに各種の機器をレイアウトするような比較的簡単な業務項目のみならず,非常の多くの制約条件やら,目標値が有り,これを考慮して実際の結論を導きます。ですから,この,入力と出力を繋ぐロジックの部分を聴取して完全な物にする事は,おおよそ不可能でしょう。
      6. 次いで,この現在の業務のみを聴取しただけで,これをコンピュータ化しても何のメリットもないわけですから,問題点は何か,何を改善するのかなど種々な情報を入手して,業務知識とは別に管理して文書化する必要が有ります。
      7. これらの情報が集まると,これからがシステム構築担当者の出番です。そして,これが設計書になるわけですね。

    • それでは,どのようにしてシステムを構築すればよいでしょうか。

       

      • これに関しては,簡単に述べるにとどめます。

        1. 先ず,顧客の要求・課題を聴取する。
        2. または,自社での製品開発の場合は,その製品に対する要求仕様を確認する。
        3. 次いで,これらに関する技術環境,使用環境などを調査する。そして,将来にわたっての予測を行なう。
        4. 顧客の要求,顧客の問題点などの形式で与えられた課題を整理して,システムの要求仕様としてまとめる。すなわち,この仕様を満足するシステムを構築すれば,顧客の要求を満足し,課題を解決することになることを確認する。
        5. 自社製品の開発においても同様である。通常,その製品に対する要求は営業部門などから提出されるので,これらの部門から提出された要求,すなわち,事業目標を満足するような要求から,SEが構築するべき製品の要求仕様を作成するわけです。この,営業部門から提出された要求を,要求仕様書の形式のまとめる手法は,上記の顧客の要求・課題を要求仕様にまとめる手法と同じです。

        さて,これからが本格的なシステムの構築段階です。また,順を追って説明します。

        1. 上記の要求仕様書が完成しているとします。それを元に,顧客の要求仕様を再確認します。そして,具体的な要求仕様をまとめます。このとき,要求を満たしているか否かを判断するために,定量的に測定可能な目標を定めます。
        2. この段階で,上記の段階での技術動向の調査,使用環境動向の調査などの将来予測を考慮します。と言うのは,このような将来予測をしないで現在の技術,使用環境のままでシステムを構築すると,システムが完成したときには既に技術は古いものになっており,使用環境も全く異なっている可能性が有り,このようなシステムは顧客を満足させるようなものにはなりません。
        3. 次いで,この仕様を,いくつかの機能に分割します。もちろん,種々な分割の方法が有りますが,常識的にインタフェースがより簡単な切り方がより良い分割であると言えます。また,既存のシステム要素(コンポーネント)が使用できるならば,それを使用することによって新規な開発が少なくて済みますし,最近流行のオープン指向にも沿っていることで,非常に好ましく受け入れられるものでしょう。
        4. 機能分割は,実際のハード,ソフトの分割と異なる可能性が有りますが,あくまでも機能的な観点から検討をするべきでしょう。
        5. 引き続いて,上記のように分割された機能単位ごとに仕様を定めます。そして,同時に隣り合う機能間のインタフェースの仕様を定めます。これが重要な作業であることは云うまでも有りません。インタフェースを定めずに,いくつかの機能要素を組み合わせても,最終的に動くようなものが出来上がるようなことを期待するほうが無理というものです。
        6. さて,これは,上位から下位に向かってのトップダウンの設計です。このようにして,実際の実現可能な要素の単位まで落とし込んでゆきます。
        7. 実現可能な要素というのは,候補が沢山有る可能性が有ります。また,機能分割する場合も,その分割方法に関しても多くの可能性が有るのが通例でしょう。そうすると,数多くの組み合わせが出来ることになります。<通常,この段階までを「設計」と言うようです。>
        8. それで,これらの全ての組み合わせに関して,評価尺度を用いてシステムの動作を評価します。当然,コストは制約条件に入るでしょうが,この制約条件の元で,評価値を最大にするようなシステムの構成を採用することになります。当然,工期も制約条件に入りますから,例えば,マイクロソフトの製品に頼るようなシステムを設計するようなことを試みるならば,製品の仕様も,出荷の時期も全く分からないわけですから,SEの苦労もどのようなものかがおおよそ分かるというものです。それも分からずに,むやみに,価格が安いと信じて,システムエンジニアの負担も省みずにマイクロソフト製品の使用を強制する上級管理者の多いことにはビックリします。
        9. まあ,このようにして,細部の構成要素まで仕様が固まれば後は製作ですから,システムエンジニアの仕事は終了です。
        10. もちろん,工程管理というか,プロジェクト管理という,コスト,品質,工程を所定内に納めるように,製作部門を管理するのもシステムエンジニアの業務の大きい部分を占めております。<これを忘れると大変なことになり,会社がつぶれたりしますね。でも,大会社は潰れないけど,受注金額の2倍も3倍ものコストをかけてシステムを完成させるような事例も,日経コンピュータの「動かないシステム事例」で山のように紹介されていますね。十分に気持ちを引き締めて仕事をしましょう。

      今日はこれで終了します。これ以上時間をかけてこのようなものを作っていると,私の上級管理者がどのように私を見ているかは十分分かりすぎるほど分かっているので,本当に困るのですが。

      この記事に対するコメントは小林まで。 御愛読感謝いたします。


本サイトの内容全ての著作権は,作者(小林健三)に所属します。無断の使用はお断りします。
更新情報は, What's new? を御参照下さい。
あなたは 番目の訪問者です。