MacOS Mojave で pip install pygame がエラーになる時

MacOS Mojave に python3.8 を入れた後に、　

pip install pygame

とすると、

 Running setup.py install for pygame ... error
 ERROR: Command errored out with exit status 1:

エラーが出る。exit status 1 はコンパイラなどパッケージ管理の外側で何かが起こっていることが多い。追っていくと案の定、

src_c/_pygame.h:216:10: fatal error: 'SDL.h' file not found

とあるので、SDLの関連ライブラリを入れてあげると

brew install sdl sdl_image sdl_mixer sdl_ttf portmidi

$ pip install pygame
Collecting pygame
  Using cached https://files.pythonhosted.org/packages/0f/9c/78626be04e193c0624842090fe5555b3805c050dfaa81c8094d6441db2be/pygame-1.9.6.tar.gz
Installing collected packages: pygame
    Running setup.py install for pygame ... done
Successfully installed pygame-1.9.6

問題なく完了、なお、この環境では、pyhton3とpip3にそれぞれ、python, pip にエイリアスが貼ってあります。この手の軽量ゲームライブラリはマルチメディアの処理にSDLを使うことが多いのですが、Macがmetalデフォルトになったので、OSには含まれないようになったのですかね。

「現代品質管理総論」メモ

現代品質管理総論 (シリーズ 現代の品質管理)

ソフトウェア品質に関わる技術者の初歩的かつかなり遠大なテーマである「品質管理」と「品質保証」ってどう違うの？という疑問に、ズドンとくる腹落ちを賜れる著作。いかにも大学の講義で使いそうな装丁ですが、飯塚先生の軽妙かつちょっとだけシニカルな語り口のおかげで案外読みやすいです。読みやすい、だけで内容は濃すぎるので、しっかり時間を確保して読まれることをお勧めします。

「品質確保のための要件」

品質技術者として製品、チーム、部門の品質向上を推進するにあたって、①動機 もある、③技術 も何となく整えられてきた、④管理 ⑤ひと もそれなりのリソースをもらっているけれど、どうしても ⑥推進 がうまく進んでいる気がしない時期が数年あったのですが、この図をみて衝撃を受けました。そう、②思想　がないのです。僕自身にも、組織にも。だから、何となく何かをやってる気はするけどこの方向で合っているのか確信が持てなかったんですね。「思想」というと大げさに聞こえるかもですが、見えている範囲（全社、事業部、チームなど）が仕事を成すうえでどんなことを大事にしていきたいか、それがどのように製品に織り込まれるのか（トレーサビリティ）辺りが合意できれば良いのかなと思いました。

品質保証の方法の進展

「検査重点主義」

　米国から近代的品質管理を学んだ第二次世界大戦直後。保証の対象となっている製品の集まり（ロット）に対して、その全部または一部の品質レベルを評価し、一定レベルに達していると判断されたものだけを出荷する。もしかしたら、農業などでは、いまもここに重点を置いているかもですね。

「工程管理重点主義」

　検査には作ってしまった不良品を除く機能しかない。はじめから良品を作るほうが良いに決まっている。ということで、1950年代から製造工程をきちんと管理することによってはじめから良いものを作ろうという考えが広まった。「品質は工程で作り込め」の時代。

「新製品開発重点主義」

　1960年代にはいると、いくら製造工程が整然としていても、不良率がどれだけ低くても、結局売れなければ意味がないよね、という考えが生まれた。真の品質を保証するためには、まず良い製品仕様を作ることが重要である。また、製造工程でのトラブルを分析してみると、その原因の多くは上流工程である生産準備や設計・開発にあることが明らかになってきた。こうして「品質は企画・設計で作り込め」という言葉が生まれた。

経営における三つの管理

こうして日本的品質管理は, 品質を中核とする経営アプローチでありながらも経営管理システム一般に対して重要な概念や方法論について発言するようになり, これがアメリカの品質管理, 経営管理に大きな影響を与えたのである
P.59 3.品質のための管理システム 3.2 管理システムのモデル

