AOKI's copy&paste archive

高専から駅弁大学から東工大を経て大企業へ 浅く広い趣味とかキャリアの日記を

SQL.py

背景

業務上のデータ分析において。

注意事項

都合、固有名詞的な機密に関連しそうな部分は置換して隠す。
モジュールのインストールや詳細な結果は割愛。
環境はAnacondaのSpyderを利用。
細々と修正していくにはJupyterの方が便利かもと感じたりも。
まあデバックモードを使いこなせていないとも。

方法

題名通りSQL的内容をPythonで。
単純なデータ結合ならMSのAccessで十分だが、使い慣れておらず、また追加的分析も行うには相性がいいだろうと押し通した。

コード

#%%import modules
import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.datasets import load_boston
from sklearn.tree import DecisionTreeClassifier
from sklearn.tree import export_graphviz
from io import StringIO
import pydotplus
from IPython import display
from sklearn.metrics import classification_report, confusion_matrix
import statsmodels.api as sm

#%%Load Data
df_rent = pd.read_csv(r"C:\xxx\rent.csv", 
                 encoding = "utf-8", 
                 parse_dates = ['xxx_date'])

df_rent['xxx_date'] = pd.to_datetime(df_rent['xxx_date'],
                                        errors = 'coerce')

df_tel = pd.read_csv(r"C:\xxx\tel.csv", 
                 encoding = "utf-8",
                 parse_dates = ['xxx_date'])

#as sql left outer join
df = pd.merge(df_rent, df_tel, how = 'left',
              left_on = 'ID', right_on = 'ID')

#%%Set Dummy target value
df.loc[df['types'] == 'zzz', 'flg'] = 1
df.loc[df['types'] == 'zzz', 'tgt_flg'] = 1
df.loc[df['status'] == 'cancel', 'tgt_flg'] = 0
df.loc[df['tgt_flg'] != 1, 'tgt_flg'] = 0
print('target sarf', sum(df['tgt_flg']))

#Exclude invalid SARF
df = df.query("tgt_flg == 1 | (tbl_flg == 1 & (`xxx_date()`.notna() | `xxx_date`.notna()))", engine='python')

#As Export for Excel Pivot Table
df0 = df
df0.to_excel(r"C:\xxx\merge.xlsx")

#%%Set Dummy Basic Info
df['Type_Fix'] = df['Type'].replace(r'\_.*', '')

df_region = pd.get_dummies(df['region'], prefix='region')
region_list = list(df_region.columns)


#%%Set Dummy as Large Cate
for yyy in yyy_list:
    df[yyy] = df['type'].str.contains(yyy)
    df.loc[df['type'].str.contains(yyy, na = False), 'category'] = yyy
    
df = df.fillna({'category': 'その他'})


#法人
df = df.fillna({'法人種別': '-'})
df.loc[df['法人種別'].str.contains('法人'), 'corp'] = '法人'
df.loc[df['法人種別'].str.contains('個人'), 'corp'] = '個人'
df = df.fillna({'corp': '分類不可'})


#%%LT
date_list = ['xxx_date']
for date in date_list:
    date_alt = date + '_int'
    df[date_alt] = dt_now - df[date]
    df[date_alt] = df[date_alt].dt.days


df['LT'] = df['xxx_date_int'] - df['xxx_date_int']
df = df.fillna({'LT': 0})
df['LT'] = df['LT'].astype('int')


#%%Model Setting
x_list = ['LT']
x_list.extend(region_list)

y = df['tgt_flg']
y = y.astype('int')
x = df[x_list]


#%%corr
corr = pd.concat([y, x], axis = 1).corr()
corr_series = corr['types']
ttl = x.sum()

