転職：2017

新卒で入社した車載システムの大企業に10年近く勤め、3つの職種を経験し、退職しました。最初はプログラマーで、次に企画職を少し、最後は複数のソフトウェア開発チームに対して技術支援をする職種でした。退職してから転職活動をし、巨大企業で研究開発をすることになりました。前職のキャリアと転職活動を振り返り、記すことにします。

自分にとってのキャリアの整理のために書くのですが、もしかすると似た境遇の人が参考になるかもしれないですし、公開する文章にした方が本腰を入れて書けるので、ここに書きます。時折見られる華々しい転職エントリとは異なり、凡人のキャリアについての文章です。社名は本旨には関係しないので載せていませんが、いくらか調べれば出てくるでしょう。

駆け出し：2007〜2008

私は大学で情報工学を学んでいました。学業では周囲に比べると劣等生で、あまり研究は好きではありませんでした。その代わりといっては何ですがDTMを何年か続けていて、音楽とコンピューター技術に関する仕事に就きたいと考えていました。といっても、それは漠然としたもので、特にやりたいことが明確になっていたわけではなく、「シンセサイザーやDJ機器を作るのがいいかなぁ」程度の気持ちで楽器メーカーやオーディオメーカーを受けました。確か5社くらい受けて、2社から内定を得て、1社は最終面接で不採用と判定されました。その不採用となった最終面接では、面接官から「あなたの希望する職に就けない可能性もあるが、それでもよいか？」と問われて『絶対にダメです。何のために応募したと思っているんですか。』と答えました。きっとそれが不採用の原因だと思います。

結局、入った会社でも第一希望の部署には配属されず、車載デジタルテレビの開発部門にてソフトウェア開発に5年半従事することになりました。この5年半で組込みソフトウェア開発の基礎を習得し、電機メーカーにおける企画・調達・開発・生産・市場投入・市場調査という流れも理解しました。学生時代には全く知らなかった調達部門・生産部門・品質保証部門の存在・役割も知ることができました。

ソフトウェア開発メンバーとして配属されたのですが、最初のタスクは意外にもテスト用のハードウェアの開発でした。その辺に転がっている水晶発振子と分周ICを使ってパルスを生むものでした。ユニバーサル基板上に実装し、ケースも作りました。これはハードウェア開発を行う会社らしいところですね。

ソフトウェアの開発では大学時代に学んだ知識が役立ちました。例えば、情報工学の知識は、マルチプロセスにおける同期処理の仕組み、デバッガ上に見えるレジスタの意味、論理回路の理解に役立ちました。また、ディジタル無線の知識も、性能測定やフィールドテストの際に役立ちました。

あまり自信がなかったのがプログラミングです。というのも、学生時代に書いたコードといえば、演習課題を除けば一番大きくて1000行程度のJavaアプリケーションしか開発したことがなく、ソフトウェア工学らしい知識も幾つかのUML図と簡単なユニットテストくらいしか知らなかったからです。ところが、プログラマーとして働くことは思ったより難しくなかったというのが開発に携わって間もない当時の感想でした。テクニック、ライブラリ、ツールの知識がさほど無くても仕事をすることはできました。むしろ職歴5年10年の先人が書いたソースコードを見て、「プロって意外と大したことないな」と思っていました。実際に先輩に対して「何年やってるんですか」と大人気なく煽ってしまったこともありました。

仕事にもある程度慣れてきた頃、あまり勉強せずとも周囲の開発者と同様に仕事ができることに疑問を感じました。というのも、学生時代に比べて本を読んで勉強しなくなったからです。「書店には沢山の技術書が並んでいるのに、それらを全く読まずとも仕事ができているのはなぜか？」「さすがに学部レベルの知識で仕事ができるのはおかしいのではないか？」と思いました。また、学生時代に周囲にいた人々の中には、フリーソフトウェアを開発したり、技術書を翻訳したり、国際プログラミングコンテストに出場するなどの能力のある人々がいました。そうした人々と自分たちを比べると「プロが大した事ないのではなく、周囲の多くのプロはプロレベルに達していないまま仕事をしているのではないか？自分もプロレベルに達していないのに気づかなかったのではないか？」という疑問がわいてきました。今振り返ると周囲の実力も自分の実力も適切に評価できていなかったと思いますが、当時はそう疑問に思ったのです。

