大学および学外での活動の中から、講義、業務、研究などに関連した話題を中心に発信します。

20. ソフトウェア・シンポジウム2020 オンライン開催決定!

新型コロナウィルスの感染拡大を受け、2/7(金)に開催したSEAフォーラムを最後に、ソフトウェア技術者協会(SEA)関連のイベントやソフトウェア・シンポジウム2020(SS2020)の実行委員会、SEA幹事会は、Face to face での会議を中止し、すべてオンライン会議に移行しました。

2月~3月は、ソフトウェア・シンポジウムに投稿された論文の査読やシンポジウムの企画検討などがあり、今年の実行委員長である野村さん(岩手県立産業技術短期大学校)、プログラム委員長である日下部先生(長崎県立大学)、河野さん(ディー・エヌ・エー)、事務局の栗田さん(ソニー)、インフラ担当の中野先生(中野秀男研究所)、ひろのぶさん(usp lab.)、基調講演担当の本多さん(東京エレクトロン)達と定期的にSS実行委員会を開催しました。最初は、5月連休明けに現地で開催するかどうかの最終的な判断をしようと思っていましたが、3月に入ってからの感染者数の増加状況から、現地での開催中止を決め、オンライン開催とすることにしました。毎年楽しみにしていたイベントが開催できないのは、本当に寂しいです。

投稿された論文の査読も終わり、プログラムの企画とオンライン開催の計画を準備して、4/10(金)の午後、プログラム委員会を開催しました。これもZoomで開催しました。当日は、30名以上のプログラム委員の方々が参加してくれました。いつもと同じように査読結果の審査をしっかりと行えたと思います。その後、プログラムを検討し、オンライン開催の計画を伝えました。

ソフトウェア・シンポジウムは今年で40回目の開催という記念の年でした。過去の歴史は、SEA ソフトウェア・シンポジウムの歴史を参照してください。今まで、日本各地を巡ってきましたが、今年は初めてのオンライン開催となります。盛岡で開催できないのは残念なのですが、気持ちを前向きに切り替えて、初めてのオンライン開催を多くの方々に楽しんでもらえるように、これから準備作業を開始します!

今年のソフトウェア・シンポジウム2020は、6/17(水)~19(金)にオンライン開催します。5月連休明けにはプログラムを公開し、参加者募集を開始する予定です。今まで、開催時期や開催場所の関係で参加できなかった方々にもぜひ参加してもらいたいと思っています。中身の濃い発表と議論を楽しめます! みさなまの参加をお待ちしております。

戻る

19. 小笠原研最初の卒業生

2月7日(金)に、小笠原研究室1期生の卒業研究発表会がありました。2018年4月に着任して、その2日後に、3年生のオリエンテーションがあり、そこで研究室配属の希望を集めました。そのオリエンテーションの時に初めて研究室紹介をしましたが、当然のことながら私の研究室を志望する学生はほとんどいませんでした。第一希望が通らず、私の研究室に配属となった学生もいましたが、最終的には私の研究室に9名の学生が配属となりました。

それからはあっという間の2年間でした。

3年生の前期には3人でプロジェクトチームを作り、約4ヶ月をかけてWebサイトを開発するというプロジェクトマネジメント演習を行いました。このプロジェクトマネジメント演習で目指すことは次のとおりです。 工業大学の学生なので、PCを使いこなし、プログラミングもある程度出来るのかなと想像していましたが、そんな事はなく(^^;)、いろいろと大変でした。しかし、そのおかげで、PHP+データベース(MySQL)を使ったWebサイトの開発方法をある程度習得できました(^^)

3年の後期は課題研究を行いました。9月に研究テーマを決め、10~11月と研究を進め、12月にポスター発表を行うというスケジュールでした。ゼミの中でうまく進めていきたいと思っていたのですが、どうもうまくいきませんでした。学生達の興味をうまく引き出すことは難しいということを感じました。

9名全員が4年生に進級できましたが、結構ヒヤヒヤものでした。春休みに週一回の勉強会も企画しましたが、これもあまりうまくいきませんでした… 4年の4~6月頃は就職活動が中心となりました。ゼミの日に説明会や面接が入るということもあり、ゼミをどのように行えばよいのか、いろいろと考えさせられました。

そうこうしているうちに、あっという間に夏が過ぎ、4年生の後期が始まりました。残るは卒業研究です! 10月に中間審査を行い、2月に最終発表会です。これまでうまくいかない事が続いてましたが、卒業研究もあまりうまく進められなかったという気持ちが強いです。でも、最後はみんな頑張って、60ページ以上の卒業論文を書き、しっかりと発表してくれました。小笠原研究室1期生9名の研究テーマは、次のとおりです。 この2年間、うまく進められないことも多くありましたが、無事卒業できて良かったです。新型コロナウィルスの感染拡大の影響で卒業式と謝恩会が開催できなかったのは、残念でした。

みんな卒業研究は大いに苦しみましたが、とにかく元気で面白い4年生でした。特に、LINEのやり取りは面白く、4年生のグループLINEでよく笑わせてもらいました。また、研究室に入る前に、私の部屋に寄って話をしてから、研究室に入っていく学生も多くて嬉しかったです。これから、とにかく頑張って欲しいと思います。これからの彼らの人生が素晴らしいものでありますように!

Heaven helps those who help themselves!
戻る

18. IoT時代のアプリ開発を考える

ソフトウェア技術者協会(SEA)主催のSEAフォーラムを開催しました。今回は、組込みソフトウェアの世界で長年に渡り活躍中の二上さんに講演をしていただきました。二上さんは現在、(株)東陽テクニカ R&Dフェローであり、信州大学 工学部客員教授でもあります。東陽テクニカ 軽井沢ラボの活動状況は、次のサイトから参照して下さい。 講演のタイトルと概要は次のとおりです。 2000年頃から日本国内で利用する計測器が売れなくなってきて、日本で売って、海外に出荷するというパターンが増えてきた、という話から始まりました。そうなると、海外に拠点を出すとか、海外のユーザにどのようにトレーニングするか、ということを考える必要があり、東陽テクニカでも海外での活動が増えてきたそうです。また、今まではスペック重視で製品開発をしていればよかったのが、海外でのニーズを元に検討しなければいけなくなったことで、次製品の検討が難しくなってきた、とのことでした。

2018年平昌オリンピック500mで金メダルを取った
小平奈緒選手との関係も深く、小平選手の活躍の一端を担って いるということでした。詳しくは、こちらこちらを参照してください。

今回のメインテーマは、グローバルなニーズを狙ったものづくりの話でした。IoT技術とIT環境の発展によって、これまでとは違うものづくりの機会が生まれていることを、ヘルスケアの事例をベースに説明をしていただきました。ご存知のとおり、現在は長寿命社会であり、その中でも日本は世界の中でも最も早いペースで高齢化社会を迎えています。高齢者が病気をすると、典型的には以下のようなパターンになると言われています。 このステップを防ぐには、医療(薬)に頼って元気を取り戻すということではなく、病気にならない努力の方が効果的と言われています。しかし、このような状態になってしまうのを防ぐためのシステムを開発しようとすると、一筋縄ではいかず、複雑なシステムが必要となってくるということが想像できます。このようなシステムは、センサーや装置を開発している会社だけで考えられるようなものではなく、広い視野でシステム化を検討しないと実現できないものです。広い視野の例は、次の図を参考にしてください。

IoT_System

上述した図が実現した際のマーケットは「明らかに巨大で複雑」です。このよ うな状況の中、日本は世界の先端テストベットを保持している立場です。この 課題(広い視野でシステム化をするには)に対して、今は、世界中の方々と一 緒に考えながら開発するスタイル( 伽藍とバザール)で立ち向かっていました。具体的には、IIC(Industrial Internet Consortium)Healthcare Task Groupに参画し、そこでいろいろと議論をしているとのことでした。この Task Group の目的は、上述したような高齢者が陥りやすいパターンを防ぐためのインフラを構築する、ということです。現在、日本国内でのチーム作りも進行しているそうです。二上さんは、2014年から、IIC(Industrial Internet Consortium)の日本リエゾンを担当しています。

最後に、このIICでのWGの活動状況や実際にどのように議論がなされいているか、という説明がありました。定期的なWeb会議を開催して、議論を深めながら、具体的な活動に落とし込んでいくという方法は、日本人にとっては苦手な領域かもしれません。しかし、IoTシステムを開発するには、IICで行われているこのような世界に入っいき、グローバルなニーズを狙ったものづくりが実現できるかどうかが今後のポイントである、というコメントで講演が終わりました。

講演後の質疑応答では、「インフラ」とは何か、というところで議論が盛り上がりました。見方を変えれば、“人々”を監視するためのインフラだよね、というコメントもありました。情報化社会には常につきまとう話題ですが、得られた情報をどのように使うのか、どのように生かすのか、という事とセットで常に議論を進める必要があるということを再認識しました。

講演後は、いつものとおり、懇親会を開催しました。楽しかったです。参加者は、中野先生ひろのぶさん新森さん奈良さん、二上さん、私の6名でした。中野先生から「みんなでワイワイやっているところがいい。このプロジェクト(IICのHealth Task Group)、うまくいくんちゃう。日本にインターネットを導入しようとしていた頃の雰囲気と似ている」という言葉が印象的でした。
戻る