#%%decision tree analysis
def decisiontree(x, y):
    #adjustment required
    tree_clf = DecisionTreeClassifier(max_depth = 6,
                                      min_weight_fraction_leaf = 0.1,
                                      class_weight = {0: 1, 1: 100})
    tree_clf.fit(x, y)
    predicted = tree_clf.predict(x)
    print(len(y), ': ', int(sum(predicted == y) / len(y) * 100),'%')
    y_pred = tree_clf.predict(X_test)
    print(confusion_matrix(y_test, y_pred))
    print(classification_report(y_test, y_pred))
    
    g = StringIO()
    export_graphviz(tree_clf,
                    out_file = g, 
                    feature_names = x.columns, 
                    class_names = True, 
                    rounded = True, 
                    filled = True)
    graph = pydotplus.graph_from_dot_data(g.getvalue())
    graph.set_fontname('MS UI Gothic')
    #Setting font for Node 
    for node in graph.get_nodes():
        node.set_fontname('MS UI Gothic')
    
    #Setting font for Edges 
    for e in graph.get_edges():
        e.set_fontname('MS UI Gothic')
        
    graph.progs = {'dot': u"C:\\Program Files\\Graphviz\\bin\\dot.exe"}
    display.display(display.Image(graph.create_png()))
    
    import  matplotlib.pyplot as plt
    feature = tree_clf.feature_importances_
    label = X_train.columns
    indices = np.argsort(feature)
    
    fig =plt.figure (figsize = (10,10))

    plt.barh(range(len(feature)), feature[indices])

    plt.yticks(range(len(feature)), label[indices], fontsize=14)
    plt.xticks(fontsize=14)
    plt.ylabel("Feature", fontsize=18)
    plt.xlabel("Feature Importance", fontsize=18)
    
    

print(x.columns)
X_train, X_test, y_train, y_test = train_test_split(x, y)#, random_state=0)

decisiontree(x, y)


#%%model
x = x.astype(int)
model = sm.OLS(y * 200, sm.add_constant(x))
result = model.fit()
print(result.summary())


#%%Summary TBL
df_merge = df[df['tgt_flg'] == 1]

fp = pd.crosstab(df['flg'], [df['region'], df['prefecture']],
                  margins=True)

fp_ = pd.crosstab(df_merge['flg'], [df_merge['region'], df_merge['prefecture']],
                  margins=True)

fp_ratio = fp_ / fp * 100

#%%out-sorced to excel
df_merge.loc[df_merge['tgt_flg'] == 0, 'invalid_column'] = np.nan

pvt = pd.pivot_table(df_merge, index = 'reason', columns = 'corp',
                     values = 'LT', margins=True)

感想

と思っていたらジョブローテでBigQueryを扱うようになった。
環境が整いゴリゴリにSQLで書いてる。
そもそもデータが極めて大きいときは、いくら高性能だろうがサーバーに叶うわけもなく、ローカルで処理すべきではないですよね。

ただやはりモジュールを結合して、グラフ等をそのまま整えられるのは便利だ。
それもクラウドSQLで集計したのをローカルにエクスポートすればいいわけだが。

余談

ちなみに上記の作業において、下記なども参考になる。

youtu.be

Bars

Sometimes bar charts are avoided because they a are common. This is a mistake. Rather, bar charts should be leveraged because they are common, as this means less of a learning curve for your audience. Instead of using their brain power to try to understand how to read the graph, your audience spends it figuring out what information to take away from the visual.

Bar charts are easy for our eyes to read. Our eyes compare the end points of the bars, so it is easy to see quickly which category is the biggest, which is the smallest, and also the incremental difference between categories. Note that, because of how our eyes compare the relative end points of the bars, it is important that bar charts always have a zero baseline (where the x-axis crosses the y-axis at zero), otherwise you get a false visual comparison.

my BS / PL on 2022

非常に雑ではあるが昨年の家計簿をあえてカタメに経済的にまとめてみた。

細かい話はしていないので、それぞれ有効数字は1,2桁の世界である。

また経済学専攻ではないので色々細かいところはご愛嬌願う。

 

