アジャイルプロセスはJSOXを駆逐できるか〜JSOXとアジャイルな関係勉強会成果報告会〜

知り合いのプログラマーさんに誘われて行ってみたイベントです。当日は会場で休憩時間に２〜３話しただけでしたが。アジャイルプロセス協議会主催のイベントは初めてでしたけど、かなり面白かったです。また機会があったら行ってみたいですね。以下は当日の内容のまとめです。

●基調講演「ソフトウェア開発における人間的側面の課題」
京都光華女子大学の阿部先生による講演でした。
・阿部先生の担当科目
阿部先生はメディア情報の授業を通してソリューションワーカ(問題を解決する人・解決する能力を持つ人）の育成をされているそうです。また上級シスアド連絡会や京都きづき塾についての説明もありました。
・久々のソフトウェア開発現場での勤務
阿部先生はおととしインターンシップの一環として、自動車会社のソフト開発に参加されたとのことです。久々の開発現場とのことでしたが、

開発環境は恵まれている
セキュリティコントロールが厳しい
ＳＥ職場は相変わらず３Ｋ
エンジニア個人の能力・やる気に依存している

とのことでした。（昔からかわってないのですね）上記内容に加えて

組織から個人が抜けきっておらず、個人がかんばってプロジェクトがなりたっているが、それが評価されているかは疑問

との話が印象的でした。
・ソフトウェア開発の分野にも、科学的手法が必要
多くの科学工学分野では、計測して定量化、モデル化して評価、それらのフィードバックを行っている。ソフトウェア開発の分野では、いろいろな技法、システム、ツールが提案されたが多くは消え去り、十分な評価が行われていない。また評価することには手間暇がかかる。
・エンピリカルソフトウェア工学(EASE)
Empirical=Experiment+Experience.の造語。ソフトウェア工学に実証性の概念を前提とするアプローチ。
・ソフトウェア工学の人間的側面
ポイントは３つ

ソフトウェア開発は、大勢の専門家からなるチーム作業によってなされる
開発作業の中心的部分は、高度な知的作業
ソフトウェア製品それ自体、高度に複雑な機能をもち、ユーザあるいは関連システムとの多様なインターフェイスを有する

・「技術的側面と人間的側面は車の両輪」
開発にかかわっているのは、クライアントも開発者含めて人間である。ソフトウェア工学の健全な実践と発展には「開発者個人あるいはチーム」「製品あるいは成果」「技術それ自体」の面から見て、人間的側面に対する深い配慮が大きな価値をもつ

人間を機械としてあつかうのはよくない、無理だ
→定量性は、無理かも？

・アジャイルソフトウェア開発
「プロセス指向」よりも「人間指向」。人間を重視する。
・今後の研究の視点
「ソフトウェアは人の問題が重要な位置を占めている」「ＳＥを幸せにするために出来ることがある」

●成果報告１「開発者のためのJ-SOX入門」
エンロン事件などの不正会計事件を受けて成立した米国ＳＯＸ法の日本版。日本向けとして「ＩＴへの対応」が追加された。適用されるのは上場企業であるが、取引のある会社から報告をもとめられることもあるので中小企業でも関係がないとは言えない。

●成果報告２「内部統制の時代到来、情シスは主役になれるか？」
・内部統制のためのＩＴ推進

情報システム（ＩＳ）主導で進めた場合、アプリ統制で進めがち→利用されないコンピュータになってしまう
現場主導で進めた場合、業務統制で進めがち→「今やっていることが正解」になってしまう
全体最適のＩＴ推進　経営戦略とＩＴ全体統制を基盤とする　事業・経営・現場・ＩＳ等のすべての視点を意識し、経営戦略に沿ったＩＴ化を行う

・内部統制推進の実際
「ナンデモ文書化」がすすめられてしまうと、検証可能か運用可能かわからない大量の文書ができてしまう。また現場にはやらされ間や作業の負荷がかかってしまう。
現在の課題としては「あつかう内容が複雑」「あつかう規模が広い」「スピードが要求される」という３つの問題が同時に重なってボリュームを生み出している。
・内部統制推進の適任者は誰？
ＩＳ部門を中心に推進・運用するのが効率的。ＩＳ部門は職務上、部門横断的に仕事をすることがおおいため。
・内部統制へのアジャイルなアプローチ

内部統制を一気に推進しようとしても無理がある
評価は小さな単位で行う方が正確かつたやすい
リスクも小さな単位で見直しできるほうがよい

「ビッグプロジェクトより小さなイテレーション」「変化を前提とする」「変わるモノと変わらないモノを認識する」
変化を前提としているため、ゴール自体も動くものとして考える。ただし、ゴールを常にとらえていればゴールが動いても正しい道（プロセス）を行ける。
・アジャイルなアプローチという新しい基準を導入するために
１番偉いヒトと仲良くなる

やるべき事をやる為には、１番偉いヒトが味方でないと難しい
やるべき事をやった後には、１番偉いヒトが後押ししてくれると非常に効果的
最後の決め手は人間関係、力関係、常日頃の”社内営業”を疎かにしてはいけません

・まとめ
ＩＴ化推進プロセス「変化の小さい領域は思慮深く、堅牢に構築する」「常に変化する領域は小さく、素早く構築し、評価を繰り返す」。その時の状況に応じて、次の要求の実現対象を決定する。対象の評価がＮＧなら確実に前の状態に戻す。小さなＯＫの積み重ねでゴールを目指す。

●成果報告３「システム開発と内部統制」
・システム開発で内部統制に関わるものは？
手順(Plan)→実施(Do)→記録(Check,Action)がされていますか？
Input→[プロセス]→Outputが定義されていますか？
システムを開発する上での重要点

開発標準(基準)　(開発するって何ですか？定義されてますか？)
品質基準(含むISO9000)
モラル

プロジェクト運営する上での重要点

開発計画(プロジェクト計画)
契約関連
組織

・何があれば良いか
基準(標準)や計画書などのドキュメンテーションがあるということは、内部統制がおこわなれているといえる。ただし標準はすべてを網羅するものではない。テーラリング(tailoring （目的などに）合せる　仕立て直す)が手順化されていることが必要。開発対象を「特定化」するというためにドキュメンテーションが重要（分厚い資料やこと細かく定義することが重要なのではない）
アーキテクチャがわかっていることが必要。アーキテクチャは以下のように定義できる

広義(Why,What なぜ必要か、何をシステム化するか)
- システム
- 開発
- 全体の構成
- 構造
狭義(How 「どのように」システムにするか)
- 開発手法
- ネットワーク、データベースなどの構成、構造

なぜ選んだか、何を基準に選んだか。評価、選択することが手順に必要。「基準」が必要
・アジャイルプロセスでは
アジャイルプロセスのプラクティスは、ＰＤＣＡサイクルに有用である。例えば計画ゲームとストーリーカード。
システム開発において、アジャイルプロセスは内部統制と相反するものではないのではないか、なぜならアジャイルプロセスは無手勝流ではない。ソフトウェアエンジニアリングが必要。
・システム開発と内部統制
アジャイルプロセス云々よりも、開発手法の選択を含む、アーキテクチャの選択をしなければならないことが手順に明記されているかが重要。開発手法の選択を誤ると、莫大な費用と時間を要する。最初の手順がメタ化されていないと内部統制が本当にされているとは言えない。

●成果報告４「アジャイルプロセス開発とJ-SOX〜モニタリングの視点から〜」
ＣＯＳＯフレームワーク（ＣＯＳＯキューブ）でのモニタリング(monitoring "日常的・継続的に"監視すること)のこと。
ＩＴ統制が始まると、ＩＴシステムも監査の対象となるため、常にチェックすることが求められる。アジャイルプロセスのうちモニタリングに関係しそうなことは「ペアプログラミング」「タスクカード」「オンサイトのユーザ」「１週間サイクル」などがある。
ＩＴ業務処理統制については、継続的にアジャイルプロセス開発を行うだけで実現しているといえます。

あと、最後の質疑応答で出ていた、ＳＥ＝しあわせなエンジニアの略という話はいいですね。