駆け出しの頃を振り返ってみると、機能追加やバグ修正などの個々のタスクをこなすことはできていましたが、より良い設計をしたり、より快適な開発環境を整えたりすることはできていませんでしたし、ユーザーの利便性を考える機会も乏しいものでした。また、担当している範囲でしかシステムを理解していませんでした。特に2年目はほとんど成長できていなかった気がして、「このまま過ごしてゆくと技術が身につかず、仕事を選べなくなったり、楽しめなくなってゆくのではないか？」と危機感を覚えました。

プロを目指して学習：2009

それから、以下の目標を立てて学習することにしました。

  • (1) 開発対象のソフトウェアがどのような仕組みで動いているのかを自身の担当範囲にとどまらず全体的に理解し、時間さえあれば一人で全てを開発できるだけの技術を身につける。
  • (2) 組込みシステム開発、ソフトウェア開発に関する基礎的な公知技術を身につける。
  • (3) 身につけた技術は仕事で実践する。

といっても、あまり気合を入れて学習したわけではありません。学習のほとんどは業務時間中に担当業務の延長線上の活動として行いました。読んだのは、規格書、他の開発者が担当する部位のソースコードや設計書、ハードウェアの設計書、開発ツールのマニュアルです。読む中で知らないことが出てくると逐一検索して調べました。ほか、プライベートの時間でやる気があるときだけ技術書を読むようになりました。平均すると2ヶ月に1冊程度のペースだったと思います。1冊あたり2ヶ月かけて読んだのではなく、2ヶ月に1回程度読む気が出たということです。

また、この頃には既にIT勉強会文化があり、IT勉強会カレンダーのおかげで存在も知っていたのですが、独学で困らなかった、自分に合った勉強会を探すのは面倒だったという理由で行きませんでした。

実践：2010〜2012

システム全体の理解が進んだので、要求同士の整合性を考慮したり、不要になるコードを見つけて削除するなど、全体最適を目指した変更ができるようになりました。他の開発者の仕事を助けたり、全体的な指示をすることもできるようになりました。全てのソースコードの詳細を理解していたわけではありませんが、各コンポーネントの重要なAPIや変数は大体覚えており、全てのソースコードと要求仕様の対応は多少の時間があれば調べることはできる程度には理解していました。

また、ハイブリッドアジャイルに近いイテレーティブな開発プロセスを組み立てて、アーキテクトのような立場で開発をリードする経験を積むこともできました。誰もアジャイルという言葉を使っておらず、私もアジャイルを目標としていたわけではありませんでしたが、今振り返ると中身はまぁまぁそれらしかったと思います。

ほか、幾つかのツールの導入や浸透に関わり、積極的に使う経験ができました。私が新規導入を提案したものも、他者が提案して私が浸透に関わったものもあります。

公知の知識を仕入れて実務で応用する機会には、社内では比較的恵まれたのではないかと思います。ソフトウェアの規模があまりに巨大であれば (1)+(3) の目標は達成できなかったでしょうし、ツールや手法を実践する機会が無ければ (2)+(3) の目標も達成できなかったでしょう*1。技術によっては実践する機会に恵まれない場合もあり、最初は反対されましたが数ヶ月の実験と説得の末に実践できたこともありました。

大企業において複数の開発チームへ並列的に関わることができた最後の職種になって思うのですが、所属組織によって成長できる経験を積みやすいか否かが大きく異なるのではないかと思います。あのチームならもっと成長できたかもしれない、あのチームだったら成長できずに腐っていったかもしれない、といったように。得られた知識を仕事で活かせるかどうかは、自分たちの状況に当てはめて利点や必然性を見出す応用能力と、具体的な実施方法・コスト・評価方法などもまとめて計画を立てて提案する能力が必要なのですが、それが受け入れられるかどうかの因子は自分がコントロールできることばかりではなく、運もそれなりに関係するというのが実感です。

「勉強しても実践するのが難しい」「教科書と現場は違う」という意見を言う方々に時々出会いますが、私はそれらの意見とは真逆の経験をすることができました。エンジニアリングを勉強して得られた知識は、応用能力・提案能力・運があれば、会社組織のビジネスで実践することができると考えています。

思い返すと、ハードウェアを扱う領域ならではの面白さがありました。スマートフォンやPCなどの汎用的ではないデバイスで動くものを作るというだけでも心が踊りますし、おかしな映像が出てしまったり電源に異常が出てしまったりしたときもなぜか笑えましたし、故障品を調べていてアドレスバスのパターンが切れていたことに気づいたときは「そういうのもあるのか*2」と思いましたし、フィールドテストにて後部座席でデバッガを見つめながらおかしな挙動を見つけてその場でコードを書いて「さっきのところもう一回曲がってください」と指示して「またかよｗｗ」という会話をしたのも楽しい思い出でした。

