私がコンピューターで文書を書く方法の変遷

最近になってMarkdown形式で文書を書くことが増えたのですが、改めて考えるとコンピューターを使って文書を書く方法は多様であって、それらの方法をどれだけ経験しているかも人によって様々ではないかなと考えることがあります。

例えば、PC上のMicrosoft Officeなどのアプリケーションで書くのか、Google Docsなどのウェブアプリケーションで書くのか、見たまま編集なのか、何らかの書式に従ったテキストを別途レンダリングするのか、といった方法の違いがありますが、どういった方法に慣れ親しんでいるのかは人によって異なるのではないかと思います。知っているのは1つの方法だけという方々もいるでしょうし、複数の方法は知っているけど特定の方法は肌に合わないという人々も、「肌に合わない」という人々をなんとか矯正したい複数の方法をマスターしている人々もいることでしょう。

一昔前はワープロという言葉があり、それが文書作成のスタンダードだったのかもしれませんが、現在ではそれが揺らいでいるのではないかと考えます。コンピューターを使った文書作成の方法をどこで学ぶかというと、学校の "コンピューターリテラシー" などの授業で学んだり、就職してから同僚から学ぶというケースが思いつきますが、そういった場で多様な文書作成の方法を学べるかというと多分必ずしもそうではないのでは？と思います。

私の観測範囲では、方法を問わず書ける人々もいれば、「Google Docs？初めて聞いたよ」「ローカルのOfficeで書いてdocxとかをDriveに置く方が合ってる」「Wikiみたいなのは記法を覚えるのが面倒くさい。」という人々もいます。私はどちらかというと前者の方法を問わず書ける人に属します。

そして、文書作成方法が多様化した現代では、組織によっては上述の文書作成リテラシーの違いによる問題が起きているのではないかと推測します。

本エントリでは、私の考える現状に問題提起をする前に、私自身がコンピューターで文書を書く方法の変遷を振り返ります。

最初はプレーンテキストとTeXだった

初めてコンピューターを使って文書を書いたのは大学1年生のときです。初めて買ったパソコンのOSはWindows98SEでした。また、コンピューターリテラシーという授業があり、そこでもテキストエディタで文書を作成する演習がありました。

コンピューターリテラシーの授業が少し進むと、TeX(てふ)という文書作成アプリケーションを使用して、章や節の見出しをつけたり、画像を貼りつけたり、数式を書いたりする演習が行われました。入学してしばらくすると紙でのレポート提出が必要な授業が増え、TeXでレポートを作成するようになりました。図はTgifというドローツールで描きました。表計算が必要な状況は無かったので、スプレッドシートというものを知らずに過ごしました。

TeXはWordと異なり、決まった形式でテキストファイルを書き、それを別途レンダリングします。TeXを使用できる環境は自宅のPCには無く、大学のコンピューター演習室か、サークルの部室で作業していました。演習室の環境はSolarisのワークステーションで、部室の環境はFreeBSDでした。部室にMS Officeの入ったWindows機もあったのですが、体裁のある文書はTeXで作るものと覚えていたので、結局学生時代はMS Officeを使わずに過ごしました。もちろん論文もTeXで書きました。

HTMLで日記を書いた

2000年代初頭ではホームページを作成するのが流行しており、私もそれに乗って作りました。WordPressのような contents management system は存在せず、エディタでHTMLやCSSを書いていました。「TeXとは書式が違うんだな」「リンクが便利だな」「章番号や図表番号を参照するような文書には向かないな」と感じた覚えがあります。ホームページでは日記を書いていました。「授業が面倒」だの、「カレーを作った」だの、取るに足らない内容を書いていた覚えがあります。Twitter と同じですね。

ブログに移行、そしてmixiへ、Wikiも

2003年ごろだったでしょうか。日本で幾つかのブログサービスが始まりました。この頃になるとウェブ上で論説文やエッセイなど、それなりの量があって、構造や論理展開がある文章を見るようになりました。そして、多感な大学生らしく「自分もそうした文章を書きたい」と考えるようになり、それまでホームページで続けていた日記をブログに移行しました。ブログ時代は2年くらいは続いたと思います。今はもう残っていません。

ほどなくして日本発SNSの代名詞であるmixiが登場しました。mixiはどちらかというと友人などとクローズドなコミュニケーションを取るために使用し、mixi日記には日常を書き、ブログには長めで一般向けの文章を書いていました。

趣味の活動でWikiも使用しました。簡単な書式でテキストを書くとHTMLに変換されるというのは便利だと感じました。確か、PukiWikiだったと思います。

OpenOffice.org でプレゼンテーション

大学の研究室に入るとプレゼンテーションをする機会が増えました。その研究室では原則的にWindowsが禁止されていたので、Debian GNU/LinuxにてOpenOffice.orgを使っていました。いわゆるOffice系アプリを使用したのはこれが初めてでした。見たままを編集するというのはなかなか軽快で良かった覚えがあります。一応TeXでスライドを作成することもできましたが、見栄えを練るのには向いていないと判断しました。

一方でメモをとるならテキストで十分ですし、レポートや論文を書くならTeXしかないと考え、ワードプロセッサー機能は全く使いませんでした。また、数値計算はPythonなどを使用しており、スプレッドシートも使いませんでした。

就職して初めて Microsoft Office を使った

こうして、大学に入学して初めてコンピューターを使用してから卒業するまで、Microsoft Office に触れないまま過ごしてきましたが、就職して初めて使うことになりました。

