商売力開発ブログ

非エンジニアがWebサービスの開発、運営によって商売力をつける記録、その他の雑記

Google API を利用して、2019、2020年の日本の祝日を取得した結果を確認する

今回はGoogleのカレンダーAPIを利用して、2019、2020年の日本の祝日を取得した結果を確認します。
具体的な取得方法については以下を参照して下さい。

2019、2020年の日本の祝日の取得結果

2019年と2020年の現時点(2019/01/04)で日本の祝日をGoogleのカレンダーAPIを利用した結果を確認します。
この2年は新天皇の即位と東京オリンピックがあり、その関連で祝日がどのようになっているか確認します。

2019年の取得結果

2019年の取得結果は以下のようになりました。

No 日付 名称
1 2019/01/01 (火) 元日
2 2019/01/14 (月) 成人の日
3 2019/02/11 (月) 建国記念の日
4 2019/03/21 (木) 春分の日
5 2019/04/29 (月) 昭和の日
6 2019/04/30 (火) 祝日
7 2019/05/01 (水) 即位の礼
8 2019/05/02 (木) 祝日
9 2019/05/03 (金) 憲法記念日
10 2019/05/04 (土) みどりの日
11 2019/05/05 (日) こどもの日
12 2019/05/06 (月) こどもの日 振替休日
13 2019/07/15 (月) 海の日
14 2019/08/11 (日) 山の日
15 2019/08/12 (月) 山の日 振替休日
16 2019/09/16 (月) 敬老の日
17 2019/09/23 (月) 秋分の日
18 2019/10/14 (月) 体育の日
19 2019/11/03 (日) 文化の日
20 2019/11/04 (月) 文化の日 振替休日
21 2019/11/23 (土) 勤労感謝の日

新天皇の即位の日となる5/1は「即位の礼」として取得され、その前後は「祝日」として取得されています。また12/23は「天皇誕生日」としては取得されていません。

2020年の取得結果

2020年の取得結果は以下のようになりました。

No 日付 名称
1 2020/01/01 (水) 元日
2 2020/01/13 (月) 成人の日
3 2020/02/11 (火) 建国記念の日
4 2020/02/23 (日) 天皇誕生日
5 2020/02/24 (月) 天皇誕生日 振替休日
6 2020/03/20 (金) 春分の日
7 2020/04/29 (水) 昭和の日
8 2020/05/03 (日) 憲法記念日
9 2020/05/04 (月) みどりの日
10 2020/05/05 (火) こどもの日
11 2020/05/06 (水) 憲法記念日 振替休日
12 2020/07/23 (木) 海の日
13 2020/07/24 (金) 体育の日
14 2020/08/10 (月) 山の日
15 2020/09/21 (月) 敬老の日
16 2020/09/22 (火) 秋分の日
17 2020/11/03 (火) 文化の日
18 2020/11/23 (月) 勤労感謝の日

新天皇の誕生日となる2/23は「天皇誕生日」として取得されています。逆に12/23は取得されません。
東京オリンピック関連では、開会式の7/24が「体育の日」となり前日が「海の日」となっており、閉会式翌日の8/10が「山の日」となっております。通常、「海の日」は7月第3月曜日、「体育の日」は10月第2月曜日、「山の日」は8/11です。ちなみに「体育の日」は2020年より「スポーツの日」に名称変更される予定ですが、そこはまだ反映されていないようです。

まとめ

今回はGoogleのカレンダーAPIを利用して、2019、2020年の日本の祝日を取得した結果を確認しました。

以上
【関連するリンク】
www.prj-alpha.biz

「レトリックと詭弁」から議論術を考える②

今回は香西秀信「レトリックと詭弁」から議論術を考えていきます。 

レトリックと詭弁 禁断の議論術講座 (ちくま文庫 こ 37-1)

レトリックと詭弁 禁断の議論術講座 (ちくま文庫 こ 37-1)

 

色々な議論術

今回は本書の中で紹介された色々な議論術について考えていきます。

多問の虚偽

問う側が何らかの前提を置いて質問を行った際、その質問に答えると、問う側の設定した前提を認めてしまうことになることがあります。

本書の中で紹介されている例では、「君は、もう奥さんを殴っていないのか?」というものです。この問いは形式上、「はい」か「いいえ」という答えを要求します。このときどちらで答えても、過去に奥さんを殴っていたことを認めることになります。
外形的には一つに見える問いの中に、「奥さんを殴ったことがあるか?」と「今はもう殴っていないのか?」という二つの問いが含まれていると解釈できます。このため多問の虚偽複問の虚偽と呼ばれているとのことです。ただ「虚偽」と言ってますが、必ずしも虚偽でないこともありえます。先の例でいえば、過去に奥さんを殴ったことがあれば虚偽ではないのです。

このような問いの場合は、答えることで事実の如何にかかわらず、問う側の設定した前提を認めたことにされることがあるのです。

このタイプの問いに答える者は、外形的な答え以上の言質を相手に取られてしまうことになるのです。逆に、問う側からすれば、これによって問うた以上のことを答えさせることができます。
(第三章: P93)

このような問いには、その前提について否定して言い返すことで対応ができるでしょう。ただ注意が必要なのは、このような問いを印象操作に利用されることです。この問いのやりとりを聞いていた第三者がいる場合、否定したとしてもその印象が残ってしまうことがありえます。
「君は、もう奥さんを殴っていないのか?」という問いに、「そもそも、奥さんを殴ったことがない」と答える分には良いですが、「そもそも、奥さんは殴ったことがない」と答えると奥さん以外で殴ったことがある人だと印象付けられてしまいます。
また第三者が「火のない所に煙は立たぬ」といった考え方を持つ傾向があれば、この問いをされること自体が、答える側を暴力的な人間なのではとの印象を持つことになってしまうかもしれません。