17. 継続することの大切さ! SS2020のロケハンに行ってきました

今年、ソフトウェアシンポジウム(SS2020)は盛岡で開催します(私の地元岩手県での開催です!)。会場は、いわて県民情報交流センター(アイーナ)です。今回、現地視察(ロケハン)をしてきました。実行委員長の野村さん、奈良さん、栗田さん、三輪さん、岩手県立大学の市川先生、それと私の6名の参加者でした。

会場のアイーナは、とてもきれいで解放感があり、素晴らしい会場でした。基調講演を行う小田島組☆ほ~るホールも広く、設備も充実していて、これもまた素晴らしいホールでした。6月の開催が楽しみになってきました。また、懇親会の会場であるマリオス(アイーナの隣のビル)の展望室(20F)から見る景色は最高でした。懇親会は、展望室にあるレストランで開催です。

お昼には焼肉と冷麺を食べ、ロケハンのあとはじゃじゃ麺を食べました。どちらも美味しかったです。夜は、姪がアルバイトをしている盛岡酒場にっかつとその隣にあるアイリッシュ・パブ SUNDANCEに行き楽しい時間を過ごしました。

翌日は、野村さんに高松公園岩山公園盛岡八幡宮を案内してもらいました。盛岡には何回も来ているのですが、どこも初めての場所でした。高松公演では鴨と白鳥を見てきました。白鳥の足は黒いのですね。鴨にも種類があって(当たり前ですが)、それぞれに特徴がありかわいかったです。岩山公園から見る岩手山は最高でした! 岩山公園の山頂にある「喫茶GEN・KI」は、朝、日の出の1時間前から8時まで営業をしています。日の出とともに眺める岩手山は最高だそうです。今年のSSの期間中、ぜひ行ってみたいと思いました。夜景も素晴らしいとのことですので、夜景も楽しんでもらいたいと思います(私は、飲み会があるので、夜景ではなく、朝にします…)。

SSのロケハンには、2014年から毎年参加していて、私のロケハン地は、秋田市、和歌山市、米子、宮崎市、札幌、熊本市と続いています。ソフトウェア・シンポジウムは、1980年の1回目の開催後、ほぼ毎年継続して実施され、今回が40回目の開催です。詳細は、SEA ソフトウェ アシンポジウムの歴史を参照してください。毎年、SSが終わったあとの7~8月から次の開催に向けて動き出し、年末か年始にロケハンをするというのが、毎年のパターンです。ロケハンは“さあ、そろそろ積極的に動き始めるぞ”という合図にもなっています。周りから見ると現地視察をしているだけ、と見えるかもしれませんが、参加者にとっては、その地域を楽しみつつ、6月の本番に向けていろいろと考えるよい機会になっています。また、みんなで集まって参加することに意義があると思います。SEAに携わってきた多くの方々によって続けられているソフトウェア・シンポジウムを今後も継続していけるように、これからもロケハンを大切にしていきたいと思いました。楽しい2日間でした!

20200125(1) 20200125(2) 20200125(3)
戻る

16. FORCE2019 (12/14-15) を開催しました

三重県伊勢市の伊勢観光文化会館でソフトウェア信頼性研究会 第15回ワークショップを開催しました。

週末の休みの日にも関わらず、19名の方に参加していただき、充実した2日間を過ごせました。昨年に引き続き今回も、大学関係者6名、学生6名、企業からの参加者7名という構成で、とてもバランスが良く、活発な議論ができました。

住友電工情報システムの中村さんと野尻から「住友電工情報システムにおける統計的品質管理とその実践」というタイトルで基調講演をしていただきました。中村さん達が推進している活動は、プロジェクトマネジメント学会から2018年度PM実施賞奨励賞を受賞しています。また、SPI Japan をはじめ、いろいろなところで発表もされています。たくさんある中のいくつかを以下に紹介します。

文書作成支援ツールによる組織開発力の強化
信頼度成長曲線の導入による統合テストの改善

今回の基調講演は2部構成で、最初は、「自社開発ツールによる統計的品質管理の全社展開」というタイトルで中村さんの発表がありました。次に、「プロ ジェクトマネージャー支援サービスの構築」というタイトルで野尻さんからの発表がありました。どちらの発表とも、実践に裏打ちされた中身の濃い内容でした。中村さんの発表では、管理図を使った品質作り込みの事例の紹介もありました。ソフトウェア開発の現場で、これだけしっかりと管理図が使われている事例は少ないと思います。とても参考になりました。

発表は10件でした。すべての発表で活発が議論がありました。私にとってすべて興味深いものでした。学生の方々にも発表していただき、感謝です。学生の方々の発表は以下のとおりです。

・「時間ペトリネットを対象とした有界モデル検査の高速化とその評価」
 井川直,横川智教,有本和民(岡山県立大学)
・「関数単位のソースコードを入力としたドキュメント自動生成モデルの提案」
 塩津拓真,水野修(京都工繊大)
・「変数に着目した変更メトリクスによるフォールト混入予測とその評価」
 川上 卓也,阿萬 裕久,川原 稔(愛媛大)
・「プログラミング試験におけるカンニング検出に向けて」
 砂田翼,石尾隆,松本健一 (奈良先端大)
・「バグ票の類似度を活用したフォールト位置推定手法の改善に関する考察」
 安里 昌真,阿萬 裕久,川原 稔(愛媛大)
・「構成管理ツールにおける冪等性を持たないモジュールの利用形態解析」
 国領翔真,水野修(京都工繊大)

1年先の話ですが、来年もこの時期に開催する予定です。場所は未定ですが、岡山が候補として挙がっています。興味のある方はぜひお越し下さい。来年は、私も発表したいと思ってます(研究ちゃんとします)!
戻る

15. SPI通信にエッセイを書きました

ソフトウェアプロセス改善シンポジム2019(SPI Japan 2019)で、JASPICから20周年記念 新聞「SPI通信」が発行されました。発行の趣旨は以下のJASPICメルマガの文章を参照してください。
───────────────────────────────
 ◆4. SPI通信の紹介
───────────────────────────────
JASPICは2020年に20周年を迎えます。これを記念し、JASPICをさらに
知っていただくために、20周年記念新聞「SPI通信」を発行します。
デジタル時代の今だからこそ、紙の新聞の手渡しと、気軽な会話から
生まれるコミュニケーションも大切にしたいと考えています。
今回、第1号が完成しました。既にSPI Japanなどで配布していますが、
広く読んでいただくために、「SPI通信」を職場などで配っていただけ
る方には送付いたします。(送料はJASPICで負担します。)
住所/氏名/部数(10部以上でお願いします)を次のアドレスにメール
してください。

newspaperアットjaspic.org

なお、現在第2号も企画中です。既にお読みの方はこちらもお楽しみに。
以下は、SPI通信に寄稿したエッセイです。紙面では写真も載ってますが、恥ずかしいので、ここには載せません(^^;)

■タイトル:“リズムの大切さとSEPGへのメッセージ”

JASPICは、2000年10月に設立されました。設立趣意書、松原友夫氏と坂本啓司氏(故人)からの設立に向けたメッセージは、次のURLから参照できます。2つのメッセージは、プロセス改善活動に関与する方々にぜひ読んでもらいたい内容です。

http://www.jaspic.org/basicDocuments/SPIshui.pdf

JASPICが立ち上がってから、例会、合宿、ソフトウェアプロセス改善シンポジウム(SPI Japan)が定例的な活動として私の中に入ってきました。これらの活動は、毎年ほぼ同じ時期に開催されるので、数年続けるとそのリズムが体にしみ込んできました。私の場合だと、このほかに、5月の派生開発カンファレンス、6月のソフトウェア・シンポジウム、夏の帰省、9月のソフトウェア品質シンポジウム、冬のソフトウェアテストシンポジウムが入ってきました。人間の体は不思議なもので、毎年続けているリズムが崩れると、その1年が何となく物足りないものに感じてしまいます。2008年の神戸で開催されたSPI Japanの時は、何故だか、私らしくもなく上長の反応を気にしてしまい、参加しませんでした。今となっては、とも悔やまれます。2003年から始まった SPI Japanに、この年だけ参加していないのです。みなさまには、会社生活の中で、“自分のリズムを確立し、そのリズムを最優先する”ということ強く推奨します。自分一人がいなくても、会社は回ります。もっと自分のことを大切にしてもよいと思います。

JASPICの活動の初期のフェーズでは、2006年5月に「熱海後楽園ホテル」で開催した合宿が思い出に残っています。合宿では、2日間集中して発表や議論をするのですが、夜は、懇親会のあと大きな部屋にみんなで集まり、朝方までお酒を飲みながら熱く議論しています。夜の議論が終わり私の寝る部屋に戻ると鍵がかかっていて入ることができませんでした。仕方ないので、エレベーター前のソファで寝入ってしまいました。そのうち、床に転がって寝ていたようです。この写真は、朝風呂に行く方々に撮られた写真です。