あえてTableauでのViz化にあたり、SQLテーブル的に費目ごとに数値をリスト化し、それを再統合する形式をとった。費目のみならず、グラフ上での属性を定義するため、その定義づけのカラムも設けた。

直近、DB操作に関する業務も増加しており、自己設計として復習になるところもあった。

 

なにはともあれまとめたのが下記となる。

Viz

単位は万円。

 

https://public.tableau.com/views/2022myfinance/1?:language=en-GB&:display_count=n&:origin=viz_share_link

 

PL

revenue

詳細はご覧の通りだが収入が450万である。

 

微々たるものだが配当やポイントも美味しい。

 

expense

これに対し税金がやはり結構しょっ引かれているのが可視化されている。普段の給与明細だとわかりにくいし、なんなら銀行の振込額しか気にしていないというところもあるにはあるが、あまりに乱暴だ。冷静に見つめ直せば、リバタリアン的に怒りも湧いてくるというものだ。ちなみにこの税金は給与明細で処理されるもののみなので、消費税などの間接税は含まれない。。

これでもサラリーマンなので個人事業主や法人よりはマシなのだろうが。。

 

また普通の消費としてクレカの履歴を1年遡ると消費額は160万だった。

家に入れる代わりのインフラ費用が含まれているが、子供部屋おじさんなので極めて安価に済んでいる。やはり家賃がないのが最も大きいか。

また食費は会社の福利厚生も利用できているので、ここは別居してもあまり変わらなそうだ。

 

クレカも費目を細分化するとより面白いかもしれない。

会社の飲み会の交際費や上記のようなある程度仕方ない消費に対する娯楽系の金額割合も気になる。まあ金欠ではないので現状必要性は薄いが。

 

余ったお金は原則投資につぎ込み、NISAの枠を活かしつつ、超過分を個別株に賭けている。会社名は一旦伏せておくこととする。いずれも日本株である。

 

さらに完全にフリーなキャッシュフローとしての現金が銀行普通口座の残高だ。

とはいえ、これは今月に奨学金の繰上返済に充てられる。

 

その他上記でトラッキングできない現金消費、主にラーメン屋があるが、ここはあまりに管理が煩雑且つキャッシュレス生活において微々たるものなので無視している。

 

BS

PLは今年の収入と支出を比較的シンプルに表すことが、このいわば演習を通じて学べた。

それに対しBSの概念は特に個人だとやや難しい。

 

assets

分かりやすいのは資産の部門としての現金および有価証券:株・投資信託だ。

それぞれ口座に記載があるので分かりやすい。

技術的裏話として、現金はPLとも同様の行のデータから取得させた。

 

PLでの株は今年の買付のみしか示さなかったが、BSだと保有全量を示すことになる。

特に株は昨年にかなりの額を注ぎ込んだので、若手にしては貯まった。

とはいえ日本株は順調なものの、テック偏重だった米株は赤い。。

 

liabilties

車も家も買っておらずローンを組んでいないので、この部門はかなりあっさりしている。

唯一的なのが貸与型奨学金という名の債権だ。PLにも月払いが示している。

とはいえこうして可視化してみると、全体に占める返済額は小さく、一体何年かかるんだという具合だ。おそらくこれでも少なめな方ではあると思うが。

 

このBSを見比べて奨学金<投資なんだから、サッサと返済しろと思われる方もいるだろう。その意見はごもっともだ。ただ大半が第一種の無利子なので、こちらは繰上げの経済的利点がない。

であれば社会的割引率の原則に従って、現金を債権化した方が効率的だ。また有利子も一部含まれるが、これも利子を比べた損得勘定をすれば答えは出るだろう。

また返済を遅延しているわけではないので、契約通りの履行であるから、それほど問題ではないはずだ。

 

最後にポイント。これは会社の先輩に興味深い話を聞いて流用している。その人も人づての話らしいが。

ポイントはPL観点では収入として消費に充てることができるが、いざ貰うとそれは未来に消化しなければいけないものになる。

