非IT現場のRPAをVisual Studio 2019でやってみた

用意するもの
・windowsの入ったPC
・Visual Studio 2019
・VB.NETやC＃が書けるプログラマ

まずインストールしましょう。

無料のやつでいいです。
visualstudio.microsoft.com

Visual Studioってめちゃくちゃ簡単にツール作れるんですよ。ボタン押したら何かするようなツール、例えば他社に依頼したらどんなに少なくても５万円くらいするようなシステム、慣れていれば１時間くらいあれば作れちゃうんですよ。

まあこれ一本で食べていくには、大量にツールを作らないといけないので私には無理ですが、上流工程のエンジニアやITコンサルが、ちょっと自分の周りの仕事をRPAするにはExcelマクロの100万倍効率的だと思います（当社比）。

Windowsアプリケーションは新しいプロジェクトからソリューションを作れば簡単に作れます。
VBAをやってきた人はVB.NETを選ぶといいと思います。それ以外の人はC＃でいいんじゃないでしょうか。
私は新卒で入社した会社がVB.NETでやっていたので、そっちを使います。
プログラマであれば言語の市場価値のようなものも重要かもしれませんが、自分だけでちゃちゃっと作るツールの言語選定などどうでもいいことです。

いいところ

・日本語
・環境構築が難しくない
・型定義の厳密性を変えられる（いいのか？）
・昔からある言語なので、ググれば日本語で答えが出てくる
・簡単なRPAのようなものから、何百画面のシステムまで色々作れる

難しいところ

・dllとかexeとかが分からないと、そもそも参照も継承もできない
・VB.NETプログラマは主にWEB系の人に下に見られる（言語に貴賎はありません！新旧や好みがあるだけ！）
・ググるとVBAがヒットしてきて割と邪魔

ただし、経験の浅いプログラマがwindowsアプリケーションを適当に作ると、メモリリークができていなくてPCがフリーズしたり、Excelを開いたまま解放せずに大量に溜まってしまったり、例外処理ができていなくてマウスもキーボードも効かなくなったり、とんでもない爆弾を作ることになってしまうので、よくわかっている元プログラマが、昔取った杵柄で片手間にやると役に立つというイメージです。

最近プログラミングスクールが注目されていますが、WEB系ばかりですよね。
windowsアプリケーションが作れるって結構非IT現場で即戦力になると思うんですが、非IT現場に新人を送り込む訳にもいかないし難しいところですね。

【ディベート超入門】テスト前の夕飯にカツカレーを食べるべきか

テスト前のカツカレーでディベートを説明しました。

SlideShareからダウンロードできるので、ご自由にご活用ください。

今回はこのスライドをちょっと補足して解説していきます。

ディベート超入門ー立論構成編ー from Midori Inukai

 

ディベートは第三者を説得する議論

これの理解が最も難しいです。今回の場合は、太郎くんというジャッジを説得する、肯定側（お父さん）と否定側（お母さん）です。

実社会では否定側＝ジャッジということもあるかもしれませんが。誰がこの件のジャッジなのかを探ることこそ難しい場合もあります。ですからこのディベートというのは、ある種実社会とは離れた存在なのです。だからこそ、実社会では磨けないスキルを重点的に磨くことができます。歩いているだけでは鍛えられない筋肉が筋トレで鍛えられるみたいなものですね。

現状維持という立場

前提として「いつも野菜中心の料理を食べているから野菜料理なら食材は揃っている」としたのは、否定側は最初「現状維持」という立場を取るためです。なぜ現状維持なのかというと、新たに別のプランを出したときには、そのプランのメリット・デメッリットを別途議論する必要があるからです。例えば太郎くんにはお姉さんがいて、「太郎が一番好きなのは生牡蠣だから、生牡蠣を食べた方が頑張れるよ」と言い出した場合には「牡蠣を食べるとあたるかもしれない」というそのプランに対するデメリットを、カツカレーとは独立して考えなければなりません。中高生の日本語ディベートでは、否定側は現状維持の立場しかとれません。

 