初めてWordとExcelを使用したときは新鮮だった覚えがあります。Wordについては「目次はどうやって作るのか？」「なぜ勝手に字下げをするのか？」、Excelについては「セル内でどうやって改行をするのか？」「countifって何だ？」などの疑問に当たり、機能やtipsをググりながら覚えていきました。見出しや図のある文書を作成したり、簡単な表計算をすることは、実務をこなしながら自然とできるようになりました。

そうした中で、Excelで書かれた見出しや構造のある文章、画像を貼りつけただけのシート、全ての行・列の幅を等しく揃えた後にセルの結合機能を使用して表を書いてあるシート、Excelは使用できるがWordは使用できない人々に出会うことがあり、「これは悪い見本なので参考にしてはいけない」と感じたのを覚えています。

Trac の記法や、Redmine の Textile を使うこともありました。

少しだけ Sphinx を使ったこともあります。章や節のある長めの文章は全部 reST になればいいのに、GitHub なんかもサポートすればいいのに、と思いました。

そして現在

現在では GitLab や Qiita:Team などでの Markdown, Word, PowerPoint, Excel, Google Docs などを使用しています。

振り返り、周囲をみると、こういった経験のある人は実はそんなにいないのではないかと思わされます。それぞれは大した経験ではありません。少しトレーニングすればすぐに覚えられることばかりです。ですが、特定の文書作成方法のみ経験している人々がいて、方法が多様化した現在ではついていけない個人がいたり、組織においては支障が出ていたりしないでしょうか？…というのは次の話。

カメをウサギには変えられないことの認識が技術支援のスタートなのではないか

組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada

www.slideshare.net

※スライドの技術的内容とは関係ない文章です

スライドの13枚目

"人は自分の速度でしか成長できない"
"プロジェクトもプロジェクトの速度でしか成長できない"
"まわりはもうみんなやっていますよは劇薬"
とのこと。t_wada が言うのならソフトウェア開発に関してはそうなのかもしれない。

成長速度を上げるにはどうすればいいのだろうか。

ウサギとカメの話で言うと、まじめに走るカメの相手がまじめに走るウサギだったら、カメはウサギには勝てない。カメをウサギにすることはできるのだろうか。

「相手はウサギだよ」と伝えても、たぶんカメはウサギにはならない。トップダウンで「ウサギになれ！」と鞭を打てばウサギになる人・プロジェクトもいるのかもしれない。しかし、場合によってはウサギになるどころか鬱になって歩けなくなる懸念もある。死んでしまうかもしれない。劇薬だというのはそういう意味だと思う。

まじめに走るウサギが沢山いる世界を知っている者は、カメを見ると「そんなんだからダメなんだ」と思うこともあるのだろう。私もそう思うときがある。だが、人やプロジェクトがその速度でしか成長できないのであれば、それを受け止めた上で自身の成長や相手への支援を考えなければならないのではないかと考えるようになった。カメをウサギには変えられないことの認識が技術支援のスタートなのではないかと思う。

カメをウサギには変えられないが、成長速度が上がることはあると思う。上げるではなく、上がるである。私は楽しむことが不可欠なのだと感じている。だから、支援をする立場からは、その職能分野のことだけでなく、楽しみを伝えることが成長速度の向上につながるのではないかと考える。ほかに何ができるのかはわからない。案外楽しむだけで良いのかもしれない。

SQuBOKから経営の世界へ, マーケットの世界へ

はじめに

SQuBOK V2読破会アドベントカレンダー20日目のブログエントリーです。 www.adventar.org

SQuBOKというのはこれです。ソフトウェア品質知識体系ガイド。 Google Books で一部を読むことができます。

books.google.co.jp

SQuBOK V2の章構成は2章のマネジメントが中心

SQuBOK V2読破会では文字通りSQuBOK V2を全て読みました。 理解が不十分な知識領域も多くありますが、少なくともソフトウェア品質に関係する知識領域が 何なのかを広く認識できるようになりました。

そこで、改めてSQuBOKの構成を全体的に見つめなおしてみることにしました。 各知識領域について知っているかどうかは、以前のエントリー SQuBOKによる無知の知の体験 - MassKaneko.Out で書きましたので、もっとメタに捉えてみることにしました。

• 第1章：ソフトウェア品質の基本概念
  • 良い品質とは何なのかは製品や時代によって変わる
  • ソフトウェアの品質には色々な側面がある
  • 良い仕事の仕方が良い品質を生む
• 第2章：ソフトウェア品質マネジメント
  • ソフトウェア品質マネジメントとは品質管理ではなく、manage本来の意味である"なんとかしてやる"という意味である。つまり、なんとかして目標とするレベルの品質に押し上げる・持続的に改善するための活動である。
  • 開発やテストだけでなく間接的なもの含めてあらゆるアクティビティがソフトウェア品質に関わるため、それらはソフトウェア品質向上のためのマネジメントの対象となる。
  • プロジェクト固有のマネジメント、プロジェクトに依らない共通のマネジメント、プロジェクトレベルを超えた組織レベルのソフトウェア品質マネジメントがある。ソフトウェア品質技術者だけが努力すれば良いわけではない。
• 第3章：ソフトウェア品質技術
  • 品質を作りこんだり確認するためのテクニックやツールが色々ある

できるだけ短く書いてみました。 こうして考えてみると、第2章が中心の本なのだなと思います。 プログラマーやテスターからすると、品質を向上するためには第3章の内容が中心となって見えます。 それは開発技術やテスト技術ですから、それはそれで閉じているわけです。