というのもポイント原資たる購買は、そのポイント付与よりも以前に行われているためだ。このあたりの詳しい話は専門を探してほしい。

別にネガティブなものではないが、経済的にシビアに直視するとこうなるのは腑に落ちるところだ。

Schema

一見関連性のないテーマたちだが、タイトルのスキーマという概念に関連が見える。

そういう面白さも感じたので、まとまりきらなくもあるがまとめてみる。

言語学

【参加申込受付中】2022年12月2日(金)開催:Global Leadership Cafe #5 Jack Halpern氏講演「My four-decade journey through the fascinating world of kanji and languages」 - ToTAL - 東京工業大学リーダーシップ教育院

ToTALで面白そうな話題が開かれていたので参加してみた。

辞書編集者のマルチリンガルが話者で、東工大トリリンガルと母国語で話していたりしてすごかった。小並感

細かい点は省略するとして、まず響いたメッセージが言語学習に対する態度。

いわばYES LEARN, NO STUDYといったところ。

これは英語のニュアンスを把握しないと伝わりにくくもあるが、機械的で研究的な学習に否定的だった。

これは考えても見れば当たり前のことで、多くの言語学習者はその言語を研究することを目的とするのではなく、コミュニケーションの道具として習得しようとしているにすぎない。大げさかもだが、多くの場面で手段が目的化しているとも言えそうだ。

自発的な心がけと熱意こそが重要だ。

具体的な態度として、彼はスピーキングを推奨していた。まあ分かる。

直截的な表現こそなかった印象だが、日本の公教育の英語教育の批判そのものに聞こえた。

実際に業務上でも稀に英語は使うが、文法がどうとかはあまり重要ではない。これは次章でも同様の話がある。

それからツールの話に移行した。最近は言語学習用のアプリも充実していて

  • dulingo
  • babbei
  • busuu
  • linq
  • glossika

などがある中、dulingoはオススメしないとのことだった。

逆にそれ以外は未知だったので知るいい機会になった。

向き不向きの個人差や語彙・文法などの役割や目的も異なるだろうから、これらはうまく活用したい。

もっともこうした表面的な部分は、本公演の主たる聴衆の学歴の上澄みには響きにくいだろうが、その根本たる哲学的な部分や外国人の漢字の受け止めもまた聞いていて面白い話だった。

英語学習

上記の本を読む:認知するきっかけになったのは以下の記事だ。

記事自体が個人的に興味深く、英語学習に現時点では必要性や課題が薄まっているものの、岩波新書は薄いしサクッと読んでしまおうと思った次第だ。

「英語スピーキングテストは愚策」と、認知科学者が断言する理由:日経ビジネス電子版

テストや公教育のあり方は一旦置いておくとして、英語学習の方法や態度を考えたい。

と思ったが、どうしても特に子供は、テストの結果という目的から逆算されるため、切り離すのは難しい。

繰り返すが、これは実際に業務で英語を使っていてしばしば感じる。

これは個人的なガサツな態度からも来るところだが、細かい文法なんてどうでもいい。

5文型、冠詞、可算名詞、関係代名詞、いずれも多少間違ったところで、相手が人間である以上大体伝わる。人間は文脈を補完できるから。

もちろん正しい文章の方が正確で手戻りも少ないが、だからといって最初から完璧を目指す必要はない。

小学生、中1の初学者だろうが、とりあえずはありあわせの語彙と文法でコミュニケーションを取ろうと努力を繰り返せば、自ずと英語力は強化されるはずだ。

学校時代を振り返っても実践的な応用には著しく欠けていた。発言するにしても教科書を音読するだけで、自身で作文するという機会が圧倒的に不足していた。

そういう問題点が記事にも繋がるとも言えるかもしれない。

とはいえ、ここまでは本を読んだ上での個人的な持論で、本の要旨とはかなり異なる。

