何かを書き留める何か

数学や読んだ本について書く何かです。最近は社会人として生き残りの術を学ぶ日々です。

朝礼あれこれ

最近、巷で朝礼なる概念が流行っているので、忘れないうちに経験したことがある朝礼を書き綴ってみる。

1社目:定時の30分前に始まる朝礼、定時の1時間前に始まる定例会議

週一回、決まった曜日に定時の1時間前から定例会議が行われていた。 内容は本社で行われた偉い人が集まる会議の議事録から部長が抜粋して口頭で伝達したり、プロジェクトごとの進捗確認などが行われていた。 抜粋は数字の共有が中心で、それに貢献できているのかがわかりづらいものであった。 進捗確認は期限通りに納品できるか否かがすべてで、品質は先方の反応から推し量る手法を採用していた。 定例会議の曜日以外の朝礼は各々の進捗確認がメインであった。

これらの問題は、定時前に行われていることをいいことに残業代を一切支払わなかったことである。 当然、問題視して入社直後にクレームを入れて最初に定例会議分の残業代が認められて、その後朝礼分も勝ち取った。 時は12月になっていた。 その後、朝礼に参加するのは裁量労働制で働く入社して数年たった社員のみとなり、若手は排除されるようになった。 残業代を支払う価値を朝礼に偉い人たちが見いだせなかったのである。

入社して数年たち、裁量労働制が適用されることとなり、裁量労働なのに何故決まった曜日に定例会議に参加しなければならないのか、なぜ裁量労働なのに出勤時間が決まっていてかつ遅刻すると査定に響くのかと闘争を始めた。 また、朝礼ではないが、半年ごとに全社員集まって行う会議とパーティが休日に行われていた。 休日なのになぜ出勤扱いにならないのかと文句を言ったら福利厚生であるという回答がやってきた。 結局、なんやかんや文句を言っているうちに転職してしまった。

2社目:毎週、社訓を絶叫する系の朝礼

入社前に気付くべきであったが、社訓を絶叫する系の朝礼であった。 社訓絶叫、発表したい事柄がある部署からの発表、事務方からの連絡、偉い人のお話という構成であった。 本社では毎週であったが、支社では毎日行われていてさらに加えてエモいエピソードを語るコーナーもあった。 朝礼自体は勤務時間に含まれていたはずである。 社訓絶叫に関しては「ここはそういう会社なんだな」と思い、頭も心も無にして本気でやっている人に失礼がない程度に付き合っていたが、 気になったのは、会社の業績が悪くなっていった頃から偉い人が朝礼に参加しなくなったことである。 本当にこの時間、必要なのかな、と思ううちに朝礼なんかかわいく思える程度のアレコレにより常に頭痛が生じる程度に体調を崩したので転職してしまった。 転職の境目で1ヵ月ほどダラダラしていたが、頭痛がなかったので職場環境が原因だったのだと思う。

3社目:毎週、技術軽視の朝礼

発表したい事柄がある部署からの発表、事務方からの連絡、偉い人のお話という構成である。 入社、退社の発表も必要に応じて行われていた。 1年がかりのプロジェクトの終了直後にトラブルがあった際に、 今まで何もしなかった偉い人が偉そうなことを言ってメンバーのモチベーションを根こそぎ削り取られたのをいまだに根に持っている。 また、最近流行りのミッションバリューが存在するが、現状の言語化ではなく理想の言語化としてミッションバリューを制定したので、頑張ったんだろうなとか、いい話だな、とは思いつつもそれとミッションバリューは違くないかと思ったりするのである。

なお、チーム単位でも朝礼(という名前ではないが)を行っているが、そちらは機能している。

よくわからないまとめ

蛇蝎のごとく嫌われる朝礼であるが、個人的には朝礼そのものは悪いものではなく、会社の状態を映す鏡であると思われる。 また、規模も当然のことながら人数が増えるとそこで伝えられる情報量も減る。 1社目だと勤務時間外にする姑息な手段で人件費を浮かせようとしたが、普通は勤務時間内なので全員参加だとそれだけ嵩むのである。 チーム単位で小規模で情報量を増やすように意識すると有意義な場になるのではないだろうか。

去る言語への餞

お亡くなりになったんだ。このバージョンは、この世を去ったの。事切れてしまった。息を引き取り、GvRの御許に逝かれた。これは『元メジャーバージョン』。EoL。命尽きて、電子の海に還っていった。Python 3移行でもめていなければ、今頃はひな菊いっぱいのレポジトリの下で読み取り専用になっていたはずなんだ。Python 2はその生涯に幕を閉じ、昇天なされたの。これは「元Python」なんだ。

2019年大反省会

自分以外特に誰も楽しみにしていない、年末恒例の反省会エントリを書く季節がやってきた。

過去のエントリは以下の通りである。

2019/02/06 『pandasクックブック』発売

年末に朝倉書店さんに訪問し、打ち合わせをしつつ校閲を行った。 ちょうど仕事納めぐらいのタイミングに体調を崩してしまい、若干朦朧としながら索引を眺めていた。