しかし品質を上げるために"なんとかできること"とは開発とテストだけではないわけで、マネジメントという概念を持ち出した時点で第3章は主役ではなくなるのです。 そして、ソフトウェア品質マネジメントのことを書こうとすると必然的に「ソフトウェア品質とは」という第1章を書かざるを得なくなる。 だから、この順番の章構成なのだと考えます。SQuBOKを読む前は「はぁあああ？？2章がマネジメントぉぉぉ？？？なんだよ結局品質管理屋のための本かよー。一生マネジメントでもプロセス改善(笑)でもやってればいいじゃん。そんなことしてる間にテクノロジーで遅れを取っていくんだよ。」と思っていましたが、1年前に比べればだいぶ考えがニュートラルに是正されてきたことを実感しています。もちろん直接的にソフトウェアの品質を決めるのはコードですし、欠陥を見つけるのはテストですが、それらの活動を満足に行うためにできることが沢山あるということです。

品質から経営の世界へ

ソフトウェア品質を真正面に考えるのであれば経営やマーケットの世界に足を踏み入れる必要がある。最近、そう思います。

一つは先ほど書いたマネジメントの話の延長線上にあることで、技術職以外の努力が必要となる領域を考えると次に管理職の努力が必要となる領域が思いつきますが、 第2章にあるマネジメントを考えるとなるとプロジェクトマネージャー・プロダクトマネージャーよりも更に上位のレベルのマネジメントが必要となることが考えられます。 例えば、会社組織における品質マネジメントシステムを構築したり、プロダクトのライフサイクル全体を考えたり、ソフトウェアプロダクトラインを考えたりといったことは、 一定以上の規模の会社組織においては一管理職にはできることではなく、経営者の努力が必要となる領域だと思うのです。 経営となるとソフトウェア品質だけに思慮を巡らせるわけにはいかなくなり、経済的合理性という側面からソフトウェア品質を考えることになります。

そうなるとソフトウェアやコンピューターの世界から経営の世界に足を踏み入れざるを得ないわけです。 会社組織ぐるみでないと行えない品質マネジメント活動に一体どのような経済的合理性があるのかを考えないといけなくなります。 しかもそれらの活動は本質的には投資であり、金銭的価値に換算することは難しいのです。 かといって技術者に「投資対効果を示せ」と言ったのではその経営者は無能であることを自白しているに等しくなります。 言い方を変えれば「私には品質マネジメント活動の価値がわからないから小学生でもわかる不等式で説明してくれ」と言っているに等しいのですから。

SQuBOKの巻頭にある"本書の利用方法"には、利用者層ごとのSQuBOKの利用方法について書かれています。 開発者・品質保証・管理者などの職種別に書かれていますが、実は最初に述べられている利用者は 経営層 なのです。 ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行う経営層といっても必ずしもソフトウェアの専門家ではないでしょうし、 専門家でなければならないということは無いと思います。しかし、少なくともどのようなトップマネジメントがソフトウェアの品質向上のために効くか ということは、ソフトウェアがプロダクト・サービスの価値を大きく決める事業を行うのであれば…技術者のように論理立てて説明できなくとも、 直感的に適切な選択肢を選ぶことができる必要があると思うのです。論理立てて説明できなくとも、概ね正しい直感を信じて迅速な意思決定ができる権限があるのは経営者だけだと思うのです。 そして、ソフトウェア品質の専門家はそうしたトップマネジメントができるように経営層を技術面で支えたり、意思決定の根拠となる新鮮で正確な情報を集めたりできることが望ましい協力関係ではないかと思います。

品質からマーケットの世界へ

ソフトウェア品質と経済的合理性の関係は、欠陥や工数が少なくなること以外に、売り上げに対する関係も考えられます。 すなわち、ソフトウェア品質を正面から考えるのであれば、いいものを作れば売れるのかどうかの問いに辿り着くということです。 しかし、このブログを書いてる現在、"いいものを作れば売れる" でググると、そうではないという旨の文章が複数ヒットします。 私はまだその答えを出せるほど品質の知識もマーケットの知識も無いのですが、思うに、"いいものを作れば売れるわけではない" かどうかの話は、 "いい" とは何なのかに踏み込みが浅いのではないでしょうか。

高機能・高性能・高信頼な製品が売れる時代は過ぎ去り、モノづくりからコトづくりの時代に変わったという論旨を、ここ数年で経済誌や講演で見かけるようになりました。 昨年のソフトウェア品質シンポジウムでも触れられていました。 ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014 － Publickey

これは "いい" とは何かが変わったということです。 もう少し言うと、機能・性能・信頼性という製品の品質から、UXや安全性といった利用時の品質にユーザーの関心が移ったということなのだと思います。

もし "いいものを作れば売れるわけではない" という論旨における "いい" というのが高機能・高性能・高信頼のことであり、 そう主張する人々がマーケターで、"良さ" を追い求めていたのが技術者だとしたら、 マーケターと技術者が合わせて "いい" とは何なのかを共有する場が足りていないのではないでしょうか。