次の道を模索：2012

開発職を5年続ける中で技術は向上したものの、プロダクトにも環境にも飽きてきました。そうした日々の中で、仕事の4分類：成長・支援・維持・再生 という文章を思い出しました。そして、「今の仕事は維持の仕事だ。成長の仕事をしよう。」と考えました。それまでの仕事はどう作るのかを考える仕事だったのですが、何を作るのかを考える仕事、更にはその自分で考えた企画に対してプロトタイプを作る仕事をやってみたいと考えました。今思うと、自分が主役になる実感を得られる成果を出したかったのだと思います。

そして、企画部門に異動しました。ここでの仕事は商品戦略に関わるため機密事項が多く、書けることはほとんど無いのですが、私は主に先端応用技術の動向を調査していました。内容によっては機能立案をしたり、商品戦略に反映させる仕事をしていました。英文を読む機会が多かったので良い訓練になりました。しかし、この部門にて自分の望むやり方で仕事をするには、複数の部署をまたいだ大幅な体制変更をする必要があり、それは自分にとっては到底マネージできない問題であり、そこに時間を費やすのはもったいないと判断して、1年足らずで企画部門を去ることにしました。事前の内情調査不足だったと反省しています。

転職か、異動か：2013

このとき転職を考えました。転職するかどうかは決めていませんでしたが、自分の市場価値を測るために何社か受けてみて、良い条件であれば転職しようと考えました。結果、数社の他業界の会社を受けて、1社から内定を得られました。同時に、社内で異動する話も進めており、迷っていました。業務内容、残せそうな成果、得られるスキル、給与、勤務時間、居住地、ビジネスモデル、財務状況などの条件を比較して考えると、転職するメリットはそれほどないと判断して、異動することにしました。この選択が妥当だったのかは今でもわかりません。どちらの選択肢にも、満足/不満足どちらの可能性も相応にあったと思います。

Software Engineering Consultant：2013〜2016

異動先、つまり前職の最後の所属部署は、複数のソフトウェア開発部署の技術を向上させる責任を持っています。この分野のスキルに関してはプログラマー時代にある程度身につけており、組織的な技術向上の実績もあったため、即戦力人材としてリーダーシップをとって遂行してゆくことになりました。特定の製品・特定の開発チームに所属せず、複数の製品・複数の開発チームに対して技術支援・問題解決をしてゆくのは新鮮でした。この職種は Software Engineering Consultant と呼ぶのが適切でしょう。*3

大きく分けて、1.コード解析ツールの全社的普及、2.テスト分析・設計手法の確立と普及、3.開発環境刷新、4.教育 という4つのことを行ってきました。多くは自分で立ち上げた仕事です(他にお蔵入りになったプロジェクトもありましたが)。この部署には3年在籍し、そして退職しました。実績を振り返ると「3年でこれだけか」とも思いますし、「まぁまぁできたかな」とも思います。自分にもっと能力があればできたことは他にもあっただろうなとも思いますし、能力があったとしても結果は変わらなかったかもしれないとも思います。

Software Engineering という技術に向き合う仕事柄、より多くの公知の知見を仕入れる必要が出てきました。以前よりも本を読むようになったり、学会やシンポジウムなどでの発表資料や論文を読んだり、JSTQB Foundation Level というソフトウェアテストの基礎的な資格を取ってみたりしました。

他社の方々と交流する機会を増やし、自身のレベル、自社のレベルを測るようにもなりました。いくらか発表する機会もありました。

そこそこ合っていた仕事かなと思います。

退職

退職した理由はいくつかあります。

  • 人生は一度なので、他の世界も身をもって知りたい。(長く居すぎたと思った)
  • もっと興味のあるプロダクト、未来を担うプロダクトを作りたい (そういうプロダクトばかりではなかった)
  • 開発する機会を増やしたい (技術と知識の幅は広がったが、根幹となる作る力が落ちてしまった。)
  • 自分の伸ばしたい能力に関して、自分よりも秀でた人が沢山いる環境に身を置きたい。(そういう人は少なかった。それぞれ長所はあるが方向性が違う。)
  • 収入をのばしたい。(成果に見合った額はもっと高いと思った)
  • もっと海の近くに住んで気軽に釣りに行けるようにしたい。(そうするには微妙な地域だった)

