読者です 読者をやめる 読者になる 読者になる

>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

Appium に Permission to start activity denied と言われるとき

システムテスト自動化

Activity なので、Androidの話ですね。IDEからAppium経由のテストを実行するとき、コンソールで、"Permission to start activity denied" と怒られることがあります。そんな時は以下を確認。

  • 開発者オプションの "USB経由のアプリを確認" をDisableにしているか?
  • AppiumGUIの方で Wait/Launch Package/Activity のチェックが外れているか?
  • そもそも adb shell am start -n YourPackage/YourActivity として起動できるか?

僕は2番めを引きました。

テスト自動化に関する翻訳本の出版

システムテスト自動化

システムテスト自動化 標準ガイド」という本が12月16日に翔泳社様より発売されます。

システムテスト自動化 標準ガイド (CodeZine BOOKS)

システムテスト自動化 標準ガイド (CodeZine BOOKS)

  • 作者: Mark Fewster,Dorothy Graham,伊藤望,玉川紘子,長谷川孝二,きょん,鈴木一裕,太田健一郎,テスト自動化研究会,森龍二,近江久美子,永田敦,吉村好廣,板垣真太郎,浦山さつき,井芹洋輝,松木晋祐,長田学,早川隆治
  • 出版社/メーカー: 翔泳社
  • 発売日: 2014/12/16
  • メディア: 大型本
  • この商品を含むブログを見る

 「テスト自動化研究会(通称 STAR)」という、システムテストの自動化についてそのスキルの定義や方法論の研究を行っているグループの共訳/共著で、僕は9章を担当しました。

 9章は「その他の課題」という、一見ぞんざいなタイトルですが、自動化の優先度、ツールとのつきあいかた、テスト容易性の導入、など、なかなかどうして、興味深いトピックを扱っています。

システムテスト

 ソフトウェア開発の現場ではしばしば、いろいろなテストの種類/区分が混同されます。今回敢えて掲げている「システムテスト」も、そんな混同されやすい区分を整理する概念である「テストレベル」の一種で、ユニットテスト、インテグレーションテストを通過したあと、一体のシステムとして動作する状態で、提供側によって実施されるテストを指します。現場によっては、UIテスト、テストチームでのテスト、QAテスト、Lテスト、などと呼ばれることがあるかもしれません。

書き下ろしも!

第二部、書き下ろしパートでは気鋭のテスト自動化エンジニアによる実践事例も掲載!ご期待ください!

組織や社会の不条理がだいたい腑に落ちるオペレーションとイノベーションのはなし

雑感

オペレーションとイノベーション

 ここ数ヶ月、価値観を大きく拡げる概念について発見があり、思索を続けていたので、ここに書いておく。

f:id:shinsuku:20141113184954j:plain
出典: 忍び寄るイノベーションの危機 小林三郎=中央大学 大学院 戦略経営研究科 客員教授(元・ホンダ経営企画部長)

オペレーション

 「オペレーション」は95%以上の確率で成功することが求められる仕事。成功率を下げるイレギュラーな変更は原則受け付けられない。それは彼らのミッションを阻害する。高確率で成功させて当たり前、成果としてはそれをどれだけ効率よく(低コストで)遂行できたか?である。


 世の中が安心安全に回っているのはこの種の仕事がほとんどだから。
 大事なことだから2回言う。
 世の中が安心安全に回っているのはこの種の仕事がほとんどだから。


 95%程度の成功率は、例えば人事、総務、経理等の管理系業務が該当する。日本では彼らは99%以上の確率で仕事を成功させているはず。スゴい。日本以外でも、技術の進歩によって98%ぐらいの確率で成功させているのではなかろうか。オペレーション仕事の最右翼は航空や鉄道、役所などの公共機関であろう。一般的に融通が効かないという印象があるが、もし仮に「当飛行機は99%の確率で成田まで到着します」と言われたらどうか。100回に1回は墜ちるような精度であなたは満足できるだろうか。彼らが高精度で業務を遂行していくれているからこそ、そこを心配しなくても社会はまわるのだ。


 f:id:shinsuku:20040516174426j:plain:w400


 「オペレーション脳」の信条は「みんながルールを守れば社会全体が幸せになる」である。社会全体を幸せにするためという大義に則り、ときに他人にルールを守ることを強要する。彼らは秩序をもたらすことで、利益を社会全体がなるべく公平に享受できるように努力する。最も効率的で、ある意味「賢い」。しかし、仮に社会全体がオペレーション脳であったら、外敵や自然による強制的なルール変更に対応できない。ダーウインに尋ねるまでもなく「最も強い種や最も賢い種ではなく、最も変化に強い種が生き残る」のだ。これはイノベーターの仕事である。