製品・サービスの "良さ" を考える(決める)ということはすなわち半分くらいは商品企画をするということだと思います。 これまでは、商品企画というのは今まではマーケターの仕事というイメージがあったと思います。 そしてこれからは、ソフトウェアが価値を大きく決める製品においては、品質に関する知識のあるソフトウェア技術者が商品企画の領域に切り込んでゆく余地があるのではないでしょうか。 そうすれば "いいものを作れば売れるわけではない" から "ユーザーにとって価値があるものを作ることが売れることの第一条件だ" に進歩できるはずです。 そう、売りたいマーケターと技術に触れたい技術者の間を取り持つのはユーザーに価値を届けることだと思うのです。そこだけは両職種に共通するところだと思います。 今のソフトウェア品質体系は、良さとは何かをマーケターと共に決めることができるくらいに成熟していると思います。 だから、もし良さとマーケターが中心となって決めているのであれば、そこにソフトウェア技術者が協力できることがあると思うのです。 また、ユーザーに価値を届けずに売り上げを立てようと企てるマーケターや、ユーザーに届ける価値を考えずに提示された要求仕様を実現することだけしか考えないプログラマーを是正して、 ユーザーに届ける価値を中心に仕事をする啓蒙活動を行う役割も必要となり、それを品質のわかるソフトウェア技術者やマーケターが担う可能性もあるでしょう。 そういう意味で、ソフトウェア品質に携わる技術者はソフトウェア品質という技術の世界からマーケットの世界に足を踏み入れる余地があるのだと思います。

SQuBOKの中で一番好きな箇所

はじめに

SQuBOK V2読破会アドベントカレンダー12日目のブログエントリーです。 11日目は 「不具合管理」を見てみる | 四方山話 でした。

www.adventar.org

SQuBOKというのはこれです。ソフトウェア品質知識体系ガイド。 Google Books で一部を読むことができます。

books.google.co.jp

熱い箇所：ソフトウェアの品質マネジメントの特徴

上のGoogle Booksを開いてみるとわかりますが、SQuBOKはBOKというだけあって、突っ込んだ記述や個々の著者の主張は含まれていません。 しかし、p48-50にかけて書かれている "1.3 KA:ソフトウェア品質マネジメントの特徴" では、BOKらしからぬ強い主張が含まれた長めの文章があります。

要約すると以下のようになります。

• ハードウェア開発で培われた品質マネジメントの手法をソフトウェア開発に適用することはできない。
• ソフトウェア開発のほとんどは知的作業であり、技術者のモチベーションがソフトウェアの品質と生産性に大きく関係する。
• ソフトウェアはチームで開発するため、チームワーク・リーダーシップ・コミュニケーションが重要である。
• 製品とプロセスの質は互いに依存するため、両者の質の評価と改善を融合させて進めなくてはならない。
• 継続的な品質改善のためには「全員参加」「品質第一」「改善」「次工程はお客様」「5ゲン主義」「品質の作りこみ」という品質管理の基本原則の理解と実践が必要。

ハードウェア開発とは違う

"ハードウェア開発とは違う" という文脈からソフトウェア品質マネジメントの特徴を説明しているのがSQuBOKらしいと思いました。 SQuBOK策定の動機の一つとして日本の製造業を中心として発展した品質向上の取り組みを形式知化することがあるそうですが、 それが1.3KAの文章にも影響しているのかもしれませんね。

ソフトウェアはハードウェアに比べて設計の自由度が高いこと、再利用可能なコンポーネントの設計が難しいこと、測定すべき特性とは何なのかがはっきりしていないこと、 変更に対する影響の特定が難しいこと、故障モードのパターン化が難しいことなど、様々な違いが述べられています。 ハードウェア開発の経験はあるがソフトウェア開発の経験が無い方に対して、 何が違うのかを説明するために非常に参考になる文章だと思います。 電機メーカーなら技術者全員に基礎教育としてこの文章を読んでもらうのもありではないでしょうか。

SQuBOKには書いてありませんが、実装 という用語から想像する知的作業か否かのイメージはハードウェア開発とソフトウェア開発で大きく異なることには注意が必要だと思います。 コーディングは実装と訳されることが多いですが、ハードウェア開発者にとっての実装工程は "基板にパターンをひいて部品を載せる工程" なので、 設計が終わった後の工程であり、機械化が可能であり、知的作業ではないと捉えられてしまう懸念があります。 そうした誤解があるのであれば、コーディングは設計であり、工夫の余地があり、機械化ができるのではごく一部であり、知的作業であることを説いて理解してもらうことが重要ではないでしょうか。

知的作業の質にはモチベーションが大きく関係する

1.3KAではハードウェア開発との違いから始まって知的作業について触れられています。 私が一番熱いと思う部分を引用します。

人間の知的作業の質には、モチベーションが大きく関係する。モチベーションの高い技術者が開発すると、品質も生産性も向上する。 逆にモチベーションの低い技術者が開発すると、大量の障害を作りこんだり深刻なプロジェクトトラブルを引き起こしたりするため、 ともすると品質や生産性がマイナスになることすらある。 技術者のモチベーションを向上させるには、やりがいを感じ、快適と感じられる環境が必要である。 またソフトウェア開発はチームで開発するため、個人のモチベーションだけでなく、チームワークやリーダーシップ、 及びそれらを支えるコミュニケーションも重視しなくてはならない。

BOKでここまで書くか！と感じた文です。ただただ同意するばかりです。 ソフトウェアの品質マネジメントをやろうと言うのなら… 快適な開発ができるマシンとネットワーク環境を用意しなさい、オフィス環境を整えなさい、個々人の貢献を可視化する仕組みを作りなさい、 コラボレーションツールやチャットツールを使いなさい、朝会や振り返り会などで対話する機会を作りなさい、 モチベーションが下がってしまったメンバーをケアしなさい、ということなんですね。