プラン導入前後の対比構造

プラン前後は対比していなければなりません。

こういう図をシステムマップと言います。

たとえば、カツカレーを食べなくて、ゲンを担げなくても、プラン後と同じ結末の「テストでいい点が取れる」になるのなら、カツカレーを食べる必要がありません。

カツカレーを食べるべきとは言えません。

このあと質疑や反駁がありますが、このシステムマップの対比構造を徹底的に突き崩していくことになります。

よく「立論時点で立っていない」「イニシャルで切られた」というのは、立論の時点でこの構造がジャッジに伝わっていなかったということです。

今起こっている問題がプランをとっても起きる、というような主張をする否定側は要注意です。それは、肯定側のメリットに対する反駁であって、否定側の示すべきデメリットではありません。実は否定側は肯定側とイーブンにしさえすれば勝てるので、肯定側を０にすれば、デメリットがなくても勝てます。しかし、それは現実的ではありません。太郎くんがカツカレーを食べた方が頑張れる可能性が少しでも残ってしまった場合には即負けとなります。頑張れる可能性と比較するための何か、それが脂っこくてお腹を壊すかもしれないというデメリットです。

 

肯定側も否定側もやる

どちらのサイドにも立つことは絶対的にお勧めします。

社会で生かすことを考えると、投資効果をずっと言い続ける人と、投資効果とリスクを考えた上で投資効果が大きいと言える人のどちらが説得力があるでしょうか。この肯定する理由を考えると同時に否定する理由を考えるというのは、ある程度訓練しないと自然には出てきません。

ぜひ両方やってみてください。

 

カツカレーシリーズ、しばらく続きます。

非WebエンジニアのReact＋Django開発

Web開発経験：

新卒の頃phpを少し

2年前くらいにASP.NETを少し

最近ScalaとTypeScriptを少し

もともとVB.NETがメインのSIerのPGで、最近は分析でPythonを使っていました。

その程度の知識の私ですが、この度簡単なWeb開発をする必要があったので、フレームワークをどのように決めたかメモしておこうと思います。

ちなみに下記はだいたい３日くらいの話だったと思います。

前提条件

• APIは用意されていない。
• Web画面であればなんでもいい。
• 接続するDBは変わる可能性がある。
• メイン業務はPGではないので、簡易に開発したい。
• 後々機械学習要素を取り入れたいからPythonで書きたい。

１、バックエンドのFramework選定

Pythonで開発したいということで選択肢は限られていて、DjangoかFlaskかなと思いました。他にもありますが、とにかくこの２つを試しました。

最初に試したのはDjangoで、何もしていないのに管理画面が作られて感動。これで行こうかなと思ったんですが、ファイルが多い。フォルダ構成もかっちり決まっているみたい。Setting.pyがうまくいかないと何かとうまくいかない。

次に試したのがFlask。ファイルが少ない。とにかく軽量。自由な構成で、自由に書ける。

これで一旦はFlaskで行こうと思いました。

２、フロントエンドのFramework選定

これはなぜかあまり迷いませんでした。Reactです。

divをReturnするという記述方法がなんとなくしっくり来たんですよね。一応他にもいくつか試しましたが、印象にありません。

３、バックエンドとフロントエンドを結びつける

ここがWebエンジニアでない初心者の難関でした。

Flaskの中にReactのフォルダ構成を入れる？Djangoの中にReactのフォルダ構成を入れる？そういうことをやっていて、色々パス設定を変えたりして大変でした。全然うまくいかない。

それで思い出したんです。最近 Scalaでやっていた仕組みを。バックエンドとフロントエンドは分けるんです。バックエンドはREST APIにして、完全に別々で動かす。

ということで、結局Django rest frameworkを使うことにして、Flaskは忘れて再始動です。

（不慣れな人がFlaskで書くのは難しいんじゃないかという周囲からのアドバイスもありました）