全てを満たせる選択肢があるかはわかりませんが、前職では多くを満たせないと判断しました。

入社当時は10年近くも働くとは思っていませんでした。1つの部署だけでなく、自分で希望して3つの部署・職種を経験できたのは他の社員と比べて恵まれたと思います。社内という内輪の中とはいえ、自分の能力を売り込んで異動して、経験・実績を積むことができました。特に、IT・ソフトウェアという好きな分野を基軸にして楽しめる仕事ができたのは喜ばしいことでした。

転職

在職中に次の職を決めるのがセオリーらしいのですが、ものぐさな私はなかなか本腰を入れて活動できず、転職せざるを得ない状況にするために、先に退職することにしました。

希望条件は退職理由から導いた条件が中心ですが、転職活動をする中で明らかになっていった条件もあります。大まかには以下に分けられます。

条件種別 例
プロダクト 自分が使いたいと思えるプロダクトか？未来を担うプロダクトか？
実績 成したいことができるか？公開できるか？
スキル 身につけたいスキルを習得できそうか？既に身についているスキルを活かせるか？
労働環境 労働時間が許容範囲か？便利なグループウェアがあるか？服装などの非合理な規定が無いか？自分が改善してゆけるのか？
勤務地 周辺の家賃相場は？家族や既存の友人に会いに行ける距離か？
収入 希望額以上か？上記条件の充足具合によって変動。

これらの条件種別ごとに詳細な条件を設け、希望・前職・応募先企業を比べる表を作りました。また、前職の方が良かった条件というのは気づきにくく、応募先企業について調べる中でわかってきました。私は複数の条件のバランスを考えたので結構迷ってしまいました。「金だよ金！」みたいに1つの条件だけで選べるなら楽だなぁと。結果、前職よりも複数の条件について改善するポジションのオファーを得られました。

企業・ポジションを探すにあたり、いくつかのサービスと転職エージェントに頼りました。以下、それぞれについて感想を書きます。他の方には当てはまらないところもあるでしょう。

  • LinkedIn
    • 外資企業を探すのに役立ちました。Job Description が明確に示されている場合がほとんどで、選びやすかったです。
    • メッセージの9割は転職エージェントから。全て大手外資系企業における前職同業のポジションの紹介で、異業種へのお誘いは皆無でした。
    • 国内大手企業も中にはありますが、自分が探している業種・職種についてはほとんどが外資でした。
  • Wantedly
    • 国内新興企業が多く、自分が知らない企業を知るのに役立ちました。
    • メッセージもそれらの企業から来ます。プロフィールを読んでいると思われるものばかりでした。
    • 転職エージェントからのメッセージが一切無かったのは好印象でした。
    • メッセージの数は LinkedIn に比べるとかなり少なく10分の1程度ではないかと思います。
    • LinkedIn と同じ使い方をすることもできますが、話を聞きに行きたいボタン、社員個人に焦点を当てた文章があるなど、別の価値があると思いました。
    • リアルウォンテッドリーにも1回行ってみました。参加企業の方から「サーバーですか〜？フロントですか〜？」と開口一番に話しかけられ、ウェブしか見てない視野の狭い人達がいるものだと落胆したのを覚えています。 イベント自体は良い機会を得られるものだと思います。
  • ビズリーチ
    • メッセージの8割は転職エージェントからです。
    • LinkedIn とは対象的に全て国内企業の紹介でした。
    • 大手が多いですが、中にはスタートアップもありました。
    • LinkedIn が日本に普及できていない部分を埋めるようなサービスで、存在価値を感じませんでした。ビズリーチを利用している企業は全部 LinkedIn に乗り換えて欲しいと思いました。
  • 転職エージェント
    • エージェントとの最初の接点はLinkedIn かビズリーチである場合と、私のメールアドレスに直接連絡してきた場合がありました。
    • 転職あっせん会社/エージェント個人によって扱っている業界が異なることがわかりました。
    • 業界/企業によっては転職エージェントに頼らないと知り得ない非公開求人があることがわかりました。
    • どのような企業/ポジションを探しているのか、詳細に伝えた方が良いです。「詳細な条件を書くと該当する求人が無かったりわがままと思われるのではないか？」などと尻込みをする必要はありません。でないと全く興味のわかない企業/ポジションを紹介される可能性が増えます。
    • レジュメの書式についてアドバイスを頂くことはありましたが、スキルと求人要項を照らし合わせて合いそうか否かについてコメントして頂けることはありませんでした。
    • 転職エージェントはあくまで転職のあっせんをする役割で、キャリアアドバイザーではないと思いました。