酔っ払いの恥ずかしい写真なのですが、このような写真が残っているということは貴重なことで、今は撮って下さった方に感謝しています。ここで目を覚ましたあと、お風呂場に向かいました。そこには、露天風呂があり、そこでまた寝入ってしまったようです。体が寒くなると、手でお湯をかけていたそうです。当然、JASPICの方々にも見られていたのですが、みなさん、起こすこともしないで、眺めていたそうです。今でも仲良くしていますが、とても優しい方々です(起こしてよ!)。このような事件のあった合宿ですが、毎年一回みんなで夜遅くまで深い議論をすることが楽しくて、その後も継続して参加しました。

2006年5月の合宿では、JASPIC初代理事長である岸田さんの講演がありました。講演タイトルは、「SEPGへの8つのメッセージ」でした。この時の内容は、その後のプロセス改善活動を推進する時の心構えのベースになりました。すべてのメッセージをここで紹介はできないので、いくつかのメッセージを紹介して、このエッセイを終わりにします。

■1番目のメッセージ:
われわれの状況は、大海の真中で自分が乗った船を修理しながら航海を続けなければいけない水夫みたいなものである。港に戻って、新しい船を最初から作り直せたらよいのだが、それはできない。(オットー・ノイラート)
ソフトウェアは?
20世紀前半の哲学の状況について述べたノイラート(ウィーン学派の代表的論客)のコトバは、ほぼそのまま、われわれソフトウェア・エンジニアにあてはまる。

■2番目のメッセージ:
言語は、たえまなく変化しつづける。変化しなければ機能しえない。(エウジェニオ・コセリウ)
ソフトウェアの宿命
ソフトウェアも、やはりたえまなく変化し続ける。ソフトウェアは、変化しない限り、その機能を果たすことができない。それは、社会プロセスの中に組み込まれたツールとしての宿命である。

■8番目のメッセージ:
ネットアートの世界では、コンピュータと通信技術の複合がオープンな制作の場を実現し、観客たちは、その上で行われる創作活動に自由に参加することができるようになった。アーティストは、伝統芸術における著作者ではなく、むしろシステムデザイナーのような役割をになう。さまざまなユーザたちが出会い、お互いの関係を発展させる場ができたことで、そうしたインタラクション・プロセスそのものが、創造活動のほんとうの「対象」と化すのである。したがって、そうしたプロセスを支えるシステムの機能が、きわめて重要になる。(エリザ・ジャカルディ)
プロセスとプロダクト
われわれの仕事は、プロダクトとしてのソフトウェアを作ることである。しかし、そのソフトウェアを使うのはわれわれ自身ではなく、ユーザである。われわれソフトウェア・エンジニアにとっての仕事のほんとうの目的は、ユーザの要求に応えてさまざまなプロダクトを作るためのプロセスをどうしたらよいのかを考えることなのだ。
戻る

14. EuroSPI2019 (9/18-20) に行ってきました

5年ぶりに、EuroAsiaSPI2019に参加してきました。今年の開催場所は、スコットランドのエジンバラでした。飛行機の予約が遅くなり、少し時間がかかるルートになってしまいました。今回は、成田空港からドーハ空港経由でエジンバラ空港に到着しました。所要時間はそれぞれ7時間半、11時間半ですので、ドーハでの待ち時間も含めると、行きは約23時間、帰りは約19時間でした。結構疲れましたが、ドーハとエジンバラ間は結構空いていたので、思ったより楽でした。映画も沢山観ました。

今回投稿して採択された論文のタイトルは、"Historical Significance and Suggestions on Future Works of Software Process Improvement in Japan"です。内容は、SQIPシンポジウム2017【SQiP特別セッション】で発表した<<第3部>>プロセス改善の黒歴史 ~何を学び、どこへ向かうべきか?で発表したものをベースにしたものです。著者は、安達さん(HBA)、古畑さん(デンソー)、艸薙さん、伊藤さん(東芝)、小笠原(千葉工業大学)の5名です。日本では、SW-CMMの翻訳版が公開された1990年代の後半から、各社でのプロセス改善活動が広がりました。その後、盛り上がったり、停滞したりということを繰返しながら、現在に至っていると思います。毎年秋に開催されるソフトウェアプロセス改善シンポジウム(SPI Japan)では、毎年30件程度の発表があり、参加者も150~200名と安定しています。

この日本におけるプロセス改善活動の歴史を振り返ってみると、形式を整える(例えば、CMMIに準拠したプロセスの実装に偏りすぎている)、個人の経験や技術を元に効果を高めるという活動を行ったり来たりしていたという結論に達しました。具体的には、以下のプロセスモデル適合性-有効性評価座標で示した、形式的と属人的を行ったり来たりしている)。今回の発表では、形式も整え(モデルにも準拠し)、効果も継続的に得られるという理想の状態に到達するにはどうしたらよいか、という議論の結果を示しました。議論の結果はまだ提案レベルなので、その提案が本当に妥当なのかという検証まではできていません。

プロセス適合性-有効性座標

発表後の質疑応答は活発で、このような状況や理想状態に向けた方向性を議論することに対して懐疑的な反応はありませんでした。来年のEuroSPIでは、理想状態に向けた提案をより明確なものにして、その提案内容の妥当性も示せる ようにしたいと思います。

今年は日本からの参加者も多く、総勢で6名(奈良さん、笹部さん、伊藤さん、込山さん、古畑さん、小笠原)でした。エジンバラは観光名所なので見どころ満載でした。写真は、発表中のもの、街から撮ったエジンバラ城、観光後のお店の中の3枚です。楽しかったです。

picture(1) picture(2) picture(3)

来年は、2020年9月9日(水)~11(金)の日程で、場所はドイツのデュッセルドルフです。来年も論文を投稿して、ぜひ参加したいと思います。参加者は、基本的に経験豊富な方が多いのですが、若手の研究者の方々もいて、発表や議論の内容は参考になることが多いです(聞き取れないことも多いのですが…)。一緒に行ってみたいという方は大歓迎なので、ぜひ声をかけてください。
戻る

13. PM学会 秋季研究発表大会 (8/29-30) に参加してきました

プロジェクトマネジメント学会主催の2019年度秋季研究発表大会に参加してきました。春季研究発表大会、秋季研究発表大会、ProMACへ参加するというリズムが出来上がってきたような気がします。今回は、2つのセッションの司会と学生発表の評価という役割がありました。嬉しいことに、私の研究室から3名が発表しました。小笠原研究室からの初めて学会発表になりました!

私が担当したセッションの発表は次のとおりです。

担当したセッションでの発表(1)
担当したセッションでの発表(2)
どの発表も分かりやすく興味深い内容でした。法政大学の山戸先生、福田さんの発表は、中小企業のIT経営をより良くするための提案で、私としては、このような側面からの研究が進んでいるということが分かり、とても参考になりました。勝部さんの発表は、何というか、とにかく面白かったです。映画「七人の侍」を対象に、プロジェクト振り返りシートを書いてみたという内容です! 実際のプロジェクトで振り返りをするのが一番よいのですが、うまくできない状況もあるという現実もあり、それならば、業務以外での活動でプロジェクトの知識を深く学習するためにはどうしたらよいか、ということが問題意識でした。確かに、業務以外の事例で書いてみると、プロジェクト管理に関する知識体系がうまく頭に入ってくるような気がします。次の表は、勝部さんの論文に載っていた「プロジェクト振り返りシート」です(クリックすると大きく表示されます)。

プロジェクト振り返りシート

最後に、私の研究室からも次の3つの発表をしました。私は座長だったので、発表は聞けなかったのですが、みんな頑張ってくれました! 次回以降、投稿論文の質をより高くして、今回以上に自信を持って発表してもらえるようにしたいと思います。

小笠原研究室からの発表
“最後が”が2度繰り返してしまって申し訳ないのですが、千葉工業大学から発表した学生3名が、学生研究発表賞の学生優秀賞(小関さん、伊藤さん)と奨励賞(石川さん)を受賞しました。おめでとうございます!
いくつかの写真をアップしておきます! お肉の写真は、塩ジンギスカンが抜群に美味しい塩成吉思汗『八仙』大通のものです。

picture(1) picture(2) picture(3) picture(4) picture(5)
戻る

12. TCSE2018 JAPAN Track (7/29-31) を終えて

TCSE2019 JAPAN TRACKを千葉工業大学で開催しました。TCSE とは、Taiwan Conference of Software Engineering, Taiwan の略です。2019年の今年、15周年を記念して、日本の2つの団体(日本SPIコンソーシアム(JASPIC)とソフトウェア技術者協会(SEA))とのジョイント・カンファレンスという形態で開催しました。

私がJASPICの運営委員長をしていた4年前、台湾のTSPIC (Taiwan Software Process Improvement Consortium) の方が、SPI Japan に参加してくださったのが出発点でした。

次の年から、毎年5月頃に開催されるTSPICの年次大会に参加するようになりました。この年次大会には、TCSE (Software Engineering Association Taiwan)に所属する大学の先生方も多く参加しています。昨年のTSPIC年次大会の時に、TCSE2019 を日本で開催したいという要望があり、そこからいくつかの議論や打合せを重ねて、開催まで辿り着きました。