イノベーション

 「イノベーション」はまず10%も成功しないが当たるとデカい、会社や社会に変革をもたらすレベルの仕事。これを成功させた組織や個人は、いかにも最初から狙い澄まして、脇目もふらずにこれを成し遂げた、という演出が部外者によってされることが多いが、おそらく輝かしい業績の影にはその10倍近くの失敗プロジェクト、理解を得にくい努力があったハズである。

 イノベーション仕事は前例がないがために分析や論理が基本的に通用しない。常識的なやり方も、適用できる部分とそうでない部分を直感で見極めながら進めなければならない。

 ある個人の強烈なビジョンと実行力によって生まれた製品が世の中を少し変革し、それをエネルギーにまたビジョンが強化されていく。自分を天才と信じつづけることが出来る人が天才である、との定義にそえば、自らのビジョンが世の中を変革すると信じ続けることが出来るかどうかが成功の大半を左右するこの仕事は、ただしく尊称としての天才しか成し得ないのかもしれない。

 イノベーションが無ければ組織や社会は徐々に(比較的に)衰退していく。1人の天才のかげに9人の"足り得なかった"天才がいるはずである。その9人を必要経費と出来ることが、社会や企業に求められる度量であろう。


f:id:shinsuku:20100310060539j:plain:w400


 「イノベーション脳」の心情は「いいから黙って見てろ」である。求められない限り、いかなる口出しも手出しも、彼らがいずれもたらす(かもしれない)社会利益に対する障害、あるいは成果を矮小化するものでしかない。社会に適合した者から見ると、彼らの言動は酷く幼く、もっと言うとバカに見える。賢い方法があるのに従わない=バカである。もし仮に、社会全体がイノベーション脳であったら、社会は9割のゴミと、1割のなんだかよくわからないけれどキラキラしたもの、で埋めつくされる。その価値を正しく理解したり、それを社会に適合させてみんながその価値や利益を享受できるようにしたり、それが出来るだけ長く続くような努力を、誰もしない。これは、オペレータの仕事である。

何が腑に落ちるのか

 あなたはどちらに属するだろうか。筆者の性格はどちらかというと後者寄りであるため、すこし偏った書き方になってしまっているかもしれない(なお、"得意"なのは前者である)。

 社会や組織が行き詰まるとイノベーター待望論が台頭する。そんなときにこれまでのオペレータの努力をおろそかにしてはならない。彼らはあなたの成果を最大化し、持続させる。

 社会や組織が勝ちパターンに入るとオペレータが台頭する。そんなときに身近に見かける「何かに挑戦しているバカ」*1をどうかそっとしておいてほしい。彼らはいつか必ず来る変化を打ち破り、次の勝ちパターンを構築する。

 自分が属していないほう、の人たちの価値を理解することで、彼らの行動や価値観が腑に落ちる、という話。

*1:挑戦していないバカ はオペレータに転換してもらうべき

技術の進歩は「螺旋」である。 @t_wada さん社内講演

こんぴた的な話 雑感

先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。
題して「この先生きのこるためには」*1

f:id:shinsuku:20140424150843j:plain:w400

第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。

エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。

新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。

技術の進歩は「螺旋」である

f:id:shinsuku:20140426193259j:plain:w300

今回最も衝撃を受けて、かつ個人的なブレークスルーになったのがこちらのトピックでした。この業界、基本的に後発有利でして、純粋な実装の能力に関しては、技術が洗練されていく点、学ぶ環境が整備されていく点において若いほうが有利です。年代的にちょうど若者とおっさんの中間地点におりまして、職制はラインマネージャ、職種はQAでありながら純粋実装技術でもそうそう劣りたくないワガママな身としてかなり焦っていたのですが、ようやく戦うすべを得られました。