先日参加した JohoKaigi - 情報会議 にも通じるところがあります。 ソフトウェア品質マネジメントの観点で情報共有を語るのも一興かなと思いました。 WikiやQiita:TeamやSlackなどのツールがソフトウェア品質に与える影響に関する文献があってSQuBOKのトピックとして載っていたらなあ。 でも無さそうだなぁ。え、書け？

おわりに

この熱いページ(48-50)はGoogle Bookでも読めるので、SQuBOKを持ってない方も読んでみるといいと思います。 ソフトウェア開発経験があんまり無い電気/機構エンジニアとか経営層の方が読むといいんじゃないですかね。

次、13日目は吉田東京さんです。よろしくー

SQuBOKによる無知の知の体験

SQuBOKv2読破会アドベントカレンダー4日目のブログエントリーです。

www.adventar.org

SQuBOKの入手動機と読破会への参加動機

SQuBOKというのはこれです。ソフトウェア品質体系ガイド。

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

いかにも堅そうな名前の本を手にした理由は 「一応専門家のはしくれだし*1持っておくか」くらいのもので、読もうとは思っていませんでした。 ぱらぱらとめくってみると、文体は淡々としており、図はあまり無く、かみ砕いた説明も無く、 色気の無い本だなという印象でした。読破会*2の主催者は「宝箱のような本」と言っていますが、 一体こんな色気の無い本のどこが宝箱なのかと思っていました。 読んだ今では、BOKにごてごてとした読者への配慮を求めるものではないということがわかったのですが、 読む前はBOKと名のつく書籍を手にするのは初めてだったこともあり、そのような印象を持っていました。

また、ソフトウェア開発に関するBOKとしてはIEEE発のSWEBOKが筆頭に挙がると思います。 SWEBOKがあるのにSQuBOKが作られたことは疑問でした。そして、SQuBOKは日本発のBOKというのも疑問でした。 SQuBOK V2の"はじめに"には次のことが書かれています。

日本のソフトウェア品質への取り組みは、製造業を中心として発展した品質のマネジメントに学ぶところから始まった。 それは一定の成果を得たものの、その技術や知識は各企業の現場それぞれで暗黙知の状態だった。 SQuBOKガイド第1版の策定動機の一つは, 日本で培われたソフトウェア品質に関する暗黙知を形式知化することにより…

こんなことを書くと何人に石を投げられるかわかりませんが… 日本で培われたソフトウェア品質に関する暗黙知に参考になるものがあるのかと。 製造業を中心として発展した品質のマネジメントが一定の成果を出したのかと。 NTT, NEC, 富士通, 日立, 東芝, 松下などの日本企業よりも、 Microsoft, Apple, Google, Amazon, Facebook などの米企業の方がソフトウェア工学において先を行っているのではないかと。

そう、思っていました。 だから、日本からSQuBOKが生まれたのは不思議でした。 いや、読んだ今でもその疑問は解けていないところもあるのですが、読む前は実に不思議でした。

そこで読破会の誘いを受けて、参加することにしました。 私に知識があるのか無いのかを確かめるために、 本当に宝箱のような本なのかを確かめるために、 日本発のソフトウェア品質の知見が参考になるのかを確かめるために。

あと、読破会の主催者がV1の策定メンバーであったことや、 8人という少人数であることも参加を後押しする理由でした。

無知の知テーブル

読破会の進め方は毎月集まって30ページずつ程度を読み進めながら議論をするというものです。 2015年の1月から始めて今月で終わる予定なので全部読んだわけではありませんが、 大体読んだとみなして、ここでSQuBOK全体の中で私が知っていたことと知らなかったことをまとめてみました。 結果、知らないことが多かったことを認識できました。なので、これを無知の知テーブルと呼ぶことにします。

• ● : 半分以上知っていた
• △ : 一部は知っていた
• × : 全くと言って良いほど知らなかった