2019/02/上旬 無限に発生する保守対応

普段の業務の1つにスマートフォンアプリの保守があるが、PMのところで滞留し続けた課題が決壊した。 分け入っても分け入っても青いイシュー。 先方の深夜対応に付き合わされることもあり心身ともに疲弊していた時期であった。

2019/03/26 『PythonによるWebスクレイピング 第2版』発売

初版が出た際は単なる読者であったが、2版では査読者の1人として関わることができた。 この頃はスクレイピング本が何冊も出ていたが、最近(2019年12月)は新しいスクレイピング本が登場しなった気がする。 ある程度ツールやマナーが固まって枯れてしまったのだろうか。

2019/04/26 『Head First はじめてのプログラミング』発売

販促のためにお試し冊子が登場した。 新宿紀伊國屋でも見かけた。

2019/05/24 『できる 仕事がはかどるPython自動処理 全部入り。』発売

Python mini hack-a-thon冬山合宿 2019でレビュワー募集があった。 同じタイミングで『IPythonデータサイエンス クックブック 第2版』も読んでいたので募集に即応はしなかったが、 「読まない?」と誘われたので二つ返事で読み始めた。

2019/05/25 『IPythonデータサイエンス クックブック 第2版』発売

初版が出た際は単なる読者であったが、2版では査読者の1人として関わることができた(2回目)。 2015年から2016年に出たPython本の改訂である。

2019/05/29 DjangoCongress JP 2019に参加

LTの枠が空いていたのでDjango QuerySetのミスを発表した。 QuerySetを書くと自動的に実行計画が見れる機能やら道具があると便利だなあと思うが果たして。

2019/06/上旬 増税のあおりを受ける

ずっとやるやる言っていた開発が増税対応で対向システム側のリソースが枯渇して開発が流れた。 まさか増税するなんて...と本気で思っていたのだろうか、ずっと前から分かっていたのに。 結局、時期がずれただけになったが。

2019/06/26 『Python計算機科学新教本』発売

PythonによるWebスクレイピング 第2版』の打ち上げの席で話題に上がり、 たまたまBooks Kinokuniya Tokyoで原著を購入していたという偶然もあった。

2019/09/18 Pycon JP 2019に参加

今年は発表せず、所属する会社のスポンサーブースのお守りがメインであった。

2019/09/27 『NumPyによるデータ分析入門』発売

PyCon JPには間に合わず。 クラウド回りの情報を最新にアップデートするのは骨が折れる。

2019/10/15 PyCon mini Hiroshima 2019に参加

いくつか考えてあったネタを携えて向かった。 ちょうど台風が日本列島に接近している状況で、開催やら移動やらが危ぶまれたが無事に移動も発表もできて本当に良かった。

2019/11/上旬 理解しがたい方針に振り回される

詳しくは書けないが、しょうもない方針としょうもない対策を上から強制された結果、プロジェクトが全く動かなくなるという事案が発生した。 一体我々はだれのために仕事をしているのか甚だ謎である。

2019/12/26『Pythonによるファイナンス 第2版』発売

思えば半年前からずっと読んでいた。 分厚さから見てもその通りであるが。

全体的な反省

昨年に引き続き、査読を多くこなした。 これはオライリージャパンの編集者の仕事のペースがすごいということも意味している。 Python本もそのうち飽和してくるかもしれないが、いい本をよりよくするために努力をしていきたい。

外部発表は概ね年2回ほどを目標にしているが、一応達成することができた。 業務経験に裏打ちされたリアリティある発表や、数学の体系をうまく示せる発表をしていきたいが、どこまでそれを満たせているのか。

普段の仕事では4月ごろにメジャーバージョンリリースがあったが、前バージョンの保守対応と新規開発が同時進行となり、担当しているプログラマが同一人物であるのでそりゃあ疲弊する。 今年は「いったい誰のために仕事をしているのか」と悩むことが多くあった。 一般のお客さん(to C)が使うものを受託開発する場合、開発する人間のお客さんはその開発を依頼してきた会社とその会社のお客さんの2人存在する。 難しいのは、我々のお客さんは成果物を触る一般のお客さんなのか、発注した企業なのか、どちらなのかわからなくなることである。 一応の解として、「発注した企業は自身の顧客である一般のお客さんのことを真に理解している」という前提を真とするならば、 発注した企業のこと第一に考えて実装すれば自ずと実際に使う人も幸せになれる、というのがある。 理想論であり、「それ、社内政治の結果じゃないの?」みたいな代物もある。 とはいえ、まだ広義のお客さんの方を向いて仕事をしているので健全であると思う。

話がここで終われば受託あるある話なのだが、「いったい誰のために仕事をしているのか」にはもう一つの観点がある。 それは、自社の都合に振り回されることである。 前期の有価証券報告書、特に、「提出会社の経営指標等」を読むとわかることであるが、あまりよい状況とは言えない。 それを打破するための、しょうもない方針としょうもない対策とは、おや、誰か来たようだ。