外から見ると「振り子

中央集権システムと分散システムの例が最もわかりやすいかと思います。1980年代に全盛を誇ったメインフレームシンクライアントの関係は、その後のパーソナルコンピューティングへの流れを経て、再度「クラウド」という言葉で揺り戻って来ています。ソフトウェアエンジニアの外からみれば「それ30年前にあったやん」と思えるかもしれませんが「ホストコンピュータ&シンクライアント」と「クラウドコンピューティング」の間には、wwwの台頭によるHTTPベースのプロトコルの整備やリッチクライアント(もはやこれも懐かしい)、ソーシャルストリームによる情報の即時共有といった大きな技術要素がいくつも積み重ねられています。

つまり「振り子」ではなく、一周して返ってくる間に少し登っている「螺旋」である。と。

これらの差分を加味した上で、なぜこちら側に戻ってきたのか?そして次はどの方向にいくのか?を考えぬくことで、この歴史を知らない人(若者に限らずボーっとしてたおっさん含む)に較べて遥かに有利に個人的な技術戦略を採ることが可能になるのです。なんということでしょう。わーい。

もちろん、エンジニアである以上、技術の大局的な方向性には以前から強い関心をもって眺めていたのですが、これからはこの”少し登っている”部分に注目してより深い洞察を心がけようと思いました。こういうとき「螺旋」のイメージを持っていることで (一見同じに見えて何か増えているはず) という前提を持てることは意外に大事な気がします。

正しい技術が生き残るわけではない

前述の「螺旋」とも繋がるのですが、技術は技術的に正しいものが生き残ってきたわけではなく、使う人だったり、環境であったり、さまざまな要因で決まる、と。

例として、Linuxについてのリーナスとタネンバウムの議論 や、Worse Is Better というエッセーを挙げた上で「大抵は汚くても*3 劣っていてもシンプルなものが生き残る」との見解を示されていました。

技術にもレイヤがあり、例えば初期のFacebookのコードはそれはそれは汚かったそうですが、それが後日世界を席巻したことなどが想起されました。「螺旋」の「差分」を洞察する上で「正しいから生き残った」というバイアスを外すことができるという点で非常に重要な気づきを頂いたと思います。また、+1で「当時技術的に正しかったもの」は何らかの技術のDNAとして一部、あるいはそのまま戻ってくる可能性があるのではないかなと考えるに、何らかの自分が信じた技術にその浮き沈みに関係なく投資をしておくと後日莫大なリターンを貰えそうな気もします。当時まじめにJavaScriptやってた人とか。

エンジニアと企業の関係性が否応なく変わる

ほぼt_wadaさんのお話のまんま、かつ、研修を設計しておいてなんですが、今後「社内だけ」で技術力を一線に保つことは、加速度的に難しくなっていくでしょう。おそらくこれは技術者以外もです。「社外」に対して何らかの看板を建てることでその人に玉石混交の情報が集まり、それをキュレーションして価値にして発信することでまた更に情報があつまる、というポジティブフィードバックの形成を、企業自体が支援していくことが、人材だけが資産であるソフトウェア企業にはMUSTとして求められます。

一方、エンジニアが社外において価値を認められれば認められるほど、企業を移ることが容易になります。経営者にとってはさぞかし辛い時代ではありますが、全力でエンジニアの社内外での成長を支援しつつ、人材自体の流動性を高いレベルで維持する、そのために、社内外に対しいかに自社が魅力的な環境であるかをアピールしつづける、ことが現時点での最善手ではないかと思います。引き続きがんばっていきましょう。

参考(手前味噌):

ご講演のあと。アウトプット重要。

受講していただいた新卒社員には「これ社外に向けてどこかに書いてね」とお願いしてあります。ここに挙げた以外にも数々の実践的、観念的両面からの素晴らしい教えを頂いたので、そのうちのいくつかは彼等の何らかの社外への出力でカバーされることでしょう。t_wadaさん、本当にありがとうございました!

*1:"せんせい きのこる" が正しい読み方です

*2:別にそれが当社に対するもので無くて良い

*3:誤認。ご指摘により訂正