立証責任と不当予断の問いと責任転嫁

ある主張に対して、その根拠を説明を立証することは労力がかかることがあります。問いの形式をとることで、立証の責任を強引に相手側に委譲してしまうことができます。

「あなたの行為は、道理に適っていない」と発言したとき、それが道理に適っていないことを論証する責任はこちら側にあります。だが、これを「あなたの行為は、道理に適っていると言えますか」と相手に問いかけたら、相手がその問いを肯定した場合、その行為が道理に適っていることを論証する責任は、形式上は相手側に移行します。
(第一章: P50)

自分の主張を問いにすることで、このような効果があります。責任の転嫁は、問いという形式が議論術として働くときの重要な作用の一つとして説明しています。

相手が思わず答えることで、この立証責任を相手に委譲する問いを不当予断の問いとして紹介しています。

不当予断の問いは、われわれが日常議論において最も注意しなければならないものの一つです。これが見破りにくい虚偽形式だからではありません。簡単に見抜け、容易に反論できるものだからです。
(第三章: P94)

本書では先の多問の虚偽と合わせて、不当予断の問いを説明しています。「君は、Kの、あの下らない議論術の本を読んだのかい」という問いは「はい」か「いいえ」のどちらで答えても、Kの本は下らないことを認める多門の虚偽となっています。
注意が必要なのはこれに言い返す(retortする)場合です。答える側がこの本の事を素晴らしいと思っていて、「Kの本が下らないとは思いません」と答えてしまうと最悪の結果となります。この答えによりKの本が下らなくない理由を説明する責任を負うことになるのです。「Kの本のどこが下らないのですか」と言い返せば、立証責任は問う側になります。不当予断の問いの危険性は、それがあまりに簡単に反論できるために、勢い余って立証責任を引き受けてしまいかねないことだと、注意を促しています。

少し違った方向で応用を考えると、ブレストなどで議論を活性化させる手法として使えるかもしれません。意見の少ない人から発言を引き出したり、違った視点や方向性に議論を発展させるために、誰でも反論できるような前提の問いを出してみるのです。簡単に反論ができるので、誰でも答えやすく、その答えを受けて更に議論を発展させていく手法です。

選択肢の詐術

二者択一のような選択肢を設定した問いは、答える側はそこにない他の選択肢を封じられることになります。問う側は自分に都合の良い言葉を使いながら、その選択肢の中から選ばせるように組み立てるのです。
議論術として利用されるとき、多くの場合、問う側は自分の狙いとする答えを選ばせるようにするため、答える側は一つしか選べないように組み立てられます。

選択肢の「一つを、好意的な見方によって提出し、その望ましい選択肢を、他の、拒否されるべき一つもしくはそれ以上の選択肢と対比して引き出せる」という技巧が使用されます。
つまり、選択せよと相手に迫りながら、選択の余地などないようなやり方で問いを出すのです。
(第三章: P97)

本書の中で選択肢の詐術として、カンニングが見つかり開きなおったの話(P30)や全面講和運動(P98)が例として示されています。全面講和運動ではその命名の妙に注目しています。ここでは「全面講和」、「単独講和」という名前を用いて二択にすることで、「単独講和」を選択しにくいように導いていることを指摘しています。実際には五十五カ国のうち四十八カ国と講和を結ぶことを「単独講和」と呼んでいたのです。

このような詐術は色々考えられます。会社のような組織体でグループ間や部署間での対立や争いの際、相手側から「組織のための行動か、自分たちのための行動か」といった問いがあったとします。この二択の場合そのまま「自分たちのためだ」とは選択しにくくしてます。これを更に言葉を変えて「みんなのための行動か、私利私欲のための行動か」とするとどうでしょうか。「組織」を「みんな」にすることで組織内だけでなく、顧客や取引先など外部までイメージする受け取り手がいるかもしれません。更に「自分たち」を「私利私欲」とすることでよりその個人の欲望が動機となっているかのように印象付けられます。
自分自身がこのような言葉を利用されて問われることに突然なるかもしれません。そのようなときの為にも、どのような言葉を使用して問うとどのような効果があるのか、色々な想定問答や思考実験を本書はすすめています。

ディレンマの活用

どちらも選択しがたい二つの選択肢からなる「二者択一」を組み立てることでディレンマに追い込まれます。レトリックの領域ではディレンマは一つの議論術と見なされるとのことです。

議論術のディレンマは全ての人にとってディレンマである必要はありません。議論の相手にとってディレンマとして成立すれば良いと言っています。

あるディレンマが、議論法として有効かどうかは、それを普遍的・一般的観点から考えてはならない。あくまでも、説得の直接の対象にとってどうかという点から判断しなくてはならない
(第三章: P110)

どちらを選択しても、答える側にとって不都合な結果を導くような状態は物語の中で良く見られます。「AかBかどちらか選べ」と言われディレンマに陥る登場人物です。本書の中でも夏目漱石の「鳴海仙吉」から引用されています。