選考方法はそれぞれです。レジュメについて深掘りする質問をされたり、技術の筆記試験があったり、ソースコードを書いたり、プレゼンテーションをしたり、その事業の・部署の現実の問題について「あなたならどうする？」と相談されるなど。印象に残っている質問は「○○(技術名)についてあなたが複数回経験した技術的な問題と、その対策を教えてください。」というものです。「その技術の実務経験があるならそれ特有の問題を経験しているでしょ？その問題に複数回ぶちあたっているならば対策も考えますよね？」という意図なのでしょう。ほか、基礎知識を問う質問に答えられずに落ち込むこともありましたが、復習の良い機会ととらえることにしました。

転職活動をして強く感じたことは2つあります。

1つは、業界や企業によって求人情報や社員個人が発信する情報への辿り着きやすさが異なることです。ここ10年で誕生した/台頭した企業や一般向けウェブサービスを手がける企業では、公式採用ページに Job Description が書かれていて、Wantedly にも載っていて、技術ブログが運営されており、SlideShare などで発表資料が公開されている傾向があります。また、社員のブログやTwitterアカウントも探しやすかったです。対して、それ以外の国内の大手企業、特にtoB事業が中心の企業になると、転職エージェントに頼らないと求人情報に辿り着けず、Job Description が曖昧という場合が多かったです。大手やtoB事業中心の企業でも外資になると、LinkedIn がある分いくらかオープンであり、Job Description もはっきりしていますが、それでも転職エージェントに頼らないと知り得ない情報があると思いました。*4

もう1つは、自分の居る業界/企業でスキルを高めても他の業界/企業では通用するとは限らないことです。と言うと当たり前なのですが、私は本業で即必要となるスキルと、少し先で必要となりそうなスキルしか得ておらず、それを何度も感じることになりました。また、業界を問わなさそうな共通スキルについても、面接の場で直接言われたわけではないのですが「我々は、あなたが解決してきた課題を既にクリアできている。それ以上の進歩を生み出してゆけるか？」と問われたと感じることが何回かありました。これについては、これからのキャリアでなんとかする必要性を感じました。*5

これから

これまでの組込みシステム中心のキャリアから一転し、主にサーバーサイドを相手をすることになる予定です。 ちょうど別の開発経験を積みたいと考えていたところであり、プロダクトも挑戦的なものです。 また、学会・シンポジウムでの発表やOSSなどで、公開できる成果を出していきたいですね。 最初のうちは要素技術と向き合うことに多くの時間を費やすことになりそうですが、ユーザーとプロダクトのことも意識的に考えてゆきたいと思います。

前職よりも複数の条件について改善するポジションのオファーを得られたと先述しましたが、それはつまり改善されないことも中にはありそうだということです。また、新たな希望や悩みを抱くかもしれません。なので、長くやってゆけるかはわかりませんが、まともな成果を出すまでは続けようと思います。

不安はあります。でも、まずは変化を楽しんでゆくつもりです。

*1:目標(1)(2)についてはもっと突き詰める余地はありましたが(3)はできたので良しとしています。自分に甘いスタイル。

*2:漫画"孤独のグルメ"の名台詞。

*3:SEPG: Software Engineering Process Group という呼称もありますが、Group というのは職種ではないというのと、日本においてはSE, PGが職種を指すのでわかりにくい呼称だと思います。

*4:Qiitaも同じように書き手や技術分野に業界の偏りを感じる。というのは別の話。

*5:「IT業界」なんて、ないんだよ。 を思い出しました

モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8

SQiPシンポジウム2016に参加し、SIG(special interest group)と呼ばれる特定のテーマについて議論やワークショップなどを開く場の一つを主催しました。テーマは モダンなチーム開発環境を追求しよう というものです。 www.juse.jp

開催の動機

チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012〜2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。

SIGの内容

SIG開催の動機はSQiPシンポジウムでの発表数が少ないことでした。それを確かめるため、数名ごとのグループディスカッションで参加者の抱える問題・関心と、サーベイによって参加者の所属組織の状況を明らかにすることにしました。また、それらを行うにあたり、技術の概要や用語の認識を共通化すべく、簡単な講義をしました。

