STAP細胞に関する論文をめぐって、2014年4月1日調査委員会は、主要研究者である研究ユニットリーダーに「不正があった」と認定した。
一方、論文データの改ざんなどを指摘された当の研究リーダーが、不服申し立ての意思表示をするなど、この問題は泥沼化の様相を呈しつつある。
STAP論文問題をプロジェクト管理の観点から眺めると、研究リーダーの責任もさることながら、組織上の問題が大きいことに気付く。
プロジェクトとは、目的と期限が定められた活動であるから、STAP細胞に関する研究も一つのプロジェクトとみなせる。
調査委員会は、論文の一部にデータの改ざんやねつ造があったとしているが、これをITのシステム構築に例えるならば、テストデータの改ざんや品質評価報告書のねつ造などに相当する、重大な問題である。
ITのシステム構築においても、このような不正は起こりうる問題（リスク）である。
では、ITシステムのプロジェクト運営では、このような不正を防止するためにどのような対策を実施しているだろうか。対策は、意識的に行われる不正だけでなく、無意識に誤りを犯すミスも考慮する必要があることは言うまでもない。
システム構築プロジェクトでは、不正やミスを防ぐ手立てとして、レビューやウォークスルー、チェック表の活用、複数人による作業実施、第三者によるチェック（レビューや監査）といったことが行われている。
レビューやウォークスルーは、成果物である設計書やソースコードに誤りがないかを、複数人でチェックするものである。
レビューアーとして、設計チームのリーダーや、開発チームのリーダーが参加することが多い。さらにその分野の有識者が加わることもある。
チェック表は作業の漏れや、設計書の不備をチェックするためのものである。
レビュー時に使用することもあるし、作業者が自身の作業漏れや作業誤りを防止するために使用することもある。
作業を複数人で実施する例にはペア・プログラミングがある。これはその名前の通り、2人のプログラマーがペアーを組んでプログラミングを行うもので、相互チェックによる誤りの防止などを目的としている。
プログラマーとテスターを分けるというのも、誤りを除去する施策の一つである。
プログラムを作った人（プログラマー）には、仕様に対する自身の理解が正しいという思い込みがある。
従って、仕様に対する誤った理解を検出するには、別の人（テスター）によるテストが有効である。
フェーズの終了時点で第三者のレビュー（品質チェック）を行うということも一般に行われている。
特にテストの終了時に作成する品質評価報告書の類は、品質管理部門など専門家のレビューを実施することで、データの不整合や、品質メトリックスに対する評価の誤りなどを除去できる。
また、システム構築作業や成果物の作成が規定どおりに行われているかを監査する、システム監査が行われることもある。システム監査基準は1985年に公表され、その後2004年に改訂版が策定、公開されている。
これら、誤りや不正を検出、除去する仕組みは特別なものではない。日本におけるシステム開発作業の標準である「共通フレーム2007（SLCP-JCF2007）」においても、以下のプロセス／アクティビティが定義されている。
・品質保障プロセス
・検証プロセス
・妥当性確認プロセス
・共同レビュープロセス
・監査プロセス
・システム監査プロセス
品質保証プロセスでは、「客観的根拠」の調査及び提出によって、「品質を客観的に保証できること」が求められる。
また、公平な立場で品質保証するためには、「独立した組織および権限」が必要になると記載されている。
システム構築における品質確保の取り組みに比べ、今回のSTAP論文問題における組織的なチェック機能は、報道された範囲を見る限りでは、はるかに貧弱で、ほとんど機能していないように見えてしまう。
検証や監査に関する規定や、独立した組織は存在しなかったのだろうか？
当然のことではあるが、品質を保証するための各種施策にはコストが掛かる。
それでもシステム構築でこれらの施策を実施するのは、後工程になるほど誤りの修復に掛かる費用が増大するからである。 STAP論文問題でも、早い段階で不正や誤りを検知できていれば、今回のような多大なコストは発生しなかったはずである。
さて、STAP論文問題では、上記の検証や監査に関する、規定および組織態勢の問題の他に、コミュニケーション管理にかかわる問題もあるように見える。
システム構築では、だれがどの作業を担当していて、今現在どこまで進捗しているのかを管理するとともに、その情報を関係者間で共有することは、最低限必要なことである。
このような情報の管理と共有がなされていないと、作業の漏れや、作業待ち、作業の遅滞が発生してしまう。クリティカルパスの把握もままならない。
特に少人数で開発するスクラム開発などでは、このような進捗情報を、「毎日」、関係者間で確認することになっている。
このように、STAP論文問題をシステム構築のプロジェクト管理と対比して考えてみると、組織としてやるべきことが行われていないという、実に不可解な点が多いことに気付く。
もっとも、システム構築でもダメなプロジェクトというのは存在する。
しかし、今回のSTAP論文問題とは異なる点がある。それは、ダメなプロジェクトの場合、ダメであることをプロジェクトの多くの関係者が知っている（自覚している）ということである。
|
