情報セキュリティについて調べていると、主眼は、いかに情報資産を脅威から守るかにあり、セキュリティは危害を受けないという意味があることがわかる。機能安全の時には、この安全はセーフティの訳であり、ソフトウェアにバグがあっても、いかに危害を与えないようにするかを主眼としていた。
セキュリティとセーフティの違いはここにある。被害者か加害者かの違いである。辞書を調べてみると、secureという形容詞には、もともと心配(cure)がないという意味がある。safeには、安全の他に、慎重、危害を加えないという意味もある。
セキュアには、備えがあって心配ないことを意味し、セーフより強固な状況と辞書にあるが、これは納得できる。それでは、最近よく耳にするセーフティネットはどっちだろう？ザルのようなセキュアな保護策なのか、犯罪者になることを防ぐ策なのか？
機能安全規格の中の重要な用語として、safety integrity lebelがあるが、この日本語訳が定まらない。先行したJISでは安全度水準としているが、最近、安全整流性水準という訳も見られたりする。
原因は、integrityという言葉にあると思うが、そもそも、安全とsafetyに差があるのではないか？
辞書で調べてみる。安は、無事である、安からという意味を持ち、平安、安否というふうに使われている。家の中に女が落ち着いている状態から来ている。全は、欠けたところがない、揃っているという意味を持ち、完全、万全というふうに使われている。
一方、英語では、safeはfree from dangerという意味であり、integrityは、being whole or undividedな状態を意味している。
つまり、safetyは日本語の安に対応し、integrityは全に対応していると言えるのじゃないか。日本語の安全は、それだけで、safety integrityまでを含む。
といっても、safety integrityを単に安全とは訳しづらい。CMMIでも、maturityを成熟ではなく、成熟度と訳しているから。安全度がいい訳だと思えてきた。
最近は展示会に参加することが減ったように感じる。混雑と待遇の悪さを敬遠するようになったからである。それなのに、11日に東京国際フォーラムで開かれたSaaS関連の展示会に参加した。
地下の展示スペースだけで行われていたが、その盛況ぶりに最初、後悔を感じた。いかにも勤め人という人で一杯。並んで、目当ての講演を聞くと、疲れているのか、つまらないのか、聞いていなそうな人は多い。その中で、一人の講演者が話した、次のフレーズが気に入った:
SaaSの利点は、オフバランスです。
つまり、IT設備を所有すれば資産となるし、それを避けようとしてリースに変えても、最近ではやはり資産になる。SaaSではバランスシートからこれらの資産を消し去ることができるという意味である。
資産となれば、その分だけ利益が増えてしまうので、これを気に入る人もいると思う。
受託ソフト開発の売上と総原価は、完成時に計上されるのが常ですが、会計基準が変更され、来年度からは開発途上であっても、決算時に一部を計上しなければならなくなります。その準備のため、工事進行基準と名を打つセミナーが賑わいを見せています。昨日、そのひとつに参加し、工事進行基準にEVMというプロジェクト管理手法が有効でないかと考えてみました。
開発途上にその時点までの売上げと総原価を算出できるでしょうか？完成時にはこの両者は確定しますから、決算時点では、これらを見積もることになります。この見積値に決算時点での進捗率を掛けることになるでしょう。これでいいんです。会計基準もそうなっています。ここで問題は、正確に見積もれるかです。
正確な見積もりを行うために、EVMという手法が有効そうです。これを説明してみます。
まず、完成時の売上ですが、これは契約等に依存し、ここでは契約で確定しているとします。
次に、完成時の総原価に対しては、EVMではEACと称しています。EACとは、そのものずばり、完成時点でのコスト見積もりです。
問題は進捗率です。会計基準では原価比例法を採用し、決算時点での発生原価を必要とします。多重外注構造であれば、この算出は相当面倒そうです。EVMを採用していれば、進捗率をEV/BACとして算出できます。ここで、EVとは決算時点までの出来高を意味し、BACとは完成時の出来高総額を意味します。
出来高とは作業成果を金銭価値で表現したものであり、もともと進捗管理のためのものです。原価実績を把握できなくても、把握できる特性を持っています。
まとめてみると、EVMを採用して次のように工事進行基準に対応します:
1）計画時にBACを見積もる。これが仕様変更等で変わるので、実際は複雑になりますが、ここでは触れません。
2）決算時点でEACを見積もる。というより、常時、EACは再評価されていて、決算時点でのEACを採用することになるだけ。
3）EVも同じように、常時、算出されていて、決算時点でのEVをもとにして、進捗率を求める。
というようにすっきりとまとまりますが、問題はEVMを実施する能力があるか。
業務システムを構築する時、まず業務プロセスの分析、設計を先行させ、それに合わせてシステムを構築する。業務プロセスを先行させるため、18か月の開発期間の中で6カ月をビジネス設計、要件定義に当てた。そういう趣旨の講演を、先週行われた日本BPM協会の交流会で聞きました。
講演者はユーザ企業のプロジェクトマネージャです。業務改革は、ベンダ任せにしないで、自らプロジェクトマネージャになって推進すべしと主張し、次のようないくつかのアドバイス、ヒントを述べていました:
●To-Beプロセスは、コンサルタントから聞くのではなく、ユーザ自ら設計する。テンプレート流用では、競争力がつかない。現場を知りすぎている人は、設計メンバに入れない。
●プロジェクトマネージャをユーザがやれば、困った時に業務のほうを変更するという選択肢がとれる。
●データの見える化ではなく、見せる化。見せるようになると、データ入力が正確になっていく。
●IT部門の人は、ITを活用できる立場なので、業務プロセス改善の推進役にふさわしい位置にいる。
プロマネをユーザがやるには、そのアドバイザ、コーチがいれば安心ですが、今回のケースでもしっかりとしたアドバイザがついていました。
プロジェクトマネジメントの団体であるPMI東京は、毎年この時期に2日間のフォーラムを開催しています。今年は11月10日、11日に豊洲の芝浦工大のキャンパスで開かれました。PMPの資格を持っている人は、それを維持するために所定の時間のセミナー等を受講しなければならないので、土日ですが、多くの人で賑わいます。その中でも、50を過ぎた人が、結構と目立ちます。
プロジェクトマネジメント分野ではEVMに関心があるので、それに関する発表を聞きましたが、ショックを受けたのが、内部統制とEVMをキーワードにした発表でした。この組合せには、今まで気づきませんでした。
気がつけば、理屈は整然としています。プロジェクトの収益が企業収益に重大な影響を及ぼしていれば、決算期間の期末にそのプロジェクトの出来高とコストが必要となり、完成までの見通しが求められます。虚偽申告ができないような体制を整備する必要が生じてきます。
もし、EVMを利用してプロジェクトの出来高とコストを管理していれば、まさにその体制にぴったりします。現実に、米国では実績があるようです。
日本でも、2009年度から、複数事業年度にわたるプロジェクトでは、期末に進行状況に応じて出来高を計上しなければならなくなり、内部統制の一環としてEVM採用に踏み切る企業が増えると期待できます。
今までは現場の有志が、散発的、非組織的にEVMに取組んできていますが、内部統制のためとなれば、組織的、体系的にEVMが浸透していきます。最初の企業はどこになるのでしょうか?建設関係でしょうか。いや、ソフト業界であって欲しい。
形式手法の概要を解説する教材を作成しています。研究者ではなく、ソフトウェア技術者を対象とした、入門的で体系的な参考書がないと感じていますので、2時間程度の講義用の教材にしたいと思っています。
形式手法は、数学を基礎とするシステムの仕様記述手法、検証手法等の総称ということができます。仕様のあいまいさを排除することができ、あるいは上流工程での検証を可能とすることができ、品質向上のための手法として注目を集めてきています。
誕生は、1970年代までさかのぼり、欧州の研究機関が多くの手法を生み出し、発展させてきましたが、その難しさのため産業界には浸透しませんでした。最近、その状況に変化が見られます。ツールが使いやすくなり、国内ツールベンダが登場し、産業界の適用事例がいくつか公表されるようになりました。
追い風もあります。機能安全規格IEC61508で安全度を最高に高めるための推奨手法として形式手法が取り上げられました。
この形式手法にどんなものがあるか、代表的な手法の特徴、活用方法などを概説する教材にしたいと思っています。
ソフトウェア外注管理の本を見つけました。昨年12月の発行です。
｢ITプロジェクトにおけるソフトウェア外注管理｣
高根宏士著、ソフトリサーチセンター発行、2800円
本のはじめにで、対象とする読者の記述がありませんが、経営者層又は管理者層が対象だと感じます。構内で一緒に作業している場合の諸問題等を取り扱っていませんから、現場の開発リーダー層には、物足りなさがあると思います。
この現場の開発リーダーを対象とするソフト外注管理の本が、なかなか見つかりません。講座教材はありますから、それをもとに本にしてみたい誘惑に駆られます。
ビジネスプロセスのモデリングに関する解説を読んでいて、そもそもモデルとは何かという問いがありましたので、辞書で調べてみました。
広辞苑によれば、モデルの意味は、1)模型、2)美術家や小説家の題材、3)ファッションモデルの略とあり、模型は、1)同型のものを作るための型、2)実物と形を似せて作ったものとあります。英英辞典でmodelを調べても、ほぼ同じです。
これを参考にすれば、ビジネスプロセスは目に見えませんから、その形を似せて目に見えるように表現したものとなると思います。ここで、形を似せるということが肝要です。
某販売店が、メーカからの応援者を直接作業指示し、職安法違反に問われています。この応援者は、メーカへの派遣労働者であり、違法な労働者供給と判定されます。
作業の効率や品質を考えれば、仕事をよく知っている販売店が直接、作業指示するほうがいいはずですが、何がいけないのでしょうか?
ここで登場するのが、給料は労働の対価であるという原則です。労働の質と量を変えれば、それに応じて給料も変えなければならないということです。先の販売応援者の件では、このバランスが崩れやすいので、法は規制している。販売店は、意識しているかは別として、追加の対価なしに、労働の質を上げ、量を増やすことができます。
作業の効率と品質を上げたければ、有能なところに委託するか、さもなければ、直接、雇用するしかなく、それなりに対価を払う必要を免れません。
販売プロセスのひとつに請求書発行があり、これを例としてリスク識別を行ってみます。
請求書発行プロセスの流れは次のとおりです：
1）請求書作成
2）請求書承認
3）請求書送付
4）請求書保管
出力を伴う作業は1）と3）であり、1）を例に取り上げると、その入力は得意先元帳で、出力は請求書です。得意先元帳にガイドワードを適用して、正常状態からのずれを考え、その結果を考えます。次のように展開できます：
無い：得意先元帳を見ず、請求書が発行されない。
複製：得意先元帳を2回以上参照し、請求書が2通以上発行される。
未完：（変形と同様）
変形：得意先元帳の参照を間違い、請求書への記載をミスる。
偽物：得意先元帳に無い架空の請求書を発行する。
請求書送付では、送付を忘れる、送付したものが届かない、等のリスクを容易にあげることができます。
財務報告に係る内部統制の整備に当たっては、業務プロセスのリスク評価が課題となっています。そのリスク評価に安全設計で用いられる手法HAZOPが適用できないかを考えています。
業務プロセスはビジネスプロセス図（BPMN表記法）で表現すれば、作業の連続として構成されます。作業には入力と出力があるので、リスクとは出力が好ましくない状態になることと考えます。ここでHAZOPの考えを適用して、入力が正常状態からずれたとき、出力に悪い影響が生まれるかを検討します。
入力にガイドワードを適用して、その意味を次のように解釈します：
No:無い（入力が無い）
MoreとLessは使用しない
As well as：複製（入力を2回以上使用）
Part of：未完（入力の一部がおかしい）
Reverse：変形（入力を読み間違い）
Other than：不正（架空の入力）
実際、この解釈、方法で「内部統制の入門と実践」に出てくる業務プロセスに適用してみると、結構うまく行くことがわかりました。
安全に関する要求事項を規定している国際規格によれば、安全とは、人に危害を与える等のリスクが、許容できる水準まで低減されている状態を意味します。したがって、リスクを洗い出し、評価することは重要であり、多くの手法が考案されてきています。
リスク評価手法の一つにHAZOPという手法があります。FMEAという手法が広く知れ渡っていますが、これに比べると、取組みやすく、かつ体系的にリスクの洗い出しができます。
その理由は、FMEAでは部品の故障から検討を開始し、最終的な悪い結果に到達するまで分析を続けなければなりませんが、HAZOPでは途中の状態から検討を開始することになるので、比較的楽に結果に到達できるからです。
この途中の状態を、HAZOPでは設計意図からのずれと呼びます。たとえば、ある属性が設計範囲を越えたとき、それによって何か悪いことが起きるか、というように検討を進めます。
設計意図からのずれを考えるとき、ガイドワードが用意されていて、ガイドワードに沿って体系的にずれを洗い出すことができます。ガイドワードは次の7つです：
NO、More、Less、
As well as、Part of、
Reverse、Other than
HAZOPは化学産業分野で連続プロセス系への適用を狙いとして開発されましたが、プラントの操作にも適しており、ソフトウェア設計にも適用されてきています。
国内でも化学産業で適用されており、安全設計の必要性が高まるにつれ、注目を集めるのではないでしょうか。
HAZOP： Hazard and Operability Studyの略。
一人会社と世間との接点は、現代においては、インターネットになると思います。インターネットへの入り方として、ポータルサイトの利用、ブックマークの利用、ウェブ検索等がありますが、私はウェブ検索が主流、いや主流になっていると考えています。
私の会社のホームページへは、検索の結果として辿り着いてもらうことを想定しています。したがって、レンタコーチと入力して、それで検索したときの結果に、常々、気をかけています。
今日も確かめました。検索結果を見ていると、誰かのブログにレンタコーチが出てきています。そのブログを見ました。9月に初めて会った人のものです。再会した気になりました。
ウェブ検索が、ユニークな言葉を通じての人の輪を形成する手段となりうるかもしれません。仕事にうまく活用しない手はないでしょう。
このブログを初めて1年が経過し、起業に関する記事も、これから法人税を申告、納税し、源泉徴収票を提出すれば、一通りの話題をこなします。それ以降は、繰返しになります。
それで、今までの記事をまとめて本にしようかと考えています。どういう形式の本がいいか?
やはり、web出版かな。Webページに目次をおき、各節は、powerpoint形式のスライド群にし、目次からリンクを張っておく。図表は1枚のスライドに収め、文章は、16ポイントくらいのフォントで書き、節ごとにPDF形式で出力する。
こんな構想で試してみようと思っています。
ソフトウェアシステムをテストするためのテストケース作りに労力がかかりますが、正しいテスト結果を用意しなくてもよいテスト方法があります。Back to back testingがそれにあたります。
この方法では、製品となるソフトとは別に、テストのためのソフトをもう一つ作り、同じテストケースに対する両者の結果を比較し、不一致のときにバグと判断します。同時にミスるとバグを検出できませんが、ある研究によれば、この確率は単一のときに比べて50分の1くらいに下がるそうです。
当然、最初のうちはテスト用のソフトのほうがバグが多いことになりますが、テスト効率が高くなったので継続していきたいと、オムロンの高木徳生さんが、16日のクリティカルソフトウェアワークショップで報告しました。
この方法は、原子力発電所関係のソフトでは、昔から使われているそうです。本番用のほかに、訓練用も作るので、二者比較ではなく、三者比較になるんだとのことでした。
NSCといえば、今、政府が計画している国家安全保障会議を意味しますが、NISCは、内閣官房情報セキュリティセンターの略となります。60名弱の職員を抱え、情報セキュリティに関する政策の立案と推進、行政機関内の情報セキュリティ強化を担当しています。
このセンターの補佐官である山口英さんが、NSF2006でNISCの活動を紹介しました。まず、上部組織として情報セキュリティ政策会議があり、官房長官が議長をして、各省庁に政策徹底のにらみを利かせます。専門委員会を作って、各課題ごとに衆知を集めます。これが役所のやり方です。
その結果、今年度を始とする3年度計画が決まり、それに沿って施策が実行に移されていくことになります。進捗は順調だということです。
計画のコンセプトは、経済国家のための、国民生活のための、安全保障のための情報セキュリティ、だそうです。
コンピュータシステムに関する事故が増えるにつれ、その被害や侵入の証拠を確保しておく必要性は高まっています。そのための技術をデジタルフォレンジックス、又はコンピュータフォレンジックスというそうです。
13日に開かれたネットワークセキュリティフォーラム2006で東京電機大の佐々木良一教授が、その基調講演でそのことを紹介しました。日本では耳慣れない言葉だと思いますが、米国では訴訟手続きで証拠書類の提出が行われており、その関係でデジタルフォレンジックスは進んでいるとのことです。
このフォレンジックという言葉ですが、forensicとつづり、法廷を意味しています。法医学の原語は、forensic medicineです。
業務文書で使われているフローチャートを調べて、それをビジネスプロセス図に書き換える変換規則、変換ガイドを作成してみました。書類の作成・更新、書類の参照、入手、送付などをBP図では作業に変換し、フロー制御を書き換えればいいわけです。
フローチャートとしては、｢内部統制の入門と実践｣(佐々野未知著）に掲載されている約30個程度の業務フローを使用しました。変換規則、ガイドは13個程度です。その程度の変換作業で、フローチャートをもとにしてビジネスプロセス図を描くことができます。
フローチャートの描き方は、企業によって、描く人によって多種多様でしょうが、それに合わせて変換規則を作ればいいわけです。
既存のフローチャートがない場合でも、下書きとしてフローチャートを描き、それをもとにしてBP図に仕上げるということも現実的だと思います。
内部統制の成熟度が現状、成熟度3にあれば、その内部統制対策として、少なくても次の選択肢が考えられます：
1)現状の業務に関する文書をもとにして、社内評価と外部監査に使えるように文書を見直す。
2)成熟度4を目指して、コンピュータシステム化することを視野に入れて、その最初の段階として、業務に関する文書を再構築し、それをもとに社内評価と外部監査に使える文書を生成する。
後者の選択肢は、その手段としてBPMの手法とツールを活用することになります。文書の再構築に際して、既存の業務フローがフローチャートスタイルで描かれていれば、これをもとにして、BPMツールでビジネスプロセス図に書き換えることが、現実的な解決策になると思います。
内部統制が現在、どの程度実現できているかを測る尺度として、内部統制の成熟度を考えてみます。現在の成熟度がわかれば、その水準に応じて、適切な対策を講ずることができるようになります。
成熟度といえば、CMM、CMMIが有名ですから、それと対比して内部統制の成熟度を考えます。内部統制の段階は、業務プロセスの確立、文書化、コンピュータシステム化ととらえます。
成熟度1：業務プロセスが確立していない状態。
成熟度2：特定の業務プロセスは確立している状態。特定の業務のやり方は定まっていますから、同種業務は繰返し、同じように実施できる段階に相当します。CMMIでは、管理された段階と称しています。
成熟度3：業務プロセスの文書化ができている状態。業務のやり方を定義することができるようになり、この文書化された業務のやり方が、組織全体で共有されている段階に相当します。CMMIでは、定義された段階と称しています。
成熟度4：業務プロセスがコンピュータシステム化されている状態。業務の実績が定量的に監視され、定量的に管理できている段階に相当します。CMMIでは、定量的に管理された段階と称しています。
成熟度5：業務プロセスが継続的に改善されている状態。CMMIでは、最適化している段階と称しています。ここで気をつけてほしいのは、他の段階では完了形ですが、成熟度5では進行形だということです。
内部統制に関する啓蒙的、概要的なセミナーは、まだまだにぎやかですが、 内部統制を規定している法律に立ち戻って、基本を認識しておくことは重要です。そこで、法律の条文を調べてみました。
まず、この5月に施行された会社法。その第362条は、取締役会の権限等を規定していますが、その一部を抜粋しますと、
第4項 取締役会は、次に掲げる事項その他の重要な業務執行の決定を 取締役に委任することができない。
第6号 取締役の職務の執行が法令及び定款に適合することを確保する ための体制その他株式会社の業務の適正を確保するために必要なものと して法務省令で定める体制の整備
第5項 大会社である取締役会設置会社においては、取締役会は、 前項第6号に掲げる事項を決定しなければならない。
次は、この6月に法律となった金融商品取引法。その第24条は、有価証券報告書の提出を規定していますが、その一部を抜粋しますと、
第24条の4の4（抜粋）
有価証券の発行者である会社その他の政令で定めるものは、 事業年度ごとに、 当該会社の属する企業集団及び当該会社に係る 財務計算に関する書類その他の情報の適正性を 確保するために必要なものとして内閣府令で定める体制について、内閣府令で定めるところにより評価した報告書（「内部統制報告書」）を有価証券報告書と併せて内閣総理大臣に提出しなければならない。
この条文で述べている内閣府令は、まだ発行されず、代わりに金融庁の審議会が作った基準案があります。
既にフローチャートで書かれた業務フローをもとにして、BPMNに従ってモデル図を描こうとすると、フローチャートとBPMNの違いを実感できます。たとえば、
1）フローチャートでは作業と書類の流れが混在している。BPMNでは作業の流れだけです。書類の流れを、書類を作成する作業、書類を運搬する作業などに変換しなければなりません。
2）フローチャートでは開始点がいくつあってもかまいませんが、BPMNでは1箇所に制限されますから、プロセスを分割する等の工夫が必要になります。
3）フローチャートでは自由に線をつなぐことができますが、BPMNでは決められているフロー制御に従う必要があります。
等をあげることができます。しかし、これらは慣れの問題でしょう。それ以上に、書き手と読み手の間に表記法が共有されていることによって、意思疎通がよくなる利点が大きいと思います。
業務プロセスを表記する標準のひとつがBPMNで、これはオブジェクト指向設計技法に属するUMLの系列に入り、実際、その中のひとつ、アクティビティ図に似ています。
フローチャートでしか業務フローを書いたことのない人にとっては、文法の決まっているBPMNで書くのは不自由だと思うでしょうが、十分な表現能力を備えています。たとえば、
1）作業の選択。
2）作業の繰返し、差戻し。
3）平行作業とその同期。
4）平行作業と一方のキャンセル。
5）エラー処理、例外処理。
6）処理待ち。
等を表現できます。業務プロセスをBPMNで記述すれば、このデータをプログラム作成ツールに引き渡すことができ、描いた業務プロセスに沿った業務プログラムの作成に連動できます。これが利点です。
業務プロセスに係る内部統制の完成された姿は、すべてをコンピュータプログラムに置き換えることですが、すぐには実現できないので、段階的に実装していくことになります。
最初の段階は業務プロセスそのものを確立する段階です。業務のやり方、手順を調べ、文書化し、それが現実と同じであることを確認します。
次の段階では、不足している内部統制を組み込み、改善された業務プロセスをテストします。
そして、コンピュータプログラムに置き換えます。一度に全部ということにはならないでしょう。選ばれた業務プロセスの一部の作業がプログラムに置き換えられ、順次、拡大を続けることになります。
ここで重要なことは、変化し続ける業務プロセスの記述を維持していくことです。業務プロセスが確立していなかったときから、かなりの部分がプログラム化されてきたときまで、一貫して同じ手法で業務プロセスを記述していけば、間違いなくコストは減ります。
業務プロセスを記述する手法には、既にBPMNという標準表記法があります。これを活用すればよいのですが、23日の内部統制ソリューション展ではあまり見かけませんでした。
内部統制ソリューション展が、日経BP主催で23日、24日と開かれています。23日に参加して一番印象に残った言葉はIT全般統制です。そして、その要が情報セキュリティだということを強く感じました。
財務報告に係る内部統制の最良の姿は、財務報告に係る業務プロセスをすべてコンピュータプログラムにやらせることです。人は間違えたり、不正をしたりするが、正しく作ったプログラムは信頼できるからです。とすれば、問題はそのプログラムは正しく作られたかに移り、システム開発とシステム運用における統制が問題の中心となります。これがIT全般統制ということになります。
内部統制は、全社統制と業務プロセスに組み込まれた統制に分けられますが、このIT全般統制は、全社統制同様、すべての連結子会社に求められるという点で重要になります。つまり、重要でない子会社は業務統制を除外できますが、IT全般統制は必要だということです。
財務報告が信頼できるかという問題が、作ったプログラムが信頼できるかという問題に変わったことになりますが、そうなると、プログラムやデータへのアクセス制御、パスワード管理等、システム開発や運用における情報セキュリティ対策が重要だという主張には納得できます。
ふじみ野市の流水プールでの死亡事故の原因は、外注品質管理のまずさにあるといってよいと思います。
プールの管理業務は、市からA社へアウトソースされ、A社はこれをB社に再委託し、B社はアルバイトを雇ってこれを実施しています。ここで、外注しているプール管理の仕事の品質が課題であり、、今回の事故は、この品質管理を軽視したことに起因していると考えます。
どうすればよかったのでしょうか？市は、A社は、それぞれ、安全確保のための要求事項とその品質基準を提示し、その実施状況を監視するべきでしょう。要求事項には、安全点検の回数、プール指導員（アルバイト）への導入教育などがあり、その実施状況を定期的に市は、A社はチェックすればいいんです。
これは外注するときの品質管理の基本であり、最小限のやるべきことでしかないと思います。それが出来ないのは、やはり、教える人がいないからでしょうか？
もうひとつ、市の落ち度を指摘したいと思います。再委託の監視です。市は契約違反だといいますが、再委託を放置していたのは、市の怠慢であり、責任を免れません。
ニュースによれば、再委託先のB社というのは、A社と一緒に入札に参加していたそうですが、事実とすれば、談合の疑いもあり、放置した市の責任は思いと考えます。市には外注管理を習得してほしいものです。
「フラット化する世界」、「ハイコンセプト」という二つの本が売れているようですが、共通に主張していることは、取り替わられない仕事をしなさいということです。
誰が仕事を奪うのか？それは、優秀で賃金の安いアジアの人であり、正確で速いコンピュータプログラムというわけです。個人は、国、企業に続いて、グローバルな競争にさらされているというのが、その根拠です。
グローバルな競争に勝ち抜く処方箋は？学ぶ方法を学びなさい。熱意と好奇心を育てなさい。人を好きになりなさい。右脳の活用を進めなさいと、フラット化する世界の著者は言います。
一方、ハイコンセプトの著者は、豊かな世界における処方箋として6つの感性を磨けと主張します。つまり、機能よりデザイン、議論でなく物語り、全体の調和、論理でなく共感、遊び心、ものより生きがい。ここでも右脳の活用がキーになっています。6つの感性を身につければ、アジアの人やコンピュータに仕事を奪われることはなく、豊かな世界に非物質的な満足を提供できます。
偽装請負という言葉が、今日の朝日新聞のサイトで目に付きます。大手メーカの工場で増えていて、当局からの指導を受けているが、違法状態は解消されていない。20代、30代の若者が劣悪な条件で働かされていると報じています。
昨年度の当局調査では、660社中358社で問題が見つかり、指導したと言います。アンケート結果によれば、派遣と請負の区分を理解しているのは、34%しかない。3分の2は、違法状態を理解しないということになり、驚きです。
ニュースで報じているのは、製造現場ですが、ソフト開発現場も同じようなものだと想像します。もっと悪いかもしれません。この原因は、教える人を育ててこなかった、教えることを無駄だとしてきたことによると思います。
今まで、有料の頃から、ブラウザとしてOperaを使ってきました。近頃、第9版がリリースされ、新しい物好きですから、それに更新しました。結果から言えば、これが失敗で、今ではFirefoxを使っています。
第9版に更新したとたん、今まで表示できていた多くのサイトが表示できません。セキュリティにうるさい金融系のサイトは、ほぼ全滅です。理由は、Operaの自己主張です。前版までは、サイトにこのブラウザはIEだと認識させていました。第9版は、Operaだと認識させるのです。当然、サイトごとにこの認識を変更する機能は用意されていますが、その手間が半端でありません。
同じく、タブブラウジングの機能を持つFirefoxに乗り換えました。ブックマークが失われますが、既に世の中は検索の時代です。大して困りません。
今回の姿勢に、開発者の傲慢さを感じました。よいと思ってる、静かなユーザを無視してはいけません。彼らは、このユーザは少数派と考え、自分の戦略を優先させたとしたら、市場の結果が出るのを楽しみにしています。
人材育成の重要性を誰もが叫びます。ソフトウェア分野では、ITSSやETSSなどのスキル標準が整備され、それに対応する教育体系、教育コースが、たくさん、提案されてきています。
それらの趣旨は、ある職種に必要なスキル、知識と、教育コースの対応関係を示すことです。つまり、この教育コースを受ければ、あの職種に必要なスキルを獲得できるといっているわけです。
このアプローチは、教育体系の全体像を示すことに貢献しますが、肝心なことから目をそらしかねません。知識の習得以上に重要なことは、学ぶ方法を教えることではないでしょうか？
かって、人工知能が話題となっていた頃、知識の量より、推論能力の良し悪しが性能を決めるといわれていました。推論能力とは、論理的に考える力を意味します。知識をもとに結論を導く能力になります。
最近、話題を集めている本、「フラット化する世界」の著者は、これからのフラットな世界では、学ぶ方法を学ぶことが重要だといっています。知識はすぐに陳腐化するし、後続する人は、より早くその知識を習得できるから、差異化能力にならない。
学ぶ方法と同じように、前段の学ぶを取り替えて、論理的に考える方法、ソフトウェアを設計する方法等も重要で、これらの基本スキルを教えることを考えなければいけないと思います。
日本IBMは、内部統制支援ビジネスを展開するため、全営業員に業務内容や手順を文書化する等の内部統制に必要な作業を教え込む社内教育をこれから始めると、日経サイトが報じています。
ニュースによれば、対象者は3千人で、講師は20名。e-ラーニングを活用し、グループ会社のコンサルタントも活用する。
これは導入教育に相当します。必要な知識を身につけて、いよいよ実線です。そのとき、身近にいてコーチしてくれる人の存在が、成果を左右することになるでしょう。
今日のニュースによれば、NECは外注先のソフト会社への支援を強化するそうです。開発効率の向上、人材育成が目的で、支援することによって囲い込もうという戦略です。
支援には開発ツールの提供だけでなく、人的支援が含まれ、指導できる人を派遣することになるようです。コーチサービスとの関係で、NECがどういうやり方をするか、興味があります。NECの人を送り込むのか、OBを組織化して、その会社から送り込むのか、第三者の会社を紹介するのか、結果としてうまく行くのかいかないのか？
実際の業務の流れを表現するのではなく、それを抽象化、概念化するのがモデル化だとわかりました。
題材としている設計役務の発注において、設計グループは複数存在し、各グループで複数の設計担当者が起案しています。設計部門からの起案を複数の管理担当が処理します。購買担当はそれを一人で処理しています。こういう事実を元にどうモデル化するか？
次のようにしてみました:
1)設計担当者は100人とし、そのうちの一人が起案等の作業要素を実行する。
2)設計グループ長は10人とし、実際は起案者の上長でないといけないが、そのうちの一人が対応するとする。
3)管理担当者は3人とし、扱いは設計グループ長に同じ。
4)購買担当者とそのグループ長はそれぞれ1人。
5)取引先は10社とし、その扱いは設計グループ長に同じ。
これで起案の発生する間隔時間を入れれば、シミュレーション結果はどこがボトルネックかを示すはずです。購買担当者一人で、待ちなく処理できるのは間隔時間がどこまでか、シミュレーションでわかります。
ビジネスプロセスをシミュレーションするには、すべての作業の作業時間を定義する必要があります。所要時間というのと作業時間があり、なんとなくわかりますが、面倒なので同じ値を設定します。さあ、シミュレーションさせました。一定間隔で30回実施です。
結果のレポートを見ると、どこにも待ちがなく、せいせいと流れています。そうです。作業する人の数を定義する必要があるんです。それで設計担当者を30人に変えました。間隔も短くしました。その結果、購買担当者と取引先がボトルネックになっています。購買担当者はそうでしょう。取引先はこれも複数にするべきでした。
業務フローだけだと定性的な分析ですみますが、シミュレーションするとなると、量的な分析が必要となり、フローの定義も変える必要がありそうです。つまり、実際のフローではなく、それを概念化し、抽象化する必要があるんです。ビジネスモデルといってますから、実際とは違うんです。
Savvion製のプロセスモデラ体験版を使って、設計役務発注業務をプロセスモデルとして書いてみました。
まず、登場人物は6人ですから、水泳コースを引くように、スイムレーンを6本引きます。作業は四角い箱の中に書き、順番にスイムレーンに配置します。差戻し点にはOR結合を配置し、チェックポイントには条件分岐を配置します。分岐にはOKとかの名前をつけます。そんなに手間取らずに作図できました。
登場人物が縦軸に並び、作業が横に進んでいきますから、わかりやすいのは確かです。
さて、次はシミュレーションです。
設計役務を取引先に発注する業務の流れを、まず、BPMツールを気にせずに考えてみます。
作業の主体を個人としましたから、設計担当者、設計グループ長、管理担当者、購買担当者、購買グループ長が登場します。取引先は個人に分解せず、取引先のままとします。
業務フローは次のようになります：
1)設計担当者が設計役務発注に関する書類を起案。
2)設計グループ長がそれを承認。
3)設計担当者がそれを管理担当者へ提出。
4)管理担当者がその内容をチェック。NGであれば3)へ差戻し。
5)管理担当者が購買請求システムへ入力。
6)購買担当者がその内容をチェック。NGであれば4)へ差戻し。
7)購買担当者が見積依頼を発行。
8)取引先は見積を検討。問題あれば7)へ差戻し。
9)取引先は見積回答を発行。
10)購買担当者が購買決裁を依頼。
11)購買グループ長がそれを決裁。
12)購買担当者が取引先に注文書を発行。
13)取引先はその注文書を受領。
次にツールを意識すると、このフローが流れるためには次の扱いがわかりません：
●書類の運搬
●購買請求やEDI等のシステムとのつながり
BPMツールを覚えましたので、何かビジネスモデルを書いてみようと思います。題材は、設計役務を取引先に発注する業務を取り上げます。
まず、この業務は設計部門、取引先、調達部門が関係します。設計部門をよく見れば、設計グループと管理グループが係ります。ビジネスプロセスを書くということは、そのプロセスをもう少し細かい作業に分解し、それらの作業の流れ、関連を図示することです。
ここで、次のことを決めておかないと、書いたものの統一が取れないと気づきます。プロセスの大きさ、プロセスと部門との関係、プロセスを構成する作業の大きさ、等です。具体的に言えば、設計部門、取引先、調達部門に分けてプロセスを定義するか、全体をひとつのプロセスで定義するか？作業は設計部門を主体とするか、設計部ループを主体とするか、設計者を主体とするか？
一つの業務を部門ごとに分割せず、部門横断的にひとつととらえることにし、作業の主体は個人とすることにして、設計役務の発注業務を書いてみようと思います。
SECフォーラムの2日目に、恒例となった組込みソフトウェア産業実態調査の結果が報告されました。これは既に、IPAホームページに掲載されています。
まず技術者数の推移として、昨年より約2万人増えて、約20万人が従事しています。不足は9万人強で、比率では50%不足となり、不足度は昨年より増えています。増加者の内訳では、40代、50代が増えている。
職種では、ブリッジSEが一番不足しており、約2倍必要という結果が出ています。技術領域としては、技術要素より、開発技術と管理技術が重要と考えている技術者が多い。
面白いことに、100人未満の企業では、30代が少なく、若年層と40代、50代の高スキル層が多い。
品質に関しては、二極化が進んでいるとみています。悪いところはより悪くなり、よい企業はもっとよくなっているという意味です。その差が、ソフトバグの量です。ソフトに強い企業が品質を上げていることになります。
この調査は膨大なもので、今回の報告も90分を費やし、これに国の威力と威信みたいなものを感じるのは、おかしなことでしょうか？
12日、13日の両日にIPA SECの1年間の成果を報告するSECフォーラムが開かれましたが、そこで印象に残った講演は、経済産業省情報処理振興課の鍛治課長の情報サービス・ソフトウェア産業維新に関する講演でした。
この産業の問題点を、粗利が5%以下という低さであること、多重下請け構造で責任と生産性がよくならないこと、学生人気が低いことと捕らえています。打破するには、透明で、価値が見える産業構造に変える必要がある。だから産業維新だというわけです。具体的には、たとえば、
1)ユーザニーズを定義できるソリューションプロバイダが出てきてほしい
2)ユーザ企業は、コーディネーション能力を高めてほしい
3)プロマネだけの独立企業が登場してもいいんじゃないか
4)情報処理試験とITSSの関連付けを進めたい
5)ベンダ能力評価制度を始めたい
等のビジョンを披露しました。最後には、システムの信頼性とユーザ企業の生産性を可視化する必要性を強調し、その推進をSECに期待して講演を終えました。久しぶりに、高級官僚の気概を感じてしまいました。興味あれば、講演記録は、IPAのホームページからダウンロードできるようになると思います。
先月30日、日本BPM協会主催のBPMフォーラムで内部統制に関して、Bizコンサルティングの佐々野さんの講演を聞き、次のことを理解しました：
1）内部統制には、会社法によるものと日本SOX法によるものとがある。
2）緊急性の高い日本SOX法が求めるのは、財務情報の信頼性。
ということは、まず必要なことは、勘定科目の数字を納得させるすべを備えることです。それで、当社に当てはめて考えてみました。
重要な費用科目として交通費があります。この決算数字がたとえば、50万円だとします。なぜ50万円なのかをどう説明するか？プロセスを説明し、これが妥当であることを納得してもらうしかありません。1回の交通費の計算の仕方、会社への請求の仕方とその承認方法、支払いと受領確認方法、証拠書類、これらを説明し、見せて、その結果として交通費総額が50万円となったといえば、納得するでしょう。売り上げに比べてこの額でいいかどうかは、これは別の問題です。
というわけで、重要な決算数字の説明のすべを、日本SOX法の適用対象会社は、これから2年かけて準備しなければなりません。当然、まずい点があれば、是正しなければならないのは言うまでもありません。このすべのひとつに、BPMがあり、当社もこのBPMの世界に身をおきたいと考えています。
日経コンピュータ5月15日号は、特集を組んで、ビジネス速度を早くする武器としてBPMを解説しています。このBPMが狙い通りユーザ企業に浸透していくためには、ユーザ企業内の業務プロセス設計者に対するコーチ役が必要だと感じます。
BPMについては、日本プロセスの宇野澤さんが、昨年9月からブログでその解説を載せています。それによると、BPM（ビジネスプロセスマネジメント）の利点を3点挙げています：
1）ユーザが業務プログラムを書けるようになる。
2）プログラムの変更が容易になる。
3）ユーザ、ベンダ等のすべての関係者が理解できる共通概念ができる。
これは次の問題意識の裏返しです：
現場ユーザの業務が、IT技術者には理解できない。
これからのシステム開発は、ビジネスプロセスを設計するユーザ、それを実際に構築するベンダ、その仲立ちをするコンサルタントの共同作業になるとみています。そのための開発ツールがBPMSで、これをプラットフォームにしてビジネスプロセスがモデル化され、シミュレーションされ、実際に構築され、実行されることになります。
最初の段階ではコンサルタントの活躍がキーになるでしょうが、普及していくためには、ユーザ自らが、BPMコーチサービスを受けて、システムを開発する段階に達すると思います。最初の段階でも、ユーザやベンダに対する支援が必要になるでしょうから、BPMには注目していきたいと思います。
カーネギメロン大学のソフトウェア工学研究所（SEI)はCMMIで有名ですが、近頃はソフトウェアプロダクトラインなるものに力を入れています。その紹介セミナーをIPAの中にあるソフト工学センタ（SEC)が主催しました。
これは要するに再利用技術の一環で、高スキル人材の活用、品質向上などを特に目的としています。SEIの定義によれば、共通の管理された特徴を持ち、共通の再利用資産に基づく一連の商品ということになります。共通の管理された特徴というのは、簡単に言えば、共通アーキテクチャといっていいでしょう。
そんな能書きはわかっているけど、いろいろな障害があって再利用できないんだという反論がありそうですすが、そこを変動性（variability)という概念で対処しようとします。まず、変動性を次の2種類に分類します：
1）機能、品質などの商品の本質に関するもの、
2）OSやミドルウェアなど、技術的なもの
次に、要求事項を必須、選択的、代替的なものに分類し、管理していくわけです。
組込みソフトの開発効率が急務の課題だけに、これは検討する価値があるかもしれません。
スキルという言葉がよく使われていますが、能力との違いは何でしょうか？
辞書を調べてみます。スキルとは、訓練や熟練を必要とする技能。あるいは、訓練によって得た技能。英語のskillもほぼ同じです。
関連する言葉として使われるキャリアは、専門的技能を要する職業についていること、という意味もあり、この専門的技能をスキルと解釈できます。
一方、能力は、物事をなし得る力。関連する言葉として、職能、能力給などがあります。英語では、faculty、abilityに対応し、共に先天的又は後天的に得た特定分野の又は一般的な能力を意味しています。先天的な能力に対しては、tarent、genius、giftなどの言葉があります。
次に、Googleで検索してみますと、能力に対しては、職業能力、能力検定、能力開発、漢字能力などが出てきます。スキルに対しては、断然、ITスキル。
これらのことから判断して、次のように考えることにしました。つまり、能力のほうが範囲が広く、スキルはその中に包含される。能力のほうが言葉としては古い（最近は、能力=脳力なんて使い方をされている）。スキルのほうが、専門的、職業的香りがある。先天的な能力を視野にしていない限り、これからは、スキルを使うことにします。
プロジェクトマネジメント関係の団体はどれだけあるのでしょうか？例によって、Googleでプロジェクトマネジメントを検索してみます。登場順に、
日本プロジェクトマネジメント協会（PMAJ)
プロジェクトマネジメント学会（SPM)
プロジェクトマネジメント協会（PMI)東京支部
先頭のPMAJはプラント業界を中心として、日本独自の資格、P2Mを推進し、PMIは米国に本拠を置き、PMPという資格を認定しています。SPMは文字通り、学術研究を主体としています。
今まで、PMBOKとかEVMとかでPMI東京支部との接触がありますから、PMI会員を取得することにしました。その申し込み方法は、PMI東京支部のサイトに載っています。年会費は、169ドルです。本部と東京支部に加入することになります。申し込み後の経過を紹介しますと、
1）PMI本部のサイトで申し込み手続きをします。英語ですし、記入項目が多いので、結構、手間取ります。支払いはクレジットカードになります。
2）カード認証が終わると、申し込み手続き中に、IDが発行されます。このとき、パスワードも登録します。
3）翌日、カード支払いの確認メールが届きます。
4）翌々日、Welcomeメールが届き、PMI本部の会員サイトにアクセス可能となります。月刊誌としてPMI today、PM network、季刊誌としてPM journal（論文等）をPDF形式で読むことができるようになります。
5）その後、会員証、PMBOKのCD-ROM等が郵送されてくるそうです。1,2ヶ月かかるらしいですが。
6）東京支部の会員サイトには、このままではまだアクセスできませんが、仮登録をすれば、即日、アクセス可能となります。ニューズレターや、フォーラム、部会等の情報を読むことができるようになりました。
先週、東京ビッグサイトでIPAの報告会が開かれ、ITスキル標準の第2版が紹介されました。各方面からのコメントに対応してわかりやすくしたということですが、基本線は同じで、おおむね、次のとおりです：
1）IT技術者の職種を細分し、定義した。従来、単にSEと称していたものが、ITアーキテクト、プロマネ等として定義された。
2）実務能力を示す尺度として、職種共通に達成度指標を定義した。その上、職種ごとに評価基準を設定した。
3）職種ごとにそれに必要なスキルとして、スキル項目と知識項目を対応させた。
4）スキル習熟度を示す尺度として、スキル項目ごとにスキル熟達度を設定した。
このITスキル標準(ITSS)を活用すれば、次のことが可能となります：
●あるプロジェクトを計画するとき、必要な技術者をITSS定義の職種と達成度指標で表現できます。
●今後、求める技術者をITSS定義の職種で表現すれば、どういうスキル項目と知識項目を教育すればよいか、その教育計画を作ることができます。
不満点と限界をあげると、
■スキル熟達度が、スキル項目共通にその意味を定義されていない。たとえば、熟達度7とは、どういう意味なのかがわからない。達成度にはこの共通の意味が定義されています。
■技術者のスキル（能力）を総合的に測る尺度となっていない。あくまでも、ある職種に求められる尺度でしかありません。
当社が提供する人材育成レンタコーチは、個人の能力、その集合としての部門の能力に焦点を当て、教育計画策定、教育効果の測定などに取組みます。その狙いと手順は、「部門能力評価の狙いと手順」を参照してください。URLは次のとおりです：
http://homepage2.nifty.com/rent-a-coach/library.html
10数年前になりますが、市場シェアで負けているソフトを開発していた頃、市場シェアの高いソフトに習熟したほうが、それがキャリアとしてほかでも通用するので、あなたの会社のソフトが優秀でも、それを選びたくないと言われたことがあります。今でも忘れられません。
先週、IPAの報告会があり、オープンソースソフトに関して自治体での利用例が紹介されているのを聞きました。マイクロソフトのOffice製品をやめて、あるOSS製品を採用して、うまく行っているという内容です。これを聞いていて、10数年前のことを思い出し、圧倒的に市場シェアの高いツールの採用をやめた勇気を評価すると共に、デスクトップ製品をOSS製品に変える時の抵抗を感じました。それに習熟しても私のキャリアにならない、という抵抗です。この対策はあるのでしょうか？
懸案の問題や課題を自ら分析し、その処方箋を作成するのが、コンサルタントの仕事になりますが、コーチは、顧客が問題を分析し、その処方箋を作成するのを助けるだけです。コーチの手を借りることによって、一段、高度な成果を達成できます。
顧客がどちらを望むかは、ケースバイケースでしょう。より早く処方箋がほしければ、コンサルタントに任せるほうが得策かもしれません。処方箋を実行することを考えれば、コーチの手を借りて自ら作成したほうが、実行はやりやすいかもしれません。
このコーチに望まれることは、対象の問題領域に関する専門家としての知識と能力、それにコーチスキルになるのでしょうが、この種の人材がまだ少ないのでしょう。後者のコーチスキルは、経験すればすぐに身につくように思います。
昨日からRSAセキュリティコンファレンスが開かれています。その関連のニュースが多く流れていて、一段と情報セキュリティへの関心が高まっているように感じます。クレジットカード番号が盗まれたとか、銀行口座から預金が勝手に引き出されたとかいう事件報道もあり、ウィルス、ワーム、ボット、暗号などの技術用語にもあふれ、面白いですが、製品設計者が気をつけないといけないことは何でしょうか？
脅威とその対策に整理してみますと、次のようになります。
■脅威1：設計情報の漏洩
対策1)ノートPCやメモリ媒体を暗号化し、盗難や紛失に備える。
対策2)メールに添付するファイルは暗号化する。
対策3)公衆無線LANを利用して仕事はしない。
対策4)ウィルス対策ソフトは最新状態にしておく。
■脅威2：製品へのウィルス混入
対策)フリーソフトは利用しない。
■脅威3：製品のセキュリティホール残存
対策)開発ツールや部品ソフトのセキュリティ対策を最新状態にしておく。
詳細の解説は、当社のサイトに掲載するつもりです。
レンタコーチという商品は、コーチというサービスを提供します。最近、コーチングという言葉が話題を集めていて、このコーチという言葉からコーチングを期待されることがあります。コーチングとは、相手の能力を引き出すことですが、話を聞いていると、求めているのは、助言、アドバイス、支援だったりすることもあります。
レンタコーチのコーチのやり方は、助言、支援、それにコーチに分類されます。助言は教えることであり、支援は手を貸すことであり、コーチは相手の能力を引き出すことになります。期待に応じて、やり方を変えていかなければなりません。この期待や求めていることが、定かでなかったり、変わったりしますから、やり方を合わせるということは簡単なことじゃありません。
60歳前の人の再雇用が話題になっていますが、この世代の仕事としてコーチサービスは有望だと思っています。相手に応じて、助言、支援、コーチを使い分けるスキルは、身につけなければならないスキルになってくるのではないでしょうか？
この4,5年、コーチングという言葉が話題になっています。レンタコーチといったとき、コーチングと比較されることがあります。両者の違いは何でしょう？
まず、コーチングとはスキルであり、コーチとは仕事又は職業です。コーチが用いている仕事のやり方がコーチングであり、逆に、コーチに望まれるスキルがコーチングであるともいえます。
コーチングとはどういうスキルかといえば、一般的には相手の潜在能力を引き出す能力であり、ビジネス領域では、マネージャがその部下を育成するときに行うコミュニケーション技術になります。
レンタコーチとしては、コーチングスキルは望まれますが、それ以上にプロジェクトマネジメントとかの専門領域に関する経験と知識の方が重要になります。
来年1月から提供する商品の商標を考えているうちに，この商品が属する業種は，レンタルコーチ業じゃなく，コーチサービス業ということになると思い始めました。この業種の中で他社の商品から自分の商品を識別するためのものが商標ということになる。
コーチサービス業というものが存在して，その中でプロジェクトマネジメントという分野を扱う。他社も同じようなサービスを提供したとき，商標で自分の商品を競争相手から区別する。
そこでこのコーチサービス業ですが，コーチを派遣するビジネスじゃありません。コーチという役務を引き受けるビジネスになります。
具体的には，当社は，たとえば，プロジェクト計画策定をコーチするという商品を提供します。このサービス提供者は，自分はこれをどう進めるのかを商品説明書に記述します。お客様はこれを見て気に入れば，提案を聞くことになります。合意ができれば，お客様の意向を取り入れ，こちらの提案にしたがって仕事を進めることになります。
定款を作成していて気づきましたが，公文書にはその書き方に決まりがあります。接続詞の使い方が独特です。これに慣れていないと，この種の文章は読めません。
たとえば，次の言い回し：
当会社の株主及び登録された質権者又はその法定代理人若しくは代表者は
接続詞として及び，又は，若しくはが出てきます。この結合の強弱には次のルールがあります：
1)and接続詞として及び，並びにを使い，及びが結合は強い。
2)or接続詞として又は，若しくはを使い，又はが結合は弱い。
3)3個以上をつなぐ場合，カンマで並べる。たとえば，東京，所沢及び新宿という具合。
4)列挙の場合は，東京，仙台，名古屋，新潟等というようになる。
そこで，先の例は，結合状況を括弧で表してみると，
（当会社の株主及び登録された質権者）又は（その法定代理人若しくは代表者）は
ということになります。こういう文章を書く人がいたら，公文書を取扱っている仕事をしている人だと思って間違いありません。