SIGの時間は100分です。ほとんど余裕はなく、議論が問題の解決方法にまで踏み込む時間はありません。それでも参加者にとって価値があるだろうか？と考えたところ、新しい知識や複数の会社組織のことを断片的にでも知る機会には価値があるだろうと考えました。また、サーベイやグループディスカッションの結果をSlideShareやこのブログで公開したり、次回のSQiPシンポジウムでの発表を奨めれば貢献の幅も少しは広がるだろうと考えました。

講義

最初の講義ではチーム開発とは何か、何のために行うのか、どのような問題がよくあるのか、モダンとは何を指すのかについて説明しました。

まず、何のために行うのかの理解を得ることが重要なのですが、私は 快適さと正確さを両立したワークスタイルを実現するため だと考えています。その結果、ソフトウェア品質に寄与するという考えです。定型的な連絡や作業はできるだけコンピューターに任せることで開発者も管理者も快適さを得られます。作業内容や作業間の整合性を記録するのにもツールを使えば正確に行うことができます。その結果、知的作業に割り当てられる時間が増え、保守するための情報が得られ、価値あるソフトウェアを迅速かつ継続的に行えるようになると考えています。

欠かせないツールについても説明しました。個々のツールを揃えるだけでは不足で、連携させることが重要ということを説明したつもりですが、もう少し強調すれば良かったなと思います。ツールがどういう変遷を辿り、2016年におけるモダンとは何か、なぜモダンに焦点を当てるのか、それらの情報はどこから入手するのかについても説明しました。単に新しいツールを使おうと言っているのではなく、どういう解決の選択肢があって、それらがどのように・どのくらいのスピードで進化しているのかを把握し、選択することが重要というのが"モダンな"というところの主旨です。

チーム開発環境が無いとどのような問題があるのか、モダンなツールがあったとしてもどのような問題があるのかについても説明しました。ソースコードの上書き・Issueの未クローズ・Pull Requestのレビューがザルなどのお馴染みの問題に加え、ウェブアプリケーションとインフラの運用問題についても触れました。ここは知る限りあまり触れられていなかったところだと思います。

こうして次のサーベイとグループディスカッションのための知識を整理しました。

サーベイ

参加者の職場の状況を調べるサーベイは7問3択の形式です。設問と回答は上記スライドの後半にあります。以下、設問ごとに問う意図と回答に対する感想を書きます。

Q1はバージョン管理システム(VCS)に関する設問です。集中型が2/3と多数派、分散型が1/3という結果になりました。何ヶ月か前に参加したアトラシアン主催のイベント*4では100名以上の参加者数に対して「GitHubを使っている方？」「Bitbucketを使っている方？」という挙手を問う質問に対し、パッと見で6割以上の方がどちらかに手を挙げました。そことはだいぶ違うなというのが率直な感想です。

Q2は課題管理システム(ITS)に関する設問です。16名中7名の方が「ITSを使用しているがVCSとは連携させていない」と回答しました。ここをクリアするだけでもかなり改善の余地がありそうです。

Q3はGitHubなどのリポジトリホスティングツールに関する設問です。評価も含めて使用していると回答したのは16名中5名でした。Q1で分散型VCSを使用していると回答したのは5名なので同じ5名なのでしょう。つまりリポジトリホスティングツールを使わずに分散型VCSを使用している方はこの中にはいないということが推測できます。一方、「よく知らない」と回答した方も5名いて、VCS/VCS hostingについては各人(各社)の開きを感じます。

Q4は運用環境(自社オンプレのみ or クラウドも含めて検討)に関する設問です。自社オンプレのみという方が圧倒的多数でした。総務省の調査によると日本ではクラウドサービスを利用する企業は少数派のようですが*5、ここにもそれが表れたのかと思います。特にクラウドを推奨する意図がある設門ではありませんので、選択肢cは「クラウドを含めて選択」としています。それでも自社オンプレに偏っているところを見ると、クラウドを利用した方が良いケースでも利用できていないのではないことが懸念されます。

Q5はユーザーアカウント管理について、個別管理かLDAPなどを使用しているかを問う設問です。地味ながら効いてくるところと考えて設問に加えました。結果は半々です。できないのか、知らないのか、やらないのかは、後のグループディスカッションでも明らかにはなっていませんが、「システムは色々立ち上がっているが管理が全部個別で面倒なことになっている」という意見がありました。

Q6は運用人員に関する設問です。小さなチームであれば開発者が開発業務と兼任するすることも考えられますが、人員数が増えて開発環境のシステム数も増えると開発の片手間ではできなくなってきます。保守だけでなく教育のコストも増えていきますし、そこがかさむと拡張・新規導入に支障が出てきます。16名中4名が「専任の人員を割り当てている」と回答しました。