JAPAN TRACK は、7/29(月)午後の「テスト自動化ワークショップ」から始まりました。ワークショップでは、2つのツールを実際に動かしてみました。SideeXMagic Podの2つのツールです。ShideX は、記録した操作を完全に再現できることが特徴です。このため、今までは、テストの記録とは別に、合格条件などをせっていする必要がありましたが、記録をしたものがテストとして正しいのであれば、合格条件などを設定する必要はありません。もちろん、テストスクリプトなどを組込み、テストを拡張することもできます。Magic Pod は、画面のUIなどから、処理内容などを推測し、テストケースの生成をサポートできるところ特徴です。今後、テスト自動化に関する研究やコンサルティングを進める時のツールとして活用したいと思います。

7/30(火)の2日目は、本会議の日で、キーノートを2つ、3トラックでの発表セッション、バンケットという構成にしました。

オープニング後のキーノートは、Professor Alan Liu, Dept. EE, National Chung Cheng University, Taiwan のBuilding Intelligent Systems: a Case with Case-Based Reasoningでした。いろいろな事例を交えた分かりやすく、かつ、これからのAIについて考えることができる発表でした。

クロージング前のキーノートは玉井先生にお願いしました。玉井先生の発表は、On Software Paradigmというタイトルでした。今年の春に出版されたHandbook of Software Engineeringで玉井先生が担当した部分Key Software Engineering Paradigms and Modeling Methodsの内容をベースにしたものでした。パラダイムとは何か、ソフトウェア工学の世界でどのようなパラダイムが起きてきたのかをよく分かりました。そして、これからどこに向かっていくのかということを考えることができました。分かりやすく、示唆に富む内容でした。

台湾からの発表は、ポスター発表も含めて68件でした。日本からは、永田さん(サイボウズ)、林好一さん、河野さん(DeNA)の3名を招待し、逐次通訳付きで約1時間の講演をしていただきました。それぞれ、“Agile開発と品質”、“プロダクトライン”、“テスト設計”という得意領域の話題を提供していただきました。質問&議論も活発で、とても楽しい時間でした。

バンケットは大学から歩いて10分程度の場所にある、イタリア料理 マッセリアで開催しました。日本のイタリアンでおもてなしをしました。たくさんの方々に参加していただき、楽しいひとときを過ごしました。

7/31(水)の最終日は、11時頃まで発表セッションを行い、昼食のあと、片付けをして、企業訪問に向かいました。JASPIC運営委員長の遠藤さんと私で約25名を引き連れての移動は大変でした! 最初にインテックに行き、そのあと、DeNAに向かいました。インテックからは、「Promoting Data Utilization for Business」というタイトルで、AIを活用 したデータ分析技術とサービスに関する発表でした。池田さん、新森さん、北橋さんに歓待していただきました。インテック訪問後は、渋谷のヒカリエにあるDeNAに訪問させていただき、テストおよびDeNAが提供するさまざまなサービスについて紹介をしてもらいました。今回の企業訪問では、台湾の学生も多かったのですが、「AIが専門なのですが、インテックで求人はありますか?」、「DeNAで働きたいのですが、台湾からでも入社できますか?」といった質問もありました。台湾の学生によってもよい経験になったと思います。前日に引き続き、河野さんには大変お世話になりました。

参加者数は少なかったのですが、3日間のイベントを運営するというのは、かなりヘビーでした。今年の春から私の研究室に博士課程として所属している今野さんには、とてもたくさん助けてもらいました(^^)

もうやりたくないかと聞かれるとそんな事はなく、機会があれば、TCSEに限らず、違うイベントも開催したいと思います。大変さより、得るものの方が圧倒的に多いということを実感しました。あ~~~~~、でも、疲れました…
戻る

11. システムテスト自動化ワークショップを開催しました

高品質ソフトウェア技術交流会(QuaSTom)「システムテスト自動化ワークショップ」を開催してきました。

QuaSTomは、東芝に入社後3~4年目からお世話になっている団体です。以前、副会長も担当させていただき、今は相談役として関与させてもらっています。今年の4月に、現会長の樋口さんから、QuaSTomの例会でワークショップを担当して欲しいというお願いがあり、事前の打合せをしました。その時に、樋口さんは、私の最近の活動状況などを調べてくれていて、“プロセス改善”というテーマでもいいのだけど、いつもと違う感じのものをやりませんかという提案から、“システムテスト自動化ワークショップ”というテーマに決まりました。自分が決めていたら、このテーマにはならなかったと思います。システムテスト自動化の内容を振り返り、新しい内容を加えることができ、とても良い機会でした。樋口さんに感謝です。

当日は、過去お世話になった方々にも参加していただきました。全体で20名程度の参加者がいました。テストの世界における“重鎮”の吉澤さんや東芝にいた頃一緒に仕事をしたことがある安孫子さんもいて、少し緊張しましたが、やってみるとそんなことはまったくなく、逆にこちらかの問いかけにうまく応えてくれるので、とても助かりました。3時間弱という時間でしたが、参加者とのやり取りも多く、私にとっても実りの多いワークショップでした。

ワークショップは、次の構成で進めました。
  1. テスト自動化の現状
  2. グループ討議(1)…自動化の取り組み事例、課題
  3. テスト自動化の取り組み
  4. テスト自動化を体感してみよう!
  5. テストセンター構想
  6. テスト自動化の実践結果
  7. グループ討議(2)…施策とロードマップを考える
  8. テスト自動化の留意点
  9. まとめ
アンケートでは、「実践・実装例についてどうすべきか悩んでいたので参考になりそうです」、「当たり前のことですが、“何でも自動化できるものではない”ということが改めて分かりました。またテスト自動化の過去も理解できました」といったコメントもいただきました。今回の内容をさらにブラッシュアップして、今後、このような要望があった時に応えられるようにしておこうと思います。

さらにありがたいことに、樋口さんが、このワークショップの開催案内とレポートを書いてくださいました。うまくまとまっていると思います。ありがたいです。開催案内は、ここから参照してください。レポートは、こちらから参照してください。

ワークショップ後は、QuaSTom 恒例のライトニングトークスがあり、その後、懇親会へと突入しました。懇親会では、シーズメッシュの本間さんと久しぶりに会いました。いろいろな方とたくさん話ができて、楽しかったです!
戻る

10. プロセス改善の輪を広げる:TSPIC(台湾)との交流

5月25日(土)に、TSPIC(Taiwan Software Process Improvement Consortium)の年次大会に参加してきました。JASPICからTSPICの年次大会には、2016年から毎年参加しています。今年は、TSPICからの要望もあり、“派生開発手法XDDP”の説明をしてきました。XDDP(eXtreme Derivative Development Process)は、SPI Japan 2011 の基調講演、SPI Japan 2017 のパネル討論やチュートリアルなど、SPI Japan で何度も講演をしてくださった故清水吉男氏が開発した「派生開発の要求に合った開発プロセス」です。今では、この手法は日本国内では幅広く浸透し、多くの企業やプロジェクトで活用されています。その活用事例は、毎年初夏に開催される派生開発カンファレンスでも多数公開されています。

発表の時間は1時間で、逐次通訳をはさみながらの発表だったので、基本的な事をしっかり伝えるようにしました。最初に、追加と変更のプロセスを持つ派生開発向けプロセスXDDP、プロセス設計技術PFD、要求仕様化技術のUSDMを説明しました。次に、XDDPの変更プロセスでは、変更に着目した成果物として、変更要求仕様書、TM(トレーサビリティ・マトリックス)、変更設計書の3点セットが作られることを説明しました。最後に、XDDPの勘所として、要求仕様書の考え方やスペックアウトなどについて説明しました。発表後の質問も活発でしたので、参加者の方々にはある程度伝わったと思っています。

今回の年次大会には、約50名が参加していました。私の発表以外にも、「産学が連携してソフトウェア開発へAIを適用した事例」、「Pythonのオープンソース機械学習ライブラリであるscikit-learnの実践的活用方法」の2つの発表と、「パネル討論」がありました。パネル討論では、日本から参加したJASPIC理事長の赤坂さん、運営委員長の遠藤さん、小笠原の3名が参加して、AIの活用、アジャイル開発の動向など、いくつかのテーマで議論をしました。質疑応報も活発で、とても楽しい時間でした。

TSPICとの連携をきっかけに、今年は、7/29(月)-31(水)の3日間、日本の千葉工業大学で、TCSE2019(INTERNATIONAL JOINT CONFERENCE OF TCSE, JASPIC AND SEA)を開催することになりました。このカンファレンスでは、テスト自動化に関するワークショップ、台湾と日本からのキーノート、台湾からの論文発表、日本からの事例発表などがあります。興味のある方はぜひご参加ください。
戻る

9. 菅野文友先生をしのんで

私の大学時代の恩師である菅野文友先生が、2019年5月5日午前11時11分に亡くなりました(享年91)。

エイプリールフール(4月1日)に産まれ、子供の日(5月5日)に亡くなりました。さらに、亡くなった時間は、11時11分という、すべてビットを立てた時間でした。忘れようと思っても忘れられません(^^;) 最後まで先生らしいのですが、こんなところで先生らしさを出さなくてもいいのに、と涙が止まりません。