ディレンマのかわし方として二つの方法を説明しています。一つはディレンマとなる二つの選択肢以外の第三の選択肢を見つける方法で、「ディレンマの角の間を抜ける」と呼ばれるものです。
もう一つは選択に伴う結果が必然でないことを主張する方法で、「ディレンマの角をつかむ」と呼ばれるものです。
しかしこれらの方法でかわせないこともあるでしょう。本書の中ではディレンマをかわす方法を思考実験として楽しむこと勧めており、それが議論術を学ぶ重要な目的の一つと言っています。

「お前も同じではないか」という論法

 「お前も同じではないか」とは、こちら側の行為などを批判してきた相手に対して、同じようなことをしてるではないかと相手に指摘することにより、こちら側への論法を封じる方法です。論理学の分野でも、伝統的に詭弁(虚偽)の一種として分類され、およそ推奨できるような論法ではないと、本書で紹介しています。

論理学の正道からは外れるものの、国家間の論争には積極的に使用するようにすすめています。

<<to quoque>>は発言内容ではなく発話行為を問題にしているのです。自国の「悪」には目をつぶりながら、他国の同様の「悪」は厳しく糾弾するというその不公平さを攻撃するのがこの論法の目的です。言い立てられた「悪」を弁護しようとしているのではありません。
(第五章: P155)

内容ではなく、その問いの行為を問題にしているのです。その問いは他にも平等に行っているのかと。

この他にもこの論法により、立証責任を相手側に負わせることができ、また事実を正確に認識させることができると言っています。
こちら側の行為だけをなぜ問題視するのか、またその理由はどのような根拠に基づいているのかを相手に説明させる責任を負わせることが可能です。この中で他のものとの事実関係を確認することになり、相手にも第三者にも事実を認識させることになると言っています。

あえて言わないふりをする

あえて言わないふりをすることでそのことを強調することができます。これは現実に色々な例がありますが本書の引用をそのまま紹介します。

・・・ドイツ語に関しては、実に早くから広く、深く、人の気づかない点にまで目をそいで研究された先生でした。(関口先生はドイツ語だけでなく、ラテン語、ギリシア語、フランス語その他の諸語、また一般にあまり知られておりませんが、古代、中世のドイツ語にも堪能であったことは、ここではふれずにおきます。書き切れなくなりますから。)
眞鍋良一「関口存男先生」
(第五章: P174)

「ふれずにおきます。」と書いておきながら、思いっきりふれています。しかしこれにより、印象付けられることになります。これは肯定的な例ですが、否定的なときにも利用されます。「彼は過去にこんな失敗をしていましたが、ここでは関係ないので省略します。」といったものです。
このように言っているのに言わないふりをすることで、通常の言及より印象付けることができるのです。実際、私も関口存男について検索したくなりました。特に「くそ勉強について」は凄みが伝わる文章ですが、ここではふれずにおきます。

後だしする

発言の機会が1回しか回ってこないような場合、後から意見を述べる方がより説得力を持つというものです。これは誰かの意見に対して、反論する機会がないために出てくる効果です。

実際の論の強さなど、順序がもたらす印象によってかき消されてしまかねないということです。
ここから、われわれは次のようなやや狡い原則を手に入れることができるでしょう。ある問題について、何人かで意見を言うときには、できるだけ一番最後に発言すべきである、と。それだけでも、あなたの発言は、実際以上に説得力のあるものに見えるはずです。
(第五章: P166)

後から意見を述べるということは、前の意見の中身だけでなく使用されている言葉を知ることができます。前の意見の言葉の効果を打ち消すような言葉を選択しながら、後から意見を述べることで、よりこの効果が大きくなるでしょう。

色々な修辞疑問を見つけよう

前回 の中で説明した修辞疑問ですが、色々な場面で使われでるのを気付くことができるようになります。修辞疑問とは疑問の形式をとりながら、その答えの内容を聞く事が目的でない問いです。

あるドラマの例です。仕事を遅刻してきた歯科衛生士が、その理由を説明したのですがどうにも個人的な都合で納得いくものでなかった歯科医。歯科医は「仕事なめてます?」と問います(これも修辞疑問です)。相手が答える前に歯科医は立て続けに同じような問いを言います。そして最後に「私、間違ってますか」と問います。これは正しく修辞疑問で、「間違っていません」と答えさせるために放った問いです。仮に「間違ってます」と答えた場合は、「どこが間違ってますか」と立て続けに問うことができるでしょう。
これに対して遅刻してきた歯科衛生士が言い返したこと(retort)は、「えっと、私が謝った方が良いってことですか?」と問い返します。この返しに歯科医は絶句します。歯科医が放った「私、間違ってますか」という問いは、間違ったことを認めさせ、その後に謝罪させるための問いだったのです(そして気持ちをすっきりさせるためです)。それを見抜いた歯科衛生士が、謝れば気が済むんですよねと、歯科医の気持ちを見透かし先に返したのです。気持ちを見透かされた歯科医の方は、沈黙することになり、その後他の歯科助手に同意を求めるシーンへと続きます。

こういった形で物語では修辞疑問の例がいたるところで見つけることができます。これらを見つけながら、どのような問いなのか・答えなのか、それらはどのような目的・効果があるかなどを考えてみるのも議論術を学ぶ練習になります。

まとめ

今回は「レトリックと詭弁」から議論術の紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

【更新情報】ホームパネルの設定

※Project-Alphaは2019年12月をもって、サービスの提供を終了します。

今回は我々が開発しているプロジェクト管理ツールProject-Alpha(プロジェクトアルファ)を更新したので内容を説明します。

更新情報

更新内容

プロジェクトのホーム画面にいくと、いくつかのパネルが表示されるようになっています。今回の更新により、このホーム画面に表示するパネルを自由に選択できるようになりました。

