it21​/public​/proceedings​/201612

IT21の会（平成28年12月）第213回議事録

日時：2016年12月2日（金）　18時30分～20時30分
場所：葺手第二ビル　5階　C/D会議室
出席者：29名
配布資料：
 アンケート用紙
 IT21-1612-1：テーマ資料
 IT21-1612-2：サブテーマ資料
 CPD行事参加票　（アンケート回答と引き換え）

議事：
[1]　開会の挨拶
　配布資料の確認
　アンケート回答の要請とCPD行事票の交換案内

[2]サブテーマ講演　（18：31-19:05）
　タイトル：オープンソース・ソフトウェアのコミュニティ活動
　講師：　NTTソフトウェアイノベーションセンタ　夏目　貴史氏
　　　　　（技術士　情報工学部門・総合技術監理部門）

　・現在業務で行っている「OpenStack」（オープンソース・ソフトウェア、以下OSS）
　  での開発業務を通して感じているOSS活用・参加活動についての講演
　・「OpenStack」はクラウド・コンピューティング・サービス、IaaS（一部PaaS）を
　   構築するためのOSSである。ライセンスはApache2.0。Python系コンポーネントが多い。
　・NTTが採用した理由
   ①効果的な投資：　自分たちが必要としている機能のみの開発に集中できる。
   ②他社（者）とのコラボレーションが容易。
   ③維持コストの低減
　・各種コンポーネントで構成されている。　Nova、Neutron etc.
　　各コンポーネントの開発は独立統治されている。
　・開発スケジュールについて
　　マイルストーンが設定され、基本的に6ヶ月毎にリリースされる。
　　これとは別途にStableブランチリリースもある。
　　打合せはリモートで参加できるIRCミーティングがある。
　　また、OpenStack　Summit、Mid-cycle Meetupなど対面でコミュ
　　ニケーションを図れる場面に積極的に参加することが重要。
　・ツール類
    リポジトリ（Git）：　GitHubで管理されている。
    Bug Trackingや新機能提案の共有：Launchpad
    コードレビュー：　Gerrit（Googleが開発したコードレビュー用システム）で行なう。
　 ・開発フローについて
     Blueprint作成：　Launchpadにおいて作成する。
     Spec作成：　必要により作成する。
     Blueprint/SpecがCore　Reviewerにより承認されるとコード作成を行なう。
     コード承認　（Core　Reviewerによる承認）
     自動化されたテストの実施
     リポジトリへのマージ
　・コミュニティ活動の難しさ
    時差の問題：IRCミーティングなどUSメンバーが多いことから開催時差が深刻。
　　　　　　　  [対策]　日本のタイムゾーンに近いメンバーを増やすことで長期的に
　　　　　　　          改善される見込み。勤務制度の対応性改善。
　　　　　　　          社内システムの使用時間制限などの問題の改善。
　　　各国の制度の違い：休日や業務形態など
　　　会社の制度上の規制：　外部への投稿時の許可手続きに時間がかかる。
　　　コミュニティでの対外調整の難しさ：特に複数プロジェクトにまたがる内容の開発
　　　など。自分たちが必要なもののみの開発ではなく、関連する機能やコンポーネン
　　　トへの修正が求められたり、開発コンセプトが却下され別のコンセプトでの開発
　　　が要請されたりする。必要な開発業務以外に拡大してしまう。
　　　コポーネントで人気がなかったり、参加メンバーが少ないものは廃止の憂き目にあう。
　　　利用者の多い（人気のある）部位や機能に集中して開発、リリースされていく。
　　　Reviewしてくれずリリースされない。対応方法はIRCミーティングなどで交渉説得する。
　　　その反面、クリティカルな問題解決は早く対応されている。
　　　アピールが重要＞自己主張などが必要
　　　オープンマインドでOSSコミュニティへ参加することが重要
　　　英語でのコミュニケーション問題：他者のコメントなどを参考にしている。
　　　summitなどが各国で開催されるが査証（ビザ）取得など渡航上の制約や海外開発者を
　　　日本によんでのコラボなどでも査証問題などで実現が難しい場合がある。
　  ・OSSコミュニティへの貢献が重要
      まず動かしてみること。
      ソースコードを読んでみる。
      Bug修正への貢献
      Code reviewの貢献：　Core Reviewではなくとも＋１のVoteはCore Review
      をその気にさせる上でも重要。
      コード修正のネタを発信：他のコンポーネントの修正情報やICTの動向から新規
      修正ネタを提案していく。