思い返せば、大学に入学して「ソフトウェア」という言葉を始めて知り、ソフトウェア工学、ソフトウェア品質管理に興味を持つようになりました。先生の授業は怖くて(よく怒鳴ってました)、難しかった(数式をよく書いていたのを覚えています)のですが、何故だか先生に惹かれ、4年生の時に菅野研究室に入りました。

私が一番最初に書いたプログラムは、レシートのようなプロッタが付いているSHARPのポケット電卓で、ゴンペルツ曲線を書くプログラムでした。最初に覚えたプログラム言語はBASICでした。確か、先生の講義の宿題で、ゴンベルツ曲線のパラメータを推定せよ、といった問題が出たと記憶しています。グラフが表示できるのが面白くて、かなり集中してプログラミングしてました。

4年生と修士の頃は、実践の場をよく提供してくれました。私は、大学病院の先生と一緒にデータ分析を行ったり、インターンシップ先でソフトウェアの開発をする、といった経験をさせてもらいました。他の同期のメンバにも、それぞれの性格や能力を見極めて、適切な場を提供してました。「ソフトウェア工学は実学である」という先生の言葉どおりの指導だと思います。

大学時代によく言われた言葉としては、次の3つが心の中に残っています。今後、これらの言葉を、自分の言葉として説明し、学生に繰返し繰返し伝えていきたいと思っています。 東芝を退職し、大学に移ると報告した時は、とても喜んでくれました。これからは、先生の姿を思い浮かべながら、先生から学んだことを学生にも伝えていきたいと思います。
菅野先生をしのぶ会で配布された資料
図書「ソフトウェア・エンジニアリング」と先生からいただいたサイン
先生、ありがとうございました。
戻る

8. 改善できないエンジニア

今、私の担当している講義は前期2つ、後期2つあります(演習、ゼミ、卒論などを除く)。担当の一覧は、プロフィールのページの「担当科目」から参照できます。前期は3年生が対象の「ソフトウェア開発管理」と「ユーザ要求とシステム設計」で、後期は2年生が対象の「品質マネジメント」と「オペレーションリサーチ入門」です。

すべての講義で、学生に興味を持ってもらえるようにいろいろと工夫をしているつもりですが、実際には、なかなかうまくいかないことが多いのも事実です。もっともっと勉強し、工夫しなければいけないのだと思ってます。講義については、またどこかで書くとして、今回は、「ソフトウェア開発管理」の中で実施した内容を少しだけ紹介します。

「ソフトウェア開発管理」では、実際の開発現場で問題になることや、工夫しいることなどを説明しています。講義は、簡単な説明をしたあと、演習問題を個人あるいはグループで解くというスタイルで進めます。演習問題は、自分で作るものもあれば、情報処理技術者試験から選ぶ場合もあります。

今回、「ソフトウェア開発管理」の中で、演習問題ではなく、レポートとして、“改善できないエンジニア”をベースにしてストーリーを作ってもらいました。“改善できないエンジニア”は、勝呂さん(というか、高橋寿一さん)の図書「知識ゼロから学ぶソフトウェアプロジェクト管理」に載っています。

■改善できないエンジニア
森の中で木を倒そうと、一生懸命のこぎりをひいているきこりに出会ったとしよう。
「何をしているんですか」とあなたは訊く。
すると「みれば判るだろう」と、無愛想な返事が返ってくる。「この木を倒そうとしているんだ」
「すごくつかれているようですが…
いつからやっているんですか」あなたは大声でたずねる。
「かれこれもう5時間だ。くたくたさ。大変な作業だよ」
「それじゃ、少し休んで、ついでにそのノコギリの刃を研いだらどうですか。そうすれば仕事がもっと速く片付くとおもいますけど」とあなたはアドバイスする。
「刃を研いでいる暇なんてないさ。切るだけで精一杯だ」と強く言い返す

かなり面白いのレポートが多く、笑いながら読んでました。ここでは、ソフトウェア開発に関連したストーリーをいくつか紹介します。3年生の前期は、PM演習の中で数名のプロジェクトを組み、開発の最初から最後まで実践しているので、実感のこもった内容が多かったと思います。ここに書かれたような状況にならないように頑張ってもらいたいぁ、と思いました。

■要求
あるソフトウェア開発で一生懸命ユーザの要求に振り回されている人に会ったとしよう。
「何をしているんですか」とあなたは訊く。
すると「みると判るだろ」と、無愛想な返事が返ってくる。
「ユーザからの要望があれば、そのたびにシステムを作り変えているんだ」
「すごく疲れているようですが… いつからやっているんですか」あなたは大声でたずねる。
「かれこれ5回目だ。くたくたさ。大変な作業だよ」
「それじゃ少し休んで、ついでにユーザの要望を一番最初に洗い出したらどうですか。そうすればプロジェクトの遅延が減るとおもいますけど」とあなたはアドバイスする。
「ユーザ要望を洗い出す暇なんてないさ。聞くだけで精一杯だ」と強く言い返す。
■バージョン管理
あるソフトウェア開発で頭を抱えてソースフィアルの一覧を見ている人に会ったとしよう。
「何をしているんですか」
「見れば判るだろう」「この適当な名前ばかりつけられたフィルから正式版がどこにあるかを探しているんだ」
「いつから正式版のファイルを探しているんですか」
「もう2時間だ。どいつもこいつもキーボードを適当に叩いたような名前ばかり付けやがって。手がかりはアップロードした日時だけだ」
「それじゃ、チームの間でフィアル命名の基準を作ってバージョンの名前を書いてもらったどうですか」
「どうせあいつらなんて『完成版』『完成版レビュー済み』『提出版』『最終版』なんてファイルを量産するだけだよ」
■専門家のアドバイス
「すごく長い文章ですね… いつからやっているんですか」あなたは大声でたずねる。
「かれこれ7時間だ。くたくたさ。大変な作業だよ」
「それじゃ、少し休んで、ついでに専門家を呼んでみたらどうですか。そうすれば仕事がもっと早く片付くとおもいますけど」とあなたはアドバイスする。
「呼んでる暇なんてないさ。打ち込むだけで精一杯だ」と強く言い返す。
■ソフトウェア構造の見直し/プログラムの勉強
あるソフトウェア開発で一生懸命ソースコードを書いている人にあったとしよう。
「何をしているんですか」とあなたは訊く。
すると「みれば判るだろう」と、無愛想な返事が返ってくる。「このバグばかりのソフトウェアを作っているんだ」
「それじゃ、少し休んで、ついでにソフトウェアの構成を見直したらどうですか。そうすれば、バグが発生しにくくなるとおもいますけど」とあなたはアドバイスする。
「構成を見直している暇なんてないさ。開発するだけで精一杯だ」と強く言い返す。

あるソフトウェア開発でソースコードを書いている人がいた。
「ソースコードの勉強もせずに書いて大丈夫なんですか?」とあなたは訊く。
するとその人は「ソースコードの勉強をしている暇がないんだ」と答えた。
■道具、ツール
あるプロジェクトメンバーが表計算で一つ一つ電卓を使って計算していた。
そこで私は、「なぜ、関数を使わないのですか」とたずねると、
「そんなの知らないし、調べる時間がもったいない」と強く言い返されてしまった。
■ツール、環境
あるソフトウェア開発の会議で一生懸命予定を合わせ、会議室をおさえたり、会議室のセットアップ、セットダウンを行っていた。
「何をしているんですか」と訊く。
すると無愛想に「ソフトウェアのシステムについて会議を行う準備をしているんだ」
「それでは、スカイプのビデオ会議などのツールを使って会議をしてみては。準備や後片付け、部屋をおさえるなどの仕事が減り、効率的に話し合えますが」とアドバイスをすると
「対面で集まることに意味がある」と言い返す。
■思い込み
あるソフトウェア開発で一生懸命ソースコードを書いている人に会ったとする。
「手伝いますよ」とあなたは言うが、
「私にしかできないことだ」と返事が返ってくる。
「教えていただければやりますよ」と言ってみたが
「教えている暇はない」と言い返された。

新規性のあるソフトウェア開発で1人で一生懸命考えている人がいる。
「何をしているんですか」と訊くと、「みれば判るだろう」と無愛想な返事が返ってくる。
「新規性のあるソフトウェアを考えているんだ」と答えた。
「皆で考えてみたらどうですか」とアドバイスすると「あいつら仕事しないから無理」と言い返された。
■ルール
あるソフトウェア開発のプロジェクトを行っているメンバー達が、全員で同じ書類を確認していた。
「何をしているんですか」とあなたは訊く。
すると「見れば判るだろう」と、無愛想な返事が返ってくる。
「全員で書類の確認をしてミスを無くしているんだ」
「それじゃ効率悪くないですか。人数を減らして他の人は別の仕事をした方が良いとおもいますよ」とあなたはアドバイスする。
「しかしこれはプロジェクトの最初に決めたことだから」
■デスマーチプロジェクト
あるプロジェクトで進捗が上手くいってない人にあったとしよう
「何をしているんですか」とあなたは訊く
すると「みれば判るだろう」と無愛想な返事が返ってくる。「思うようにプロジェクトが進んでいないんだよ」
「すごく疲れているようですが… いつからやっているんですか」とあなたは大声で訊ねる。
「かれこれもう1ヶ月前からだ。そうしたって取り戻せそうにないし、コストがかさんでいる」
「それじゃ、少し休んで、メンバも休ませて、士気を高めたらどうですか。そうすればもっと上手く進むとおもいますけど」とあなたはアドバイスする。
「自分もメンバも休んでいる暇なんてないさ。EVMを弾き直して、進捗管理するので精一杯だ」と強く言い返す。
戻る