ソフトウェア品質保証プロセスのモジュール化

軽量品質保証の部品

ソフトウェアQAテスティングギャザリング というフリーダムな試みがありまして。これはソフトウェア品質保証に関連するアクティビティのアトムを集めて、カードゲームみたいにするとプロセスデザインが楽になるかなと考えて試しにやってみた。ものです。

届ける先自体の変化の速度が速いので、プロセス自体もころころ作り変える必要があり、プロセスを変化させるための仕組みとしてはPFDが著名ですが、似たようなものをソフトウェア品質保証に限ることでより簡単に出来ないかなと思います。

現時点において「方法」は大別してふたつ。

  • 作り方を担保するか:これを本ブログではプロセスQAと呼称しています。
  • 作ったものを担保するか:これを本ブログではテスティング/テストと呼称しています。

V&Vですね。まんま。プロセスQAは作っている様子をどのように捉えるか。テスティングはどのように知るかがキモになるのですが、どちらでもスタート地点は届けたい価値における品質面/ビジネス面/その他の何かのモデルにすると、とりあえず説明責任は果たせるのかなと考えています。

インターネット個人史

雑感

今日でウェブが25周年。その70%をリアルタイムで見てきた世代のひとりとして、極めてパーソナルなウェブ≒インターネット史をまとめてみたいと思います。

Yahoo! Japan

インターネットを買った*1のと同時期にはじまったのがYahoo!Japanでした。当時はクレジットカードなどという危険物は持ち合わせておらず「月々いくら」かかり続けるなんだかよくわからないモノを親に頼むのにはかなり勇気が要りましたが、ナゼかあっさり承諾をもらえて僕のインターネットがはじまりました。いろんな投資をしてもらいましたが、費用対効果をかんがみてこれは会心の一撃だったのではないかと思います。おかげさまでむっちゃ食えてます!ちなみにサービス開始直後のYahoo! Japanはこんなかんじでした。

それしか無かったので名前はついていませんでしたが、後年「ディレクトリ型」と呼ばれる、人力でよさげなページをカテゴリに分けて登録していくタイプです。創業者のジェリー・ヤンは相撲が好きで、最初の検索エンジンのサーバ名がkonishikiだったとのこと。

ジオシティーズ

僕の知る限り日本最初の「誰でもホームページが作れる」サービス。ジャンルごとに街角の名前がついていて(例えば本に関するページならbookland)そのページを訪れた人が何かしらのコメントを残せる「ゲストブック」という仕組みがミソでした。自由に使える素材がどれもこれもケバく、どこをどう頑張っても今で言う「90年代のウェブサイト」にしかならなかったのが郷愁をそそります。

2ちゃんねる

バイト仲間から「おもしろいページがあるよ」というものすごくザックリしたリコメンドをもらって覗いてみたけどぜんぜんわからなくてめったにアクセスしていませんでした。まとめサイトはよく見るくせに未だにネイティブたる2ちゃんねるのほうはあまり見ていません。立てたスレもこの十数年で「Delphiで作られた有名ソフトって何があるの?」ぐらいです。

メーリングリスト

何でも、みんなで集まって好きなテーマで話せる仕組みがあるらしいと聞いて。今も昔もゲーム好きだったので、ゲームについて語るメーリングリストに入っていろいろお話していました。ちなみにここで知り合って仲良くなってよく遊ぶようになって好きになってふられたHさんはその後ポケモンを出す寸前のゲームフリークに入社し、企画やデザインを担当、後日説明書でまんま名前を見てびっくりしました。DSが出た時に「何かアイデアないー?」と久々にメールをもらったのが最後かも。あの頃にGmailが無くて本当に良かった*2です。

テレホーダイとWorlds Chat/J

23時~翌朝8時までつなぎ放題!(56Kbpsでな)というテレホーダイ。このネーミング凄いと思います。もともと接続料金は定額のAT&Tだったので、この時間に限れば本当にページを見放題!IT系に夜型が多いのはこれに原因の一端が無いとは言わせないです。これもバイト先の友達から教えてもらった、当時、、というか今でも画期的だと思う3D空間をペラペラの平面アバターが自由に動き回り、近くにいる人とリアルタイムでお話できる、Worlds Chat/J(略称はWC/J) というソフトにどんはまりしました。雰囲気としてはこんな感じ。いろんな部屋や、隠し通路、裏技があって、それを教え合うのも主要なコミュニケーションで、ベテラン同士になると「神社ね」とかで通じる感じがまたなんとも。画像検索で見つけた時は少しグッときました。