項目	●△×	コメント
1.1 品質の概念	×	なじみがあったのはISO25010と狩野モデルくらい。デミング賞のデミングってここで出てくるのかー
1.2 品質マネジメントの概念	×	日本における品質マネジメントの歴史があるんだなーと
1.3 ソフトウェア品質マネジメントの特徴	×	理解はともかく冒頭の文が熱い！
2.1 ソフトウェア品質マネジメントシステムの構築と運用	×	日本企業、昔から努力してたんですね。QCサークル,品質会計,Qfinityとか色々初見。
2.2 ライフサイクルプロセスのマネジメント	×	プロセスモデルだけならまだしもライフサイクルと言われると難しい
2.3 ソフトウェアプロセス改善のマネジメント	×	名前しか知らないものがほとんど。三階層SEPGやばい
2.4 検査のマネジメント	△	1ページだけで、まぁそうだよねという内容。
2.5 監査のマネジメント	×	経験がないので全く知りませんでした。
2.6 教育・育成のマネジメント	×	知っていたのはETSSだけ
2.7 法的権利・法的責任のマネジメント	×	PL法なんてあったなーとか
2.8 意思決定のマネジメント	×	IPD, 今でもやってるんでしょうか
2.9 調達のマネジメント	△	外注するなという話が欲しいところだけどBOKには書かれないかなぁ
2.10 リスクマネジメント	×	ISO/IECの規格があるんですね
2.11 構成管理	●	仕事でやってるのでここはまぁまぁ
2.12 プロジェクトマネジメント	×	PMBOKの名前くらいしか
2.13 品質計画のマネジメント	△	トピックがベンチマーキングだけなのはいいんでしょうか？
2.14 要求分析のマネジメント	●	深そうな項目名だけど難しいことは書いていない
2.15 設計のマネジメント	●	まぁやりますよねという内容
2.16 実装のマネジメント	●	まぁやりますよねという内容
2.17 レビューのマネジメント	●	大事
2.18 テストのマネジメント	△	やけに手厚い
2.19 品質分析・評価のマネジメント	△	どうマネージするのかは理解が浅い
2.20 リリース可否判定	△	合格基準って意外とわからない
2.21 運用のマネジメント	×	経験がないのでさっぱり。理解できないところも多い。
2.22 保守のマネジメント	×	経験がないのでさっぱり。理解できないところも多い。
3.1 メトリクス	●	だいたいは
3.2 モデル化の技法	△	PAD, DSLは初見。
3.3 形式手法	△	経験はありませんが、ツール名・効果・労力に関して話に聞くことがあります。
3.4 品質計画の技法	×	そういうのもあるのか
3.5 要求分析の技法	△	清水吉男さんの本を読んだくらい
3.6 設計の技法	△	デザインパターンやTDDなど馴染みのものもありますが、ほかにもあるんですね。
3.7 実装の技法	●	契約による設計が初見
3.8 レビューの技法	△	3.8.1については名前は知らないけど実はやってるというケースが多いのではないかと
3.9 テストの技法	△	SQuBOKの中で一番ボリュームがあるのではないか。"3.9.9テスト技法の選択と組み合わせ"は熱い！
3.10 品質分析・評価の技法	△	知っているのは2割くらい
3.11 運用の技法	×	仮想化よくわかりません
3.12 保守の技法	△	コードクローン分析は保守の技法なのか？
3.13 使用性の技法	△	黒須先生の本を読もうかなと
3.14 セーフティの技法	×	安全とは一体うごごご
3.15 セキュリティの技法	△	テスト, これ以外に無いのかなと

SQuBOKを読んで良かったこと

どの知識領域をどれだけ知っているかを認識でき、どこを伸ばしてゆくかを考える機会ができました。 BOKでありポインタ集なので知識そのものが増えるわけではないのですが、知識を増やすためのキーをたくさん得ることができました。 キーというのは、用語・人名・書籍名・規格名のことで、SQuBOKを読む前はこれらのキーを全く知らなかったことを考えると、それだけでも収穫だと思います。

ソフトウェア品質マネジメントの歴史の中に日本の大企業や日本人が多く登場することも初めて知りました。 実は20年前の方がプロセス改善やマネジメントの面では力を入れていたのではないかとも考えさせられました。

また、少人数で集まって読むというスタイルは、SQuBOKを全て読むために欠かせないことでした。 一人では最初から最後まで考えながら読むということは、BOKに対してはできなかったと思います。 今でもSQuBOKを開くと読破会の情景や議論したことを思い出します。 この知識領域は誰が詳しかったなとか、あのトピックは意見が分かれたなとか。

主催者の言うように宝箱のような本なのかは読んだ今でもわからないのですが、 私の職務に関わる広大な知識領域において、有志の協力を得て無知の知を体験できたことは、とても貴重であることは間違いありません。

おわりに

あっさりとしたエントリにしようと思っていたのに結構書いてしまった！ SQuBOKV2読破会アドベントカレンダーはまだまだ続きます。 次は @Kazu_cocoa さんです。よろしくー

*1:私はQAではなくSEPGやSoftware Engineering Consultantの立ち位置です

*2:詳細は1日目のエントリーを参照

情報会議#3に参加してみて

情報会議

johokaigi.org

ソフトウェア開発チームの情報共有を扱う会に参加しました。 ちょうど最近チーム開発ツールに関する仕事をしていたところ、たまたまTwitterでPeatixの申し込みを見つけたのがきっかけです。 ただ、その時は既に満員で「満員かー」とツイートしたところ、主催者の@so1_さんから「キャンセル出たので参加しますか？」とリプライが来て参加することに。 そんなこともあるんですね。

グループワークでは幾つかの少人数グループに分かれて各々のお題について議論しました。 私がいたグループでは「情報共有ツールを導入する効果の定量化を求められてしまった」という悩ましいお題について考えました。 思い付きをポストイットに書いて貼っていくスタイルで考えたのですが、数名で前向きに考えると短時間でも結構アイデアが出てくるものですね。 アイデアは以下の5種類でした。単なる効率化では済ませないところが重要かなと思います。

• 指標を考える前にまず導入目的や期待するを明確にする
• どの程度利用されているかという指標
• 現在の仕事の効率化に関する指標
• 新しい価値に関する指標
• 定量化せずに済ませる荒業

主催者の一人がIncrements社員(Qiitaの会社)ということもあってか、参加者は事前にQiita:Teamでお互いを知ったり情報共有に関する議論を重ねていました。 Qiita:Teamに触ることができたのも良い収穫でした。

あと、@so1_さんから誘われてLTしました。5分なのでLightningな感じで喋りました。人前で話す機会は仕事含めてここ2年でぼちぼち増えてきたのですが、実はLTと名がつくものはやったことが無かったり。最短記録更新。(最長は3時間)

Joho kaigi#3lt from Masanori Kaneko

情報共有のスコープ