React＋Djangoは調べるとたくさん出てきます。でも、切り離してしまえば別にお互いにFrameworkはなんでも良いわけで、わざわざ「＋」と考える必要もないんですね。

フォルダを分けて各々起動させることで無事開通しました。

４、開発環境/ツール

VS Code

Postman

MySQL workbench

Chrome

５、バックエンド対フロントエンド

こういう記述が調べているとたくさん出てきたんですが、なんで戦っているんですかね。よく分かりませんでした。一人で全部作れた方がいいと思うし、お互いできない部分を尊敬しあって仕事した方がいいと思います。

言わずと知れた名著 

Web API: The Good Parts

始まらないデータ分析プロジェクトが始まる５つの質問

データ分析プロジェクトを始めたいというところは多くあります。

展示会にも行き、ベンダ選定をしているにも関わらず始まらないのはなぜでしょう。

そこで、今回はデータ分析プロジェクトを始めるためにしておく５つの質問を挙げます。

分析をしたいと思うきっかけになった出来事はありましたか？

分析の目的として、利益の最大化や業務の効率化を図りたいというのは聞かずとも誰もが思っていることです。それを具体的に分析していくためには、「これが出来ていないからダメなのではないか」という仮説が必要です。ただ、「仮説はありますか？」と聞いても、人々は仮説という概念で世界を捉えていないため分かりません。

逆にこのきっかけになる出来事がないのに、漫然となにかいいことができるんじゃないか、と思っているだけだとプロジェクトは進みません。何より、それは現状の業務に特に問題を感じていないということです。仮になんらかの分析を出しても、驚くような効果は見込めないでしょう。

しかし、きっかけになる出来事がすぐに浮かんでこなくても根気強く聞いてください。例えば、「新商品の類似品を過去に出しているはずだが、その時の売上を見ることができなかった」「機械が故障するタイミングが分かれば営業しやすいはず」などです。ここまでブレークダウンさせることが分析プロジェクトを始めるファーストステップです。

その時どういう対応をしましたか？

問題となる出来事に対して、その時なりに手を打ったはずです。

ではそれは、どこにあるどういうデータを見ることにしたのか。それがexcelでも紙の資料でもホワイトボードに日々書いている数字でもいいです。どういう指標を使って、どのように判断したのかが、データ分析で重視したい指標になります。

それが蓄積できているのであれば分析を始められますし、蓄積できていないのであれば、蓄積するというプロジェクトが始まることになるのです。

その対応のどの部分を変えたいですか？

言われてみれば変える必要がないな、ということなら、わざわざコストをかけてデータ分析プロジェクトをしなくても良いのです。当然効果を感じてもらうこともできません。

どう変えたいかで分析の方向性は大きく変わってきます。データ分析は、レポーティングとシステム構築に大きく二分されます。つまり、分析者に望むこととして、定期的に分析した結果を報告書にして欲しいのか、分析結果を常時見られるシステムを構築して欲しいのかということです。データ分析企業を選ぶときも、どちらをやって欲しいのかによって会社も契約もプロジェクトの進行も全く異なるものになるでしょう。

これが、仮説に対する今望んでいるデータ分析の形です。

一つ注意してもらいたいのは、「こういうグラフならいいんじゃないか」「こういう仕組みにしたらいいんじゃないか」というところまでは聞かないでください。細かい形式や仕組みこの段階で決めてしまうと分析者が本来発揮すべき専門性を狭めてしまいます。

その対応は効果がありましたか？

効果がなかったというなら問題です。前述の何も対応ができなかったという場合も同じです。

その効果は何で測ったのか、どれくらい効果があったのかがこの質問で分かります。効果があったかどうか実はうまく測定する術を持っていないということもあります。これも課題の一つとして認識し、プロジェクトの中で効果をどのように測ればよいのか決めていく必要があります。

十分な効果があったのなら、３つ目の質問にまた戻ります。効果があったのにどこを変えたいのかを詳しく聞いていきます。

これまでにデータ分析のプロジェクトをしようとしたことはありますか？