またプロジェクトのホーム画面のパネルは移動・サイズ変更ができるようになっており、その変更した設定は自動で保存されます。

更新画面など

例えば、プロジェクトのホーム画面が以下のようになっているとします。

このとき、プロジェクト設定からホーム設定を選択して状態を確認します。

確認すると、ガントチャートの「進捗表」、「サマリ表」、「日次累計工数グラフ」、そして「タスク一覧表」が選択されています。またルートフォルダは常に表示されるので、これらがホーム画面に表示されています。

このホーム設定の表示を以下のように変更して更新してみます。

更新後のプロジェクトのホーム画面は以下のようになります。ホーム設定の変更が反映されています。

これらの表示されるパネルは対象のコンテンツに対して、更新可能か参照の権限がある場合のみ表示されます。権限なしの場合はパネルは表示されません。

ホーム画面でのパネルの移動とサイズ変更

ホーム画面で表示されるパネルは、その移動やサイズ変更が可能です。
以下ではパネルの位置を移動させたり、サイズを変更すると自動で配置が切り替わる動きが確認できます。

表示するパネルの列数を変更することで、サイズの変更単位が変わります。以下では3列から4列の表示に変更した場合の状態になります。

まとめ

今回は更新情報の内容の説明でした。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

home.prj-alpha.biz

「レトリックと詭弁」から議論術を考える①

今回は香西秀信「レトリックと詭弁」から議論術を考えていきます。 

レトリックと詭弁 禁断の議論術講座 (ちくま文庫 こ 37-1)

レトリックと詭弁 禁断の議論術講座 (ちくま文庫 こ 37-1)

 

「護心術」としての議論術

著者はまえがきの中で、「護心術」という言葉を用いて議論術を学ぶことの意義を説いてます。人間は論理的な生き物であり理屈を通すことを重要視するがゆえに、自分が論理で説得されることを嫌うのです。

だから最も重要な論理で、理詰めで説得されることをあたかも精神の敗北のように感じ、それを自分で認めたくないわけです。
(まえがき: P7)

逆に議論に勝つことが喜びをもたらすのであれば、議論をむやみに他人に吹っかけてくる人間が当然います。論破とか言ってくるタイプの人ですね。このような人々から、言葉によって自分の心を護るために議論術を身につけようと言っています。

この理詰めで説得されることを嫌がるというのは実感としてわかります。そこに反論の余地がなければないほど、大きな敗北感とそれに反発する感情が生まれます。また議論ではなく感情の操作によって説得されることは、理詰めの場合とは逆に問題とならず、むしろ快感を与えます。
この辺りの特性を考えると誰かを動かしたい場合、理詰めだけで説得するのではなく感情にも働きかけることがより効果があります。理詰めの部分も反論の余地を残したり、一部はあえて自ら負けるように仕掛けておくと、反発が少なく動かしやすい状態になるでしょう。
会社で考えてみると管理職・マネージャーは「権限を利用して人を動かすこと」ができます。このとき、「私には権限があるから動きなさい」という理屈は、部下・メンバーにとって時には反発を生みます。そうならないように感情に働きかけておき、権限という理屈ではなく、求められて動いているという状態を目指すと良いかもしれません。
話はずれますが、更に発展して部下・メンバーが自分の意志で動いているという能動的な状態を築けることは、リーダーシップの一つの形態と見ることもできます。

問いの技術が議論を制する

本書では「問いは議論を制す」として問いの問題に多くのページを割いています。
議論における問いには大きく2つの区分があると説明しています。1つは知らないことを尋ねたり整理するための単なる情報の要求、もう1つは何事か論証しようと意図を含んだものです。この意図とは相手をうろたえさせたり沈黙させたりしたり、他の聞き手に相手の議論に関する不信感を抱かせたりするものです。

こうした場合の問いは、何かわからないことについて説明を求める体裁をとりながら、痛烈な反論として、あるいは聞き手に与える論拠として用いられる。
(第一章: P19)

単なる情報の要求のように「何かわからないことについて説明を求める体裁」をとっているため、答える側は問われたことに対して答える必要が出てくることになります。このように疑問のかたちをとっていながら、その疑問の内容を聞く事が目的でない問いは修辞疑問として紹介されます。
また問う側の大きなメリットとして、問いに使用する言葉を自由に選択できるというものがあります。今回はこの2つを中心にして考えていきます。

議論における修辞疑問

本書の中で修辞疑問の例をいくつも取り上げられています。「どうやってそれをやれというのか」、「誰がそんなことをやれと言った」といった反語的なものや、「ここをどこだと思っているんだ」といったわかりきってることを聞く問いもそうです。

問いの形式による効果

反語的な表現やわかりきっていることを問いの形式にするのは、どのような効果があるのでしょうか。議論において問いにすると、形式上、問われた相手は答えることを要求されます。答えることを要求されため、何か対応する必要が出てきます。
このとき問いに答えられないこと、沈黙してしまうことは口頭での議論において致命的となります。

問いはその形式上の約束として、それに対する答えを要求します。だから、問いに対して沈黙した人は、問われたにもかかわらず答えられなかったということになり、その沈黙を敗北の証拠として言質に取られてしまうのです。
(第二章: P78)

現実の議論においては勝敗を判定する審判はいませんが、沈黙は少なくとも暫定的な配所を認定する指標となりうるのです。その議論を聞いてる他者にはそのような印象を残すことになるでしょう。