ICQ

アッオーです。僕のICQナンバーは25638612です。"I seek you"のアルファベットよみで”ICQ”。当時はページャーとか呼ばれてた、インスタントメッセージングソフトです。メーリングリストでもWC/Jでも、仲良くなったらとりあえずICQナンバーを交換、というまんま今で言うTwitterアカウント的な存在でした。登録されている友達がいまオンラインかどうかわかる機能の草分けではなかったでしょうか。テレホーダイと同時期に普及したため、23時になると一斉に友達リストがオンラインに変わっていく様子に「いつもの場所に集まっている」という不思議な感覚を覚えました。


Lycos

ライコスのほうがたくさんヒットするよ」。Yahooのディレクトリもほとんど片っ端から見てしまい、ホームページにもそろそろ飽きてきた頃に耳にするようになった言葉です。当時としては珍しいロボット型の検索エンジンで、Yahooでは探せないあんなページやこんなページが出るわ出るわ。「あるとわかっているページはYahooで。あるかどうかわからないページはLycosで」というのが当時の僕のネットサーフィンスタイル(ドヤ でした。いま思えば「普段の生活に役立つページ」ってほとんど無かったような。どうでしょう。

i-mode

衝撃でした。いままで↑こんなにワクワクしてきたインターネットがいつでもどこでも出来る。本当に鳥肌がたちました。AT&Tはなんと当時からウェブメールを提供しており、メールがどこでも読める!という意味不明の万能感を得たのをよく覚えています。会社の人はご存知かもですが、僕の返信が異様に速いのはたぶんこの頃の逆トラウマです。加えてまさかその数年後に”そのソフト作ってる”会社で働いてるとは夢にも思いませんでした。画像は最初に使ったP501iHYPER。あんた、ホントにハイパーだったぜ。…まんなかのレバーが痛かったけど。


テキストサイトReadme!

最初のうちは面白がっていたロボット型検索も、たいがいの言葉を探してしまってさてどうしよう?と焦りだした頃に一世を風靡したのがこの「テキストサイト」というジャンルでした。テキストのフォントでフレーズに強弱をつけて、空白でテンポをつけて日常やニュースを何倍も面白く伝えるスタイルは「侍魂」がパイオニアだったと思います。そういえば「ウェブサイト」って言葉もこの辺から定着しだしたように思います。恐らく「トップページ」と「おしながき」という構造が一般化してきたため「ページ」という表現がそぐわなくなってきたのではないかと。「侍魂」を皮切りに雨後の竹の子のように増殖したテキストサイトをまとめていたサービスが「Readme!」です。友達のサイトもけっこうここでいいランクに居たと思います。

BIGLOBECGI

AT&Tでも2MBという十分なホームページ容量がついてきていたので、そこで自分なりの静的なページをつくっていたのですが、コミュニケーションが発達していくにつれ、どーーーしても掲示板を置きたい。しかし、AT&TではCGIが使えない!ということで当時かなり限られていたCGIが使えるプロパイダであるBIGLOBEに乗り換え。当時運営していた個人サイトには常連さんが10人ぐらい来てくれていたので、定期的にオフ会を開催していました。オフ会!うわあ!相互リンクが友情の証で、いくつかのサイトさんと合同のオフ会なんかも。オフ会!うわあ!

ちょうど友達もウェブサイト開設真っ盛り。その友達のひとりに自分のサイトで自作のmidi(うわあ!)を公開している人がいて、ダウンロードしてきたzipを解凍すると、中にはその楽曲に対する思いや制作ノートを綴った readme.txt が付属していました。なぜか当時はこの readme.txt をものすごく羨ましく感じて「僕もreadmeが書きたい!」(でも音楽とか作れない)「…よし、フリーソフトを作ってそこにreadmeを入れよう!」という今考えても本当に意味がわからない動機でソフトウェア制作*3を覚えました。3本目ぐらいの作品が窓の杜とかに載って、月に10冊ぐらいCD付きの雑誌が送られてくるというはじめての体験もこの辺です。

Google

Lycosより”いい感じに”ヒットする検索エンジンがあるよ」という顧みて実に的を射たリコメンドをもらって使っていたのがGoogleです。ちなみに初めてGoogleを見た時の印象は「検索するとこが横にながーい」です。今でも思います。しばらくしてIT系の会社に入った(まだ居る)のですが、その当時は「ホームページ(この頃は既にブラウザの設定名)にGoogleを指定するのがオシャレ」という謎の風潮がありました。

mixi

このへんからもう「イマドキのウェブ」ではないかなと思います。職種に「ウェブ系」というジャンルが出てきたのもこの辺でしょうか。けっこう初期に登録していてユーザIDが4万台です。自分のサイトを更新するより日記のほうが反応が多いのが嬉しくてしばらくはこちらを更新していましたが、mixiの友達は90%ぐらい非IT系にも関わらず技術的な話が多いのがちょっと申し訳なく、そういう話ははてなダイアリーに移して、いまこちらになってます。


リアルの思い出はだいたいその時々の流行歌と紐づくのですが、ネットの思い出が紐付かないのはたぶん「文字を読んでる」からかな、とふと思いました。おかげさまで人生が500倍(当社比)ぐらいおもしろくなったインターネットへ感謝をこめて。

*1:誤用ですが感覚としてはこれが近い

*2:残るから

*3:最初は"上手に"作ろうとかいう発想自体無かったので正しく制作だと思います

プラクティカルクオリティモデルのメモ

ソフトウェアテスト 軽量品質保証の部品

けっこうな数の運用を経て型が出来てきたのでメモ。

何がうれしいの?

品質保証の活動(主にテストとプロセスQA)について

  • なぜそれで充分と言えるのか?
  • なぜその活動が大事なのか?

が自分の意見で説明できるようになります。字面で見ると響かないかもですが、現場の品質保証活動の最上流から自律的にブレイクダウンできると手を動かす場面へのトレーサビリティが確保できて、結果として周りを動かす大きな力になります。

成果物は品質特性をコンテキストにあわせて狭めたもの

品質特性は非常に数が多くその全てを適用した品質保証体制を敷くことは出来ず、ステークホルダー全員がわかる何らかの基準なり思想にそって削ぎ落とす必要があります。戦略とは戦いを略すと書くとおり、品質特性全てに向かって戦うのは上策ではありません。略すのはいいけどその課程には筋を通したい、そのためのメソッドがこのそぎ落とし方のモデルです。

そぎ落とし方のモデル

このそぎ落とし方のパターンを適用して、そのプロジェクト、ビジネスにとって最適な量のモデルに作り変えたものをプラクティカルクオリティモデル、とよびます。造語です。クオリティモデルのままだと、公的に定義されているものと見分けが付かないからです。Practical は 「(理論上ではなく)実際の, 実践的な, 現実的な」とかいう意味です。なぜメソッドではなくモデルなのかというと、このフィルタ自体も構造を持つことが多かったからです。

具体的にはどんなモデルがあるの?

ビジネスリスクベースド

いま一番熱いそぎ落とし方。ステークホルダーの納得度が違う。
これはサービス開発向けのモデルが確立できてきたところ。
向かうビジネスにとって何ができなければヤバいか?を優先付けする。
サービス開発の現場では変更性=CIをかなり高くおいてみている。

ドメインベースド

これが出来ると仕事がかなり楽になるので頑張りたい。
多業種多ドメイン垂涎。
モバイル、ウェブ、組み込み、などドメインにとって
当たり前に期待される部分と自分たちが表現したい品質を
モデル化する。

ゲーミフィケーション

DevQUTで紹介した方法。機能を含めた品質をボスに見立て、
プロセスをマップに見立て、各種特性のHPをゼロにしたらDONE!ってやつで、
とっても楽しいです。

プロジェクトオリエンテッド

最初のモデルはこれ。すさまじくアタマをつかう。でも、プロジェクトメンバーの意識を品質というボードに乗せて同期できるところは非常に良かった。