Q7は開発環境のトレンドを把握する情報源に関する設問です。知ることは改善のきっかけなので、最も重要な設問だと考えています。半数の方が書籍やウェブから能動的に情報収集していることがわかりました。特にチーム開発ツールについてはOSSも多いですし、商用ツールでもGitHub EnterpriseやJIRAの情報も結構ありますし*6、少しずつ進化してゆくものなので能動的に追ってゆくのが良いと思います。

グループディスカッション

講義とサーベイを踏まえ、参加者それぞれの組織で抱えている問題をポストイットに書いて分類することを、4人x4グループで行いました。 問題の解決策を議論する時間はありませんでしたが、参加者それぞれの組織ではどうしているかなどをざっくばらんに話しました。

以下にポストイットに書かれた問題を列挙し、私が聞いた議論の内容と合わせた所感を書きます。文面はできるだけポストイットに書かれたものをそのまま書き起こしています。チーム開発の技術分野ごとに分類しています。

課題管理(ITS)に関する問題

  • BTSが内製で他のサービスと連携できない
  • バグトラッキングはGoogle spread sheet
  • Redmine, Mantis... と複数のBTSがあり、情報が分散している。
  • BTSのカスタマイズが非常に難しい
  • Redmine スキル. 使いこなせてない
  • ようやくJIRA導入。→どう運用しよう？
  • ITSでレビューが止まってボトルネックになることが時々ある
  • BTSで不具合がクローズされないままになってしまう

サーベイQ2の結果と同じく、導入をしているがうまく使えない、VCSと連携できない、導入していない、という状況に分かれているようでした。 カスタマイズやワークフローの話が多く出ましたが、ここはそれぞれ問題が異なりそうなので、1つ1つ掘り下げることができそうです。 "BTSが内製で他のサービスと連携できない" 問題については他所でも聞いたことがあります。よくあるのかもしれません。

バージョン管理, リポジトリホスティング, コードレビューに関する問題

  • コードレビューする文化がない
  • プロジェクトマネージャーがC++コードを読めない
  • VCSを使ったことがない開発者がいる
  • バージョン管理システムが複数ある(VSS, Integrity, SVN)
  • SVNからGitへの移行が進まない。
  • リポジトリホスティングツール(GitBucket)の利用が進まない
  • 社内に集中型VCS, 分散型VCSが混在していて統一できていない
  • GitLabを導入したがまだ活用できていない
  • レビューの基準が？
  • ドキュメント管理がリリースバージョンと連携していない
  • SVNのブランチ構造がプロジェクト毎にバラバラ
  • SVN, merge 戦略
  • 集中型VCSのためグローバル開発でsyncに時間がかかる
  • SVNで設計書が管理できてない(一部電子化されていない)

この分類では最も多く挙げられました。SVN, Gitが主流のようですが、VSS, Integrity という名前も挙がりました。Pull Request を使ったワークフローを回している方はかなりの少数派に見受けられました。ソースコードだけでなく、文書のバージョン管理も話題になりました。

CIに関する問題

  • JUnit が定着しない
  • テストを自動化していないのでCIツールをのせるメリットがない

CI そのものについては問題が挙がらず、CIのジョブである自動テストに関する2件のみとなりました。 CI以前に問題があると考えている方が多かったのかもしれません。

Chat, コミュニケーションに関する問題

  • 開発さんとどのように情報を共有するとやりやすいのか知りたい
  • 営業部門の書くWikiが汚すぎる
  • ChatOps できていない

開発以外のチームとのコミュニケーションに関する問題が出ました。 何を共有すれば良いのかはツールでは解決できませんが、素早く正確に伝える、いつでも聞けることについてはツールが役立つと思います。 Wikiについては、所定の形式でテキストを書いて別途レンダリングするという点がWordなどと異なりますので、トレーニングが必要なのだと思います。

テスト管理に関する問題

  • テストケース一覧がExcelで、バージョンごとにExcelファイルのコピーが増殖していく。
  • テストケースの実行結果がExcel管理なので集計が面倒。

私は事前に全く想定していませんでしたがテスト管理に関する問題が挙げられました。TestLink や Quality Center の領域なのでしょうか。 経験がないのでわかりませんが、ウェブアプリで他ツールとの連携もできるようなのでテスト管理もチーム開発の一部とするのが良いかと感じます。