また問いに答えられたとしても、その回答自体が問う側にとって有利に働くことがありあます。問う側は自分に都合の良い言葉を使いながら、相手から「自分の言葉で確認させ、その言質を取る」ための回答を促す問いを行うことがあるのです。このとき問う側はわからないことを聞いているのではなく、どのような回答をするかをわかっていながら言質を取るために問うのです。

こちらの知らない答えを聞くためではなく、こちらがあらかじめ承知している答えを確認するために、そして多くの場合、相手がその答えを選択できず沈黙に追い込まれるのを誘導するために問われます。つまり論法としての問いは、本来の問いの機能として働いているのではない。
(第二章: P63)

修辞疑問は、問いの形式をとりながら、答える側に自分の言葉で確認させその言質を取ることを目的とした問いであり、更には答える側が答えることができず沈黙に追い込むための問いです。

出された問いにどう応じるか

ここまで修辞疑問の効果を確認しました。それでは答える側はどのように対応すれば良いでしょうか。本書の中では、あえて無理な答えを返してしまうという方法も強引なやり方として説明していますが、「答える」(answer)ではなく「言い返す」(retort)ことを説明しています。

「はい」か「いいえ」を要求する問いに対して「はい」か「いいえ」で答えるのが『answer』であるならば、『retort』はそのような問いの妥当性を、あるいはそれを問うという行為の是非を問題とします。
(第一章: P31)

例えば、 「その問いの内容自体がおかしい」といった対応です。
また問いそのものが引っ掛けの場合、答えること自体が敗北につながるので、その問いを壊すように言い返すようにします。AとBの定義が曖昧な状態で、AかBかを答えさせるような問いです。このような問いに回答すること自体が引っ掛けです。AかBか回答した後に、問う側はAかBの別け方がおかしいなどといった追及が可能となり、それについて答える側は更なる問いを受ける状態に追い込まれる可能性があります。そこで回答を行う前に、AとBとは何かを問う側に言い返すことで、その状態に追い込まれることを避けることを説明しています。

問う側は好きな言葉を使用できる

問う側の大きなメリットとして、好きな言葉を使用できるというものがあります。

問いを構成する言葉を自分で選ぶことができるということです。答える側は、こうして選ばれた言葉に合わせて、その問いに答えなくてはなりません。この事情が、議論の中で、問う側を格段に有利にしてしまうのです。
(第一章: P20) 

 本書で紹介されている事例を使いながら確認していきたいと思います。

二極化・相対化による操作

AとBという2人の人がいたとして、どちらの言うことを信じるのかと問われる状況という前提で言葉を変えながら考えていきます。ここでは「言い返す」(retort)ことは考えず、問いに「答える」(answer)ことだけを考えます。

まず初めに「AとB、どちらの言うことを信じるのか」という問いを考えます。この場合、答える側は「A」か「B」といった形式で回答することが多いかもしれませんが、「Aの方をより信じます」といったり他の表現で回答することができます。これは問う側からすると、予期せぬ修飾を伴った回答がくる可能性があることになります。

次に「AよりもBの言うことを信じるのか」という問いを考えます。この場合、答える側は「はい」か「いいえ」で回答することになります。この問い方にすると回答の仕方が上の問いに比べると狭まります。この問いでは「Aよりも」という言葉により、「はい」(Bの言うことを信じる)と答えると「Aの言うことも信じてるが」という意味が含まれてきます。AとBに関して相対化した表現にすることで、より比較が強調された印象を与えることになります。

次に「Aの言うことは信じないが、Bの言うことは信じるのか」という問いを考えます。こちらも「はい」か「いいえ」で回答することになります。この問いでは「Aの言うことは信じない」という言葉により、「はい」(Bの言うことを信じる)と答えると「Aの言うことは信じない」という意味が含まれてきます。このように二極化した表現にすることで、答えるのを難しくしたり答えることで言質をとることができます。

現実では議論の流れの中で問うことになりますし、答えることなります。また気付きにくい表現になっていることも多いでしょうから、どのように問うか答えるかを意識していないと不要な痛手を被ることでしょう。

人物の表現を変える

ある人物を示すとき、その人物の名前以外にも色々な表現があります。本書の中では以下のように言っています。

人間は、場によって異なった資格・職能をもつため、同一の人間がその場に応じてさまざまな「名」で呼ばれうる。
(第一章: P24) 

このことについて、「AとB、どちらの言うことを信じるのか」という問いの「A」や「B」を人物などの表現に変えてどうなるか考えてみます。

例えば、「先輩と後輩、ちらの言うことを信じるのか」という表現はどうしょうか。2人の関係性を持ち出し、経験値が豊富な方が有効である、と問う側が意識して発しているのです。他に「ベテランと若手」など色々と考えられます。
「頭の固い人と斬新なアイデアの持ち主」とするとどうでしょうか。この表現の場合は、経験値が足を引っ張っているのでは、と問う側が意識して発しています。

他に人をグループ化した名称を使用することもあります。「賛成派と反対派」「推進する人たちと保守的な人たち」といった表現です。注意したいのはグループ化の名称はある種のレッテルをはるのに有効になってることがあります。例えば「反対派」という表現は全てに反対しているかのような印象を与えますが、現実ではある一部分に関して反対しているだけのことが多いでしょう。レッテルをはることで問う側はなんらかの方向性へ議論を向かわせるようにすることがあるのです。

