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

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時頃まで発表セッションを行い、昼食のあと、片付けをして、企業訪問に向かいました。約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:2019/09/10