実際とは？

1.1実際原価の本質実際原価は財務諸表作成のために不可欠な原価であり，財貨の実際消費量をもって計算した原価である．また，実際原価は厳密には実際の取得価格をもって計算した原価の実際発生額であるが，原価を予定価格等をもって計算しても消費量を実際によって計算する限り，それは実際原価の計算である．実際原価は次のように表わすことができる．
個別生産及び大量生産という2つの異なる生産形態に応じて，原価計算の形態も個別原価計算と総合原価計算とに区分される．
個別生産においては，製品別にその製造を命令する製造指図書が発行され，この指図書をもって個別の製品を代表させて，製造活動を効果的に運営していこうとする．この個別生産に適用される原価計算を個別原価計算という．個別原価計算では，製造指図書が特定の製品を代表して，その製品の製造において発生した原価をこれに記入し，その製品の完成と同時に，製造指図書ごとに集計して，その製品原価が計算される．
大量生産においては，同一種類の製品が継続的に大量生産されており，かかる生産形態に適用される原価計算を総合原価計算という．総合原価計算は一原価計算期間に製造された製品の総生産量でそれを製造するために発生した原価を按分することによって，その製品の単位当り平均製造原価を求める原価計算の方法である．それ故，総合原価計算は個別原価計算と異なり，製造指図書は製造命令書としての役割を果たすだけにとどまり，原価集計の単位とはならない．
製造指図書は製造命令書，製作伝票とも呼ばれ，特定の製品の製造を製造部に命令するための書式である．生産企画部では，特定の製品を製造するとき，製造品目別の設計図の作成，各種材料の所要，所要作業の手順等についての製造企画を行うのである．製造現場では，この製造指図書を受け入れることによって，特定製品の製造が開始され，同時に必要な材料，労務，用役等の消費に関する権限が製造現場に与えられる．製造指図書には，特定製造指図書と継続製造指図書とがある．
特定製造指図書 これは個別生産を行う企業で発行される指図書で，一定量の特定製品を製造することを命令するものである．
継続製造指図書 これは大量生産を行う企業で発行される指図書で，同一種類の製品を反復継続して製造することを命令するものである．
主製造指図書と副製造指図書 大規模な生産を行う場合には，工事全体の製造作業について発行される基本的指図書とともに，この工事をいくつかの作業に区分して，それぞれの製造指図書が発行される．基本的な製造指図書を主製造指図書といい，各区分ごとの作業に対しての製造指図書を副製造指図書という．
2.1個別原価計算の概観建設業，精密機械工業等のように受注生産あるいは請負生産を行う場合，その受注品あるいは請負品の製造原価を計算する方法を個別原価計算という．
受注生産においては，当該受注品の製造開始前に製造指図書が発行され，それにもとづいて製造が行われ，製造原価の計算もこの製造指図書にもとづいて作成されている原価計算表別に集計される．この場合，原価要素のうち直接費は直接に当該指図書番号の記載された原価計算表に賦課できるのであるが，製造間接費はなんらかの方法によって，各指図書番号の記載された原価計算表に配賦しなければならない．この製造間接費の配賦方法の相違によって，単純個別原価計算と部門別個別原価計算とに分けられる．
個別原価計算は，原則として，「原価要素の費目別計算」，「部門別原価計算」および「製品別原価計算」の3段階からなっている．個別原価計算においては，特定製造指図書が発行されており，この製造で発生する製造原価を集計するために製造指価計算表が作図書番号の記載されている原成される．原価計算表は製造が完了すると締め切られ，製品原価を算出し，これを製品勘定，または売上原価勘定へ振り替える．また，原価計算期末に製造が未完成のときは，原価計算表の原価合計は仕掛品勘定へ振り替える．
この原価計算表（図3-1）への原価の集計は直接材料費，直接労務費，直接経費および製造間接費別に行われるので，各々の記入方法を説明することが，個別原価計算の手続を示すこととなる．
直接材料費は材料庫出講求書（出庫票）の製造指図書番号によって，当該原価計算表の直接材料費の欄に記入する．
直接労務費は作業時間報告書または出来高報告書の製造指図書番号によって，当該原価計算表の直接労務費の欄に直接記入するか，あるいは直接材料費と同様に直接労務費集計表に作業時間報告書または出来高報告書から記入して，その合計額を定期的に記入する．
直接経費はあまり発生せず，僅かに外注加工賃や特許権使用料等の費目が直接経費として発生する．このため，図3−1の原価計算表には直接経費の欄が設けられていない．
製造間接費は材料庫出請求書等の消費伝票や支払伝票等の伝票顆により把握されるが，この伝票類には製造指図書番号が記入されておらず，しかも製品の製造のために消費された原価要素である．
3.1材料費の意義と分類材料とは，製造工程で消費される物品であり，この物品の消費によって生ずる原価を材料費という．「原価計算基準」では，次のように分類される．
仕入先からの材料の調達には図3−2で示されているように，4種類の書類が重要な役割を果たしている．4種類の書類とは，材料購入請求書，注文書，送り状および材料受入報告書である．
材料購入請求書 材料の購入は材料購入請求書を発行することからはじまる．これは外部の仕入先からある品目の材料を調達してほしいという購買部に対する請求書である．請求材料の現在の貯蔵状況および将来の必要性を最もよく知っている者がこれを作成するのが原則である．
注文書 購買係は仕入先を決定すると，注文書を発行する．注文書は原本を仕入先に送付するとともに，複写3通を作成し，1通は購買係が手許に保存し，1通は倉庫部の受入係に回付し，1通は会計係に回付する．注文書は仕入先がこれを承諾すると契約書となるので，契約書として完全な一定形式のものでなければならない．
材料受入報告書 仕入先では，材料納入と同時に送り状を購買係に郵送する．この送り状には，材料の品名・規格・品質，数量，単価および金額等が記載されており，購買係から材料元帳係および会計係に回付され，会計処理のための証憑書類となる．現品が到着すると，受入係はその数量，品質およびその他必要事項について注文条件に合致しているかどうか検査し，その結果を材料受入報告書に記録する．購買係は送り状および照合済みの材料受入報告書にもとづいて材料仕入帳への記入を行う．
図3−3は倉庫からの材料の払出に関する会計処理手続を示している．第1段階は材料が製造に必要であるという事実の認識である．材料の必要なことが認識されると，材料庫出講求善が倉庫から材料を得るため作成される．材料庫出請求書は材料の消費についての総勘定元帳および補助元帳への記入のための原始伝票である．材料庫出請求書にもとづく材料の消費についての総勘定元帳への記入は材料諸勘定の貸方への記入と製造勘定（仕掛品勘定）あるいは製造間接費勘定の借方への記入となる．
材料の消費により，材料費が発生する．この材料費は材料の実際消費量にその消費価格を乗ずることによって算定される（材料費＝材料の実際消費量×その消費価格）．それ故，材料費を把握するには材料の実際消費量とその消費価格を測定しなければならない．
消費量の計算 材料の実際消費量の測定は，材料庫出請求書にもとづいて行われている．この測定方法は継続記録法と呼ばれている．材料の実際消費量の測定が継続記録法により行うことが困難な場合，また継続記録法の実施が可能であっても，測定される金額が少額である場合には，棚卸計算法や逆計算法が用いられて，その消費量が測定される．棚卸計算法は定期的に材料の種類ごとに実施棚卸を行い，棚卸高を求め，これを材料の繰越高と仕入高の合計から差し引くことによって消費量を期間的に測定する方法である．逆計算法は製品単位当りの予定消費量または標準消費量を決定しておき，製品の生産量に単位当りの予定消費量または標準消費量を乗ずることによって，材料の実際消費量を推定する方法である．
材料の購入原価 材料の消費価格の測定であるが，このためにはまず材料の購入原価を測定し，これにもとづいて消費価格を決定するのである．材料の購入原価は購入代価，すなわち送り状値段にその購入から庫出までに要した諸費用を加筆した価額である．すなわち，次の算式によって算定される．
材料の購入代価を材料主費といい，材料の購入から庫出までに要した諸費用を材料副費という．この材料副費は，これを�ヽ杏�副費と��内部副費とに大別することができる．外部副費とは，買入手数料，引取運賃，荷役費，運送保険料および関税等の材料の買入れに要す引取費用をいい，内部副費とは購入事務，検収，整理，選別，手入れ，運搬，移管および保管等に要した外部副費以外の費用をいうのである．
材料の消費価格（または半価） 同種材料であっても，仕入先，仕入方法，仕入条件，仕入数量および仕入時期等が異なるとき，その購入原価は異なるのが一般的である．企業が製造工程で少量の材料だけしか使用しないとき，材料庫出のつど，どの購入原価の材料であるかを確かめて，それを消費価格とすることは困難なことではない．この方法は個別原価法といわれ，注文生産のために特定の材料が消費される場合にはこの方法が適用される．しかし，通常の製造においては多種材料が多量に使われる．材料庫出のつど，材料の項目ごとに単位購入原価を識別することは実行不可能である．この場合，材料消費価格は先入先出法（FIFO），後入先出法（LIFO），移動平均法，月次総平均法および予定価格等の方法が適用され，決定される．
先入先出法 これは買入順法ともいわれ，先に（古く）仕入れた材料の購入原価が先に消費された材料につけられる消費価格とする方法である．
後入先出法 これは最も新しく仕入れた材料の購入原価が最初に消費される材料につけられる消費価格とする方法である．
移動平均法 これは単価の異なる材料を購入するごとに，保有材料の原価と新規購入材料の購入原価との加重平均を計算し，これを消費材料の単価とする方法である．
月次総平均法 これは月末に月間の加重平均単価（月初の棚卸高と月間の受入高とを合計し，これを総数量で按分して算出した単価）を算定し，これを月間のすべての消費材料の単価とする方法である．
予定価格 過去の購入代価や現在の市価を基礎として将来の市価の変動を予測することによって予定価格を設定し，この価格によって一定期間（原則として1会計年度）にわたって，消費材料の原価を計算する方法である．
4.1労務費の意義と分類企業における従業員の労働力の消費によって生ずる原価を労務費という．労務費は労働力の消費であり，一方，従業員の提供する労働力に対する対価は賃金および給料等である．ここに，労務費は提供きれた労他力（その対価は貸金）の消費であり，これを消費賃金といい，労働力の対価としての賃金を支払賃金という．
労働力の対価に対する支払形態による分類 従業員から提供を受ける労働力に対する対価は，その支払形態によって次のように分類される．
賃金−これは従業員のうち工員の提供する労働力に対して支払われる給与をいう．
給料−これは従業員のうち職員および業務担当役員の労働に対し支払われる給与をいう．
雑給−これは企業に従業員としての籍のない臨時雇いやパートタイマーの労働に対して支払われる給与をいう．
従業員賞与・手当−これは工員や職員に作業に直接関係なく支払われるものである．手当とは，家族手当，住宅手当および通勤手当等の手当である．
以上のような費目で労働力の対価が労働力の提供者である従業員に支給される．これらは労務主費と呼ばれている．これに対して，従業員には支給されないが，労働力の調達および消費に付帯して発生する費用がある．これは労務副費と呼ばれる．
労務費の分類 労務費は，その計算と管理の観点から，次のような方法で分類されている．
組織職能による分類 組織職能は，通常，製造，販売および管理に分類される．製造活動において消費された労働力である労務費は，製造原価として把握される．また，販売活動および管理活動において消費された労働力である労務費は，期間原価である販売費および一般管理費として把握される．
製品との関連における分類 特定の製品製造のために直接的に消費されたことを確認しうる労務費を直接労務費といい，識別しえない労務費を間接労務費という．
部門との関連における分類 製造活動において発生した労務費は，さらに製造工程の各部門別に分類される．
従業員が提供した労働力に対する対価である賃金および給料等を計算し，支給することを一般に給与計算といい，特に，製造活動に従事する従業員の提供する労働力に対する対価を計算することを支払賃金計算という．また，労働力の消費についての計算は労務配分計算と呼ばれ，特に，製造活動での労働力の消費についての計算は消費賃金計算と呼ばれている．
出勤票 出勤票は各従業員別にその出勤時間および退出時間を1週間かあるいは2週間ずつ記録する伝票である．これは当該期間の定時作業時間数，残業作業時間数および深夜作業時間数を記録し，明示するようになっている．
作業時間報告書および出来高報告書 製品製造のために，工員が何時間，いかなる作業に従事したかを記録するために，作業時間報告書が用いられる．作業時間報告書は作業時間票とも称され，これに，各工員がいかなる作業に何時から何時までの何時間従事したかを記入する．出来高給の場合には，作業時間報告書の代わりに出来高報告書が用いられる．製造指図書番号・作業種類・作業場所，出来高，賃率および金額を記入する欄がある．製品が完成した後，工員が各自で記入し，これを製品とともに検査係に提出し，その合格印を受ける．そして従業員から賃金計算係および原価計算係に回付される．
労働の量とは，時間給制の場合には就業時間数，日給制の場合には労働日数，月給制の場合には労働月数，出来高給の場合には出来高（生産高や作業量）である．この労働の量を示す作業時間数，労働日数，労働月数は，前述の出勤票によって把握される．
次に，労働の質とは賃率のことであり，時間給制の場合には1時間当りの賃率，日給制の場合には1日当りの賃率，月給制の場合には1月当りの賃率，出来高給の場合には出来高単位当りの賃率である．この労働の質を示す賃率は，各工員の勤続年数，年齢，性別，学歴，技術の有無および経験等によって工員ごとに決定される．
労働力の消費の計算は労務費配分計算といわれ，企業の製造活動，販売活動および管理活動という3つの主要活動のそれぞれでいか程の労務費が発生したかを計費するのである．直接工および間接工が製造活動において，いか程の労働力を消費したかを計算することを消費賃金の計算という．消費賃金の計算は製造原価としての労務費の把握であり，次の算式により行われる．
消費賃金 ＝（製品製造のための作業量）×（作業量単位当りの消費賃率）
5.1経費会計の意義と分類経費とは，原価要素のうち材料費と労務費を除いた一切の原価要素をいう．したがって，経費の性質を理解するために，製造原価を構成する原価要素のうち材料費と労務費に含まれない費目が経費となるので，これを列挙することとする．例えば，福利費，減価償却費，保険料，修繕料，電力料，ガス代，水道代，租税公課，旅費交通費，通信費，保管料，交際費，棚卸減耗費，外注加工賃，特許権，雑費などが挙げられる．
経費の消費高の計算は経費の性質によって異なるが，その性質にもとづき，�〇拱Х佝顱き�測定経費，�７邀箏佝顱きと�生経費の4種類に分類されて計井きれる．
支払経費 これは原価計算期間中に発生した経費額が支払額とほぼ一致するので，その支払額をもって当該原価計算期間の負担額とする経費をいう．支払経費は，福利費，支払修繕料，支払保険料，旅費交通費，通信費，交際費，外注加工賃および雑費等が主なものである．
測定経費 これは原価計算期間における消費量を計量器によって測定し，それをもって当該期間の経費額とする費目であり，電力料，ガス代，および水道代がその代表的なものである．
月割経費 これは減価償却費，賃借料，保険料および租税公課等の費目であり，1会計期間あるいは1年を単位として計上されるか，あるいは支払われるものである．このため，これを月割して各月の消費高を計算するので，月割経費という．
発生経費 これは原価計算期間に実際に発生しているが，支払を伴わない棚卸減耗費のようにその発生額を消費額とする経費である．
図3−4は経費会計に必要な書類および会計処理手続を示している．原価計算係は経費支払票，経費測定票，経費月割票および経費発生票を定期的にまとめ，その企業の採用する原価計算の方法に従って，経費仕訳帳，総勘定元帳，原価計算表および製造間接手元帳への記入を行う．
6.1製造間接費の意義製造間接費は2種類以上の製品の製造のために全体的に発生する原価であり，発生のときにどの製品の原価とするかを識別しえない原価である．製造間接費の各費目別発生額は，材料庫出請求書，作業時間報告書，出勤票，支払伝票，経費支払票，経費測定票，経費月割票および経費発生票等の証憑書類にもとづき，製造間接費元帳の各費目別勘定口座の借方に個別に記入され，同時に材料仕訳帳，賃金仕訳帳および経費仕訳帳に記入される．製造間接費は後述する配賦基準により各製品に配賦されることとなる．以上の製造間接費会計に必要な書類および会計処理手続を図解すると図3−6のようになる．
製造間接費の実際発生額は各種製品の製造において発生した原価であるので，なんらかの基準により各製品へ配賦することが必要である．これを製造間接費の実際配賦という．製造間接費の配賦基準として，一般に，�…樟楮猯組餞霆燹き�直接労務費基準，�Ａ撚全霆燹きだ源採夢霆燹きツ樟楮邏隼�間数基準および�Φヽ１薪昌�間数基準等が用いられる．
上述の製造間接費の製品への実際配賦は，その実際発生額および配賦基準の実際数値を把握し，原価計算期末に行われる．しかし，その時点までに発生したすべての製造間接費が，当該勘定において把握されているとは限らない．その他，この実際配賦には次のような欠点がある．
製造間接費の実際発生額が製品に配賦されるとき，製品単位当り製造間接費は原価計算期間ごとに変動することとなる．これは月次の財務諸表作成における棚卸資産価額および期間損益に影響を与えるし，その結果として，経営上の意思決定にも影響を与えるのである．
特定の経営意思決定においては，製造間接費の実際発生額が算定される原価計算期末まで，その費定を延期することができない場合がある．
経営管理者は製造間接費の発生額が期末に算定されるまで，特定製品の原価の計算を待つよりも，その製品が完成した時点で，その原価を知ることを望んでいる．これは製品製造による利益がいか程であるかを知りたいからである．
製造間接費の実際発生額を製品に配賦することについて以上述べた欠点は，製造間接費の発生前に，製品へ配賦する製造間接費を予定あるいは見積り，予定配賦を行うことによって解決される．すなわち，予定配賦率を設定し，これを各製品の実際配賦基準数値に乗ずることによって製品への配賦するのである．
製造間接費の予定配賦を行うには，予定配賦率の決定が必要である．予定配賦率を決定するには，一定期間（通常は1か年）の製造間接費を見積ることと，その見横の前提となる基準操業度の予定とが必要である．この操業度は直接材料費，直接労務費，素価，直接作業時間および機械運転時間等の配賦基準数値によって表わされる．すなわち，製造間経費の予算が予算設定のための基準操業度である予算操業度のもとで編成され，次いで，予算操業度における製造間接費予算を予算操業度でもって按分することによって予定配賦率が算定される．
製造間接費を予定配賦で各製品に配賦する場合，原価計算期末には予定配賦額合計と製造間接費実際発生額との間に，通常，差異が生ずる．すなわち，予定配賦額は製造間接費配賦表で各製造指図書番号別に計算され，各指図書別予定配賦額がそれぞれの原価計算表の製造間接費欄に記入される．月末に予定配賦合計額が次のように仕訳される．
そして予定配賦額は次の仕訳により，配賦製造間接費勘定から製造間接費勘定に振り替えられる．
かくして製造間接費勘定の借方には実際発生額が，貸方には予定配賦額が記入され，差異が製造間接費勘定で算定されることとなる．この差異を製造間接費配賦差異という．予定配賦額が実際発生額よりも多額（超過配賦）のとき，有利差異（貸方残）といい，少額（配賦不足）のとき不利差異（借方残）という．この製造間接費配賦差異は次のような原因によって発生するである．