インフラに関する問題

  • 運用が大変で導入できない。(インフラ的に)
  • シェフとか？環境構築
  • アカウント管理がバラバラ
  • 運用がボランティアベース
  • クラウドのセキュリティ
  • オンプレの運用
  • 国内に全サーバーがあるので海外からのアクセスが遅い
  • 開発環境の管理をソフト開発者が兼任しているので時間が見積もれない

インフラの問題は多く挙げられました。 無償のOSSツールを使えば構築は簡単なのですが、継続的に運用してゆくには課題があるようです。 SQiPシンポジウムでは製造業(組込み)の方々が比較的多いので、ウェブアプリケーションのためのインフラについては あまり強くないという背景がありそうな気がします。(本SIG参加者の所属企業・業界は把握しておりません)

ツールや技術分野によらない問題

  • 品質保証としてソースコード管理などに踏み込めていない
  • どのような状況で開発が行なわれているのか知りたい
  • 社内とプロジェクト(顧客先)で同じツールが使えない
  • 直近の開発業務を優先するため、改善の工数をなかなか確保できない。
  • ブログなど外部情報のアクセスが制限されている。
  • 運用ルールが決められず導入以前。(チーム内/プロジェクト内で)
  • 使用するツールの選定方法
  • 新しいツールに移行するとしてどうやって
  • 新しいものを導入しようとしても権限がないのでインストールできない
  • ツールがカオス：GitHub vs GitLab vs SVN, Redmine vs JIRA (ボトムアップでいろいろ")
  • エクセルから離れられない
  • 新メンバーの学習時間
  • 運用ルールの定義
  • メトリクスは可視化されているが技術的負債が増えていく

その他、チーム開発に限らず、新規技術の導入方法、情報収集、改善の問題が挙げられました。

特に「どうやって浸透させて行くのか」については関心が高いようで、個別に質問を受けました。 ボトムアップであれば、まず環境を立ち上げて動かす→新しもの好きの数人に利便性を実感してもらう→チームとしてトライアルすることに合意し、ルールであれば使う層(多い)に拡大する→最後に、合わない・移行したくない層を何とかする…というのがパターンかなと思います。 トップダウンでチームの公式ルールとする場合は浸透は早いのですが、利便性を体感できるような運用ルールを早く備えないと反発を招いて一気に下火になったり、使用しても効果が上がらない恐れもあると思います。

総括

SQiPシンポジウムの参加者層においても、チーム開発技術の需要・改善の余地はかなりあるという実感を得られました。参加者の方々にとっては、解決策を得る場ではなかったものの、ヒントが得られたり、関心が高まったのではないかと思います。

私はこの分野のエキスパートというわけではなく、参加者層の所属組織での関心・採用している技術にもバラつきがあることを想定しましたので、どこに照準を合わせて本SIGのプログラムや講義内容を組むかを迷いました。結果的にはこれで良かったかと思います。また、サブタイトルにある "快適さと正確さを両立したワークスタイルの実現に向けて" というメッセージはもう少し伝えられる余地があったかと感じます。

私のSQiPシンポジウム参加回数はこれで3回です。2014年は一般聴講、2015年に論文発表、そして2016年はSIG主催となりました。SIG主催は論文発表とは違って100分を自由に使って価値を提供することを考えることになり、良い経験ができました。来年は何をするか、何もしないかは未定です。

最後に次回シンポジウムでの発表をお勧めしておきました。これで発表者が出れば本SIGは大成功です。

参加者の皆さん、シンポジウム事務局の方々、ちょっと強引な誘いにも関わらず引き受けてくれたサブリーダーの三浦さん、ありがとうございました。

*1:http://gihyo.jp/book/2014/978-4-7741-6428-1

*2:http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=002372

*3:何に取り組むのかはもちろん組織やプロダクトのコンテキストやエンジニアの興味によるが、私ならSQiPシンポジウムで投稿数の多いテーマである "テスト", "メトリクス", "欠陥分析" よりもチーム開発を優先する。といっても私は2015年にテスト分析手法の論文を書いているので説得力がない。

*4:http://atlassian.connpass.com/event/31664/

*5:http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h26/html/nc254110.html

*6:対して、IntegrityやCoverityやEnterprise Architectなどのいかにもな商用ツールの情報は、カンファレンスやベンダー/代理店からでないと手に入らない。

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

最近になって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 などを使用しています。

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

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

software development

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らしからぬ強い主張が含まれた長めの文章があります。

f:id:masskaneko:20151212232938j:plain

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

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

ソフトウェア品質知識体系ガイド -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日目のエントリーを参照