7. ナレッジマネジメントについて考えてみる

活動のページでも紹介しましたが、3月中旬にプロジェクトマジメント学会の春期研究発表大会に参加してきました。初日は、司会や学生の方々が投稿してくださった論文の評価などがあり、やや緊張しながらの参加でしたが、2日目は特に役割はなかったため、楽しみながら発表を聴いてました。

その中で、IBMの若手のPM(技術者)の方の発表が印象に残ったので、何が印象に残ったのかを書き留めてみることにしました。タイトルと発表者は次のとおりです。 SECI モデルは、一橋大学の野中郁次郎名誉教授と竹内弘高名誉教授が著書「知識創造企業」(1996)の中で提唱したナレッジマネジメントにおけるフレームワークであり、暗黙知(個人が過去の経験から得た主観的な知識で、その個人でしか保持することができず、伝達することが難しい知識)は、共同化(Socialization)、表出化(Externalization)、連結化(Combination)、内面化(Internalization)の4 つの変換プロセスを経ることにより、形式知(言葉や文章や絵や数値などに表現された伝達可能な知識)に変換され、それを繰り返すことで組織におけるナレッジの高度化を図るというものです。このモデルは、有名なので、ご存知の方も多いと思います。

それぞれの変換プロセスは以下のとおりです。 SECIモデルの詳細については、「野中郁次郎・一橋大学名誉教授が語る「今の時代に求められるリーダーとは」を参照してください。

論文では、ナレッジの人から組織への移転、つまりSECI モデルでいうところの表出化における具体案として、3つ挙げていました。 一番良いと思ったのは、ナレッジ管理者の設置という提案でした。私が企業に勤めていた頃、ソフトウェアプロセス改善活動を全社的に推進していました。推進担当者はペアを組んで開発部門の支援をしていたのですが、推進担当者の経験や工夫はどうしても自分達だけのものになりがちでした。そこで、みんなの経験や工夫を共有するために、半期毎にみんなの活動記録や成果物の中から共有した方が良いものをピックアップしてまとめるというグループ(ナレッジ管理チーム)を設置しました。そして、まとめたものを、期末あるいは期初に報告して議論するという場を作り、みんなで共有を図りました。このことによって、個人、チーム、組織の幅が広がり、支援活動の改善にも効果があったと思います。残念ながら、効果測定という面では弱かったような気もします。

あと、“コア領域”と“ノンコア領域”という切り分けが斬新で面白かったです。企業にいた頃は、コア技術という呼び方をよくしていましたが、それは、担当する業務固有の技術や知識という使い方をしていました。しかし、この論文では、以下のように定義していました。

IT 企業及びPM の視点から見た場合、コア領域とは、技術的なスキルをはじめとして、コミュニケーション、ロジカルシンキング、ドキュメンテーション、プレゼンテーションといった一般的な知識やスキル領域のことである。一方、ノンコア領域とは、業界知識や慣習、業務に関する独自プロセスといった関連する組織やプロジェクトに属さない限り知ることのできない領域のことである。

この定義は目から鱗というか、私たちは視点を変えなければいけないという事を思い知らされました。確かに、今までコア技術と呼んで守っていた(と思い込んでいる)ものは、全体から見るとノンコア領域であり、本当のコア技術とは、上記に書かれているような事なのではないかと思いました。若い方々の視点は新鮮であり、大事にしないといけないということを実感しました。

今回の発表は提案まででした。発表後、私から、「ナレッジ担当を設置するのはとても良い。コア領域とノンコア領域の考え方は新しい気づきだった。次回は、実践結果をぜひ聞きたい。」というコメントをしました。

とても興味深い発表を聞けた2日間でした。2019年度秋期研究発表大会は、8/29(木)-30(金)の2日間、北海道の札幌で開催です。次回も楽しみです!
戻る

6. ITパスポート、いいですね!

千葉工業大学の場合、授業は1月でほぼ終わり、卒論、修論のない学生は、2月から春休み状態です。今年は4年生がいないため、私も2~3月は結構時間があるはずなのですが、何となく慌ただしい毎日を送っています(^^;) 計画的に過ごさないと、あっという間に時間だけが過ぎてしまいますね。娘の大学受験も終わり、志望校に合格しました! 娘の勉強している姿を見ると、親も頑張らなければと強く思いました。

このような背景もあり、研究室の3年生に、ITパスポートの合格を目指して春休みの毎週火曜日午後に勉強会を開こうと提案してみました。最初、集まらないかなぁと思っていたのですが、9人中6人が手を挙げてくれました(就職活動もあるので、出席率はボチボチです)。

参考図書「情報処理教科書 出るとこだけ! ITパスポート 2019年版」を選び、過去問を入手して、毎週過去問を解いて間違ったところを復習するというスタイルで進めています。
購入した参考図書
毎週火曜日、学生と一緒に過去問を解いているのですが、恥ずかしながら、思ったより難しく苦戦しています。問題は、ストラテジ系(経営全般)、マネジメント系(IT管理)、テクノロジ(IT技術)の3つの領域に分かれていて、問題数は、35問、20問、45問程度の100問となっています。出題形式は四肢択一式で、時間は120分です(試験内容・出題範囲)。合格基準は各分野で60%以上の正答があり、かつ総合でも60%以上が正答のようです(単純に1問何点という配点ではないようです)。

私の場合、ストラテジ系とテクノロジ系が弱く(70~80%程度)、マネジメント系はまあ大丈夫(95~100%)という感じです。ストラテジ系の中では会計・財務、経営戦略マネジメントが弱く、テクノロジ系では、ネットワークとセキュリティが弱いという状態でした。会計・財務は大学の頃習ったはずなのですが、ダメダメですね。ネットワークやセキュリティも、頭では何となく分かったつもりでいたのですが、ダメダメでした。でも、分からなかった事を勉強して理解できると嬉しいですね。学ぶ事に年齢は関係ないということを実感しています。

実は、4月の情報処理技術者試験では、プロジェクトマネージャを受験するつもりだったのですが、申込み期限を間違えてしまって申し込めなかったので(本気で受けるつもりであれば間違えるはずがないので、言い訳に過ぎないです)、学生と一緒にITパスポートの勉強を始めましたが、逆に良かったかなと思います。ちなみに、情報処理技術者2種、1種、プロジェクトマネージャは大学時代~入社2年目までに合格していますが、出題内容も大きく変わっていると思い、プロジェクトマネージャは再受験しようと思いました(プロジェクトマネジメント学科なので、最低限、資格は持っておかないといけないかなと思いまして…)。

自分で解いてみて分かったのですが、基本的な事を幅広く理解するために、ITパスポートはとても良いと思いました。学生には、少なくとも卒業までにはITパスポートは合格してもらいたいと思ってます。馬力がかかれば大丈夫だと思ってます。私は、今年はITパスポートに合格し(落ちる事はないと思います)、来年、プロジェクトマネージャを受験することにしました。
戻る

5. 業務設計とプロセス改善活動

今年度、建設業務を中心とした会社において業務設計に関する研修(1日7時間コース)を何度か実施しました。研修コースを開発するにあたり、業務設計の定義を以下のように定めました。 上記の定義を真正面から受けとめると、“とても大変で難しい”と思う方が多いと思います。私もそう思います。しかし、この研修コースの開発に関与している方々に話を聞いてみると、業務設計の仕事の中には、以前に実施した同じような仕事が含まれているという話もよく聞きました。それならば、プロセスを整備し標準化を進め、その標準化したプロセスをベースにテーラリングをすればよいのではないか、という考えに辿り着きました。結果として、プロセス改善活動の考え方をベースにして、以下のようなプログラムにしました(グループ演習と講義は6対4という構成です)。
  1. 業務設計とは
  2. プロセスとは
  3. プロセスの構造と種類
  4. プロセスの表現方法
  5. プロセス定義の留意点
実際に研修を行ってみると、システムやソフトウェアの開発部門の方々に対して行ってきたプロセス改善の教育の評価や感想と大きな差はないように思いました。また、CMMIA-SPICEで定義されているプロセス(例えば、CMMIの要件管理プロセス)のいくつかは、業務設計の中でもうまく当てはまることも多いということが分かりました。 以下の図は、「能力成熟度モデルのキープラクティス 1.1版」(技術報告書、1993年2月、CMU/SEI-93-TR-25、ESC-TR-93-178)の 0-52 ページの 図4.1 と同じものです。図の中の“ソフトウェア”を“業務設計”に置き換えても、違和感なく読めると思います。今後、ソフトウェア開発に限らず、プロセスに関する相談や研修開催の依頼を受けた時には、この枠組みをベースにヒアリングや確認などをして、お客様の要望に近いものが提供できるようにしていきたいと思っています。
出典:能力成熟度モデルのキープラクティス 1.1版、0-52 ページ、図4.1
戻る