個人とグループを並べること表現もあります。例えば「社長と反対派、どちらの言うことを信じるのか」はどうでしょうか。片方は「社長」というその人の組織内での地位、もう片方は「反対派」という意見に対する姿勢・属性の表現です。本来比較される対象でない名称をあえて並べて問いを行っています。「何を言ったか」より「誰が言ったか」が重要になるような組織や場面においては、このような表現が強烈に有効になることがありますので、気を付けましょう。
ここで気を付けるというのは、相手が使ってくることもあれば、自分でも使ってしまうことがあるからです。このような問いをすることで、相手が言い返してきた場合、自分が苦しくなる立場になることになります。本書ではこのような表現は詭弁として注意するように促しています。

間違った問いの可能性

問う側の言葉によっては問いそのものが間違っていることもあるかもしれません。

例えば「なぜ日本にはグーグルが生まれないのか」といった問い方を考えてみます。グーグルではなくアマゾンやアップルとしたり、またはそれらを併記してることもありますし、スティーブ・ジョブズといった人名のこともあります。これは日本という国でグーグル(のようなIT企業、といった意味で問われることが多い)が生まれない理由を何かという問いになっています。
日本と指定していますが、日本以外の国ではどうでしょうか。それを考えるとアメリカ以外で生まれていないというのが正しいようです。その場合、「なぜアメリカにはグーグルが生まれるのか」または「なぜアメリカ以外にはグーグルが生まれないのか」、あるいは「アメリカでは生まれるのに、なぜ日本にはグーグルが生まれないのか」といった問いの方が適切なようです。
この問いの場合、事前に「アメリカでは~」という前振りがあったりと前後で議論されていることの方が多いでしょう。ここで意識しておきたいのは、受け入れやすい言葉によって、間違った問いになっているかを見落とさないことです。

まとめ

今回は「レトリックと詭弁」から議論術の紹介でした。

以上

【関連するリンク】

www.prj-alpha.biz

JavaScriptのDateオブジェクトを文字列で作成する場合について

今回はJavaScriptのDateオブジェクトのメモです。

時刻なしの日付文字列で指定する場合、ハイフンで行うとき注意する

Dateオブジェクトをnewするとき、指定する方法がいくつかありますが、日付文字列で指定する場合について調査します。
結果は Google Chrome で起動した場合の例になります。
まずはスラッシュで区切った日付文字列の場合です。

var date =new Date("2018/10/1");
console.log(date);

コンソールでは以下のようになります。想定通りです。

Mon Oct 01 2018 00:00:00 GMT+0900 (日本標準時)

次はハイフンで区切った場合です。

var date =new Date("2018-10-1");
console.log(date);

コンソールでは以下のようになります。こちらも結果は同じです。

Mon Oct 01 2018 00:00:00 GMT+0900 (日本標準時)

続いては少し日付を変更して、確かめます。

var date =new Date("2018/10/10");
console.log(date);

コンソールでは以下のようになります。想定通りです。

Wed Oct 10 2018 00:00:00 GMT+0900 (日本標準時)

次はハイフンで区切った場合です。

var date =new Date("2018-10-10");
console.log(date);

コンソールでは以下のようになります。

Wed Oct 10 2018 09:00:00 GMT+0900 (日本標準時)

この場合、時刻の部分に差異があり、「09:00:00」となっています。この時間は日本の時差の分と一致しています。この原因を調査すると、ハイフンで日付文字列にした場合、UTCとして扱われるためのようです。
developer.mozilla.org

注: ブラウザごとに動作が異なり一貫性がないため、Date コンストラクタ (または同等の Date.parse) で日付文字列を解釈しないように強くすすめます。RFC 2822 形式の文字列のサポートは、慣例にすぎません。 ISO 8601 フォーマットのサポートは、日付のみの文字列 (例: "1970-01-01") が地方時ではなくUTCとして扱われる点で異なります。

しかし、「2018-10-1」のときはUTCではありませんでした。これは ISO 8601 の年月日の形式が「YYYY-MM-DD」であり、日が2桁表示だからです。「2018-10-1」の場合、ISO 8601 の形式ではありませんが、ブラウザ側で日付として解釈してDateオブジェクトを作成しているようです。(例えばIE11で試すと、「Invalid data」としてエラーとなります。)
正しい形式で指定した場合、どうなるか確認してみます。

var date =new Date("2018-10-01");
console.log(date);

コンソールでは以下のようになります。

Mon Oct 01 2018 09:00:00 GMT+0900 (日本標準時)

この形式の場合、UTCとして扱われていることが確認できました。
ISO 8601 の年月日の形式が「YYYY-MM-DD」ですので、ハイフンを利用してDateオブジェクトをnewする場合、日にちだけでなく月の部分についても2桁になるようにしておかないと時刻まで扱うときに不具合の要因となるので注意しましょう。例えばgetTime()を利用して日付の大小比較をしているときなどです。それまで問題なかったものが、MM-DDとなる10月10日からおかしくなってしまうという問題が発生するかもしれません。

まとめ

今回はJavaScriptのDateオブジェクトを文字列で作成する場合についてでした。

以上

【更新情報】工数推移グラフの表示

※Project-Alphaは2019年12月をもって、サービスの提供を終了します。

今回は我々が開発しているプロジェクト管理ツールProject-Alpha(プロジェクトアルファ)を更新したので内容を説明します。

更新情報

更新内容

ガントチャートで登録した内容から工数の推移がわかるグラフを表示できるようになりました。ガントチャートの入力画面から「表・グラフ」を選択して、工数推移グラフを選択すると新しいウィンドウで表示されます。

