後継者育成（事務引継ぎ）と仕様説明の方法

過去の桐井戸端ＢＢＳ　（桐談義・その他）

10194	後継者育成（事務引継ぎ）と仕様説明の方法	tomo	2001/03/11-04:33
高校で成績処理に関わる教員ですが、転勤になりました。仕事を引き継がなくてはなりません。過去２年間一緒にやって来た人に対してです。コマンド「コマンド」や更新可能な結合表は難しいようですがその場面場面で必要なことは出来る人です。問題なのは全体の構成です。どのように伝えればいいのでしょうか？全体の仕様を説明する為の常套手段があるのでしょうか？例えば、外部からのシステム開発を受注し複数の担当者で分担するときの方法やその結果を一つに構築するときの方法などが参考になるのではと思い、ここで質問することにしました。桐に限った事ではないのですが何かのヒントでも頂ければと思っております。今までの仕事が表計算やら手作業やらに戻るのは悲しことですが、それ以上に他の職員の仕事が増えます。同じような状況に窮している人もいるのではないかとも思うのです。ご意見を下さい。
10197	Re:後継者育成と仕様説明の方法	toshi-chan	2001/03/11-12:07
記事番号10194へのコメント tomoさん、こんにちは。 ★転勤の頃　私も２年前に転勤の話が持ち上がりましたがその時は立ち消えになり、１年前に転勤になりました。私の職場は桐ver３から使用しており、Ａさん→Ｂさん（昨年のｉモードセミナーに同行した方）→toshi-chan　と引き継いでまいりました。Ｂさんにしろ、私にしろ桐の魅力にとりつかれ、佐田さんの本をよんで独学で頑張ってきました。組織としての対応はしていませんでした。　さて最初の転勤話の時、桐使いがいなくなることを心配した上司が、私の後輩を大塚商会のセミナーに参加させようとしました。事務部門に相談したところ、「うちではＡｃｃｅｓｓを推奨しているのにどうして桐のセミナーに行くのか」といわれ、話はポシャリました。 ★私のシステムの作り方　ホントに大事なシステムで、これを使わないと手作業の時代に戻り多大な労力を要してしまう場合がありますね。このようなシステムでは必要なことをすべて一括処理で行えるようにしました。つまりユーザは入力の方法、どのボタンを押すとどのような処理がなされるのか、を覚えればいいこととしました。古いデータの削除と表整理も自動です。ただ、この方法だと定型処理以外は全くできません。そこでCSV書き出しやＫ３書き出しの機能もつけてあります。　それほどの重要性がないもの（無いよりはあった方が便利という程度のもの）は、会話処理中心にしてあります。それで皆は、並べ替え、絞り込みくらいは自力でできるようになったみたいです。 ★仕様の引き継ぎ　私が担当していた仕事は、執務室の移転とマシンの更新を控えていました。ファイルの移植等は後任者に自力でやってもらうしかありませんでした。そこで、エクスプローラを開いたような図を紙に書きました。フォルダの構成もツリー式に記し、どのフォルダにどのファイルを格納するのかを示しました。要するにマニュアルの作成です。上記のことは、システム概要としてマニュアルの先頭に書き、機能の概要はそのあとに書きました。具体的な操作方法等はさらにそのあとに書きました。文は少なくし、表をなるべく多くしました。 ★tomoさんの場合　引き継ごうとしている相手の方は、一括処理を書けるようですね。あとはその方の努力に任せ、一歩一歩機能の習得をしていただけばいいのでは。システムの操作方法の伝授はそれほどむずかしいことではありません。そのシステムの設計自体を伝授するのはなかなか困難です。わたしも前任者からの引き継ぎを受けたとき、項目数の多い表などは表定義すら理解困難でした。しかし執念？で何とかしました。　３月３１日までに相手の方にシステムのすべてを理解してもらうのは大変ですね。転勤後も電話で相談を受けるとか、このＢＢＳを紹介するのもいいと思います。管理工学研究所のユーザサポートの利用の仕方も説明しておくといいですね。私は２回前任の職場へ出張しました。原始的な方法の紹介で参考にならなかったかもしれませんが頑張ってくださいね。
10222	システム設計の考え方は伝えにくいようですね	tomo	2001/03/12-23:07
記事番号10197へのコメント toshi-chanさん、ありがとうございます。曖昧な内容なのでコメントが付かないかと覚悟していたので嬉しいです。 >…(略)…佐田さんの本をよんで独学で頑張っ >てきました。組織としての対応はしていませんでした。：企業でもそうなんですか。意外でした。 >　ホントに大事なシステムで、これを使わないと手作業の時代に戻り多大な労力を >要してしまう場合がありますね。このようなシステムでは必要なことをすべて一括 >処理で行えるようにしました。… ：そこは同様です。が、将来のマイナーチェンジにどの程度対応できるのか？ >…それで皆は、並べ替え、絞り込みくらいは自力 >でできるようになったみたいです。：ここが大きく違います。電算化を進めようとする思いが強すぎ、「普通」の人にはソフト(桐）を意識せずに使えるようにしすぎてしまいました。 >…エク >スプローラを開いたような図を紙に書きました。フォルダの構成もツリー式に記 >し、どのフォルダにどのファイルを格納するのかを示しました。：なるほど。下手に色々書くより、その方がコンピュータさわれる人にはわかりやすいですね。あの書込をした後、思いついて桐の表の中身や表定義をhtmlで出力し、ホームページの感じで参照すべきものにジャンプして見られるようなものを作成し始めました。先頭に概念図を付けること、大切ですね。 >…システムの操作 >方法の伝授はそれほどむずかしいことではありません。そのシステムの設計自体を >伝授するのはなかなか困難です。：やはりそうですか。知識と知恵の違いのようなものを感じておりました。が、それを何とか伝えうる知識の形に変える方法がないものかと考えていました。 >原始的な方法の紹介で参考にならなかったかもしれませんが頑張ってくださいね。いいえ、本当に有り難う御座います。後任者や組織全体が、一歩後退二歩前進となるよう頑張ります。
10225	ある事はあるのですが	佐田　守弘	2001/03/12-23:49
記事番号10194へのコメント tomoさん後任の方へのシステムの仕様説明などにつき御苦労されている事と思います。さて、システムの仕様を記述する方法は、ある事はあります。と言いますか、実際にはシステム開発の段階からその様な手法で、システム仕様を記述し、関係者間で内容の確認をしたり、開発者に仕様の説明などを行います。私自身も(実際にはある年齢の全社員が対象でした)、社内でその様な「システム分析」の研修を受けた事がありました。私が折に触れて、システム設計の前のシステム分析の重要性を言うのは、その様な背景からです。ただし、その内容はここに数行で記述できるようなものではありません。数日の研修を経て教えこまれ、かつ、実際に使った事例に出会ってみないとなかなか分かるものではありません。私自身が教えられた手法は、「Mind-SA」と呼ばれるもので、当時はMindリサーチ社、現在はトランスコスモス社で扱っております。では、それを導入すればよいではないかと言う事になりますが、金額的に簡単ではありません。大体、数千万円から数億円規模の費用を払ってコンサルティングを受けるものですから、おいそれとお薦めできるものではありません。その真髄らしきものを一言で言えば、システム概念図といった絵でシステム全体の概要を描き、システム連関図と呼ばれるチャートで各事象や処理の連関性を記述して行きます。それ以外に様々な書式の書類があり、それらのフォーマットにのっとって業務内容の分析結果をまとめて行けば、問題点が明らかになったり、現状の状態、あるべき姿が記述でき、どう言ったシステムを構築すべきかと言ったものが作られて行きます。通常、現状の業務を分析するところから数箇月ないし年単位の時間を掛けて分析し、そういった書式を作って行く訳ですが、でき上がっているシステムであれば、それを記述するのは比較的容易なのかも知れません。佐田守弘(KS-00119)
10233	Re:後継者育成と仕様説明の方法	えむに	2001/03/13-08:50
記事番号10194へのコメント tomoさんこんにちは。参考になるかどうかは解りませんが・・・・最近、他の人が作った桐の処理を見る機会が多くなりました。（作った会社が潰れたとか辞めたとかの依頼です）仕様書がある場合も無い場合もあります。一番理解しやすいのは、懇切丁寧な処理の仕様記述よりもファイルの種類の分類訳がはっきりしている事が理解を早くできます。テーブルに関しては、１．データの明細が入っている台帳に相当するものなのか。２．何か処理する時に結合や表引きなど「参照」で使用するのか。３．分析や印刷の過程で使用するテーブルなのか。このヘンの分類が明記されていると解読するためには理解が早いんです。この表題には関係ないのですがちょっと個人的な感想です。(笑) ある処理をする為に作成された処理過程のテーブルが沢山残してあるケースが多くこれには悩まされる事があります。せめて表題を変更して「削除可」とかいれてあると良いんですが。システムは、ちゃんと稼働しているものは必ず変更の時期がきます。そして他人が改造するケースは多くなってると思います。その時の為にもシステムは不用なものは削除されたシンプルなのが理想ですね。他人の一括処理を解読するより、明確なテーブルがあればそれを使って部分的に作り直した方が圧倒的に早いケースは多いですし。桐＝個人的に作るシステムではなくなりつつあると思います。あっ、ちと関係ありませんでした。ごめんなさい。
10241	Re:後継者育成と仕様説明の方法	宮城	2001/03/13-12:28
記事番号10194へのコメント私の場合は全体概要の「マンガ」をひとつ。あとはひたすら文中コメント。見てみようという気になってくれたときに、そのほうが便利がいいかなと。別途に仕様書書いたって、なかなか読んでもらえないし、書いてるそばから次の修正がきたりしますから。それでも足りない部分は「口伝」。（別にふざけているつもりはなく、「効率的」なひとつの方法だと思っています。読んでももらえないドキュメント作るのは空しいものです。）
10242	Re:ある事はあるのですが	tomo	2001/03/13-13:10
記事番号10225へのコメント佐田先生　ありがとうございます。金額の単位が大きいですね。そういう質の事柄なんですね。技術的な事柄と、組織上の問題をうまく区別できればわかりやすくなるように思えてきました。がんばってみます。
10243	ＴＢＬの分類	tomo	2001/03/13-13:16
記事番号10233へのコメントえむにさん　ありがとうございます。確かに経過的なファイルをつくりますね。使いっぱなしのことが多いです。テーブルの分類、大変参考になります。もう少しがんばってみます。
10244	「マンガ」ですか	tomo	2001/03/13-13:23
記事番号10241へのコメント宮城さん　ありがとうございます >私の場合は全体概要の「マンガ」をひとつ。あとはひたすら文中 >コメント。見てみようという気になってくれたときに、そのほう >が便利がいいかなと。：「マンガ」って、その手のセンスを必要とするみたいな気がします。多分、そういうセンスがあれば今もあまり苦労せずに全体像なんかを伝えられたんじゃないかとも思ったりします。文中のコメントというのは一括処理の中のことですね。それはしつこく書いておこうと思っています。 >別途に仕様書書いたって、なかなか読んでもらえないし、書いて >るそばから次の修正がきたりしますから。本当にそうなんです。印刷物があるのに聞いて来たりする人多いですからね。マニュアルに書いてあるよといっても、聞いたほうが早い、と。もう少しがんばってみます。
10248	それがシステム概念図です	佐田　守弘	2001/03/13-13:51
記事番号10241へのコメント宮城さん、tomoさん >私の場合は全体概要の「マンガ」をひとつ。あとはひたすら文中 >コメント。これがシステム概念図と呼ばれるものです。ひと目でシステムの概要を把握できる紙を１枚。全てはそこから始まります。佐田守弘(KS-00119)
10273	Re:それがシステム概念図です	tomo	2001/03/14-05:39
記事番号10248へのコメントそうですか。それがシステム概念図。やはりこの部分に私の足りないとこがあるんだと確信。できるところから手を付けていきます。関係ないですが、転勤先では桐５が動いてました。

戻る