モダンなチーム開発環境を追求しよう : 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 の導入事例が報告され*2SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、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 などを使用しています。

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

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

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日目のエントリーを参照

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

情報会議

johokaigi.org

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

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

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

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

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

情報共有のスコープ

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

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

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

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

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

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

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

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

次回参加するかどうか

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

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

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

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