ソフトウェア工学やQA(Quality Assurance)に関する様々な角度からの研究について、研究者の方にお話を伺う『QA最前線!』。ソフトウェア開発、品質向上・QAを推進する上でも様々なエコシステムが活用されています。こういった流れの中ソフトウェアメトリックスの考え方はますます重要になってきました。最先端の研究現場で、今、どのような研究が行われているのか、注目されている方も多いと思います。
今回は、奈良先端科学技術大学院大学 先端科学技術研究科の松本 健一教授にお話をいただきます。
今回、お話を伺った方
- 松本 健一 教授
NAIST
奈良先端科学技術大学院大学
先端科学技術研究科
情報科学領域 ソフトウェア工学研究室
1989年5月大阪大学・基礎工学部・情報工学科・助手、1993年4月に奈良先端科学技術大学院大学・情報科学研究科・助教授、2001年4月から同大学教授。ソフトウェア工学でソフトウェアメトリクスを中心に研究を進めている。2007年8月からソフトウェアタグの研究開発を目的とした文部科学省STAGEプロジェクト研究代表者。2018年より先端科学技術研究科 情報科学領域 教授。2020年度から5年計画で日本学術振興会科学研究費助成事業「次世代ソフトウェアエコシステムのための基盤・展開技術」を推進。
- もくじ
自分が知っていることだけを出発点にしていては良い研究ができない
――これまでのご経歴や現在、研究されているテーマを教えてください。
現職は奈良先端科学技術大学院大学で情報科学領域のソフトウェア工学研究室で教授を務めています。学生の頃から「ソフトウェアメトリックス(Software Metrics)」に取り組んできました。1985年が学部卒なので、そのあたりからずっと同じことをやっていますね。
開発データを収集するところから始まって、それを分析したり可視化したりして開発者にどうフィードバックするかを中心に、ソフトウェアそのものや、開発・利用のプロセスの定量的評価、数値化の研究を進めています。よく「(ソフトウェアを)作っているんですか?」と聞かれますが、私が研究しているのはソフトウェア工学でも「どうやって作るか?」という話ではなく、作られたソフトを評価し、特徴づけをすることです。
プロダクトとプロセスは両輪のように関係性が強く、プログラムコードを評価しようと思ったら、どんなプロセスで作られたかを見ないとできません。逆にプロセスだけ見ても、最終的に何が作られたかを知らないと評価できません。決められた通りに作っても、完成したソフトウェアがバグだらけでは何の意味もないわけです。プロダクトとプロセスの両方を見ていく形になっています。
プロセスに関しては、最近ではコミュニティで情報共有をして進める機会が増えていて広がりを感じています。
――1980年代後半、ソフトウェアを定量的に評価する動きはあまりなかったと思いますが、先駆的にこの研究に取り組まれた"きっかけ"は何だったのでしょうか?
当時も開発は"力技"や苦労が多く、スマートでないことが多かったですね。開発者のスキルや生産性にも非常に大きな差があったので、開発の生産性を明らかにしたいと考えたのです。これを明らかにしないとソフトウェアの品質も上がらないだろうなと思いました。
1990年代になるとソフトウェアの品質に注目が集まり、関心も高まってきました。ソフトウェアのテスト、評価に関する研究も増えましたが、海外の研究の多くはリリース"後"の話でした。しかも、単位は「年」とか「月」でリリース後3年間でのバグの出方がグラフになっているようなものが多かった印象を受けています。開発中のプロセスを対象にして解析している研究はあまり見られませんでした。
――研究を始められ当初、苦労したことはあったのでしょうか?
今と違い、プログラムコードはもちろん電子的にファイルになっていますが、それ以外はほとんどが紙だったので、開発データを集めるのが紙ベースでした。ラインプリンターで打ち出した紙が何10mといった膨大な量になり、ダンボール何箱分も集まりました。
現在では構成管理ツールなどが普通にありますが、当時はありませんでした。例えばプログラムコードがどう作られているかを調べようと思ったら、全て記録するしかなかったのです。企業でいきなりやるわけにはいかないので、今思うと無茶ですが、学生実験で5分おきに全学生のディレクトリを見に行ってダンプするみたいな感じで進めました。しかも容量がないので、5分ごとに取ってきて「diff」を取って差分だけ残すようなことをしていましたね。
今なら、構成管理ツールもあり、バグトラッキング・不具合管理もシステム化されていますし、開発者間のやりとりも残っていますから簡単になりました。オープンソースでは全て残っています。もう「データがないから解析できません」とはいえなくなりました。
――どんなときに研究の面白さや、やりがいを感じますか?
私が在籍しているのは大学院大学のため、マスターとドクターの学生しかいません。毎年、向学心のある学生が入ってきて新しいアイディアを持ってきてくれて、一緒にやれるのが面白いですね。特に情報分野、ソフトウェアなどは特に新しい技術がどんどん出てくるので、彼らと一緒にできることにやりがいを感じています。
学生は新しい技術をよく知っていて、使っていることもあります。自分が知っていることだけを出発点にしていては良い研究ができないので、学生の学術的興味を優先するよう心がけています。
海外の学生を中心に研究インターンシップにも積極的に取り組む
――研究室には様々な国から留学生が参加されていますが、どんな雰囲気でしょうか?
ここ10年ほど、海外の学生を中心に研究インターンシップに取り組んでいます。単に実習するだけではなく、場合によっては論文も書いてもらっているうちに留学生が少しずつ増えてきました。
受け入れてみると、たしかに最初は言葉の問題はありました。「ちゃんと喋らなあかん」とか思うと話せなくなるので、学生には下手な英語でも何とかなると日々私が示してきました(笑) 最近は日本語と英語がシャッフルされた状況で、お互い別にどっちでもいいという感覚になっていますね。研究も、テーマによっては日本人と留学生等が一緒にやるケースが増えています。
研究室内の連絡はSlackなどが多いですが、メッセージも、以前、日本人学生は日本語だけでしたが、最近は英語でも書くようになってきました。コロナ禍もあり、一緒にご飯に行くとか、旅行に行くとかいうことができないのでコミュニケーションは難しいです。研究と直接関係ありませんが、そういうことも大事だと思っています。
次世代ソフトウェアエコシステムのための基盤・展開技術を研究
――研究室では「次世代ソフトウェアエコシステムのための基盤・展開技術」など、新たな取り組みを進められているそうですね。
数年前にバズワードになり、広まってはいますが「エコシステム」というと分かりにくいかもしれません。「次世代ソフトウェアエコシステムのための基盤・展開技術」というのは、要するに「ソフトウェア開発の効率を改善し品質を高めていくために、組織の枠を超えてみんなで情報や知識を共有したり活用したりしましょう」という枠組みのことです。
例えばソフトウェア開発プラットフォーム「GitHub」やプログラミングに特化したQ&Aサイト「スタックオーバーフロー(Stack Overflow)」もその一例だといえます。
現在、研究室では2020年度から5年計画で日本学術振興会科学研究費助成事業「次世代ソフトウェアエコシステムのための基盤・展開技術」を進めています。2014年度から2016年度には「ソフトウェアエコシステムの理論構築と実践を加速する分野横断国際ネットワークの構築」に取り組みました。
エコシステムがもう社会全体を含む流れになっていると研究では位置づけています。
日本学術振興会 頭脳循環を加速する戦略的国際研究ネットワーク推進プログラム
ソフトウェアエコシステムの理論構築と実践を加速する分野横断国際ネットワークの構築 (2014~2016年度)
――そういった枠組みを見ていく上でのポイントはありますか?
エコシステムを大袈裟にいうと「ソフトウェア資産」です。これまでは個人的に所有していたり、どこかに消えてしまっていたりしたものを、皆で共有することで、それぞれの知恵で新たなモノを作り出します。こうした創造的な活動を自由な発想で行うのは凄いことですし、素晴らしいことだと思います。
しかし、たくさんのモノが共有されてもその間の関係性などが分からないままでは、本当に使っていいのか分からないという問題があります。例えば最近では、ソースコードと「GitHub」や「スタックオーバーフロー」といったサイト上での議論や学術論文などが繋がってソフトが作られるようになってきています。
こうした流れでソースコードの中に増えているのが、開発者が学術論文などを読んで、その内容に基づいて一部のアルゴリズムがコーディングされているケースです。コメントが書いてあればいいのですが、必ずしも書かれているわけではないので、ある部分の実装が何故そうなったかが分かりません。もしかしたら、学術論文などから引用されていたりするかもしれないのです。
こうなるとややこしいのは、もっと良いアルゴリズムや改良版が出ても、そのソースコードに反映されないことです。間違っているわけではなくても、いつまでも古い実装でのまま動かすことになるかもしれません。「GitHub」やQ&Aサイトなどでの議論や学術論文などが繋がって、新しいソフトウェアが作られるのはとても良いことですが、その後がフォローできてない可能性も存在することになります。
開発中も開発後もそうですが、「どういうふうに作られていったか」とか「リリースされた後どんなふうに使われているか」とか「どういうふうにアップデートされていったとか」といった出自・由来が分かるようにしてソフトウェアを評価しないと安心して使えないのではないかという視点が大切だと考えています。
――ソフトウェアに誰かが信頼性を与えないと良いモノが使われるようにはならないのですね。
そうですね。その意味で第三者検証は大事だと思います。不具合に関する情報は広く開示できないので、第三者検証が入りユーザーの代わりに開発データを詳細に見て品質を保証することが必要です。結果を公表することでこれまで以上の信頼関係が生まれると思っています。
――ご研究されていることが今後、ソフトウェア開発にどのような影響を与えうるのでしょうか?
バグをなくすのは多分無理ですが、少なくすることはできると思っています。バグが全くないことは証明できませんし、リリース時点ではバグでなくても、周りの環境や使われ方が変わることで変更や修正の必要が出てくることもあります。もちろんソフトウェア工学にはバグがないコードであることを証明する検証系の研究がありますが、まだまだ、分野が限られたり、条件があったりすると思っています。
ですから「どう作られたか」とか「広く使われているか」といった視点で不具合の影響度を評価して重大なところから優先的に取り除く、あるいはテストするなど、メリハリをつけてやっていくしかありません。この根拠を示せるようにしていきたいですね。
また最近のキーワードでいうと「技術的負債」への対応です。DX(デジタルトランスフォーメーション)の文脈で語られる技術的負債は抽象的な話ですが、私たちの研究では「バグとはいえないけども、改良の余地がある部分」あるいは「将来的にバグになるかもしれない部分」をいいます。これを少しでも減らし、悪影響を小さくできる可能性があると思っています。
ソフトウェア開発の生産性や品質を上げるため、産学連携を推進したい
――今後のご研究を通じて、将来にどのようなインパクトを与えたいとお考えでしょうか?
エコシステムの中で、ソフトウェア開発の生産性や品質を上げるために、今後の研究テーマというより、アプローチになりますが、大学と企業との間での産学の情報共有が進むような枠組み・仕組みを作りたいと考えています。
これまでも企業との共同研究や、数は少ないですが、ベンダーとユーザー企業、大学の三者による共同研究の事例があります。なかなか難しい面があることは分かっていますが、企業と大学が発展するためにも実現したいですね。
大学側は多種多様な研究をしているため、情報や知識があるかもしれませんが、企業の技術者は、やはり現場のことをよく知っており実践的なノウハウを持っています。ここを合わせないと面白い研究にならないと思っています。
大学の人の解釈と違って企業人はもっと現実に即した解釈ができるので、有用な知見が得られる可能性があります。現場の人が見たらとても役に立つ情報があるかもしれません。その意味で共同研究を進めていき、お互いの持っている知識や経験を合わせて、より良い技術を創っていきたいですね。
――本日はいろいろお話をしてくださり、ありがとうございました。