工数推移グラフで開始から終了までの期間の工数推移が分かるようになります。予定については、開始日付と終了日付が入力されているものが反映されます。実績については、開始日付が入力されているものが反映されます。進捗率があっても、開始日付が入力されていない場合、グラフ上には反映されません。

またマイルストーンの設定を行っている場合、その日付についてラインで表示されます。表示するラインの日付は以下の優先順位で入力のある日付上に表示されます。
①実績の終了日付がある場合、その終了日付
②実績の開始日付がある場合、その開始日付
③予定の終了日付がある場合、その終了日付

グラフの配色について

予定や実績の色については、進捗表の設定と同期しています。プロジェクト設定のコンテンツ設定から変更することが可能です。

例えば、進捗表の設定を以下のように変更します。

この場合の、工数推移グラフは以下のようになります。進捗表も同時に表示することができ、配色が同期するようになっていることがわかります。

※追記 以下の追加更新を行っています。

マイルストーンだけでなく基準日付もラインで表示されるようになり、タイトルだけでなく日付を表示するようにしました。

更に日次推移以外にもグラフを表示できるようになりました。

週次推移の場合は以下のようになります。

週次工数の場合は以下のようになります。各週ごとの予定と実績の工数を棒グラフで表示します。

 週次工数推移の場合は以下のようになります。累計工数と週ごとの工数を同時に表示されます。

各グラフの凡例の名称にマウスを乗せると、そのグラフ以外がうすくなります。またこの名称をクリックすると非表示となり、再度クリックすると非表示から表示に戻ります。

例えば予定工数をクリックして、非表示にした場合の表示は以下のようになります。

まとめ

今回は更新情報の内容の説明でした。
現在はこの表示のみですが、グラフについては今後複数のパターンで表示できるようになる予定です。

以上

【関連するリンク】

www.prj-alpha.biz

www.prj-alpha.biz

home.prj-alpha.biz

Laravelのクエリビルダを構築するメソッドの検討 - Select文を作成する②複数の結合条件の対応など

今回はPHPフレームワークの一つのLaravelの中から、データベースのクエリビルダを自動構築する設定を検討してみたいと思います。具体的には取得条件のテーブルなどの定義情報を渡して、クエリビルダを構築するメソッドを検討します。今回利用するDBはMySQLです。SQLの基本が理解できていることが前提となります。
これまでの内容は以下を参照してください。

Laravelのクエリビルダを構築するメソッドの検討 - Select文を作成する① - 商売力開発ブログ

Select文の構成

前回までの説明で結合条件と取得するカラムについて対応しました。以下のようなクエリ定義情報を渡すことでクエリビルダを構築するようにしました。

$queryDef=[
   'table' => [],
   'join' => [],
   'select' => [],
];

$queryDef['table']=['table1','joinTable2','leftTable3'];

$queryDef['join']=[
    [
        'tblNo' => 1,
        'type' => 'join',
        'cond'=>[
            ['leftTblNo' => 0,'leftCol'=>'col1','ope'=>'=','rightTblNo' => 1,'rightCol'=>'col1']
        ]
    ],
    [
        'tblNo' => 2,
        'type' => 'leftJoin',
        'cond'=>[
            ['leftTblNo' => 0,'leftCol'=>'col1','ope'=>'=','rightTblNo' => 2,'rightCol'=>'col1']
        ]
    ],
];

$queryDef['select']=[
    [
        'tblNo' => 0,
        'column' => 'col1',
        'alias' => NULL,
    ],
    [
        'tblNo' => 1,
        'column' => 'col2',
        'alias' => 'ColName',
    ],
];

ただこのままだと、使いにくい部分があるので、変更を加えていきます。

取得する部分の設定

取得するカラムの設定については、テーブルのNoと列名を指定することで取得してます。このままだと計算式などができないので、DB::rawメソッドで対応できるようにします。例えば以下のようなrawフラグをクエリ定義情報に追加してみます。'column'にDB::rawメソッドで使用する文字列を設定しています。注意が必要なのは、テーブル名のプレフィックスとして設定する文字列(この場合、「tbl」)を含めた形式で記述する必要があります。プレフィックスを変更する場合、こちらの設定も変更する必要が出てきます。

$queryDef['select']=[
    [
        'tblNo' => 0,
        'column' => 'col1',
        'alias' => NULL,
        'flgRaw' => FALSE,
    ],
    [
        'tblNo' => 1,
        'column' => 'col2',
        'alias' => 'ColName',
        'flgRaw' => FALSE,
    ],
    [
        'tblNo' => NULL,
        'column' => 'tbl1.col3+tbl2.col3',
        'alias' => 'ColRaw',
        'flgRaw' => TRUE,
    ],
];

この追加したフラグを元に、addSelectの部分を変更します。

for ($i=0; $i < count($queryDef['select']); $i++) { 
    //flgRawの有無
    if($queryDef['select'][$i]['flgRaw']){
        //flgRawの場合、カラムからのみ設定する
        $addCol=$queryDef['select'][$i]['column'];
    }else{
        //テーブルとカラムの設定
        $addCol=$prefix.$queryDef['select'][$i]['tblNo'].'.'.$queryDef['select'][$i]['column'];
    }
    
    //別名の設定
    if(!empty($queryDef['select'][$i]['alias'])){
        //別名を設定する
        $addCol=$addCol.' as '.$queryDef['select'][$i]['alias'];
    }
    //flgRawの有無
    if($queryDef['select'][$i]['flgRaw']){
        //DB::rawとして設定する
        $addCol=DB::raw($addCol);
    }
    
    //カラムの設定
    $query->addSelect($addCol);
}