　　  規約（ルール）に従っていない部分の修正
　　　不要コードの除去
　　　ドキュメント作成への貢献
　  ・Q&Aセッション
      Q：コミュニティでの開発はボランティアという考えであればコミュニティから
         要求される機能追加や他機能への展開など余分な業務は拒否できるのでは？
　　　A：結果的に承認されリリースされなければならず、それに向けては交渉が必要。
　　　　 オープンマインドで対応をしていくことが重要。

[3]　メインテーマ講演　（19:15-20:30）
　　タイトル：X線天文衛星「ひとみ」の失敗は、「発注者のエンジニアリング」の失敗
　　          ～ 新国立競技場建設の白紙撤回に続く、我が国の大規模技術プロジェクトの歴史的破綻
　　講師：　澤田雅之技術士事務所（電気電子部門）　所長　澤田雅之氏
   講演要旨 :
   ・講師は、「技術プロジェクトのマネジメント」と「発注者のエンジニアリング」を
     コアとして技術士事務所を営んでいる。
 　・本日は、X線天文衛星「ひとみ」の失敗事例に基づき、プロジェクトマネジメントの
 　  要諦としての「部分最適化から全体最適化へ」、また、発注者エンジニアリングの要諦としての
 　  「的確な性能仕様書の作成」について、お話したい。
　 ・「ひとみ」は、JAXAの宇宙科学研究所による欧米との国際協力ミッションであった。
　    今年2月の打ち上げに成功したが、今年3月、姿勢測定系のバグにより回転を開始し、
　    姿勢変更系のデータ誤入力によりその回転を加速したため、遠心力で
　    「ひとみ」は分解して失われた。
　 ・「ひとみ」は、昨年に観測活動を停止したX線天文衛星「すざく」の後継と
　   なるものであった。X線天文衛星は日本のお家芸。「すざく」の数十倍の性能の
　   観測機器を搭載した「ひとみ」の喪失により、X線天文学研究の大きな
　   停滞要因となってしまった。
　 ・今年6月にJAXAから事故原因報告書が公表され、その翌日にJAXA理事長、
　   副理事長、宇宙科学研究所長の処分が発表された。
　 ・「ひとみ」が失われた直接的な原因は次の二つ。
　　 ①打ち上げ後の軌道上で衛星本体の機能を確立させるクリティカルフェーズ段階に
　　   おいて、ソーラーパネル展開等に伴う衛星の重心移動を姿勢変更系に反映させるため、
　　   RCSスラスタ(小型のロケットエンジン)の制御パラメータを変更した。
　　   この際、パラメータデータを絶対値とすべきところをマイナス符号付きのままで
　　   「ひとみ」へ転送してしまった。
　　 ②姿勢測定系の想定外の動作(ソフトウェア上のバグ)により、正確な姿勢を
　　   実測できるスタートラッカを自動的に排除してしまい、加速度を測定して
　　   姿勢を推測する慣性基準装置のみに依存する結果となった。
　　   慣性基準装置では、等速度運動によるる姿勢の変化を認識することができないため、
　　   「ひとみ」は、正確な姿勢を把握不能となった。
　 ・姿勢測定系として次の3種が搭載されていたが、天体観測の時間と精度の確保の
　   最大化を追求した結果、トレードオフの関係にある姿勢測定系の信頼性の確保の
　   最小化に繋がった。
　　 ①スタートラッカ：星々の位置を調べて姿勢を正確に実測する。撮像部が地球に
　　   向いている時には機能しない。
　　 ②慣性基準装置：加速度の大きさと方向を調べて姿勢を推測する。誤差が累積するので、
　　   スタートラッカ等の実測値による補正が欠かせない。また、等速度運動による
　　   姿勢の変化は検知できない。
　　 ③粗太陽センサ：　太陽の方角を調べて姿勢を実測する。
　 ・姿勢変更系として次の3種が搭載されていた。
    ①リアクションホイール：ホイールの加速減速の反動で衛星を回転移動させる。
    ②磁気トルカ：電磁石と地磁気の相互作用で姿勢を変更する。
    ③RCSスラスタ：小型のロケットエンジンであるため、非常に強力。