[ 120] 第3章実際原価計算総説
[引用サイト]　 http://www2.econ.osaka-u.ac.jp/~asada/ca/03.html

「第4回 セキュリティポリシー運用のサイクル」では情報セキュリティポリシー運用のサイクルについて、「第5回 ポリシー運用サイクルに適した形態」ではサイクルに従った情報セキュリティポリシーの運用に適する形態について紹介した。今回は、それらの内容を踏まえて、情報セキュリティポリシーの運用をスムーズにしてくれるツールや、運用をより効果的にするための体制の整え方、テストの実施など、情報セキュリティポリシー運用のコツについて紹介する。
前回、情報セキュリティポリシーをサイクルで運用する場合の形態について、紙で運用する場合と、掲示板やグループウェアなどのWebベースで運用する場合の問題点などについて紹介した。
紙での運用は迅速に対応することが難しく、文書管理作業に手間を取られて情報セキュリティポリシーの内容を周知徹底する作業が手薄になってしまうなどの根本的な問題が発生するため現実的ではない。
また、掲示板やグループウェアで運用する場合も、効果的な運用が行えるかどうかは使用するシステムの機能に依存するところが大きく、システムと手作業を並行して行う必要があるなど、管理者の手を煩わせる作業が多数発生してしまう。そのため、結果的に管理作業が煩雑になってしまいスムーズな運用が行えない可能性が高い。
このような問題を解消する1つの方法として、情報セキュリティポリシー運用管理専用ツールの導入が挙げられる。一般的にこの運用管理専用ツールに求められる機能としては、以下のようなものが考えられるだろう。
オプション機能はあると便利だが、なくても特に問題はない。しかし、必須機能として挙げたものに関しては情報セキュリティポリシーの運用サイクルをスムーズに実行するために必須であるといってよいだろう。
情報セキュリティポリシーの運用は専用ツールを使用しなければ行えないわけではない。確かに、既存のグループウェアやそのほかさまざまなツールなどをうまく組み合わせることができれば不可能ではないだろう。しかしながら、いくつものツールを組み合わせることにより管理作業が雑多になり、結果として管理しきれずユーザーへの徹底作業が手薄になってしまうという状況は容易に想像がつく。
これから情報セキュリティポリシーを策定するという場合には、このような選択肢も1つあることを知っておくこともよいだろう。
情報セキュリティポリシー運用ツールに求められる機能として、違反の検知機能が挙げられることがある。このことについて一言述べておきたい。
そもそもポリシー違反を検知するということはどういうことか考えてみてほしい。例えば、「パスワードは8文字以上でなければならない」という規定があるとして、パスワードを6文字に設定している場合は明らかにポリシー違反であり、これはOSの設定ファイルを監査するような何かしらのツールで検知できるかもしれない。しかし、「パスワードはメモしてはならない」というような規定の違反は、ツールの特定の機能などで検知できるものではない。このような規定が守られるかどうかはユーザーのセキュリティ意識レベルに依存する。
情報セキュリティポリシーには前者のような論理的（技術的）なセキュリティに関する規定よりも、どちらかというと後者のような人的、もしくは物理的な管理策を規定しているものの方が多い。ユーザーのセキュリティ意識の向上なしに情報セキュリティポリシーのスムーズな運用はあり得ない。
何でもかんでもツールに頼ろうとする考えは捨てた方がよい。それならば、機能のオートメーション化を促進し、ユーザーは何も意識しなくてもよいという状態を作り出すことだけに経費と労力を注げばよい。しかし、それにつぎ込んだ経費と労力とは裏腹に、セキュリティを意識する必要がなくなったユーザーのセキュリティ意識はどんどん低下していくことだろう。
ユーザーに情報セキュリティの意識付けをする意味で、同意させることが重要であるという話は前回した。しかし、運用開始当初は同意しない、もしくは同意を要求しているのに返信しないユーザー、または同意はしているが内容をよく読んでいないユーザーが少なくないことと思う。
そのため、情報セキュリティポリシーの運用開始時、および定期的に情報セキュリティ教育を全社員に受けさせなければならない。
情報セキュリティ教育というと、社員を集め、少し部屋を暗くしてスライドを見せながら説明するというような光景をすぐに思い浮かべてしまうが、この「説明会」がどのくらいの効果をもたらすだろうか。
全社員にこの「説明会」を受けさせるには、会場を手配し社員の業務調整をしなければならない。企業の規模によってはこれを何回も開催しなければならないだろうし、どうしても都合がつかない社員など出席できない社員もでてきてしまうだろう。また、せっかく行った「説明会」の話をよく聞きもせず、寝てしまう社員も少なくないのではないだろうか。
そこで、情報セキュリティポリシーの内容そのものだけでなく、情報セキュリティへの理解を深めさせる方法として、情報セキュリティポリシーの配布後、情報セキュリティに関するテストを実施することをお勧めする。
これも同意をさせることと同様に、ユーザーに情報セキュリティポリシーの内容を読まなければならない状況を作り出す1つの方法であるが、情報セキュリティポリシーの参照率を上げるという点においては同意をさせる行為よりもはるかに効果が高い。「説明会」では話を聞かない人間もなぜかテストとなると必死になって内容を読もうとするものだ。筆者がコンサルティングをさせてもらっている企業でも「テストを行って効果が上がった」という声はよく聞かせてもらうし、もちろん小社内でもかなりの実績を上げている。
情報セキュリティ「説明会」について上では少し否定的に述べたが、「説明会」自体に意味がないわけではない。ただ、一方的に説明をするだけでは周知徹底していることにならない。「説明会」を行う場合にも、必ずその理解度を深めるために最後にテストを行う方がよい。「説明会」を始める際に、「説明会」の最後にテストを行うということを伝えておけば、ユーザーは必死になって説明を聞いてくれることだろう。
情報セキュリティポリシーを全社的により浸透させるために、組織の体制を整備することが必要になってくる。ここでいう体制とは、セキュリティ委員会などのいわゆるセキュリティ組織のことではなく、各部門、プロジェクトごとに情報セキュリティの責任者を置くことを意味する。
情報セキュリティポリシーにはすべての対象者各自が情報セキュリティに関する責任を持つという基本理念があり、「自分が使用するコンピュータは自己責任の下においてセキュリティ事故が起こらないよう管理する」とすることが理想であるが、そうはいっても事務処理のみを業務として行う社員などにそこまでのセキュリティ対策を行わせることは難しいだろうし、まして責任を取らせることはほぼ不可能に近いだろう。
そのため各部門、もしくは各プロジェクトなどの単位ごとに1人ずつ情報セキュリティに関する責任者を置く。この責任者は、セキュリティ委員会からの通達を部門のすべての社員に伝えたり、それぞれが適切な情報セキュリティ対策を行っているかどうか確認する作業を行う。また場合によっては、部門内で使用するすべてのコンピュータのセキュリティ対策も行い、さらに、情報セキュリティポリシーの配布時に同時に配布される同意書に全員がサインしているかどうかや、テストの結果などを把握し、部門長を通してセキュリティ委員会に報告する義務も負う。
この責任者は、部門長が兼任してもよいが、部門長自身のコンピュータリテラシーが低かったり、情報セキュリティに関する知識レベルが低いと効果が上がらないので、部門長がコンピュータやシステムに詳しい社員などを情報セキュリティ責任者として任命するとよい。
各社員が使用するコンピュータに適切なセキュリティ対策が施されていることを確実にする
部門の全社員の同意状況、テストの結果を把握し、部門長、またはセキュリティ委員会に報告する
セキュリティ事故が起こった場合に、何をするか、だれに連絡するかを決めておく
実際にセキュリティ事故などが発生した場合の責任は部門長が負わなければならないが、情報セキュリティ責任者はまず何をすればよいか、だれに連絡するべきかなどを理解しておき、部門長が不在の場合にも迅速に対応できるような体制をつくり上げておくことが重要である。
2002年8月から住基ネット（住民基本台帳ネットワーク）の運用が開始され、このネットワークおよびシステムのセキュリティを疑問視したいくつかの自治体が、このネットワークへの接続を拒否していることは皆さんもご存じのことと思う。
このような状態をかんがみてか、現在、経済産業省を主管とした情報セキュリティに関する監査基準の策定準備が進んでいる。この監査基準の内容についてはまだ詳しくは公開されていないが、住基ネットを使用する、つまり全国民の個人情報を取り扱う団体として、情報セキュリティに関してそれぞれの自治体がクリアすべき一定の基準値を示すものとして全国の地方自治体に適用される可能性が高い。
この監査基準の中には、情報セキュリティポリシーを策定することはもちろん、策定された情報セキュリティポリシーがその自治体の現状に即した内容であるか、きちんと運用されているかなどを監査する項目が盛り込まれるであろう。つまり、世の中の流れはすでに情報セキュリティポリシーを策定することではなく、その運用に向かっているということである。
また先ごろ、OECD（経済協力開発機構）の「情報セキュリティガイドライン」が改定された。今回の改定ポイントの中で注目すべきは、改定前は2番目に定義されていた認識原則が、『セキュリティに係るリスクの認識を啓発することが重要』であるとして第1原則に変更されている点だ。つまり、ユーザーに情報セキュリティ教育をすることの必要性が再認識されたということだ。
これらのことから、情報セキュリティを考える場合に重要なのは、情報セキュリティポリシーをきちんと策定し、その内容の周知徹底とセキュリティ教育に重点を置いた適切な運用ということがお分かりいただけると思う。
筆者自身、社内の情報セキュリティポリシーの運用を行っていて、情報セキュリティポリシーの要は策定ではなく、その運用にあり、運用とは、いかにしてユーザーに情報セキュリティポリシーを読んで、理解してもらうかの闘いであると感じている。これは決して大げさな感想ではなく、読者の皆さんも実際に情報セキュリティポリシーの運用に携われば必ず同じような感想を持たれることと思う。
ユーザーにとってみれば、訳も分からないコンピュータ用語がずらずらと並べ立てられている文章など読みたくもないだろうし、便利なソフトウェアの使用を禁じられたりと、面倒や不便を強いられるのだから当然の反応だとは思うが、まさに「管理者の心、ユーザー知らず」といった感じだ。
しかしながら、前回と今回で紹介したような細かい工夫などをすることによって、ユーザーの参照、同意率、ひいては情報セキュリティポリシーの順守率を向上させることが可能になる。徐々にではあるが確実に情報セキュリティレベルは向上していく。これも実際に情報セキュリティポリシーの運用を行ってみての実感だ。
同じことを行うにしても、その内容いかんによって失敗にも成功にも転じるのが情報セキュリティポリシーの運用である。今回の記事が、読者の皆さんがポイントを押さえた効果的な情報セキュリティポリシーの運用を行う際の助けになることを願う。（今回で連載は終了です。ご愛読ありがとうございました。）
情報セキュリティポリシー運用管理専用ツールの1つである「LivingPolicy」を簡単に紹介する。
基本的には情報セキュリティポリシーをWebコンテンツとして管理するためのツールだが、上の表1で挙げられているオプション機能を含むすべての機能を実装しており、対象者別に配布するためのアクセスコントロール機能および、情報セキュリティポリシーのコンテンツのバージョン管理が容易にできる。
また、ユーザーへ同意を要求するメールを自動的に配信することができ、ユーザーの参照、同意状況もグラフなどで簡単に分析できる機能も持っている。同意の要求に返信してこないユーザーに対しても定期的にメールを再配信するなど追跡機能も実装。
さらに、情報セキュリティ教育の一環として、ツール上でテストを受けさせることが可能で、その通知、結果の分析などもすべてこの専用ツール1つで行えるといったユニークな機能も用意されている。
画面3 ユーザー教育の一環として、ツール上でテストを実施できる（拡大）
このアプリケーションには初めからサンプルポリシーが登録されているので、策定から運用開始までの期間を大幅に短縮することが可能である。大げさにいうと、アプリケーションにユーザー登録すれば、その日からでも情報セキュリティポリシーの運用を開始できる。
情報セキュリティポリシーを対象者全員に公開する仕組みを用意する
対象者に公開するが、そのままでは見てもらえないため、メールで告知をする。
メールで告知するだけでは、だれが見ていてだれが見ていないか分からないため、
また情報セキュリティの意識付けをする意味で同意という形態でユーザーに返信させる
返信してこないユーザーに対しては返信期限が切れた際、もしくは定期的に本人とその上司の両方に警告メールを送信する
情報セキュリティポリシーの参照率と理解度を高めるためテストを行う
トラブルシューティングはCentOS 5におまかせ （2007/11/15） リリースから半年が過ぎたCentOS 5、もう使っていますか？ これにはSELinuxの運用をもっと楽にしてくれる便利なツールが追加されています
ヘルスチェックしてる？ 怠ってはならないDNSのケア （2007/11/9） DNSやDHCP、安定稼働しているからといって放っていたりしませんか？ ネットワークを支える要となるサービスにもう一度注目しよう
脆弱なホストを狙った不正中継を見抜く （2007/11/7） 攻撃者は設定ミスや脆弱性を残しているマシンへどのように攻撃してくるのか？ 踏み台にされないために、その見抜きかたを知っておこう
不正を見破り、紙・メール・ファイル状況変化“なし” （2007/11/6） 「守る」という意味が日々変化するセキュリティの世界。あらゆるデータの不正を許さない環境を実現するために、製品も日々進化します
ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン
＠ITトップ｜Security&Trustフォーラム トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 121] ＠IT：セキュリティポリシー運用の実際とコツ
[引用サイト]　 http://www.atmarkit.co.jp/fsecurity/rensai/policy16/policy01.html