本の内容を簡潔にまとめて紹介すると、本記事の題のスキーマの重要性を説いている。

要はその言語特有の文脈というか文化的背景のようなものである。

具体的には動作について、日本語がオノマトペや副詞を多様するのに対し、英語は動詞そのものを使い分ける点などだ。

それから上記と相反するが、スキーマとしての冠詞の重要性も説いている。やはりこれが不適切だとネイティブには気持ち悪いらしい。とはいえ、「普通」のコミュニケーションでは大体埋め合わせてくれるのでいいんじゃねえと私は思うわけだが。

さらに語彙としてのスキーマを強化するため、オンラインの辞書あるいはそれに類似したツールの使い方を紹介している。

ここも前章と同様に、英語力はなんちゃってTOEIC800程度と依然不足しているものの、大方英語学習を完了した私個人には関係性が低かったものの、それはそれとして読み物としても面白く、英語初学者や学習中であれば尚の事参考になるだろう。

それとそれに関連して、既存の英語学習方法も批判されている。

SQL

最後のこれは無理やり変わり種として仕込んだ感は否めない。

とはいえここまで英語について振り返りつつ、業務でプログラミング言語アセンブリ言語を使用していると、そこに関連性を見出した。

特にGoogle BigQueryにおいては、Schemaというタブが実際に存在している。他の言語にもありそう、しらんけど。

会社の研修や友人からの相談で、プログラミングの習得に苦労するという話は耳が痛くなるほど聞いてきた。

そこで感じたのが私自身の英語学習に対する苦労感だ。

要はPCとはプログラムとは外国人あるいは異星人なのだ。

その忠実な命令を概ね理解さえできれば、語彙:関数の知識が不足していても、プログラムと対話:デバックしてコミュニケーションできる。

逆にPCの文化としてのスキーマを理解できなければ、プログラミングは身につかないのだ。

表面的な習得に苦慮している人は、プログラムを根本的に見つめ直してもいいかもしれない。

いわゆるプログラミングが得意な人らは、これらを自身の内発的動機づけによる繰り返しの実行によるバグへの直面とデバック、StackOverFlowでの検索・解決といったPDCA的プロセスを経て、自然に理解したものと考えられる。

プログラミングの原則的スキーマ

  • 命令は自明でなければならない
  • 情報は予め入力(準備)されなければならない

上記のようにまとめられたりするのかなあと思う。厳密なものは先駆者がいそうだ。

書いていて思ったが、そもそも言語的なアプローチで理解するのが誤りにも思える。

これはどちらかというと数学だ。要は定式化と境界条件だ。

確かに?微分方程式が解けて、プログラミングができないという話は聞かない。そもそも前者の条件がかなり厳しいが。

となるとプログラミング入門書より、算数ドリルの文章題を復習した方が存外近道ということもあるかもしれない。

少し話題の2021の小6の共通テストを扱おう。

令和3年度全国学力・学習状況調査の調査問題・正答例・解説資料について:国立教育政策研究所 National Institute for Educational Policy Research

https://www.nier.go.jp/21chousa/pdf/21mondai_shou_sansuu.pdf

文章題

8 人に, 4 L のジュースを等しく分けます。

1 人分は何 L ですか。求める式と答えを書きましょう。

数学的定義

\displaystyle{
n = 8
}

\displaystyle{
L = 4
}

\displaystyle{
l = L / n
}

Latexをはてなブログmarkdown形式に変換 - ano3のブログ

プログラミング

今回はPythonじゃなくてあえてややこいJavaで書いてみたんだけどね。

class problem{
  public static void main(String[] args){
    int n;
    n = 8;
    
    double vol_all, vol_pp;
    vol_all = 4;
    
    vol_pp = vol_all / n;
    
    System.out.println("1人当たり:" + vol_pp + " L");
  }
}

近況報告と簡易書評

近況報告といえば、読んだインプット量に対してアウトプット足る書評が止まってしまっている。

