今回、対応を進めるにあたり、サービス内で一部語句が伏せ字になる点、特定語句を新規表現へと置き換える点を報告。後者の具体例としては「ロリ→ひよこ」「催眠→トランス／暗示」「調教→しつけ」などがある。
同人販売サイト「DLsite」アダルト表現を「ひよこ」「秘密さわさわ」などに変更 クレジットカード会社から要請（KAI-YOU.net） - Yahoo!ニュース
⇧ この対応は、悪手に過ぎる気が...
アダルトコンテンツということで、影響範囲が局所的になると思われるとは言え、「ダブル・ミーニング」が汚染されてしまう気がするんだが...
今回、「ゾーニング」という概念を初めて知ったのですが、
⇧ 利用される業界は様々らしいと。
⇧ 予め定義した基準に対して「有効である」か「有効でない」で「区分けする」行為を「ゾーニング」というってことになるんですかね。
ちなみに、アダルトコンテンツの規制の話は、前々からあったようですね。
ハリウッド映画には1930年代～60年代にかけてヘイズ・コードと呼ばれる自主規制条項があり、多くの主要映画がこの規制に沿って作られました。ところが、ポルノ業界におけるヘイズ・コードはMindGeekなどの企業によって維持されているのではなく、クレジットカード会社・決済サービス・銀行といったエコシステムによって維持されているとのこと。
⇧ へぇ～、アダルトコンテンツに限ると。
「春画」とか扱っている会社も「クレジットカード会社」から要請があったら、対応するのかね？
『華氏451度（著：レイ・ブラッドベリ）』の世界みたいに、文化を破壊しかねない方向に進みかねない危惧はあると。
まぁ、ソフトウェアエンジニアの仕事を増やさないでくれるなら文句はないので好きにしてくれたら良いのですが、こういう動きを見ると、他の国の策定したサービスを利用していると、その国の事情でのルール改訂などに従わざるを得ないことがハッキリしてくるので、海外発祥のクラウドにデータを預けたくないという気持ちは分かりますな。
とりあえず、
ストーヤ氏は、ほとんどの政府による決定とは異なりクレジットカード会社などの検閲は特定のプロセスがなく、事前に当事者との話し合いや公的な説明もほとんどない点が問題だと指摘。「Mastercardのオフィスに行って『こんにちは。この問題について市民として対話をしたいと思います』と言えるとは思いません」「性的なメディアで何が可能かを調停しているのは誰なのでしょう？私にはわかりません。彼らは哲学の授業を受けていましたか？女性学の学位を持っていますか？」と述べました。なお、Financial Timesが接触したクレジットカード会社などの規制担当者には哲学者はおらず、社会学者が1人、弁護士が数人いたとのことですが、彼らは自分自身を決済やリスクのマネージャー、あるいは商取引の促進者だと考えており、ポルノ規制の専門家だと自認している人はいなかったとのことです。
⇧ 規制の基準が分からないのは、良くないですな。
「自由の国アメリカ」にある企業だから、自分たちの好き勝手に自由に規制して良いとなるわけは無いと思うのですが...
Webシステム開発の工程と成果物を整理してみたかったが...
いつまで経っても、統一される感じが無いのと、未だに整理されている情報が無いので整理してみることにします。
「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」の公開しているドキュメントによると、
ソフトウェア開発において、発注者、受注者などの利害関係者間での認識のズレや、取引（主として二者間契約）における作業項目、役割分担等が不明確で取引の適正化がされていない、などの問題が発生しています。
これらの問題の解決策の一つとして、ソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組みを提供する「共通フレーム」を提供しています。「共通フレーム」はソフトウェアライフサイクルプロセスの国際規格である、 ISO/IEC 12207(JIS X0160)をベースに、日本独自のプロセスを追加したものです。
2013年3月4日に発行した共通フレーム2013は以前の版である「共通フレーム2007第2版」を大きく変更しリニューアルしたものです。
主な特徴として以下があります。
・ベースとなる国際規格をJIS X 0160:2012に変更
・要件定義プロセスに、要件定義の国際規格であるISO/IEC/IEEE 29148のエッセンスを導入
・運用・サービスとシステム開発の連携を考慮した、サービスブロセスの導入
・システム開発とソフトウェア開発の明確な分離
「共通フレーム」が整合を図ってきた国際規格/JIS、ISO/IEC/IEEE 12207 ［JIS X0160］が「共通フレーム2013」発行前後から2021年にかけて改訂されましたが、「共通フレーム2013」の改訂は行っていません。というのは、改定内容はソフトウェアライフサイクルプロセスの内容そのものに大きな変更を行うものではなく、システムライフサイクルプロセス（ISO/IEC/IEEE 15288 ［JIS X0170］）との調和性を高めるものだからです。したがって、ソフトウェアに閉じた範囲で従来通り企画、開発、運用を行う場合においては、「共通フレーム2013」に基づくことに不都合は生じません。なお、関連国際規格/JISの改訂経緯の詳細等に関しては、次のページをご覧願います。
⇧ とあり、日本でソフトウェア開発においては「共通フレームワーク2013」に従うようにすれば良い模様。
で、エンタープライズ系のソフトウェア開発においては、
⇧ とあるのだけど、「共通フレームワーク2013」に準拠してるのかが分からない...
ネットの情報で、
⇧ 上記サイト様がまとめてくださっておりましたので、参考にさせていただくということで。
IPAが『共通フレーム２０１３の概説』というPDFを公開しており、
⇧上記の情報も参考にするということで。
で、「工程」に対応する「成果物」としては、
⇧ 上記を参考にするしか無さそうなのだけど、「外部設計（基本設計）」の成果物しか説明が無いというね...
情報が足らな過ぎて正確なマッピングが不可能なのだけど、ソフトウェア開発の「工程」と「成果物」の関係としては、
| No | 工程 | プロセス | 成果物 | ||
|---|---|---|---|---|---|
| 1 | 要求定義 | 企画プロセス | 構想立案 | 問題点、課題、ニーズなど一覧 | |
| 2 | 要求一覧 | ||||
| 3 | 業務機能構成表 | ||||
| 4 | システム化計画立案 | 問題点、課題、ニーズなど一覧 | |||
| 5 | 要求一覧 | ||||
| 6 | 業務機能構成表 | ||||
| 7 | 外部インターフェイス一覧 | ||||
| 8 | 機能一覧 | ||||
| 9 | 業務要件定義プロセス | 問題点、課題、ニーズなど一覧 | |||
| 10 | 要求一覧 | ||||
| 11 | 業務機能構成表 | ||||
| 12 | 画面一覧 | ||||
| 13 | エンティティ一覧 | ||||
| 14 | 外部インターフェース一覧 | ||||
| 15 | バッチ処理一覧 | ||||
| 16 | 帳票一覧 | ||||
| 17 | ドメイン一覧 | ||||
| 18 | コード一覧 | ||||
| 19 | エラー一覧 | ||||
| 20 | 要件定義 | システム要件定義プロセス | システム化業務一覧 | ||
| 21 | 画面一覧 | ||||
| 22 | エンティティ一覧 | ||||
| 23 | 外部インターフェース一覧 | ||||
| 24 | バッチ処理一覧 | ||||
| 25 | 帳票一覧 | ||||
| 26 | ドメイン一覧 | ||||
| 27 | コード一覧 | ||||
| 28 | エラー一覧 | ||||
| 29 | 外部設計（基本設計） | システム方式設計プロセス | |||
| 30 | ソフトウェア要件定義プロセス | システム振舞い | システム化業務一覧 | ||
| 31 | システム化業務フロー | ||||
| 32 | システム化業務説明 | ||||
| 33 | システム振舞い共通ルール | ||||
| 34 | 画面 | 画面一覧 | |||
| 35 | 画面遷移図 | ||||
| 36 | 画面レイアウト | ||||
| 37 | 画面入出力項目一覧 | ||||
| 38 | 画面アクション明細 | ||||
| 39 | 画面遷移・レイアウト共通ルール | ||||
| 40 | データモデル | ER図 | |||
| 41 | エンティティ一覧 | ||||
| 42 | エンティティ定義 | ||||
| 43 | CRUD図 | ||||
| 44 | 外部インターフェース | 外部システム関連図 | |||
| 45 | 外部インターフェイス一覧 | ||||
| 46 | 外部インターフェイス項目説明 | ||||
| 47 | 外部インターフェイス処理説明 | ||||
| 48 | バッチ | バッチ処理一覧 | |||
| 49 | バッチ処理フロー | ||||
| 50 | バッチ処理定義 | ||||
| 51 | バッチ処理共通ルール | ||||
| 52 | 帳票 | 帳票一覧 | |||
| 53 | 帳票概要 | ||||
| 54 | 帳票レイアウト | ||||
| 55 | 帳票項目説明 | ||||
| 56 | 帳票編集定義 | ||||
| 57 | コード | コード一覧 | |||
| 58 | ドメイン | ドメイン一覧 | |||
| 59 | エラー | エラー一覧 | |||
| 60 | 内部設計（詳細設計） | ソフトウェア方式設計プロセス | |||
| 61 | ソフトウェア詳細設計プロセス | ||||
| 62 | コーディング（製造） | プログラム作成・実装 | |||
| 63 | テスト（単体テスト） | 単体テスト | |||
| 64 | 結合テスト | 結合テスト | |||
| 65 | システムテスト | システムテスト | |||
| 66 | 受け入れテスト（運用テスト） | 受け入れテスト（運用テスト） | |||
⇧ という感じになるということですかね。
気になるのは、「シーケンス図」とか「外部設計（基本設計）」で作らないんかいっていうね...
あとは、「ハードウェア」「ミドルウェア」「ネットワーク」などの考慮もされていないし、「非機能要件」とかに関する成果物も無いし...
IPAのドキュメントだと抜け漏れが多過ぎるんだが...
「内閣官房情報通信技術（IT）総合戦略室」が公開している『アジャイル開発実践ガイドブック』というPDFに、
⇧ とあるのだけど、今回参照しているIPAのドキュメントは「ウォーターフォール型」になっているのだから、「工程」と「成果物」を曖昧にしている意味が分からないんですよね...
IPAの公開しているドキュメントが中途半端で適当過ぎるんですよね...
そりゃ、IPAの資格が意味無いって言われても仕方ない気がしますな...
せめて、「工程」と「成果物」の対応表の一覧ぐらいは整備して公開して欲しいですかね...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