この状態でtoSqlメソッドで確認すると以下の結果が得られました。

select
  `tbl0`.`col1`
  , `tbl1`.`col2` as `ColName`
  , tbl1.col3 + tbl2.col3 as ColRaw 
from
  `table1` as `tbl0` 
  inner join `joinTable2` as `tbl1` 
    on `tbl0`.`col1` = `tbl1`.`col1` 
  left join `leftTable3` as `tbl2` 
    on `tbl0`.`col1` = `tbl2`.`col1`

問題なくDB::rawメソッドの部分も設定されました。

複数条件による結合

joinやleftJoinの結合条件について、その結合条件の数が一つの場合はメソッドの引数に指定しますが、複数ある場合は、第2引数にクロージャを指定して設定することになります。

//結合条件が一つの場合
$query->join('table2', 'table1.col1', '=', 'table2.col1');

//結合条件が複数の場合
$query->join('table2', function($join){
    $join->on('table1.col1','=','table1.col1');
    $join->on('table1.col2','=','table1.col2');
});

複数の結合条件を構築するには、クエリ定義情報から動的にクロージャを定義し、それを渡すことによって対応することができそうです。ですが動的にメソッドを定義することは、ちょっと調査しても簡単に対応できそうにないので、他の方法で対応します。
具体的にどのように対応していくかと言うと、結合条件が一つの場合の書き方とDB::rawメソッドを利用して、複数の条件を渡します。結合条件の左辺の部分をDB::rawメソッドで設定し複数の条件と最終条件の左辺まで記述して対応するイメージとなります。

//結合条件が一つの場合と同じ形式にして、DB::rawで対応する。
$query->join('table2', DB::raw('条件1' and '条件2' andand '最終条件の左辺'), '=', 'table2.col1');

クエリ定義情報の結合条件を複数持てるようにし追加してみます。

$queryDef['join']=[
    [
        'tblNo' => 1,
        'type' => 'join',
        'cond'=>[
            ['leftTblNo' => 0,'leftCol'=>'col1','ope'=>'=','rightTblNo' => 1,'rightCol'=>'col1'],
            ['leftTblNo' => 0,'leftCol'=>'col2','ope'=>'=','rightTblNo' => 1,'rightCol'=>'col2'],
        ]
    ],
    [
        'tblNo' => 2,
        'type' => 'leftJoin',
        'cond'=>[
            ['leftTblNo' => 0,'leftCol'=>'col1','ope'=>'=','rightTblNo' => 2,'rightCol'=>'col1'],
        ]
    ],
];

このクエリ定義情報から、結合条件が一つの場合と同じ形式にして、DB::rawメソッドで対応するように設定すると以下のようになります。

for ($i = 0; $i < count($queryDef['join']); $i++) {
    //左辺に設定する文字列
    $leftString='';
    //結合するテーブルと別名の設定
    $joinTable = $queryDef['table'][$queryDef['join'][$i]['tblNo']].' as '.$prefix.$queryDef['join'][$i]['tblNo'];
    
    for ($j = 0; $j < count($queryDef['join'][$i]['cond']); $j++) {
        //左結合カラム
        $leftCol = $prefix.$queryDef['join'][$i]['cond'][$j]['leftTblNo'].'.'.$queryDef['join'][$i]['cond'][$j]['leftCol'];
        //等号などの演算子
        $operator = $queryDef['join'][$i]['cond'][$j]['ope'];
        //右結合カラム
        $rightCol = $prefix.$queryDef['join'][$i]['cond'][$j]['rightTblNo'].'.'.$queryDef['join'][$i]['cond'][$j]['rightCol'];
        
        //左辺の文字列への設定
        $leftString = $leftString.$leftCol;
        
        if($j != count($queryDef['join'][$i]['cond'])-1){
            //最後の結合条件でない場合、左辺の文字列に、演算子と右結合カラムを追加し、and条件で設定する
            $leftString = $leftString.' '.$operator.' '.$rightCol.' and ';
        }else{
            //最後の結合条件、結合の種類ごとに設定する
            if($queryDef['join'][$i]['type'] == 'join'){
                //join
                $query->join($joinTable,DB::raw($leftString),$operator,$rightCol);
            }elseif($queryDef['join'][$i]['type'] == 'leftJoin'){
                //leftJoin
                $query->leftJoin($joinTable,DB::raw($leftString),$operator,$rightCol);
            }
        }
    }
}

この状態でtoSqlメソッドで確認すると以下の結果が得られました。

select
  `tbl0`.`col1`
  , `tbl1`.`col2` as `ColName`
  , tbl1.col3 + tbl2.col3 as ColRaw 
from
  `table1` as `tbl0` 
  inner join `joinTable2` as `tbl1` 
    on tbl0.col1 = tbl1.col1 
    and tbl0.col2 = `tbl1`.`col2` 
  left join `leftTable3` as `tbl2` 
    on tbl0.col1 = `tbl2`.`col1`

問題なく結合条件が設定されています。これにより複数の結合条件にも動的に対応できるようになっています。この対応によりクエリビルダを自動構築するメソッドの対応範囲が大きくなり、色々な場面で利用できるようになったと思います。

まとめ

今回はLaravelのデータベースのクエリビルダについて、定義情報から構築する方法を検討しました。
今回の検討により、Select項目や結合条件については、ある程度対応できる状態になりました。この他の設定については、また別の機会で紹介します。

以上

【関連するリンク】 www.prj-alpha.biz www.prj-alpha.biz

【スポンサーリンク】