これはひとえに本業の仕事が忙しく時間が確保できていないためだ。

 

また最近は家での空き時間がもっぱらゲームに当てられていた。

 

どちらも時間の都合でゆっくりめ

スプラは最高B-で主にスクイク、ローラー、ドライブワイパーで、対戦形式としてヤグラが好き

ポケモンは普通にストーリー、時間的にランクマは潜ったところで感ありそう

 

書評としては最新はこれで

 

pytho.hatenablog.com

 

本格的なのはこっちか

 

pytho.hatenablog.com

 

本格的なのはまたやるとして速報版としては降順で以下の通り。

  • 面白かった

もはや論文。硬派が無理なら無理。

東京を含むケーススタディもありつつ、ロンドンとニューヨークの都市空間と特にその管理に焦点を当てている。

日本でも公園の各種禁止など、公共空間がありながらに死につつある中、実際に重要な社会問題感がありつつも、あまり話題になっている雰囲気がないのは悲しい。

事実は小説より奇なり、それだけで面白い、以上。

池井戸潤のイマイチさをリアルの実存観を補ってくれる

ケンブリッジ・アナリティカ然り、米国を主とした有機的な西洋現代哲学は面白いですね。

カウンターカルチャー然り、その原因的なリベラル然り、時代の寵児たるインセル然り、

頭の良さをなんとするか、子供の幸せを考慮しない手段が目的化した教育ママに皮肉として送りたい一冊かな。

進学校と自称進学校の本質的違いに迫り得るところもあり、そうした教育意識高い系がまず参考にすべき良書。

これよりは同じ出版系列から出ている「禍いの科学」の方が生々しくて好きだったので微妙な位置。

政治的リベラルの推進もいいけど、同程度に科学的誤認やバイアスも排除してもらいたいものだ。

参考

 

  • つまらなかった

東工大リベラルアーツセンターの本を読みすぎて陳腐に感じてしまった。

高校生、大学に興味のある人にはおすすめ。

いきいきした感じは伝わったけど、これもふーんで終わってしまった。

日常的な関わりが薄くて、そもそも実存感がないからかなあ。

映画の方が面白い、以上。

書いていることは至極まともだし、流行りの表面的なアジャイル推進のアンチテーゼとしてその根本哲学を説いている。

できている感があるからか特段新奇性を感じず刺さらなかったかなあ。

フェミニズムを否定はしないが心に残らなかった。

もう一回読み直さないとなんとも。。

片付けの話は冒頭だけで、後半はそれに関係ないFPのマウントトークでタイトルで煽っているだけ。

FPとして各種データを集めて参照しているのはいいが、巻末に参考リストも載せないので情弱商売がにじみ出ている感。

単に硬派を求める立場として相性が悪かったというところもある。

Tableau LOD計算がクソ便利な話

今回は仕事に関する内容。

 

Tweets

 

異動

最近出向を伴う大きな異動があった。

業界が完全に変わった、が、そもそもどちらも詳細を見るというより全体を俯瞰する総合職でも本社的機能の部署なのでギリついて行けている。

 

前部署は主幹事業の運用補佐、本社による進捗管理・調整だったのに対し、

現在の新部署はやや新規事業的な企画の効果測定などに従事。

 

Tableau

どちらも具体的にデータを触ることに変わりはなく、いずれでも社内研修で教わったTableauのスキルやその他ExcelPythonなどを使い分けこなしている。

 

pytho.hatenablog.com

 

前部署はどちらかというとToBなビジネスでデータ規模が小さめだったが、

新部署はゴリゴリのToCでデータが大きい。

そこでLODを非常に重宝している。

顧客の情報がガンガン貯まるが、これを顧客ごとの粒度で集計したり、非レコード単位で処理することがしばしばあるためだ。

例えば以下のような具合だ。

{fixed [user_id]: sum[(spend)]}

{fixed [user_id]: count[(item_id)]}

 

