ディベートは人を屁理屈で言い負かす弁論術ではありません
ディベートが割と誤解されている風潮がありますので、ディベート本の紹介を。
ビジネス・ディベート (日経文庫) | 茂木 秀昭 |本 | 通販 | Amazon
どちらも素晴らしい本です。非常に読みやすくもあるので、ぜひ読んで欲しいと思います。
ディベートって何？
ディベートは、決められた論題に対して、肯定派と否定派とにわかれ、それぞれがルールに従って主張を行う競技です。 そう、競技なんです。ルールがあります。審査員もいます。
肯定派と否定派が意見を述べる時間が決まっており、大体以下のような順序で行われます。
- 肯定側立論
- 質疑
- 否定側立論
- 質疑
- 否定側第一反駁
- 肯定側第一反駁
- 否定側第二反駁
- 肯定側第二反駁
- 否定側結論
- 肯定側結論
立論というのは、「私はこう思いますよ」という主張を、なぜそう思うのかという理由とともに説明する時間です。 反駁は、相手の主張に対して、いやいや違いますよというリアクションでの反撃を行う時間です。
論題は、必ず賛否が明確に分かれるように設定されます。例えば、 「死刑制度は廃止すべきである」 「日本は移民を受け入れるべきである」 「当社は英語を公用語とすべきである」 といった具合です。
相手を言い負かすのが目的なんですか？
Noです。肯定派も否定派も、相手の意見を聞いて、立場を変えるようなことをしません。ディベートは、どちらの言い分がより説得力があるかを、審査員という第3者視点で判断し、優劣を競うゲームです。最終的にどっちが良かったかジャッジされるということです。
また、論述に対する意見を述べるのであって、人格攻撃や、論題と無関係なことを述べてはいけません。そして、肯定派を取るか否定派を取るかは、大抵くじで決まります。その人の信条と同じか違うかはあまり関係ありません。
ゲームスキルってことになるけど実践で使えるわけ？
冒頭で紹介した本でも力説されていますが、考え方の教育に非常に適していると思います。その効果は、ディベートはルールのあるゲームだからこそでしょう。
理由1. 審査員が判断する
審査員は、述べられた意見に対して、どちらの方が説得力があったかを審査します。審査員による評価が入ることで、自分の意見の組み立てが適切だったかどうかの振り返りの機会が得られます。
例えば、社内公用語の英語化について、否定派が「英語だとコミュニケーションロスが増えるから反対です」とだけ主張をした場合、否定派に賛同できるでしょうか？
Noでしょう。これだけだと、あっそう、で終わってしまいます。その主張の理由付けが要ります。例えば、どれくらいのコミュニケーションロスが発生するのか？それは他でリカバリできないほど深刻だと言えるのか？英語の公用語化のメリットを上回るほどのものなのか？その問題が業績にどれくらいのインパクトを与えるのか？などの観点から説明を加える必要があります。でないと、ただのボヤキです。
ここで役に立つのが演繹法や帰納法などの垂直思考になります。垂直思考が出来ていないと、論理の接続がおかしいため、ツッコミが入ってしまいます。ここの辺りの考え方は、紹介した本に丁寧に書かれています。
また、審査員がいることで、先ほど書いた人格攻撃のような、無意味な論述は排除されます。これも大きなメリットです。
理由2. 論述の順番と時間が決まっている
時間が決まっているので、声のでかい一人が延々としゃべり続けることはできません。また、論旨不明のままダラダラしゃべってしまうと、すぐ時間切れになってしまいます。発言する内容を精査し、取捨選択する必要があります。時間設定にも拠ると思いますが、立論で主張できるポイントは、大体2つくらいです。
この主張ポイントはただ増やせばいいというものではなく、ポイントが増えた分、どうしてもそれぞれに対する「なぜそう思ったのか」を述べる時間が短くなります。主張ポイントの優先順位付けと、どのくらい述べるかの戦略を練る必要があるということです。
日常見られるような長ったらしい会議も、座長はこんな感じの戦略をあらかじめ練って欲しいと常々思っています・・・。
理由3. 相手がいる
これは割とディベートならではの環境だと思いますが、自分たちと真逆のポジションを取った相手がいます。相手の立論や質疑、反駁をよく聞いて、その主張を理解する必要があります。相手の主張に穴がないか、相手が何を狙ってこちらの攻撃をしているのかなどを判断し、自分たちの戦略をその場で練り直す必要がでてきます。いわゆるクリティカルシンキングです。
立論で終わらず、意見の応酬があるのがミソですね。相手がどこからパンチを繰り出してくるのか、ある程度予測しなければならず、不測の事態にも対処しなければならないということです。
理由4. しゃべる
当たり前ですが、実際にしゃべります。喋り方も、やはり説得力に直結します。プレゼンスキルは誰しも重要だと思っていますが、そのトレーニングにもなります。
下の動画はフジテレビでやっていたディベートの番組で、現役高校教師チーム vs 落語家チームの対決です。実は、この現役高校教師チームの男性教師が、冒頭紹介した本の著者です。本でもチラッとこの時の紹介がありますが、落語家チームの話し方の上手さに舌を巻いていました。
それにしてもフジテレビがこんな本格的なディベート番組をやっていたことに驚きました。本を読むまで知りませんでした。
最後に
以上、本に書いてあったことを自分なりの解釈を織り交ぜながらディベートの説明をしてみましたが、自分には実際ディベートの経験がありません。興味はありますけど。
ただ、ディベートに必要な思考法が、現実のビジネスシーンでも非常に親和性が良いと感じています。「考える」というのは言うは易しで、なかなか身につかないスキルです。その「考える」ということがどういうことか、ディベートのトレーニングを行うことで、身につくんじゃないかと思います。
Raspberry pi + YMZ294用MMLプレーヤーコード公開
Raspberry pi + YMZ294用MMLプレーヤーのソースコードをgithubに公開しておきました。ライセンスはMIT。
GitHub - kinokorori/rpi_psg_mml: MML player using Raspberry Pi with YMZ294(PSG).
使い方はREADME_ja.mdを参照してください。ごく一般的な再生のみサポートしていますが、オープンソースということで、適当に改変して使っていただければ幸いです。サンプルとして、Ave Mariaを16小節分再生するコード(sample-avemaria.py)もくっつけてあります。Raspberry PiはArduinoと違って「こうやってピン配するよね」というデフォルトがないので、外側から設定できるようにはしてあります。
オリジナルで曲を書く場合、sample-avemaria.pyを改変するのが一番楽だと思います。MMLの文字列を弄って確認してみてください。
なお、READMEには日本語版があります。GitHub上でREADME_ja.mdを選択すると、日本語版READMEが表示されます。
Raspberry Pi + YMZ294でのノイズ対策にコンデンサを使用する
前回はアナログフォトカプラでスピーカーを絶縁し、ノイズの少ない電源を用意しました。
今回はコンデンサでノイズ除去。アンプ周辺の回路図はこんな感じにしました。47μFはアルミ電解コンデンサです。ちなみに今までサボってYMZ294近辺のデカップリングコンデンサすら配置していませんでしたが、それも配置。
電源のパスコンもちょっと効果ありましたが、信号線(IN+,IN-)側の効果が大きく、ほとんどノイズが聞こえなくなりました。グランドノイズが大きいということですかね。ただ、全体的なボリュームが若干下がってしまう上に、少し音がマイルドになってしまいます。47μFから10μFに変更すると、PSG特有の元のとんがった音がある程度保存されますが、ちょっとだけノイズが気になります。22μFあたりが丁度よさげな感じ。なお、全体的なゲインが下がってしまうので、抵抗を1Kから100Ωに変更しています。
ノイズ対策にはコンデンサを使いましょうとか、アンプ回路を見ると、コンデンサが大量に配置されてたりしますが、実際に試してみると、おーなるほど、という感じです。オーディオも楽器もやらないソフト屋にとっては割と新鮮な体験だったりします。結構コンデンサ容量は勘だったり試行錯誤だったりという話を聞きますが、確かに入れ替えてみるとノイズ感がガラッと変わりますね。
非常に素人感満載ですが、動画も撮ってみました。
Raspberry Pi + YMZ294でのノイズ対策にアナログフォトカプラを使ってみる
前のエントリで、ドレミファソラシドを鳴らしてみましたが、凄くノイズが乗っています。
Raspberry piでYMZ294を鳴らす - キノコの自省録
ラズパイに挿しただけで、ピギャーピーという感じのけたたましいノイズが乗ります。以下のエントリの時にも書きましたが、シールド線使ったところでどうにもなりませんでした。
ノイズの原因と対策
ノイズの原因は電源です。電源はラズパイから引っ張っているので、ラズパイの電源がノイジーだということです。ピュアオーディオマニアが発電所を評価したりマイ電信柱買ったりと、電源にやたらこだわる理由がちょっとだけわかった気がします。ちょっとだけ。電源ってこんなにノイズが乗るんですねえ。
ということで、スピーカー電源にラズパイのピンを使わず、どこかで電気的に絶縁してノイズ対策を施してみます。どこかで、といっても、2か所しかありません。
- ラズパイとYMZ294の間をフォトカプラで繋いで絶縁する
- YMZ294のSO出力とアンプ間を絶縁する
1はデジタルですが、なにしろピン数が多いため、かなりヘビーです。あまりやりたいと思わない、というかこんなことするならノイズの少ないArduino使います。2はSO出力だけなので配線は楽チンですが、アナログです。アナログの絶縁ってどうやるんでしょう・・・
※もう一つ、ラズパイに使っているUSB電源から5V/GND線を横取りしてスピーカー電源につなぐという方法もアリだと思います。
アナログフォトカプラ
アナログフォトカプラみたいなものはなんかないですかね？と検索したら、すぐ出てきました。
ＣｄＳ＋ＬＥＤ アナログ・フォトカプラ ＭＩ０２０２ＣＬ: 半導体 秋月電子通商-電子部品・ネット通販
フォトカプラというかフォトレジスタですね。構造は至って単純で、片側にLED、片側にCdSを取り付けて箱に閉じ込めているだけです。LEDの光量に応じて、CdSの抵抗値が上下するという仕組みです。なるほど。なので、CdSサイドはただの可変抵抗と考えればいいということです。スピーカーユニットを鳴らすには、抵抗の変動に応じて、電圧を上下させる必要があります。単純に繋いだ場合、変動するのは電流になってしまうので、GNDとの間に抵抗を繋いで並列回路構成にする必要があります。
MI0202CLのLED順方向電流は最大40mAです。YMZ294のSO電流を調べたところ、大体15mA～20mAで変動しています。なので、直挿ししてOK。
ということで、回路はこんな感じになりました。大分単純です。
鳴らしてみる
ちゃんと鳴るか心配でしたが、ちゃんと音が出ました。YMZ294を直挿しした時に比べると、音が丸くなっています。音が丸くなるというか、Lo-Fiっぽいです。これはこれでなかなか味があって良いかもという感じなのですが、たまにボツ音が乗ります。うーん。
電源はいくつか試したのですが、一番静かだったのが乾電池でした。ノイズがほとんど聞こえません。AC/DC変換しないせいですかね。ちょっと驚きました。
とりあえず動画。最初はラズパイ直での再生、0:57あたりから、MI0202CLで絶縁して、アンプ電源に乾電池を使用したバージョンです。ノイズ比較も行っています。
コンデンサでのノイズ除去も試してみようかなあと思いますが、とりあえず今回はこの辺で。
シャイニングゴッドチェリー
シャイニングゴッドチェリー描きました。
【アイドルマスターシンデレラガールズ】「シャイニングゴッドチェリー」イラスト/kinokorori [pixiv]
6年前のGWから絵を練習しようと決めたので、GWにはなるべく絵を描くようにしています。最初から比べると上手くはなったけど、具体的に何が変わったかと言われると説明できない。
プロダクト設計にはDtoDの当てはまりが良さそう……な気がする
タイトル通り、かなりフワっとしているお話になります。
上流設計、特にどういう製品を作っていこうか、というプロダクト設計には、DtoD(Discover to Deliver)というフレームワークの当てはまりが良さそうだなあと思ったお話です。
私自身、DtoDについて詳しく調べたり本を読んだりしているわけではありませんので、こんなものがあるんだ、という参考程度に。
Discover to Deliverとは
米国EBG Consulting社のエレン・ゴッテスディーナーさんとメアリー・ゴーマンさんが、2015年に考案したフレームワークです。割と最近ですね。本家はこちらです。
日本では、オージス総研がまとめています。
DtoD手法に基づくアジャイル要求 | 株式会社オージス総研
こちらのページでは、こんな風に紹介されています。
個人的には、「プロダクトの7側面」がとても当てはまりの良いモデルだと感じました。
プロダクトの7側面
オージス総研のページにも少し紹介がありますが、ソフトウェア開発にはユーザストーリーマッピングやスクラムといった開発フレームワークがあります。これらのフレームワークはかなり浸透してきてはいますが、如何せんソフトウェア開発に直結していることもあって、少し技術者寄りな側面が否めない部分があります。特にスクラムはそうですね、。そして、ユーザーストーリーマッピングも、それだけではプロダクト設計を考える上では、不十分です。開発すべき部分ではない部分、例えばクレーム対応や在庫管理といった点は、ユーザーストーリーマッピングにはなかなか登場しないと思います。
少し話が脇道にそれますが、私の関わっているプロダクトオーナーは非技術者が多いせいなのか、プロダクトの方針について全く整理されていない状態で、新規プロダクトの話を持ち掛けられることが多いです。はっきり言ってしまうと、顧客要望をそのまま伝達しているようにしか見えません。せめて、プロダクトの指針くらいは決めて欲しいのですが、ある部分について顧客要望がない場合「何も言ってこないんですよ」と言ってくることがあります。ないならないでプランを立てるのがプロダクトオーナーの役割だと思うので、それを技術者に言うのはどうかと思います。
じゃあ、プロダクトオーナーに対して、「せめてこのくらいは考えたり、顧客からヒアリングしてほしい」というのは何ですか、と聞かれると、なかなかうまく整理して話せなかったりします。そこで、このプロダクトの7側面です。よくまとまってるなあと感じました（もしかしたら曲解しているかもしれませんが）。
プロダクトの7側面は、以下の通りです。
- ユーザ
- インターフェイス
- アクション
- データ
- 制御
- 環境
- 品質特性
ユーザ
プロダクトの使用者です。どういう使用者を想定しているのか、という部分を考えましょう、ということです。ユーザストーリーマッピングも、ここにある程度含まれます。使用者を主眼に置いた分析といえば、ペルソナが有名ですね。
稀に、プロダクトの納入先（要するに顧客）が使用者のスコープを想定していない場合がありますが、だからといってユーザ分析をしなくていいわけではないと思います。ちょっと考えただけでも、万人向けなのか、弱い部分をターゲットにするのか、強い部分をさらに伸ばすのかのプランがあり、それによってプロダクトの方針が変わります。顧客が外部企業の場合、それらのプランを提示するのもプロダクトオーナーの役目だと思います。
インターフェイス
APIというより、どれくらいの企業や人が関わり合いを持つか、という部分です。顧客企業と自社、ユーザのみの関係で完結することは稀でしょう。例えば、プロダクトがハードウェアを含む場合、絶対に物流や倉庫が登場します。故障対応はどうするのか、ハードウェアが自社開発ではない場合、カスタマイズはどうするのか、在庫管理は顧客企業がやるのか、自社がやるのか、いろいろ考えることがあるはずです。これを考えないで技術屋に投げると100%怒られます。
アクション
トリガーです。これはユーザストーリーマッピングやユースケースで考えることになると思います。
データ、制御
DtoDの資料をさらっと読む限り、業務フローや法務規制を検討するようです。技術寄り、例えばRDBのデータ構造をどうするかといった系統のものではないと思います。業務フローというのであれば、これは本当に大事で、作ったシステムが客先にマッチしない場合、受け入れを拒否されることすらあると思います。データは、顧客マスタや発注伝票なども含むかもしれません。そういう意味では、確かにプロダクト設計の段階で、絶対に把握しておく必要があります。
環境
どういう場面やシチュエーションで使用されるか、ということだと思っています。業務フローのように「流れ」を伴うものではなく、もう少し定性的なものでしょう。プロダクトの使用環境が、静かで薄暗い環境だと思っていたのに、屋外＋凄いノイズ環境下でした、となった場合、プロダクトがそもそも使用できないということも考えられます。
品質特性
ソフト屋（特にサーバ屋）の場合、想定ユーザ数とアクセス頻度は絶対気にしますし、ハードウェアの場合は耐性試験などの指針にもなるので、技術者からプロダクトオーナーに、どうなってんの？と聞くことも多いと思います。非技術者にとっては何をどう気にすべきなのかわからないので、ある程度、技術屋からインプットする必要があると思います。
メモリやストレージ、CPUはどのくらいのスペックを用意すればよいのかなどは、顧客要望、およびコストと絡む場合が多いため、技術者とプロダクトオーナー間で調整が必要になるでしょう。
まとめ
正直DtoDについてそこまで調べてないのにエントリを書くのもどうかとためらったのですが、紹介してみました。というのも、プロダクトの7側面は、プロダクトオーナー自身も気にかけていて欲しいし、技術者側も、これが足りないよ、とプロダクトオーナーにつっつくべき項目として、割と当てはまりが良いと思ったためです。
PSGで風色メロディ
YMZ294のみ使用して、風色メロディを鳴らしてみました。PSG3音を使用しています。ノイズサウンドはなし。
今回はRaspberry Piを使用したのですが、めちゃくちゃ環境ノイズが乗ってます。一応1m300円くらいのシールド線を使用しているものの、それだけじゃいかんともしがたいようで。色々調べて回ると、完全を目指すならば電気的に絶縁ということなので、そうするとフォトカプラですかね。とりあえずラズパイ直だと少し厳しそうな模様。まあシンプルにいくならArduinoにすればいいのですが。
ちなみに曲のプログラムに当たっては、MMLパーサを自作して、MMLで書いています。MMLパーサ+シーケンサコードもそのうちアップするかも。