　 ・衛星本体は、実用衛星について国内で最も実績がある企業が開発し製造した。
　 ・宇宙科学研究所の長年の伝統に従い、Ｘ線・ガンマ線天体観測の権威である
　   教授(理学博士)がプロジェクトマネージャとなっていた。しかし、大規模な
　   技術プロジェクトのマネジメント経験が無い上に理学者であるため、
　   衛星の工学的な信頼性の確保については、その重要性と方法を
　   理解していなかったのではないか。因みに、2010年に奇跡の生還を成し遂げた
　   「はやぶさ」は、宇宙科学研究所の工学博士である教授がプロジェクトマネージャを
　   務めた。また、「はやぶさ」と「ひとみ」の開発・製造元は、同じ企業であった。
　 ・プロジェクトマネージャは、ハブ系（衛星本体系）とミッション系（観測機器系）の
　   両方を統括しなければならない立場であるが、専門分野であるミッション系に
　   偏りがちとなり、ハブ系については認識が浅いまま、開発・製造企業に
　   無理な注文をつける結果となったのではないか。
　 ・大規模な技術プロジェクトでは全体最適化が必要であり、これにはトップダウンに
　   よるマネジメントが欠かせない。トップダウンによる全体最適化がなされなければ、
　   プロジェクトはボトムアップによる部分最適化の積み上げに陥らざるを得なくなるが、
　   部分間に依存関係(トレードオフの関係)がある場合には、各部分ごとに最適化して
　   積み上げても全体最適化は望めない。
　 ・「ひとみ」では、天体観測の時間と精度の確保(ミッション系)と衛星の信頼性の
　   確保(ハブ系)とは、トレードオフの関係であった。このため、プロジェクトの
　   目的を見据えた全体最適化に基づく性能仕様書の作成が、本来求められる
　   ところであった。
　 ・事故原因報告書の中で各種の再発防止策が策定され、また、「ひとみ」の後継機の
　   2020年の打ち上げが検討されているが、ハブ系とミッション系のそれぞれに
　   プロジェクトマネージャを立てたのでは、部分最適化を促進しかねない。
Q&A :
    Q1:姿勢変更のパラメータデータ作成時には、誤っていないかシミュレーションで
       確認したり、複数の担当者によるチェックを行う筈であるが？
　　 A1:驚くべきことに、シミュレーションも他の者によるチェックも実施されていなかった。
　　 Q2:姿勢測定系における相互補完関係は、構成図などを用いれば設計審査会で
　　    問題把握できた筈だが？
　　 A2:想定外の事象発生への対応を設計図書に基づき設計審査会で全て
　　    チェックすることは、想定外であるが故に不可能である。ソフトウェア上で
　　    見落としている点(バグ)の発見については、第三者である設計審査会に
　　    期待するのではなく、設計の当事者が全責任を持ってあらゆる角度から
　　    チェックする他に有効な手立てはない。
　　 Q3:新国立競技場建設が白紙撤回された問題や豊洲市場移転にかかる問題について、
　　    「発注者のエンジニアリング」の観点からのご意見を伺いたい。
　　 A3:いずれのケースもプロジェクトマネージャが不在のまま、すなわち、
　　    誰一人としてプロジェクト全体をマネジメントしないまま、「組織対応」と
　　    称する無責任体質の中で推進されていたことが問題の根本に共通する。
　　 Q4:実用衛星では国内で最も実績のある企業が請け負ったのに、過去の開発・
　　    製造事例の再活用などで問題は押さえられなかったのか。
　　 A4:この企業は、「はやぶさ」の奇跡の生還を成し遂げた非常に力のある企業である。
　　    このため、姿勢測定系及び姿勢変更系のいずれについても、機械的には
　　    全く問題は無かった。しかし、宇宙科学研究所が発注者の立場で、
　　    ミッション系活用の最大化ばかりを要請した結果、受注者であるこの企業は、
　　    過去の開発・製造の成功事例を直接的に活かすことが難しくなったと思われる。
　　    改善策としては、設計審査会での審査済みの設計図書に基づく製造発注から、
　　    衛星に求める機能要件・性能要件を網羅した性能仕様書を作成して
　　    設計審査会で審査し、この性能仕様書に基づく設計・製造発注に改めることが
　　    効果的である。

[4]　初参加者の自己紹介　7名

[5]　次回開催の案内
　2017年1月6日（金）開催予定。
　メインテーマの講師はCQ出版株式会社 トランジスタ技術 編集長の寺前氏、
　サブテーマの講師はIT21の会前副会長(第19期)の靭氏である。

（春原　一義@情報工学部門　記）
以上