これ自体はPythonSQLのgroupbyでもできるが、やはりGUI操作でできるTableauの利便性は強い。

またExcelのピボットのグラフでもできなくはないが、MTG中に上長と設定したフィルターでインタラクティブな図で戦略を練られるのもグッド。

Excelの弱点としては大規模データをそのままでは重く、MTGをサクサクと進めることが難しい点がある。特にライセンス周りで手軽なのは確かだが。一旦中間テーブルを作ろうにもその作業自体がナンセンスでもある。

 

こうした話を具体的にするためにも、統計局には匿名化したデータを公開してもらいたいものだが。

あるいは小分けでしか取得できないが、気象庁のデータを積み上げて、それっぽく見せる記事を今後書くのが現実的か。

 

またこれはあまりいい使い方ではないが、ローカルなCSVファイルの結合云々にも地味に便利だったりする。

最左のデータソースのタブ内で雑にUnionとJoinができて、それを特定条件に絞って、あるいは上記のFixedなどの計算式のカラムを付加してエクスポートできる。

 

しかし先日あった話として、何故かテーブル内に格納されない計算式があり、これを含また全レコードを排出しようとしたら重すぎてエラーになってしまった。

手軽さはあるものの実際的な器用さはPythonなどの明示する言語が勝るか。

 

キャリア観のアップデート

とはいえ、これらは使いようで、こうして日常的に使い分けられている事自体は良好だ。

ただ思うところもあって、エンジニア入社を除いた同期と比べても明らかにデータ分析や操作系は長けているが、上位1%に入る自信はあるし、アイデンティティ的にもなければならない、この得意のみを主幹していていいのかという疑問もある。

個人の思想としてはジェネラリストよりむしろスペシャリストの方が今後の将来においても価値がありそうな気はする。ジョブ型も増えてきている流れで。

だがぬるま湯に浸かっている感があって、面白さがイマイチだ。

 

それと最後に引用したツイートのように、表面的なシンギュラリティが本格的に訪れつつある。

 

普通なら統計の勉強を積んだり、使えるツールをTableauのように増やせば、競争相手の人間に打ち勝ち得たが、AIだとどちらの方向も分が悪そうだ。

 

ただ今の部署が割とマーケ系で、ガチの新規事業のPoCを主幹するような人もいるが、彼らの報告を聞いていてもときめかないというか面白みを感じない。内々で進めているだけなので。これが外部の声を積極的に取り入れたアジャイル的でワークショップ的な企画なら、クソほど面白そうなのだが。

 

という中で前回の記事を書いていて個人の思想においても、リバタリアン的な表示価格改革の企画系なんかは面白そうに見える。

あるいはこれまで入社時から研究の延長として一貫している配送関連や在庫管理問題は面白そうだ。

 

 

労務環境

具体的な業務内容についてやや話しすぎてしまったきらいもあるので、

働き方的なテーマも振り返っておきたい。

 

まず出向により会社が変わったことで労務環境が結構変わった。

これまでは基本毎日出社で9時17時半が定時というガチガチに縛られた環境だった。

これが週1在宅可のフレックスになった。

 

在宅は頻度的に微妙なものの、フレックスは世界が変わった。

ピークの電車に乗らずに済み、程度はあれ寝坊が許されるのは助かる。

特にピークシフトにより長距離通勤でもより座りやすくなったのがありがたい。

 

朝の遅い時間の電車は近距離通勤が多く途中のターミナル駅で降車する人が多い。

逆に夕方も定時前に早上がりしてしまえば、めちゃくちゃ空いている。

学生時代から長距離の通学:通勤には慣れているものの、座れるかどうかは結構違う。

参考

東工大時代:片道1時間40分程度

桶川-(湘南新宿ライン)-渋谷-(東急田園都市線)-すずかけ台

高専時代:片道1時間半程度

桶川-(高崎線)-高崎-(上越線)-新前橋