4. 2018年12月:CMM と「CMMI Ver.2.0 の特徴と日本語化」

CMMI(Capability Maturity Model Integration:能力成熟度モデル統合)の新バージョンであるV2.0は、2018年3月に公開されました。
https://cmmiinstitute.com/products/cmmi/dev

これは、2010年11月リリースのV1.3以来のメジャーアップグレードとなります。モデルの構成要素の変更や、アジャイル開発手法への積極的な対応など、モデル、評定手法、トレーニング体系が全般的に改訂されています。

日本SPIコンソーシアム(JASPIC)では、従来バージョンに引き続き、V2.0の日本語化についても開発元であるCMMI Instituteとの協力作業を進めていて、2019年春のモデルリリースを予定しているそうです。

JASPICから隔月に発行されている「JASPICメルマガ 2018年12月号」に、CMMMI Ver.2.0 に関する以下の記事が載っています。興味のある方はぜひ読んでください。
私は、1990年後半、当時の上司である、山田さん、艸薙さんからSW-CMMを教えていただき、ソフトウェアプロセス改善の世界に入ってきました。その頃、社内では、SW-CMMの内容を自分達の組織の言葉に置き換えたうえで、実際の活動と書かれていることを比較し、良いところ、改善が必要なところを定期的に評価し、その結果に基づいて、組織の改善活動を推進していました。

最初の頃は、のんびりとしたやり方だな、手法とかツールを導入した方がよっぽど効果があるのになぁ、などと思い、あまりよい印象は持っていませんでした。しかし、乘松さんがインストラクターをしていた3日間の「SW-CMM入門コース」を受けた当たりから気持ちが変わってきました。というのも、その当時私は、静的解析ツールや構成管理ツールなどの研究開発や導入推進をしていました。とてもよい技術であり、ツールなのですが、なかなか社内に広がらないという思いを抱いていました。

SW-CMMでは、各成熟度レベル(レベル1からレベル5まで)はキープロセスエリアで構成されています。それぞれのキープロセスエリアはゴールとキープラクティスか構成されています。そして、キープラクティスは、「実施のコミットメント」、「実施能力」、「実施される活動」、「計測と分析」および「履行検証」という5つのコモンフィーチャに分けられています。

各レベルで定義されているプロセスも、それまでの経験と照らし合わせると納得のいくものだったのですが、それ以上に、コモンフィーチャという考え方がとてもよいと思いました。

これらのコモンフィーチャーは、組織として制度化することが組織力向上の鍵となります。
組織力とは何でしょうか?
それは誰かが頑張ってうまくいくのではなく、誰もが当たり前にやってうまくいくようになることです。そのために大事なのが、制度面での工夫です。
といったことを確立する事です。制度化することで初めて組織の力として継続していけることになります。このような状態になると、“みみちゃん(みんなで決める、みんなで守る、ちゃんと見直す)”ということが、組織で出来るようになります。これは、例えばプロセスをルール化する場合に、独断で決めるのではなく、組織の話合いの中で決める。そして、組織のみんなで決めたプロセスのルールは、同意したうえできちんと守る。最後に、そのルールに対して守れない事態が生じたならば、きちんと声を上げてみんなで見直すということを表しています(この部分の文章は、次の文献から引用)。

艸薙匠、猪野仁、石川隆、ソフトウェア開発プロセス改善活動、東芝レビュー Vol.61 No.1、2006.

SW-CMMは進化を続け、今では、CMMI Ver.2.0 となりました。このモデルは、私を成長させてくれただけではなく、多くの素晴らしい方々との出会いも作ってくれました。今後、CMMI Ver.2.0 をよく勉強し、みなさまにその内容を説明できるようにしたいと思っています。

戻る

3. 2018年11月:ProMAC2018に初参加してきました!

タイのバンコクで開催された ProMAC2018 (12th International Conference on Project Management) に参加してきました。

ProMACは、プロジェクトマネジメント学会が主催する国際会議で、今年は12回目の開催でした。いつかは参加したいと思っていたのですが、タイミングが合わなくて参加できませんでした。今年、ようやく参加できました!

ProMACは、日本からの参加者が多い国際会議です。企業からは、日立製作所、日本IBM、NTTデータ、NEC、富士通からの参加が多く、大学からは、プロジェクトマネジメント学科を持つ千葉工業大学からの参加者が多いのが特徴です。3日間の中で、キーノートは5件、発表(質疑応答込みで20分)は8トラックに分かれて合計147件でした。また、発表と並行して、ワールドカフェとスペシャルレクチャーが実施されていました。

発表と質疑応答はもちろん英語です。英語に関して言えば、やはり個人差は大きいのですが、各参加者ともに準備はしっかりしているので、内容は分かりやすくまとまっているものが多かったと思います。

2日目朝のキーノートスピーカーは、千葉工業大学 プロジェクトマネジメント学科の谷本先生でした。タイトルは、"New Paradigm of Information Security Management in the Digital Transformation Era" で、セキュリティマネジメントに関する幅広い内容を分かりやすく説明されてました。時々、ジョークも交えながら、笑いを取っていたところはさすがでした!

私は、セッションチェア(座長)と発表があったので、ちょっと大変でした(^^;) 担当したセッションでは次の4件の発表がありました。
最初の発表者はノルウェーからの参加者でした。アジャイル開発と一般のV字型の開発で、仕様変更やリリースの回数がプロジェクトの成功とどのような関係があるのかを調査した内容でした。仕様変更とリリース回数が多いほど、アジャイル開発は成功し、V字型開発では失敗するという結果が得られていました。妥当な調査結果だと思いますが、しっかりとアンケート調査をベースにした分析が行われているので、今後、いろいろなところで引用できる論文だと思います。

2件目と3件目の発表者は、日本IBMの杉本さんと木村さんでした。お二人とも、英語が流暢で、とても分かりやすく、実践に裏打ちされた内容の濃い発表でした。まさに、今まさに、PMをバリバリ実践していることがよく分かりました。私も、お二人のようにスムーズに英語が話せるように頑張らなければ、と強く思いました。

4件目の発表者は、NTTデータの杉浦さんでした。スクラムがうまくいっているかどうかを、客観的に評価したいというモチベーションのもと、その仕組みを提案して実践した結果の発表でした。英語ももちろん上手だったのですが、それ以上に、実践した内容を伝えたいという熱意があふれていました。内容ももちろんよかったのですが、それ以上に、発表する時に一番大事なのものは何かを教えてくれた発表でした。

私は、"Practical Approach to Promote System Test Automation in a Large-Scale Organization" というタイトルで発表しました。内容としては、システムテストの自動化をターゲットにしていて、その自動化を推進するための技術、環境、体制、進め方などについてまとめたものです。私の発表したセッションの参加者はとても少なく、私の発表の時は数名だけでした(-_-) ですが、発表後は、NTTデータの木暮さん(今回も司会と発表の両方をしてました)や島中さん(ICTTI:Information & Communication Technology Training Institute)などから質問もあり、発表後の議論もできて、とても有意義でした。チェアの方からも、実践的でよい内容ですねと言われました。

島中さんと久しぶりに会ったのですが、今は、ミャンマーの ICTTI で働いていることを知りました。とても元気そうでした。いろいろな話ができて楽しかったです。以下は、ICTTI の紹介です。

Information & Communication Technology Training Institute (ICTTI) is a public school which has been established by University of Computer Studies, Yangon (UCSY) and Japan International Cooperation Agency (JICA) so that the graduates are able to get practical system development skills solving the problem of classroom lecture of the university.

期間中、たくさんの方々と交流ができ、また、他の大学の先生方と今後の研究の事などで意見交換もできて、とても有意義な3日間でした(私のよく知っている他大学の先生方も数名参加していました)。

来年 ProMAC2019 は、ミャンマーのヤンゴンで開催です。期間は、2019/11/12(火)~11/16(土)です。興味のある方、ぜひ、一緒に参加しませんか! 面白いですよ(^^)

Facebookの投稿

戻る

2. 2018年10月:ソフトウェアプロセス改善について

活動のサイトにも記載したのですが、9月にソフトウェア品質シンポジウム(SQiPシンポジウム)で、ソフトウェアプロセス改善に関するチュートリアルを行い、10月にある企業でソフトウェアプロセス改善をメインテーマとして講演をさせていただきました。その中で、ノイラートの舟 - Neuraths Boat - という詩を紹介する時もあります。
ソフトウェア開発の現状を見ると、保守や派生開発が多くの割合を占めています。組込みソフトウェア開発データ白書2017(該当箇所は33ページ)によると、415件の回答のうち、384件(93%)が改良(派生)開発であり、31件(7%)が新規開発でした。

