私が，開発現場の標準化スタッフ・管理職(1986-1989)をしていときにやったときの工夫です。
標準を普及していくにはどうしたらいいのか、いろいろなノウハウがありますよね。
私が、標準化の仕事から離れる最後の方に気が付いたテクニックに、「コンビニ標準」と名付けたテクニックがあります。
「コンビニ標準」とは、選べる標準ということです。それぞれの標準化の項目の長所、短所を公開して最終的な判断は、採用するかしないかは相手に任せるというやり方です。
なぜ、これに気付いたかというと、会社で昼食の取り方からです。中年以上の社員は業者の弁当をとっているのが圧倒的でしたが、若い社員は近くのコンビニに買いに行きました。値段、栄養のバランス、手間を考えると業者の弁当が合理的です。それなのに、なぜ、若者はコンビニに買いに行くのか？ 不思議に思い行く人に聞いてみると、味がいいとか、安いとか、散歩をかねているとかありましたが、「選べる」魅力があるというのが決定的な理由であると判断しました。
このことからヒントを得て、「選べる」標準を目指しました。あることを実現するのに、例えば3通りの方法が現場であり、可能であることをことを指摘します。
その３通りのなかから、標準を決めます。３通りそれぞれの長所と短所の比較表を書きます。標準としてはこう決めたが、仕事によっては、この比較表を参考にして選んで下さいというやり方です。
このやり方だと、標準を採用する方に自分で決定したという満足が生まれます。結果としてかなりの標準化が浸透します。結果としてほとんどの人は、こちらが指摘した標準を採用するからです。いくつかの方法を並べておくと、標準を検討している人はこんなに研究したのかとか、自分のいままでやっていた方法以外にこんな方法があるのかって、結構面白がってくれます。
標準化を進めると最初はどうしても、「押しつけ標準」になりがちです。「押しつけ標準」から、「コンビニ標準」へ、これが最後の方のテクニックでした。
あるソフトウェアの技術者の会合で、５０才の人が、「最近の若い者は机上デバックをしないので、だめだ」と主張した人がいました。それを聞いていた若者が「机上デバックを重視するのは、机上で見渡せるぐらいの小さなプログラムしか経験していない年寄りの台詞である」と反論して、けんけんがくがくと議論を戦わせていました。そこに現れた仙人は、「どちらがいいか測定したらどうかね。もうそれは議論するネタではないよ。どうせコンピュータを利用して開発しているのだから、コンパイラを細工して、個人ごとのコンパイル回数とプログラム当たりのコンパイル数をとって調べるといい」
そこで私は、自分の会社の開発メンバーの，プログラムが完成するまでのコンパイル回数を測定することにしました。また、開発している人ごと完成までのコンパイル回数も測定しました。人の評価には使わないという前提で、本人にそれをフィードバックしました。
机上デバック派が効率がいいか、画面デバック派が効率がいいか、測定しているうちに、数字を見ていることがおもしろくなって、もうそんなことはどうでも良くなってしまいました。（この件関しては、好きにしたらが私の見解）
シンタックスエラーがなくなるまでのコンパイル回数と実行時エラーがなくなるまでのコンパイル回数の比率もおもしろいです。
シンタックスエラーはたいていコンパイルエラーに番号付加されているので，どのコードのエラーがどれくらいでるか、ABC分析もしました。Aランクのエラーを未然に防ぐだけでかなりの効率が上がります。Aランクのエラーの対応の仕方は新人研修などで重点的に学習しました。
プログラムを作成していて、試しに一度コンパイルしてみるかって、よくやりませんか？
この試しコンパイルは，コンピュータパワーが大きくなった現在，マシンからみるとそれほどのコストではありません。しかし，開発する人からみるとどうでしょうか？
ここで私が提唱したのは、「コンパイル一発主義」でした。文法エラー、論理エラーを含めて、一度のコンパイルで完成させるということです。実際には、一度のコンパイルで完成させることは、ほとんどありません。しかし、一発で通すという気合いが、プログラム作成に集中力を生み出します。また、エラーが出たときの反省する過程も気合いが違います。コンパイルをかけているときの、どきどき感もおもしろいです。小さなエラーでも発生させない工夫がそのうち生み出されます。
みなさんの職場でも、ぜひ、「コンパイル一発主義」を普及させて下さい。
コンパイルエラーとか、テスト中のエラーなど、バグ・トラブルシートに記入するよう、開発メンバーに指導しました。この用紙はA4１枚で一項目記入しました。
記入項目の主なものは
エラー現象
原因
対策
再発防止のテクニック
です。
例えば、
エラー現象
未定義変数の使用
a1 = Falsu
原因
Falseの間違い
対策
FalsuをFalseに修正
再発防止のテクニック
コンパイルの前にスペルチェックをかける
Falseは手でいれず、どこかの文字をカット＆ペーストする
エディターでALT+FでFalseを入力できるようにする
などと書きます。
再発防止のテクニックは、実現不能のものでもかまわず記入するようにします。
なお、このバグ・トラブルシートは、プログラム開発だけでなく、シスアド業務のプリンタエラー対応などにも使用できます。プリンタエラーが発生したら、そのつど、この用紙を記入します。原因、対策が不明なときは、現象だけでも書いて起きます。その記録は、プリンタのそばにおくと役立ちました。
この用紙、書くのが面倒ですが、効果は歴然です。この用紙、システムテストなどにも使えます。
みなさん、職場の机の上は整理されていますか？
５０人ぐらいの部署を想像して下さい。
机の上を片づけろとか、棚が足らない、通路に物をおくなよ、とか、会議で話題になったときが初めどきです。ドキュメントであふれかえっているのは棚が足らないからだとたいていなりますので、では棚の整理から始めようと会議で決めます。それで、必要なら棚を購入しようと決めます。（本当は購入の必要はありません）
まず、職場の整理状況を確認する意味で写真をとります。５０枚ぐらいをめどに、何人かの机の上、引き出しのなか、机の下、棚の中、棚の上を撮ります。棚の中は、ふたを開けて、徹底的に撮影します。フロアー全体のレイアウトが見える位置から何枚か撮っておきます。ときどき、人も入れて撮るとあとから楽しいです。
次ぎに、棚の一番下はすべて破棄をすると宣言します。必要なものは、上の段にあげるようにと指示を出します。
捨てるのは、２段階に分けます。最初は一月後ぐらいに日程を決めて、棚の一番下の物を管理者の机のそばなどに、大きな机を用意してそこに並べます。そこに一ヶ月ほど展示をして、必要がないと判断したものは、本当に破棄をします。これで、棚のスペースは１割以上は空きます。これはポスタを作成して掲示で知らせます。棚のふたはできれば以後開けたままを原則とするといいでしょう。ふた付きの棚はふたをはずします。
次ぎにバインダ背表紙の標準化をします。整理整理と同時でもいいです、これで、また棚がさらに一割ほど空きます。次の２つを実施します
１ 背表紙には、内容を表す言葉 背表紙を書いた年月日（下に補足あり）、バインダの管理者を書くと決めます。この３つをどのように背表紙に書くか決めて標準化をします。ここで欲張って、色分けしようとか、破棄の予定日付を入れようと思ってはいけません。また、分類のコードを付けようとは思ってはいけません。この３つだけにします。ただし、この３つは絶対に守ります。バインダの管理者がよく分からないときは、背表紙を書いた人の名前で結構です（下に補足あり）。仮でもいいので３つは絶対に書きます。
２ 上記の背表紙の標準化を、新しくおろしたバインダと、今、棚にあって背表紙に何も書いていないものに適用します。欲張って、現在あるすべてのバインダに適用しようと思ってはいけません。
次ぎ、通路にあるドキュメントとか、机の上のドキュメントは基本的には帰りにには片づけると決めます。ここでミソは、イスの上には置いて帰って良いこと、机の下も置いてもよいことにします。
ここら当たりで一ヵ月ですので、写真をとりましょう。最初の写真と比較して、改善前、改善後とダイエット広告のようにまとめて回覧しましょう。
以上、標準化として
バインダの背表紙の書き方（守る３つの事柄、あとは自由）
帰りには机の上には書類、バインダを置かない
通路には書類、バインダを置かない
棚の上に物はおかない
を以後守るようにします。
以後、バインダの表紙の中で、バインダ管理者の名前に他の部署や退職した人の名前がないかどうかなど一年に一度見直しをします。背表紙の標準化が棚の７割位守れた位で、古いバインダも日にちを定めていっきに背表紙を標準化してもらいます。このメリットは仕事が背表紙を通じて視覚化され、責任者を明確にしていくことで（急がずに）改善の責任も明確になって行きます。これを３年ほどやってたら、いよいよ、棚に番号を振り、バインダに番号をつけ、コンピュータ検索の対象にしていきます。でもこの頃には、すでにドキュメントを探すために労は多くなく、コンピュータ化するメリットがなくなっていたりします。
この標準化されたバインダは、仕事の項目を明確する効果、引継項目を数量化するにも役立ちます。
補足
バインダの日付
中身を作成した日付ではありません。バインダ自体はたいてい固定的で中身がどんどん変化していきます。中身に対応した日付は確定することは、たいへんです。背表紙を記入した日付を書くと決めると、簡単に日付をいれることができます。もし、背表紙を修正したときは、日付を更新してもしなくてもどちらでも結構です。
バインダの責任者は？
忙しい部署では、だれかに背表紙をまとめて書かせたりします。そのとき管理者の名前が不明なときは、記入した事務職員の名前で結構です。１年ぐらいたつと、その仕事に全然関係ない人の前が書いてあることは、だんだん恥ずかしい雰囲気がでてきます。いずれ、名前がだんだんと妥当になってきます。
もし、バインダがどこか他の棚に紛れこんだときも、その名前をヒントに、正しい位置がわかります。
上の「棚整理、バインダの背表紙」から
> 次ぎ、通路にあるドキュメントとか、机の上のドキュメントは基本的には帰り
>にには片づけると決めます。ここでミソは、イスの上には置いて帰って良いこ
>と、机の下も置いてもよいことにします。
実は、机の下も本当は置かないと標準化した方が、いいです。しかし、机の上は置いてはいけないという規則は、守るのが大変です。逃げ道を用意しておく必要があります。逃げ道は、イスの上と机の下です。イスの上は毎朝、これを整理しなくてはと本人が自覚をします。また、ある量を超えてはおけません。
この段階で，「ドキュメントの共有推進」キャンペーンを実施します。
仕事に関するドキュメントは出来るだけ各自コピーで保存せず，共有のファイルを利用しようと持って行きます。バインダを自分で所有せず，グループの所有としていきます。ここで，自分のために整理するのではなく、この規則は、バインダをみんなで共有化をしやすくするためであると持っていきます。
机の上、棚の中、コンピュータ（サーバー）の中身は連動してます。まず、物理的なところの整理で習慣化と、整理した方がいいと納得してもらい、だんだんとバーチャルなコンピュータの中身の整理と持っていきましょう。
社内にいくつかの書類があふれて整理したいと思っている人も多いと思います。どんな種類の伝票、報告書があり、目的は何かとリストアップするのが業務改善の最初です。
今回は、本質的なテクニックではありませんが、私が実施したものでこんなものがあります。
XXX表
パソコンなどに入って表計算のワークシート、もしくは、それで打ち出しした書類
XXX書
A4一枚の書類
XXX票
A4(あるいはB5)未満の伝票類（書類）
XXX入力、XXX登録など
コンピュータの画面にでる名称
こんな感じで、社内のドキュメント関係の名称を整理していきました。一気にやるほどの価値がありませんが、改善の過程でこのように統一して行きました。仕事がシンプルになって行きますよ。
もうすでに、改善運動で書類のA4化を実施したところも多いと思います。私ももちろん実施しました。業種にもよると思いますが、私の職場では，最終的には、B4は消えませんでした。B4を消すことを一生懸命努力するとけっこう疲れます。現場は、A4に統一されてくる過程でほとんどの書類がA4化されるとB4書類は、折り込まれてB4バインダに綴じられます。さらに、A4化が進んでくると、B4で作成した原紙をコピーしてA4にしてしまい、B4は破棄してしまいます。強制力を出さなくても自然とそうなるようです。
A4化キャンペーンと同時に，A4書類の雛形を作成することをおすすめします。ワープロなどで、余白を標準化することです。これは会社で使用しているプリンターをもとに、印刷実験をしながら、天地、左右の余白を決定します。左余白は、バインダで穴をあける前提で決めます。単純な寸法では、天地はそれぞれ１０ミリ、左は２０ミリ、右は１０ミリです。これを基本書式として、サーバーにアップしておきましょう。
私が実施していた会社はソフトハウスでしたので、設計書関係はすべてこの雛形をもとに作成しました。雛形はあまり欲張らずに、最初は寸法だけの白紙、それから、一番よく使用すると思われるものから１０種類ぐらいから初めましょう。これも、現場は、ダウンロードしても、いろいろ修正して使用します。そのうち、修正する暇があれば、中身に時間をかけた方がいいとなります。いろいろバリエーションが増えてもあまり叱らず逆に参考のためにその書式をもらいましょう。
書式の統一は、現場にこんなカッコイ書式は作れないと思われるのがコツだそうです。さらに、サーバーにあげておく雛形は、すべて「未使用出張申請書」のように未使用という名前を付けました。これは、ゼロックス社のJSTARから学んたテクニックです。
承認印の位置
申請書など、上司、その上の上司の印を押す欄が必要になります。標準は印の欄を３つにして、中から外に向かって、申請者、上司、その上司と欄を作ることをおすすめします。
理由は，申請書などの書類は、位が上にいけば行くほど、数が多くなります。上の人の印が押しやすい位置から配置を決めています。
決済印の数はほかっておくと、増殖します。中から外に印の欄を作ると増殖がしにくいです。
フッタに書式のバージョンをいれる
基本的に書式は仕事の改善とともにどんどん変わっていきます。ぜひ、フッタ機能を利用して、その書式名とバージョン、日付などを入れておくことをおすすめします。バージョンの付け方は別の機会に説明します。
例 有給申請書 19960102 Ver1.00
プログラムなど更新管理をする上でバージョンを付けますよね。その付け方で、私が実施していたのを書きます。文書書式、設計書、プログラム、関数など更新管理を必要とするものに付けます。
A,B,Cを数字の一桁を表すとすると、
Ver A.BC 例 Ver 1.01
とします。
一番後ろのＣは、基本的にバグ修正です。書類でいうと誤字脱字の修正レベルです。機能の変化はありません。
０から始めるか、１から始めるか、ほとんど気分でやってまいた。ほんとに新規であれば、０。その書類、そのプログラムと同等なものがあった場合は１、新規に作成したものであれば０とした例が多かったです。
Ｂは、副作用のない機能アップです。Ｃの桁上がりと、過去の機能を満足してさらに機能アップしたときに変えます。使用するメンバに知らせた方がいいレベルです。しかし、もし、この機能アップを知らなくも実害がないレベルです。
Ａは、大幅な機能アップとします。Ｂの桁上がりと、モジュールなどでは，パラメータの数など、変化したときに変えます。書類などでは、ここがアップすることは、書類の流れ自体が変化したときです。
関数を２つ使用した上位のプログラムのバージョンの付け方
この場合は、関数とそれを利用したプログラムとバージョン番号を別々につけます。Ver2.01の関数Ａと、Ver1.21の関数Ｃを利用して新規のプログラムを作成した場合は、プログラムはVer1.00です。
ここで関数Ａのバージョンアップの案内が届いて、Ver2.01から、Ver2.20と上がったとします。この番号のアップは，単純なバグとりではありません。プログラムにそれを使用すると、修正、テストが必要です。
もし、関数ＡがVer2.01から、Ver2.03にアップならリコンパイルだけでいいです。で、このプログラムのバージョンは、このプログラムを使用する上位モジュールが、リコンパイルのみで済むなら、Ver1.00からVer1.01とします。もし、機能がアップしたら、Ver1.10です。ほとんど無視ができる修正でも少しでも変えたら最後の数字はアップします。
このバージョンの付け方を，少し変更して，Ver 2.01.0105 のように，後のコンパイルの管理番号を入れるといった使い方ができます。商品化されもの場合，Ver 2.01.0105 から Ver 2.10.3105 のように，小数第一位が，変化した場合は，有料バージョンアップといった位置付けができます。
職場でプログラムの名前を呼ぶときに、英語のコードで呼んだり、日本語の名前で呼んだり混乱していませんか？
人間ならどちらでいっても判断してくれるので問題ありませんが、設計書などに書くときにどちらかに統一して置かないと不便なときがあります。私が実施した標準でつぎのように決めました。
例えば、売り上げ入力プログラム、URI001があったとします。
プログラム名 ：売り上げ入力
プログラムＩＤ：URI001
と名とIDで区別をします。日本だけで通用するインチキテクニックです。英語では、両方ともIDだし、Nameです。ちなみに、英語の世界では、「売り上げ入力」にあたるのは、NameやIDではなく、コメントとか、テキストとか呼んでいるようです。
このやり方は，かなり普及しました。どこからでこの規則を見つけたら，教えて下さい。
かって、私の部署は、管理課（後に開発支援課と名称を変更）といっており、開発部に発生する事務処理も担当していました。その部署の事務系職員がその事務を担当していました。上から言われた仕事を片づけることで一日が終わっていました。
私の下にその事務系職員が付いて私が上司となり、３・４人で改善をはかりました。
改善の一つは，毎日定番でやる仕事を明確にすることでした。郵便の受付と配布、現場のだれかの遅刻届け、有給届けの書類の整理などです。まず、書類を回収する人、たとえば、部長、課長など机に、管理課行きというボックスを用意しました。また、受付ボックスも同時においてもらいました。
正確な時間は忘れましたが、朝１０時前後に１度目の配布・回収し、それをできるだけ早く事務処理をします。お昼前に、２度目の回収・配布をします。最後３時頃に配布・回収をしたと思います。朝１０時までに提出した書類は、たとえば旅費精算伝票などは、お昼の１時から、本人が管理課にくることで出金できることが目標です。また、有給の書類なども午前に受付したものは、昼までには回すべきところには回して印をそろえてます。
回収した書類の定番のものは何時間で処理が終わるかを改善対象としながら短縮を目指します。定期的に確実に回収される、決まった時間に事務処理が終了するという安心感が現場にできると、現場からの問い合わせは減ります。その分また、事務処理の効率が上がります。
回収・配布を管理課が自らがやることにより、バラバラに書類を受け付けることが無くなります。さらに、現場の人に、管理課に来てもらって書類を書いてもらうと、どうしても、書き方など説明したり時間がかかりますが、こちらから取りにいくという体制にすると、書き方の見本などを作成してみんなが自分の机の上で書ける工夫もすることになります。
朝の回収の量で、ルーチンワーク担当の人の目標が決まります。来たら処理をするという事務の仕方だと、だらだらとなりやすいですが、目の前にxxxの伝票が５枚、yyyの書類が３０枚と具体的に作業も明確になり、やる気もわきます。
管理課とか総務部とかは、よく威圧的に、書類をもってこさせるという対応になりがちですが、それは、逆に損です。
最後の方は、現場全体に午前中は自分の仕事に集中しようというキャンペーンもやり、午前中の電話の内線使用自体を減らすこともしました。代わりに昼からは、敏速に内線などにも対応できるようにします。
こうして、最初は事務職員の一日６時間ほどかかっていた毎日の仕事が、３年ほどで、速いときは１時間ほどで片づくようになりました。改善前は、出張の精算も伝票を提出してから、お金がもらえるまで、一週間かかることもありました。改善後は、朝請求伝票が来たら、昼には出していました。
事務処理のルーチンワーク化とそれ以外の仕事と分離していくのは、ボックスの回収を軸に展開をします。回収は、書類を取りにいくというだけでなく、仕事の時間をめぐる主導権をこちら側に取るという戦略的な意味もあります。
ルーチンワークとそれ以外の仕事を分離していくというのは、複雑な事務作業から、単純な事務作業を切り出していく作業でもあります。そのテクニックとして、ルーチンワークのローテーション化があります。
ルーチンワークは、マニュアル化して、事務職員内でローテーションをします。もし、事務職員が３人いたら、同じ人が処理するのは３日おきです。これによって、その日の事務処理はその日に済ませようという意識も生まれます。あとの２人は、単純な事務作業でなく、各自のテーマに従った事務作業のコンピュータ化の計画など時間をかける仕事をします。
総務などの仕事は、よくその人が休むとよく分からないということがあります。ルーチンワークをローテーション化することで，そういった問題の発生が防げます。ローテション化がされていれば、日々に発生する仕事の一時的な対応なら総務のみんなが知っているからです。
有給などの管理はたとえばＡさんが担当だったとします。しかし、有給関係の申請などの受付処理などは、ルーチンワークでだれでもできるようにします。Ａさんは、月に一度の台帳の更新時に責任をもって処理をする、有給処理のルーチンワークのマニュアルの改善責任を持つという風にしていきます。
ルーチンワーク化とローテーション化は、最初は大変で、改善時間もかかりますが、これによって、仕事は視覚化され、見通しがよくなります。さらに、事務員の有給がかなり自由にとれる体制にもなります。事務改善のコンピュータ化を検討する時間も生まれるし、さらに、ワークフローがかなり明確になります。
よく事務所などで、毎週月曜の朝とか朝礼とかしますよね。朝礼もやり方で効果ありますが、私が実践したのに、１６時の終礼があります。
１７時３０分に終業の会社で、１６時に終礼をするわけです。その終礼は、形式ばった５分ほどの終礼ではありません。もし、あなたが五人をグループとするリーダであったとします。あなたをいれて６人でミーティングをします。今日はどんな仕事をしたかを簡単に言ってもらいます。それをその部署の日誌に記入します。一人一行で十分です。
次に、その日にあったクレームの確認をします。そして、そのクレームにどう対応したか、そしてどうなったか、次からどうしたらいいかを話し合います。もし可能ならマニュアル化を目指します。それらを日記に記入しておきます。これが中心です。
最後に明日の仕事の確認と、今日，残業をする人がいるかどうかを確認をします。もし、本人が残業をしたくないなら、みんなで残りの時間を手伝ってやります。
私が部署で書いた日誌ですが、最初の１年位はＢ５のノートでしたが、そのうちに、ハイパーテキストのソフトを使用し、保存しました。後で改善資料として利用しました。
私の失敗
この４時終礼は効果はものすごいです。その部署の残業がほとんどなくなります。仕事は効率化されているのですが、他の部署からみるとあそこは遊んでいるとかクレームがでます。そのためには、仕事がどの程度改善されたか、具体的な資料をおおきく掲示するなり宣伝をしないといけません。
定時前に暇になるので、トイレに立ったついでに、女の子がきれいにお化粧してきます。これが、かなり目立ちます。机の整理とか、明日の準備をするようにし、たばこを吸ったり、お茶を飲んだり、お化粧したりは禁止します。結果的にこの１６時終礼は、効果があったのですが、他の部署からのクレームで私の直属上司より、やめてくれといわれて中止しました。
2004/09/30 宿題メール特別号のために整理
1997/05/10 私が、Niftyserveライセンスフォーラム 情報処理大学にて，上級シスアド向け ノウハウとして公開したもの（96/12/15〜）を一部修正したのものです。neccaの９７年５月１０日会合で発表
| 当時の前書き
この文書は，私が、Niftyserveライセンスフォーラム 情報処理大学にて，上級シスアド向けノウハウとして公開96/12/15〜）したものです。採録にあたり，一部修正しています。 まずは、私のシステムアドミニストレータから見た経歴 1957 誕生 1982 初めてプログラムを作成する 1985 (株)テスク（IBMオフコン向け小売店用業務パッケージを開発している）に就職 1985 社内で、自主的にS/36,S/38のマニュアルの整理、プログラムのパターン研究開始 1986 (株)テスク開発部管理課(後に開発支援課に名称変更)にて標準化を担当 以後、開発部（50人ほど）全体の事務管理、開発標準管理を担当 1989 ユーオスグループ（IBMのオフコンAS/400系を得意とするソフトハウスのグループ)の標準技術委員としてユーオス標準を作成 1992 日本総合ビジネス専門学校（当時校名：日本情報処理専門学校）教員として転職 1997 インターネットに末広ページを上げる。 |