単にソフトウェア開発のための情報共有といっても、人によって思いつくものは違うと思うのです。 VCS,BTS,CIといったチームのためのエンジニアリングツールで行われる情報共有なのか、 プロジェクトマネジメントツールなのか、チャットなのか、メーリングリストなのか、wikiなのか、身内(社内)SNSなのか、対面の対話なのか。

情報会議がどこに主眼を置いているのか今でもよくわからないのですが、今のところは 純粋なエンジニアリングツールやプロジェクトマネジメントツールがカバーする情報というよりは、 ナレッジシェア、メンバーが欠けてもタスクが継続できるようにする、モチベーション向上…といったことをするための情報に 重きが置かれているのではないかという所感です。

この先、議論を進めるには共有したい情報とは何なのか、共有したいシチュエーションとは何なのかを具体的にし、 幾つかの典型例をもとに掘り下げてゆく必要があるのではないかと考えています。

情報共有ツールの利用に必要なメディアリテラシー

Webベースの情報共有ツールを利用するにはいくらかのメディアリテラシーが必要だと思います。

• フリーワード検索, 検索式
• カテゴリ, タグ
• @アカウント名 で通知
• いいね, thanks
• 個々人のアカウントごとにアイコンがある
• 全員でばりばり書く
• 共同編集する
• コメントをつける
• 編集履歴をつける
• 編集リクエストを送る
• Markdown などのテキスト記法
• リアルタイム性によるツールの使い分け
• チームメイトが喜ぶように/傷つかないように

これらはブログ・SNS・VCSを使用している人にとっては自然と身についていることだと思います。 しかしそういう人ばかりではないのではないでしょうか？ 日本でSNSはmixiとFacebookによって広まりましたが、そのうち構造のある文章をブラウザから書いた経験のある割合はどの程度なのか。 @masskanekoがアカウント名だとわかる人がどの程度いるのか。 書いが方が良いことと書いてはいけないことの区別をつけつつアクティブに使える人がどの程度いるのか。 そういったメディアリテラシーを学ぶ機会が必要だと思うのです。

大学や高専ではコンピューターリテラシーと呼ばれる授業があり、ファイルやフォルダの概念、文書作成、メール、インターネット検索エンジンについて学ぶ機会があります。 現在ではもしかすると情報共有ツールを円滑に利用できるだけのリテラシーを教えているのかもしれませんが、今の働き盛りの年代の方々を主な利用者とするのであれば 組織内での教育努力が必須なのではないかと思います。もちろん、そういった努力があまり必要でない組織もあるかと思いますが、それはかなりラッキーなのではないでしょうか。

次回参加するかどうか

情報共有そのものについて考えたのは初めてですが、浅くないなと思いました。 道具はもうあるんです。でもうまく使うにはかなり人間にフォーカスした努力を行う必要があるのだと思います。

当たり前ですが、情報共有ってツールが登場する前からも行われていたはずです。人間にフォーカスするのであれば歴史に学ぶのが良いのかなと。 Wikiが登場する前はどうしていたのか。 Web技術が無かった頃はどうしていたのか。 掲示板か。回覧板か。 実はタバコミュニケーションや飲みニュケーションのような昭和のアナログな手法でまかなっていた情報共有が現在の情報共有ツールの役目に相当するのではないか。 100年前はどうだったのか。

もちろん、テクノロジー面からのアプローチもまだまだこれから発展すると思います。 botが一週間のまとめ記事を作ったり、個々人の端末の画面やキー操作から困っているかどうかを判別したり、手首につけた社員証デバイスが今日の気分を読み取ってグループウェアに送ったり…。

そういう世界もあるなぁと思いつつ専門家になる気は全くありませんが、少なくとも身の回りのチームが円滑に仕事できるにはどうすれば良いかを考える機会として、次があれば参加したいと思いました。

長崎旅行記

なんでまた長崎に

8月12日 長崎SWQuality&DevelopmentGathering2015(長崎県) というイベントに参加することをきっかけに長崎に行きました。主催の池田暁さんと最近付き合いがあるのですが、池田さんが急に故郷への貢献に目覚めたらしく、誘われることとなりました。

今思い出しても、よく関東から長崎くんだりまで足を運んだものだと思いますが、「九州って行ったことないし、カステラでも食って返ってくるか。」くらいの軽い気持ちで行くことにしました。どうせ遠くへ行くなら何日か観光をしようと思い、5泊6日滞在することにしました。

とりあえず江山楼のちゃんぽんは美味しかったです。ちゃんぽんって、私の生活圏に出す店が無く、全く食べる習慣が無いのですが、これは時々食べたくなると感じました。

イベント本編と清水吉男さん

イベントのテーマが派生開発でしたので、XDDPやUSDMの生みの親である清水吉男さんの講演がメインコンテンツでした。無料のイベントなのに、よく来てくださったなぁと思います。

清水さんの講演は、基本的には著書の内容に沿ったものであり、そこに自身の開発経験・コンサルティング経験を交えながら要点を説明したものでした。USDM形式のように要求仕様を書くというのは、「計画重視のプロセスはソフトウェア開発に向いていない」という先入観があった私からするとあまり現代的な印象が無かったのですが、氏の主張である「大半は仕様の問題」「要求の裏にある理由は安定している」「良い要求仕様は良いソースコードを導く」を考えると、20年経っても通用するのではないかと思わされました。

ただ、その理解はまだ感覚的なものなので、USDMとユーザーストーリー、XDDPとXP、変更設計書とDesignDocについては、共通点と違いを理解しておきたいと思いました。