JUDEはUMLツールとして無償版から始まり、有償版も出て広く使われてきているツールであるが、この製品開発がオフショア（中国）と日本とでアジャイルに実施されていることはそれほど知られていないと思う。今回はオフショア開発での話とJUDEプロダクト自身のアジャイルな一面を開発者自身に答えてもらう。（→記事要約へ）
JUDEはオフショアで開発をしている。加えて、JUDEという製品開発を進めるうえで、初めに定まり切らない仕様とその時々に出てくるさまざまなユーザーニーズに柔軟に迅速に対応していくために、結果としてアジャイル的な開発を実践してきている。今回はその一端を開発者のインタビューを通して紹介する。
当初は中国側、日本側それぞれ3名程度の体制でスタート、その後製品版の発売などでサポート要員なども増え、今回設立した新会社ではJUDEの開発とサポートに、中国10名、日本10名の体制となった。日本側開発陣の中核的メンバーである永和システムマネジメント第2事業本部 UML事業部の山本明夫 事業部長と梅田政利さんに話を伺った。
梅田 中国とは、昔から付き合いがあったわけではありません。オフショアの可能性を確認する意味もあって、当時開発が一時ストップしていた「Jude梅」の機能強化をオフショア開発で行うこととなり、2002年10月から「Jude竹」の開発がスタートしました。
山本 オフショア開発の話がなければ、JUDEの機能強化はもっと遅れており、これほど多くのユーザーの方に使われるツールにはなっていなかったかもしれません。
梅田 JUDEの開発に本格的にアジャイルを取り入れたのも、「Jude竹」の開発からで、ほとんど初めての試みでした。中国側もアジャイルは初めてでした。いまでも中国でのアジャイル開発は特殊な方で、それほど一般的にはなっていないと思います。
梅田 始めに日本側から全員が中国に3週間行って、実際に2イテレーションのアジャイル開発を行いました。次に日本と中国に分かれての分散開発を挟んだ後に、日本で2週間再び全員が同じ場所にそろって開発しています。
これは、ペアプログラミングや朝会、そして一緒に食事をすることなどによって、お互いの理解、ナレッジ共有などのためのコミュニケーションをしっかり取る狙いがあり、その効果は非常に大きかったと思います。一度ペアプログラミングをしておくと、その後分散開発になっても信頼関係やお互いへの理解が継続できます。
また、いったん分散開発を挟んで、その問題点を日本での合同開発のときに確認し合ったことも、その後の分散開発を行ううえで役に立ちました。
その後はメッセンジャーを用いてリアルタイムに会話することとしていましたが、英語でのやりとりで、仕様確認とかになるとずっとチャットし続ける状態になってしまっていたので、いまはコミュニケータとして中国側から日本語の分かる要員に1人日本に来てもらいその人を介して行うようにしています。それでも直接話をするときはやはり英語です。後は文字ベースだとどうしても限界があるので、Wikiを立ち上げてそこに画像をペタペタ張ったりして仕様を共有しています。
山本 過去に、明らかに仕様が間違っているにもかかわらず、間違った仕様どおりに無理やり作られた謎なコードが送られてきたこともあります。英語はどちらにとっても第2言語なので、どうしても十分なコミュニケーションが得られず、仕様の基となっている要求を伝え切れなかったのが原因でした。
開発メンバーには中国の人もいますが、現在は中国から1人、コミュニケータとして来てもらう形がうまく機能しています。一般的にはブリッジSEと呼ばれる役割だと思いますが、JUDEのチームではコミュニケータと呼ばれています。
徐々に変化しながら、いまのコミュニケータという形に落ち着いてきたとのことである。もちろんUMLの設計情報のコミュニケーションに関してはJUDE自身を使って行っているという。続いて実践していることに関してきいた。
梅田 いまでもこれは継続しているのだけど、だんだん選択できるタスクの範囲が限定されてきていてあまり選択の余地がなくなってきています。ある意味、専門化が進んだのだと思います。専門化が進むと、生産性は上がる傾向にあるのですが、逆にハネムーンナンバー（注1）を減らすリスクにつながるため、どのように知識を分散させるべきか、今後の課題です。
梅田 当初からの1週間を原則維持しています。継続的インテグレーションという点では共通のCVSサーバを利用しています。ただ、ピュアなXPで推奨されているように、毎日の終わりは必ずエラーなく動くものがありますよ、という状態では残念ながらありません。
梅田 ペアプロはあまり実施していません。定着させたいなと思うこともあるのですけど、コスト感があるので、効果が見えるまで続ける余裕がありませんでした。
やっぱり2人で別々にやった方が早いじゃんみたいなところがあって、リリース前にこれとこれはやらないといけないから、別の人にやらせたいとか、そういうのがどうしても出てきて、それが増えてなし崩し的にやらなくなっています。
ただし、重要な個所に対する場合や教育目的を持つ場合に、ペアプロをすることはありますね。検証はできていませんが、コードの品質はやはりペアプロで向上すると思います。とはいえ、自分はどっちかというと1人でやりたい派ですかね。
梅田 分散アジャイル開発では、ツールが特に重要になります。直接会って話をする、壁に張る、が一番なのですが、それにできるだけ近づけるツールを厳選して使っています。
プログラミングが楽。ソースを追うのが楽。テストが楽。リファクタリングが楽
WebベースのXPプロジェクトサポートシステム（JUDEプロジェクトでは未使用）
梅田 自動テストはなるべく作っていきたいという流れに、なってきています。最初に頑張れば、良いテストが書けたのかもしれないのですが、そこのコストを思い切って掛けられない状態だったので、テストがそろっていないからテストを作るのが難しいという悪循環になっているところがあります。
テストがそろっていると、その後開発したものにテストを足していくという強制力にもなりますよね。そういうところも弱くて、気が付いたらテストを書く文化が、一部に限ったものになってしまいました。例えば、モデルの周りを編集するところはテストがあるけど、GUI周りの部分はテストが少ないといった感じです。特にGUI周りは、テストする指針というか、具体的なやり方が見えなかったため、力を掛けることができませんでした。自動テストが厳密にそろっていないので、リリース前にはたくさんのテストを手作業で行っています。ここは大きな課題になっています。やはり頻繁なリリースには、自動テストの充実は欠かせないでしょう。
ちなみに、JUDEのテストのレベルは、モデルテスト、コマンドテスト、ストーリテストの3レベルになっていて、最初の2つはJUnitを使っています。また、受け入れレベルはほとんど手動のテストです。
それから、僕たちのプロセスは1リリースが3カ月、1イテレーションが1週間です。そして、ちょっと変わったところとしては、イテレーションの最初の方は、モデルに集中し、その後でモデルの上に機能を載せていきます。テストとしては、最初はモデルテストが中心です。途中からコマンドテストができるようになります。そして、製品リリースの最後のイテレーションは、ほぼそっくりそのままテストのみに割り当てられています。
アプリケーションを起動した状態でコマンドを送り、コマンドが正しく実行できるかを確認する
山本 JUDEの場合はユーザーからの要望が数多く寄せられており、非常に参考になっています。
梅田 当然ユーザーからの要望も重要ですが、一番決定権を持っている顧客の役目を果たすのが、優先度1で平鍋さん（永和システムマネジメント 取締役副社長）、次にうちのプロジェクトリーダー、後はメンバー内で適当に、という感じです。
山本 平鍋さんからの要望も、いろいろなセミナーで話をした内容に対する質問や要望が集約されていることが多いですね。そして、平鍋さん経由でリクエストされた要望は、実際に機能として採用される確率が非常に高くなります。
梅田 平鍋さん自身の意見もユーザー視点が多いと思いますね。プレゼンしていたら、ここが気に入らなかったとか、こういう機能がほしいなとか。本当に顧客みたいなものです。平鍋さん自身がJUDEのヘビーユーザーなので。
――UMLツールをアジャイルに作っているわけですが、アジャイルとUMLの関係はどう考えていますか？
梅田 私はアジャイルとUMLはあまり関係ないと思っていて、単にコミュニケーションをするためのツールがUMLなだけで、こちらの意図が正確に伝われば、何でもいいと思います。JUDE作っていていうのもなんですけど、本当に何でもいいかなと。
JUDEチームに関しては、UMLは本当にコミュニケーション目的でしか使っていないといってしまっていいと思います。そういう意味ではアジャイルにすごくマッチした使い方だと思っています。
山本 アジャイルとUML自体はそれほど密接な関係はないと思います。JUDE自身がどちらかというと、必要な部分の設計をラフスケッチ的に書いて、それでコミュニケーションするためのツールという趣旨で開発が始まっています。実際にJUDEの開発でもそのような使い方をしていますね。
梅田 アジャイル系の方の中にはスケッチというものを肯定している方が多い印象があり、JUDEは使いやすいスケッチに向いたツールとして、そういう方たちに受け入れられていると感じます。半面、UMLに新しく入るという意味での入門者は、どうしてもカタログスペックに目を奪われている気がして、そこを何か、うまく変えていきたいと感じます。UML 2.0のように厳密なものを必要とする人はごくまれですよね。
実際MDA方向が必要っていうか、いますぐ適用すべき範囲というのはごく一部じゃないのかなと思っています（JUDEは現在UML 2.0対応を進めている。2006年6月ごろには最初のリリースを行う予定）。
山本 JUDEの大きな特色として、使いやすいという以外に、マインドマップのサポートがあります。マインドマップは、ユーザーからの要望ではなく、UMLとマインドマップを組み合わせたら面白いじゃないかという内部アイデアによるものです。普通はこんな要望は出さないですよね。JUDEにマインドマップを乗せるかどうかについては内部的な議論は賛否両論いろいろありましたけどね、ユーザーの方には非常に評価していただいており、いまではほかのUMLモデリング製品と比較した場合の最大の特徴といえるでしょうね。
梅田 マインドマップでどこまで表現できるようにするかっていうのはあるのですけど、JUDEの既存の機能をベースに、マインドマップの機能を必要最低限のレベルで押さえると、結構単純じゃないですか。そういう意味で、実装するための敷居は低かったかなと。ものすごい開発ボリュームだったら、JUDEに乗らなかったと思いますけど。
梅田 パッケージ開発というのはアジャイル開発に向いていると私は思います。最初にガーンと出して、そこからあまり成長が要らないパッケージなら別だと思いますが、全体が大き過ぎて、いきなりバーンと出せないものとか、少しずつ成長させていきたいツールだとやはりアジャイルが向いているんじゃないかと思います。
山本 マインドマップも最初のリリースでは必要最低限の機能でしたが、ユーザーからの反応が非常に良かったので、その後のバージョンアップで機能追加と改善を繰り返して、マインドマップツールとして必要な機能をそろえてきました。
最初からすべての機能をそろえようとしていたら、まだ出せていなかったかもしれません。何より、それだけの工数と時間を掛けてユーザーに受け入れられなかったら意味がありません。
特にUMLは、今後も新しい規格がどんどん出てくると思いますし、ツールに対するユーザーの要望がまだまだ活発な状況ですので、数年かけて開発した新バージョンをリリースするという開発サイクルではあまりにも長過ぎて、変化の激しい市場ニーズに対応できません。そういう点ではアジャイル的な開発による年3、4回の製品リリースサイクルは、いまのJUDEに非常に合っていると思います。
今後UMLの規格も固まって、ユーザーからの要望や、取り込みたい機能がなくなってしまえばリリースサイクルも変わるかもしれませんが、JUDEでやりたいことのストックはいっぱいあるので、まだまだ先の話です。
以上、JUDEの製品開発を通して、オフショアという遠隔地との開発におけるアジャイル開発の特色の一端が垣間見られたのではないかと思う。1カ所に集まってやらなければできないなどという制約にとらわれず、果敢に実践してこられている様が少しでも伝われば幸いである。
今回のインタビューでは、JUDEの製品開発を通して遠隔地開発とアジャイル開発を組み合わせたアプローチの特徴を浮き彫りにする。分散アジャイル開発では、開発者間で円滑なコミュニケーションをとるのが難しい（もちろん、分散開発ではなくとも、開発者間のコミュニケーションは重要であり、顧客とのきちんとした意見交換の重要性も無視できないが）。結果的に、JUDEのような製品開発においては、分散環境やアジャイルのアプローチは有効であるとの結論が本インタビューで得られた。とはいえ、最初から巨大な構造を構想するパッケージソフトウェアではなく、徐々に機能を追加していくという性質のJUDEだからこそ、うまく適用できたと開発者の1人は述懐しており、このあたりに分散アジャイル開発成功の要因がありそうだ。
情報マネージャのための「今日のひと言」 - 2007/11/19『雑務』 自分の仕事の中で、雑用をバカにする人がいます。どんな仕事であっても……>>続きはクリック
.NETアプリケーションの単体テストと静的検証を自動化する「Parasoft .TEST 4.0」、テクマトリックスが発売
ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン
＠IT情報マネジメント トップ｜アーキテクチャ トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 122] オフショアでアジャイル開発の実際 − ＠IT情報マネジメント
[引用サイト]　 http://www.atmarkit.co.jp/im/carc/serial/prac03/prac03.html



実際とは？トップへ↑

お気に入り



  • track feed
    • seo