ノイラートの舟の詩にあるように、新しいソフトウェアを最初から作り直せたらよいと思う時も多いと思いますが、それはできない、というのが実状です。そうなると、大切な事は、舟を修理しながら航海を続けること、すなわち、改善活動をしながらソフトウェアの開発を続けること、になります(かなり無理やりとい感じですが…)。

ソフトウェアのプロセス改善の定義は、「インプットをアウトプットに変換する、相互に関連する又は相互に作用する一連の活動(JIS Q9001)」です。一連の活動を実施する際には、「指定された最終結果を生み出すように設計された、作業活動に関わる“人、材料、エネルギー、機器、及び手順”の論理的編成(Quality Process Management by Pall, Gabriel A.)」が大切です。プロセスというと、直感的に「あ、手順のことだよね」と思い浮かぶと思いますが、手順はあくまでもひとつの要素であって、それ以外にも、そのプロセスを実践できるスキルや経験を持った人や機器(ソフトウェア開発で言えば、技術やツール)などがセットになって、初めて効果的・効率的なプロセスになります。

ソフトウェアの品質は、それを開発・維持するプロセスの品質に左右されるということは、ソフトウェアの開発に携わった方であれば実感されていると思います。「品質は工程で作り込め」「源流の清め」「後工程はお客様」といった格言(心構え)を聞いた事がある人は多いと思います。

プロセスは、手順、技術(ツール)、人から構成されています。ソフトウェア開発のQCD(Quality:品質、Cost:コスト、Delivery:納期)を達成するためには、プロジェクトの特性に合わせた手順を設計し、その手順を効果的・効率的に実施するための技術(ツール)を活用し、それらの技術や手順を使いこなせる能力を持つ人が必要です。

出典:開発のためのCMMI® 1.3版、4ページ、図1.1

派生開発が多いという現実において、過去の資産(プロセスとプロダクト)を活用しつつ、その資産に改善を加えることが大切ということがよくわかります。また、長年の積み重ねで、プロセスとプロダクトの資産が崩れかけていることも多く、部分的には、プロセスの見直しやプロダクトのリファクタリングなども必要になってきます。このような活動を計画的に、継続して実施するには、組織的な取り組みが必須になってきます。

能力成熟度モデルCMMIが盛り上がっていた時期(2000~2010年頃)には、いろいろな企業がプロセス改善活動に取り組んでいました(日本SPIコンソーシアム(JASPIC)の会員企業も30社を越えた時がありました)。しかし、2010年頃から、盛り上がりも冷めてきて、組織的にプロセス改善活動に取り組んでいる企業は減ってきたと思います(現在のJASPICの会員企業は17社です)。

これは、個人的な感覚なのですが、この1~2年、「プロセス改善活動に取り組みたいです」「プロセス改善活動を継続することが大切ですね」といった声を聞く機会が増えたように思います。

さまざまな開発環境や開発技術、開発ツールや管理ツールなどが提案され、実践されている中、それらをうまく組み込むには、ソフトウェア開発のための土台(基礎)の重要性が再認識されてきたのだと考えています。この土台を作ることが、組織やプロジェクトに最適な技術やプロセスの導入を可能にするということだと思います。

大学に移り7ヶ月が過ぎました。いろいろなイベントや会合に参加し、今まで一緒に活動してきた方々と話をする中で、プロセス改善の大切さや、それを伝えて広げることの重要性を再認識しました。これからも、ソフトウェアプロセス改善を研究テーマの一つとしてしっかりと追い続けていこうと思います。

戻る

1. 2018年9月:大学でプロジェクトマネジメントを学ぶということ

2018年3月で東芝を退社し、4月から千葉工業大工に着任してから半年が過ぎました。何もかもが新しい事ばかりで、戸惑った事もありましたが、とても素晴らしい環境の中、先生方、職員の方々のサポートもあり、まずはうまくスタートできました。

今回は、プロジェクトマネジメント学科の3年前期で実施する、「プロジェクト・マネジメント演習」(以後、PM演習と書きます)をとおして、大学でプロジェクトマネジメントを学ぶということについて考えてみたいと思います。

PM演習では、3~4名からなるプロジェクトチームを作り、自分達で提案したシステムを開発します。期間は、4月~7月の約4ヶ月です。

PM演習で目指す事は、以下の3項目です。
マイルストーンは、4月のキックオフ、6月上旬の中間発表、7月中旬の最終発表の3つです。各プロジェクトでは、課題を設定し、それを活動の中で取り組む必要があります。例えば、管理系の課題であれば「CCPM(*1)法導入」、「アジャイル開発の導入」などがあり、技術系の課題でれあば、「外部APIを利用した実装」、「デバイスを利用した実装」などがあります。また、各プロジェクトには、ユーザとシニアの役割として先生方が割り当てられます。ユーザは顧客側の責任者で、シニアは開発部門側の部長に相当する感じです。プロジェクトでは、いくつかの成果物を作りますが、すべて、シニアの承認後、ユーザに説明して、承認をもらう必要があります。

中間発表と最終発表の評価の観点は次のとおりです。 プロジェクトマネジメント学科には12の研究室があり、それぞれの研究室は、経営システムのプロをめざす「経営システムコース」か、プロジェクト管理の実践力を身につける「プロジェクトマネジメントコース」のどちらかに所属します(Webサイトの「学びのポイント」を参照)。「プロジェクトマネジメントコース」の中では、さらに2つのグループに別れ、そのうちのひとつのグループである「ソフトウェアグループ」の研究室に所属する学生が、上記の内容で演習を行います。他のコース、グループも同じ期間で、同様の演習を行っています。

私の研究室の3年生は9名なので、3つのプロジェクトチームが約4ヶ月間に渡ってプロジェクトを実践しました。それぞれのチームともに特色があり、試行錯誤をしながらも、最後には何とか最終発表まで辿り着く事ができました。開発したシステムは、「ジョブ・マッチング・システム」、「学食のカロリー管理システム」、「教科書予約システム」の3でした。

「学食のカロリー管理システム」を開発したチームは、優秀賞を受賞しました。このチームの最終報告書は、次のリンクから参照してください。

「学生のための学食のカロリー管理システム」最終報告書

成果物として、要件定義書、プロジェクト憲章、プロジェクトマネジメント計画書、外部設計書・内部設計書、テスト計画書・テスト報告書、QCD評価報告書など、13個のドキュメントを作成しました。チーム課題は、「品質マネジメントにインスペクション技法を導入」として、内部設計書を対象にインスペクションを実施しました。

後半は、PHP と MySQL を使って Web サイトを構築します。しかし、1~2年生のころに基本的な事は学んでいるのですが、この部分はかなり苦戦してました。実際に自分の PC に環境を構築し(XAMMP や Visual Studio Code をインストールし、Github や Slack を使えるようにする)、そこでプログラミングとテストをして、Github にアップするという作業に習熟するまには、もう少し時間が必要と感じました。できれば、この演習とは別の枠で、きちんと習得しておく必要があるのかもしれません。

プロジェクトマネジメント技法をベースにして、要件定義から納品までを実践した学生達を見ると、一回り成長したと実感できました。プログラミングに関 しては、それぞれのメンバが担当した部分は数画面でしたが、自分で手を動かしてみるという事が大切だと思いました。

プロジェクトマネジメント技法は、実務での経験をしたあと習った方がよいという意見もよく聞かれます。もちろん、そのような側面もあると思いますが、ドロドロとした開発の裏事情や経験に囚われることなく、大学の頃に、その目的・考え方・技法を理解し、習得することには大きなメリットがあると思います。あるべき姿をきちんと理解し、それを発信できる事は、社会に出てから大きなアドバンテージになるはずです。

話題は変わりますが、プロジェクトマネジメント学会 2018年度 秋季研究発表大会で、京都光華女子大学の学生の方が、以下の発表をしていました。 どちらの発表者ともに、大学の1~3年の時期に実施したいくつかのプロジェクト(学内や地域のイベント、店舗で使ってもらうシステム開発など)をとおして、プロジェクトマネジメントを実践し、そこから理解できた事、学んだ事などを発表してくれました。プロジェクトマネジメントとして学んだ事が参考になり、さらに、活動計画、作業項目一覧、リスク管理などの技法を使いこなせるとともに、チームビルドやコミュニケーションマネジメントなどに注意を払う事がができたと発表していました。

プロジェクトを実施している時、問題や壁にぶつかった際には、「ミッションに立ち返りました」というコメントが特に印象に残りました。この時のミッションの例として、「文化を確立する」「商店街の活性化」の2つを挙げてました。技法も大切ですが、根幹には、そのプロジェクトの“ミッション”を、プロジェクトのメンバが共有できているかどうかが最も大切な事であることを再認識させてくれました。

京都光華女子大学のサイトに、“プロジェクトマネジメント学会「2018年度秋期研究発表大会」に参加しました”という記事が載っています。

今回の経験をベースに、来年度のPM演習が少しでも良いものになるように改善し、今後も継続・発展していけるようにしたいと思いました。そして、1年後、再び、PM演習の結果を報告したいと思います。

*1 : CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)は、プロジェクトの各タスクの予算やスケジュールをぎりぎりに抑えて、その分、プロジェクト・バッファという余裕を設けておく管理手法。

戻る

Last Update:2020/04/23