今までのプロジェクトが進まなかった理由を聞いていきます。どこまで進めたのか、どこでやめたのか、なぜやめたのか。その時の資料をもらえれば具体的に検討することもできます。

今回のプロジェクトが同じ理由で頓挫しないための布石です。

これまでの失敗したプロジェクトを最低限超えなければ、今回のプロジェクトも進めることはできません。

おわりに

いくつか課題が出れば、同じ仕組みで解決できるかできないか、優先順位はどうするかなど考えることができます。一つでもいくつでも良いですが、全てを一度に進められるわけではないことも気にしておきましょう。

以上紹介してきた質問は、決して参加者を責めることなく、あくまで建設的な意見出しとしてくれぐれも注意して行ってください。

会社員のためのお遊び論題集

会社勤めをしていてディベートをしていたことがバレると、会社でやってみたいという声がたまに上がります。

しかし、会社員にとってディベートがどうも他人事なのは「政策を決定する」ということが日常生活から遠すぎることが一因としてあるように思います。

これは日本語ディベートが「日本は〜」から始まるということです。

そこで、会社の中の研修で使える簡単な論題を考えました。

順次シナリオを書いていきたいと思います。

会社員お遊び論題集

・当社はバレンタインデーおよびホワイトデーの慣習を廃止すべきである、是か非か

・当社は会社猫制度を導入すべきである、是か非か

・当社は交通機関の計画運休時の出社を原則禁止すべきである、是か非か

・当社はスニーカーでの通勤を認めるべきである、是か非か

・当社は女性管理職の登用を推進すべきである、是か非か

・当社は男性の育児休暇を認めるべきである、是か非か

・当社は本部機能を移転すべきである、是か非か

論題はどうやって決めるか

実は論題の決め方にも理論があります。

論題

議論する価値のある関心ごとを、肯定と否定に別れて議論できるように書き記した文

『英語ディベート理論と実践（松本茂2009）』

 ディスカッションと大きく異なるのは、このようにYESかNOに別れることができるように設定されているということです。

誰々が何すべき、というのは政策論題と言います。（もう一つは判断論題といい、歴史認識などの解釈を判断するような事実論題、愛か金かなどの価値を問う価値論題があります。）

この論題のことをプロポジションと言いますが、これの大きさも重要です。

私たちが普段取り組んでいるのは、小プロポにあたります。何をすべきであるかの範囲が小さく絞り込まれていて明確です。

会社というのは、ともすれば大きな命題に取り組もうとするあまり、何をすべきか誰もなにも細分化してくれない状況に陥ります。「当社は業界の中での固有の価値を創出すべきである、是か非か」なんて問われても、じゃあそのために詐欺まがいの行為をしますとなったら当然ダメだし、設備投資しようかとなれば詳しく話をしようともなると思います。こういったことに対してディベート的にはそういう議論領域があって、その論理的構造から結論を導くこともしますが、それは一般的な感覚ではありません。

小プロポ以外で戦ったことがないので、中以上のプロポが具体的に何かというのはよく区別できていないですが、要するに、議論できる小ささまで話を落としていくことが必要です。

明日からの仕事に支障のないこと

ディベートは議論と人格を分けています。自分の意見と反対側になったらその立場で議論をします。しかし、ディベートに慣れていない会社でやる場合、「あの時ああ言っただろう、本当は心の中ではそう思っているんじゃないか」のような話にもなりかねません。

競技ディベートと会社でのディベートが大きく異なるのは、会社員には先輩や上司からの評価があり、それが出世や収入に直結するということです。これは大変重要な問題であり、上記から論題を選ぶ場合でも、遊びで済むのか、意見としての効果を持ちうるのかは慎重に検討しなければなりません。

その意味では、実は「当社は〜」のように身近に引き寄せずに、あくまで「日本は〜」から始まった方が、明日からの仕事には支障がないのです。このことを踏まえて、あえて「日本は〜」で始まる他の論題に目を向ける必要があると思います。

一般的なお遊び論題

