  |
はてなキーワード: EXcelとは
https://honeshabri.hatenablog.com/entry/The_Honest_Truth_About_Dishonesty
この件ですが。
ダン・アリエリーが主犯だとすると、捏造があまりにも杜撰すぎませんか。
そもそも論文を書くにあたって偽のデータをこしらえなきゃいけないモチベーション、インセンティブは何なのかというところから考えると、
のどちらかだと思うんです。
上記記事のブコメでは①の推測も散見されましたが、これは明らかにおかしいでしょう。
①がモチベーションになるためには、そもそも不正の無い状態で生の実験をやって、その結果が思っている結論と合わない、じゃあ捏造しようというプロセスを踏むはずです。そうであれば今回のデータの捏造方法はおかしくないですか？
去年のデータは半分だけ使って、そのコピーを乱数で揺らして二倍に。今年のデータは去年プラス乱数。謎ですよね。結論に合わない実験データが既にあるのであればそれを結論に合わせて弄っていくだけのはずです。余計な手間をかけて杜撰にしていると思いませんか？
②のデータが手に入らなかったについては不正を行うに至る状況としては理解できます。しかしそうであれば保険会社に協力を仰いだ意味はなんなのか？協力したという保険会社自体が存在しなかった？いやいやそれなら、去年の半分のデータはどこから来たのかということになります。
結局不正を行うモチベーションがいまいち掴めないんですよね。おまけに杜撰でもある。隠し通すつもりならふつう一様乱数なんて使わないでしょう。
わざわざ杜撰なやり方でデータを捏造し、そのデータを自分で公開する。案の定そこから不正がバレる。そんなに彼は無能の極みみたいな人なんですか？ちょっとそうとは思えません。
それに比べれば本しゃぶり氏の提示した「保険会社の作業者面倒くさがった説」の方が遥かに結果に対する説明力が高い。一様乱数というのが特にこの説の補強になっています。Excelでrandと入力して吐き出されるのは、一様乱数ですので。
ところでこの説に対しては「ダン・アリエリー本人は何故一目でそんな杜撰なデータを見抜けなかったのか。見抜けたはずだ」という反論が多く見られますね。
ただこれってそこまで簡単に見抜けるというほどでもないと思うんですよ。
出てきたデータ自体が一様乱数と言うなら並べた時にわかって当然だとは思います。
ただ、今回疑いの根拠となった一様分布だという話は「年間走行距離」、すなわち「今年ー去年」の値なんですよね。直接収集したデータは去年の累計値と今年の累計値なんです。
まあ今年の値が去年の値に一様乱数を加算して作られているのだから、そりゃ差分が一様分布になりますよね。
ここで理解してほしいのは、実験自体にはこの「差分」の値は登場していないということです。
去年のデータは実データをダブルにして作られているのだからまともな分布になっている可能性が高い。今年のデータはそのまともな分布に一様分布を足し合わせている。去年のデータが十分大きい場合、これもあまり変な分布に見えなかったとしても仕方がないことではないでしょうか？
結局これが変なデータだと気づくためには、実験本体には何ら関係ない「個人ごとに差分をとる」という計算操作を実施しなければいけないわけです。
それをするっていうのはどういう時でしょうか？そう、「初めからデータを疑っている時」です。
公開されたデータを見た検証者たちは当然疑いの目をもってそれをチェックします（それが検証ですから）。データの不備も考えるし、著者の捏造も視野に入れます。だから差分でも何でもとって分布をチェックするでしょう。
一方でダン・アリエリーはどうだったのでしょう。協力パートナーである保険会社から出てきたデータをわざわざ「今年のデータは去年のデータに乱数を足しているかもしれない」などと考えて引き算をしてみるのでしょうか。まあ研究者ならするべきだったのでしょうが、しなかったとしても責められはしないだろうと思います。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
Excelっていうか中身はOpenDocument準拠だべ？まーExcelで本気出せばプラスアルファの機能もつくけど・・
・端末用にデータ組んどいた → サーバーサイドで処理できないから手動補正している
A B C
1 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
2 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
3 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
4 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
5 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
6 [ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ][ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ]…
…
仕事の同僚なんて、その職場にいる時だけの付き合いだから、好きも嫌いもなかった。
はずなんだけど、異動してきた同僚がマジで嫌い。
文句を言うのに忙しくて、手を全く動かさないので、毎日の進捗がほぼない。
締め切りに間に合わずペアの自分が謝罪しまくって納期を調整している。
Excelがつかえないので、データを電卓叩いて計算。しかも間違える。
前の組織では仕事を貰えず、いじめられていたと泣きながら話す。(実際はコピーと郵便仕分しかできる仕事がなかったらしい)
任せると2時間で終わる仕事を2日かけて仕上げてくれる。締め切りは無視する。
締め切りに間に合わないので、1人で仕事すると、自分に仕事を振らないのはなぜかと問い詰められる。
なんだかんだミスを拾っていて、大きな被害がないから人事も動いてくれない。
あっちが辞めて欲しいけど、多分こちらが先に辞めると思う。ずっと一緒にいると病みそうだし、早く離脱した方が自分の精神的にもよいはず。
ここに書いたらスッキリしたわ。
次の職場にも同じような人がいないことを祈る。
先輩｢増田ぁ～、△△（会社内でのみ通じるオフィシャルでない略称）やっといてほしいんだけどいい？｣
私｢すいません、△△ってなんですか？ちょっと初めて聞くので教えてください｣
この段階だと「あれ？いったことなかったっけ？」って心境かな
この時には「とりあえず見たらわかるから見てから聞けよめんどくさいな…」って心境かな
多分その結果が
だと思う
この時は「お前俺今までいなかったろ、ていうかそんな議事録作る会議に選択肢あるか？」って心境かな
まぁ相手方が正常と仮定しての決め付け想像だから話半分に聞いてくれればいいけど準備万端で環境整ってからスタートっていうのは理想だろうけど難しいだろうし完全に理解してからしかやらないってのは一般人には土台無理な話。
それよりとりあえず言われたまま動いてから質問のほうが的確に質問も理解もできる。
議事録の内容も8月までそのままでその後動かすっていってるなら8月に動かすのは勝手な想像だし指摘されてもしょうがないかな
大雑把に想像すると先輩たちの思ってることは「やってから聞け、ただしやってる途中で迷ったら聞け、勝手に判断するな」がほとんどじゃないかな
先月配属されて、主に先輩や上司から突発的に頼まれた雑用をやっているんですが、指示が必ず完全に意味不明で毎日毎回困り果てています。
状況が正しく伝わるよう、なるべくそのまま指示を出す周りの人と私とのやり取りを書き記します。
先輩｢増田ぁ～、△△（会社内でのみ通じるオフィシャルでない略称）やっといてほしいんだけどいい？｣
私｢すいません、△△ってなんですか？ちょっと初めて聞くので教えてください｣
先輩｢うん、誰々のフォルダにExcel入ってるからそれいじってやってくれればいいよー｣
私｢えっ？？？ あの、△△って具体的にどういう仕事なんですか？△△自体初めて聞くので知らなくて……｣
先輩｢ああそうなの？なんか紙入ってるからそれ見ればわかるよ。じゃあ、俺もう出るからよろしくね｣
他には……
上司｢増田ぁー。議事録さあ、適当にワードで書いて作っといてよ。簡単でいいから｣
上司｢いや、昨日やった会議の議事録だよ（笑）ほら、俺とか次長とかゾロゾロ2時頃応接室行ってたじゃん、それのやつ。簡単でいいからさあ｣
私｢あの、私その会議に出席してないのでどんな内容の会議だったか教えて貰っていいですか｣
上司｢ええ……まあいいや。倉庫の在庫あるじゃん。あれは8月までとりあえず置いといて、そっから移すことに決まったからそう書いてくれればいいよ｣
私｢それだけでいいんですか？｣
上司｢そう｣
私｢わかりました｣
その後
上司｢ん？在庫置いとくの8月までじゃねえぞ？？？移すの10月だぞ（笑）｣
一事が万事この調子なので、さすがにやばいと思い年齢が近い先輩にこれまであったことを相談しました。
その先輩は｢雑だなあ……うちの会社の人ほんとみんないつもそうなんだよなあ｣と困惑してましたが、くれたアドバイスは｢慣れるしかない｣でした。
そのうち私の評判は｢増田は大卒だから頭が固い。全部説明しないと仕事こなせないマニュアル人間｣という感じになってしまいました。
また、こうなるまでにどうすればよかったと思いますか？
自分がおかしいのではないかと思い、他の人同士のやり取りを観察していたんですが
上司｢あの、先輩くんさあ。〇〇のやつ、あらあらでいいから作っといてくんない？｣
先輩｢わかりました｣
なんでこれで理解できるのかと衝撃を受けました。