静的管理
　タテの管理：日常管理（分掌業務管理、部門別管理）
　ヨコの管理：機能別管理（経営要素管理、管理目的別管理、部門間連携）
動的管理
　方針管理（環境適応型全社一丸の管理）

日常管理

業務目的の明確化、業務プロセスの定義、業務結果の確認と適切なフィードバックを標準化を基盤として実施する。それぞれの部門で日常的に当然実施されなければいけない分掌業務について、その業務目的を効率的に達成するためのすべての活動の仕組みと実施に関わる管理。

機能別管理

品質、コスト、納期、安全・環境などの機能を軸とした部門をまたがるプロセスを想定し、そのプロセスを全社的な立場から管理しようとするもの。意味的には「経営要素」のほうが近い。

方針管理

環境の変化への対応、自社のビジョン達成のために通常の管理体制（日常管理の仕組み）の中で満足に実施することが難しいような全社的な重要課題を、組織を挙げてベクトルを合わせて確実に解決していくための管理の方法論。

静的管理を基本としつつ、変化への対応を余儀なくされる昨今の経営ではより動的管理（方針管理）のウェイトが高まることは想像に難くないです。方針管理については別途まとめたいと思います。

変更管理

本記事の前節からいきなりスケールダウンしますが、気になったのでメモ。

変更によるトラブルには

(a) 変更の目的そのものが達成されない
(b) 品質の他の側面やコストなどに悪い影響を及ぼす
(c) 関連して実施すべき変更がすべて列挙されずに抜けが起こる
(d) 変更の実施が徹底せず, 実施されなかったり, 一部のみ実施される
(e) 変更指示内容の誤り, 情報伝達の不備, 変更指示の受け取り側の誤解などのため, 意図通りの変更が実施されない

などがある.
P.128 5.品質保証機能 (6) 変更管理

本記事の読者のかたには「何をいまさら」感があるかもですが、一部の分野ではテストの重心がリリース時点での品質の充足から安全な変更に移りつつある現代において、改めてそれぞれの項目に対してどんな施策が打てているかを振り返っておきたいと感じました。

その他グッときた記述

私は早い時期から, 品質管理というものが, およそ目的達成のための筋の良い哲学と優れた方法論を与えていると感じるようになっていた.
P.iv まえがき

標準化は, 改善の基盤のみならず, 実は独創性の基盤でもある.
P.48 品質管理の基本的考え方

改善する＝何かを良くするためには現状を正しく認識する必要がある、ということ。
独創性を発揮するための物理的、精神的リソースを生み出すための重要な基盤である、ということ。

形だけの TQM を導入して苦労する例を分析してみると, 問題解決を軽視していることに気づく. （略）二つのことが忘れられているからである. 第一は，方針管理を導入する前に日常管理の仕組みができていなければいけないこと,第二は, 管理を実施していく上での問題解決が基本であることの二つである
P.164 問題解決

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)

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

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

システムテスト？

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

書き下ろしも！

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

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

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

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

出典: 忍び寄るイノベーションの危機 小林三郎＝中央大学 大学院 戦略経営研究科 客員教授（元・ホンダ経営企画部長）

オペレーション

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

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

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

　

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

イノベーション

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

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

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

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

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

何が腑に落ちるのか

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

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

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

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

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

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

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

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

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

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

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

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

外から見ると「振り子」

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

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

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

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

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

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

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

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

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

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

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

参考(手前味噌):

Wacate2013 s bpp_session from Shinsuke Matsuki

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

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

本日は株式会社 ACCESS 様にて講演させて頂きました。お聞きくださった皆様、ありがとうございました！ (@ 株式会社ACCESS 幕張研究開発センター) http://t.co/5301MdAAGg

— Takuto Wada (@t_wada) 2014, 4月 24

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

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

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

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

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

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

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

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

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