「ドラえもんは２２世紀に帰るべきである、是か非か」というのが、高校生くらいの頃は一斉を風靡していました。しかしこれは難しいのです。漫画の展開としての是非を問うものととらえるか、漫画の世界観の中で登場人物にとっての是非を問うものととらえるか、これでそもそも話が噛み合わないことが多くありました。

私が初めてディベートをする人にまずやるお遊び論題は

・太郎くんは今晩カツカレーを食べるべきである、是か非か

　＊明日は定期テストとする。

という献立系の論題です。

会社員なら、明日は大事なプレゼンの日とか、要はなにか大事な日の前ということですね。

想像しやすい上に、これに勝っても負けてもどんな主張をしても、確実に誰も仕事にも学校生活にも支障がなさそうでいいですよね。

これは結構何度も説明していて色々ネタがあるので、スライドでも作ろうと思います。

次回からはお遊び論題のシナリオを書いていきます。

ディベート技術部201908 報告

ディベート技術部2019年8月定例を開催しましたので報告します。

本日は４名（うちリモート１名）の参加でした。

参加者はconnpassやSlackのグループで募集しています。

今回は運営に関することがメインでした。

色々issueを考えることができましたが、リソースも限られているし、順次解決していくためにまとめていけたらと思います。

１、どこまでシステム化するのか、何をシステム化するのか

・運営をフルにWebシステムにしているところもあれば、スプレッドシートを活用する、黒板に書いてアナログで運用する、など色々ある。結局回ればそれでよくて、システム化は手段であって目的になってはいけない

・持ち運べるサイズのノートPCを持っているのが普通だと思っていたが、意外とそうではないらしい。大学生はレポートをどうやって書くのかというのは、大学のPCや図書館のPCを使っていて、今ではスマホからも書けたりする。家にあるのはデスクトップPCや大型のノートPCで持ち運びではない。これによって、大会のときに使えるPCには限りがあり、これが属人化の要因の一つにもなっている。

・誰が何をできるのかをもっと把握したほうがいい

２、適正引用について

・今回ブログやTwitterで発言してみたり、全国大会の開会式で案内があったように通達に「こういう引用に気をつけて」というものがあるが、それを見たことのある選手はどれくらい居るのか（ちなみに今回のメンバーも、通達の存在自体知らない人も居ました）。webサイトのトップページからたどり着けるようにすると良いかもしれない。

・文意解釈AIは今の技術でスクラッチするのは難しい。Googleなど大手の自然言語処理の今後に期待。

３、Web会議システム

・今回初めてWeb会議をしてみたけど、Skypeで試合ができる時代なんだから運営の準備もWebでできる。

・無料のWeb会議ツールは色々あるので今後色々試してみたい。

・今回使用したのはapper.in

・集まるの自体は楽しい

４、今回の会場

Wi-fiと電源が取れるところを探して行ってきました。

Wi-fiは30分ごとに切れる。店内は土曜の夕方ですが混んではおらずゆっくりできた。全席禁煙かと思ったけど、喫煙可。

肉が旨いカフェ NICK STOCK 渋谷道玄坂
東京都渋谷区道玄坂1-19-12 道玄坂今井ビル 1-2F
https://tabelog.com/tokyo/A1303/A130301/13209007/

５、メンバー募集と次回

18歳以上で高校卒業（高専４年生）以上のディベーターを募集しています。

現状、各々役割のある人が集まっているというだけで、新たに参加したから何かをしなければいけないということはないので、緩くみんなでわいわいディベート界を盛り上げていけたらいいなと思います。

次回の予定は決まっていませんが、横のつながりを増やすことで抱え込んでいた問題が解消できるといいと思いますので、色々な人に声を書けて話を聞いてみたいと思います。

適正引用チェックシート

これまでの記事と、いろいろなチームを見てきた経験から、大会１週間前だからこそやってほしい引用資料のチェックシート作りました！

ご自由にお使いください。

引用関連の細則も１ページに収まるようにしました。