他のセッションでも興味深い話があったのですが、質疑の時間が十分でなかったのが心残りでした。

イベント後は長崎らしい料理を前に懇親会が行われました。魚だ。この街は魚がうまいんだ。

清水さんは非常にきさくな方で、氏の手法の話はもちろん、昔の開発経験、コンサルティング経験、一度は挫折した話、技術がいかに生産性を高めるかという話、大学教育の話、私のちょっとしたキャリアの相談など、色々なお話をすることができました。

市内めぐり

イベントの翌日は主催の池田さんが市内をめぐるツアーを組んでくださいました。

グラバー邸を軍服を着て歩いたり、孔子廟で華麗なやかんさばきを見たり、中華街で角煮まんやハトシを食べたり、出島で昔のビリヤードをしてみたり…など、記憶に残る観光をすることができました。観光できる場所が多い街というのは良いものですね。昔から海外との交流があった街というだけあって、文化的資料はもちろん、現在の建物や街並みにも特徴がありました。勿論、Ingress のポータルの数も多くありました。

長崎市街は路面電車が多く走っているのも特徴でした。私は路面電車には全く馴染みが無いので非常に新鮮でした。路面電車は昭和の産物なのかなと思っていましたが、この街では現役であり、市民の重要な交通網として動いていました。この旅行でも何回も利用した、ありがたい存在です。

(孔子廟で撮影した写真をうっかりデコってしまったもの)

(出島の施設にあった昔のビリヤード台。大きな耳かきのようなキューで玉を突き、立っている棒を倒すとか倒さないだとかのルールで競う。)

離島で釣り

あとの日は完全な自由行動です。釣り道具を持ってきていたので釣りをすることは決めていたのですが、どこで釣るのかを決めていなかったので、ホテルで調べることにしました。「どうせなら島に行きたい」と思って調べてみると "飛島磯釣り公園" という場所が、設備の整った磯釣り公園の割にはそこそこいい代物が釣れるという情報を得て、船に乗って行くことにしました。長崎港では高島との往復料金と釣り施設の入場料がセットになったチケットが売られており、2040円と思ったより安い値段でした。

飛島磯釣り公園のある高島までは、長崎港から伊王島経由で30-40分くらいだったでしょうか。甲板でビールを飲んで風景を見て眺めていたせいか、あまり長いとは感じませんでした。港から釣り施設へ向かうバスがあったのですが、道中を歩いて楽しむことにしました。

釣り施設への途中には海水浴場がありました。海はとてもきれいな色をしており、珊瑚の中を色鮮やかな小魚が泳いでいるのが遠目からでもはっきり見え、南伊豆や沖縄を思い出させるものでした。しかも、人はまばらで、思う存分泳いだり、砂浜で転がることができます。いいですね。海水浴場はこうでなくては。しかし、BGMとして「粉雪」がかかっていたのはしばらく忘れることができそうにありません。

いよいよ釣り場へ。磯釣り公園という名前がついているだけあって、足場がしっかりしており、竿を出せる場所も広いです。入口近くに小さな釣り具屋さんがあり、船のチケットを見せると入ることができます。ついでに餌のオキアミとアミエビも買いました。

オチから言うと、まぁまぁ釣れるのですごく楽しいです。施設の奥には、沖へ向かってのびる足場(写真)があるのですが、そこは水深が結構あります。人はあまりおらず、魚もスレていないようで、色々な場所に落とし込むだけでもアタリがあって楽しいです。

主な釣果は、カサゴ、メジナ、アイゴ、ハタの仲間と思われる何か、ノコギリダイ、ハコフグでした。他、名前のわからないものも釣れましたがわからずじまい。ホテルの冷蔵庫を生臭くすることは気が引けたので基本的にはリリースし、その日に食べる分だけその場で柵取りしました。釣り場の近くには水道があるので、そこでさばくことができます。

精霊流し

8月15日、高島から長崎市街に戻ると精霊流しが行われていました。そこら中で爆竹が鳴り響き、山車のような精霊船が引かれていく様を見ると、祭りにしか見えません。しかし、精霊船に取り付けられた遺影を見ると、爆竹の音もどこか物悲しく聞こえてきます。チリンチリンアイスを食べながら1時間ほど見ていました。

あくまで弔いであって見世物ではないのですが、その物珍しさからして観光的には見物する価値のあるものでした。爆竹の赤い箱ごと火をつける場合が通常で、中には問屋から卸したような爆竹詰め合わせのダンボールに火をつける場合もあり、音も煙もすごいことになります。YouTube でその様子を見ることができます。

平和公園

終戦記念日である8月15日に訪れようかとも思っていたのですが、ぼんやりと釣りができるくらい平和になったことを実感した方が終戦記念日らしいと思い、翌日16日に訪れることにしました。公園内はとても広く、多くの慰霊碑があり、それらを見るだけでも平和ボケした私の頭にも刺さるものがありました。

そんな場所でXMPバースターを撃つのは趣がありました。

いいところだった

ここ何年か、国内旅行というとスキーばかりでしたし、九州自体初めてだったということもあり、大いに楽しむことができました。街並み、歴史、海、魚介が好きなら楽しむことができると思います。

また、今回の行程は半分くらいは一人だったのですが、今まで一人旅はしたことがありませんでした。日本の中でも訪れたところが無い地方がまだまだ多いので、もっと気軽に旅行をしてみたいですね。

やり残したこと

カステラ食ってねぇ！