引越しました（2018年）

引越しをしましたので報告します。

引越し理由

引越した1番の理由は、夫婦の通勤時間削減です。うちの夫婦は共働きですが、それぞれが職場まで、片道1時間から1時間半かかっていました。

元々の通勤経路では、朝の時間帯に特急がなく、朝に移動すると昼に移動するより20-30分余分に時間がかかってました。

通勤時間が長いとストレスがたまり、生活がつらくなります。

その通勤時間を削減するために引っ越すことにしました。

あと、今住んでいる家は、定期借家契約で、ぼちぼち契約更新の話があったのもあります。

引越し先

ざっくり言うと東京の東の方に住むことにしました。

僕は、職場までドアtoドアで45分くらいになりました。

金銭的な負担とか設備を考えた結果、そのあたりにおさまりました。

もう少し通勤時間が少なくなると良かったのですが、現状、職場に近くなる程、家賃が高くなるというのもあり、こんな感じになりました。

個人的に時間以外の通勤のポジティブな話としては以下があります。

• 乗り換えがなくなった。
• 電車の本数が増えて電車通勤が楽になった。
• 家から駅までが遠くなったので、電車に乗ってる時間は減った。

僕は東京での満員電車通勤にすごくストレスを感じるので、移動時間はさておき、電車に乗る時間が減ったのが嬉しいですかね。

歩くのは運動になるし、別にいいかな。と思ってます。僕は。

物件的な話

もともと住んでた物件が分譲マンションだったこともあり、設備的なハードルが高かったなあと思いました。

例えば

• 浴室乾燥機ないとつらい。
• 宅配ボックスは欲しい
• 敷地内にゴミ置場あって、24hゴミ出し可能が良い。

とか言ってるとハードルが高かった。

上の条件を妥協しない代わりに、部屋は狭目にした。

おわり

とりあえず引っ越した報告でした。

また、何かあれば報告したいと思います。

iEmpathyを使ってみて思ったこと

iEmpathyというライティングツールを紹介してもらったことがありました。

empathywriting

一回使ってみたいなと思ってました。実際に使ってみました。感想を書きます。

この記事は、iEmpathyで作っています。

一回３０分程度でできた

僕は、アカウント登録してから一つ目のブログ記事の作成が完了するまで、３０分程度でした。

１回目に時間をかけてしまうと、次にやる時に、めんどくさいと感じてしまうと思ったので、急いで書いています。

とはいえ、１回の文章構成で３０分くらいだと早いと思います。

短時間で文章がまとまる

僕の場合、ブログを書いていると、どんどん書きたいことが膨らんで、話がまとまらなくなります。

そして、時間がどんどんなくなっていきます。

でもiEmpathyは文章を書くのがプロセス化されているので、今、全体の中でどの程度の文章を書いたのか、がわかりやすいですし、全体の作業量見積もりも立てやすいです。

全体の作業量がわかったら、ブログを書くのにどれくらいの時間が必要かもわかるし、短時間で文章をまとめられます。

まとめられる。というのはすごくいいなあと思いました。

文章の構成をサポートしてくれる

書いたあとで、これ何を言いたいのかわからないな。とか話がわかりにくいな。というのがわかりやすいです。

セクションを質問に従って書いた後に、それらを簡単に入れ替えられます。

まだ、一つの記事しか書いてないですが、これは便利だなあと思いました。

ずっと使わなくてもいい

当たり前なんですが、iEmpathyを使い始めたら、ブログとか文章を書く時は、必ず使わなきゃならないという話ではないです。

気が向いた時に使うでもいいのかなと思っています。

あと、iEmpathyの考え方でブログを書くというのは面白いと思うので、その考え方を学ぶために使ってみるのもいいかなと。

使い方は短い動画で説明してる

僕の場合、使い方を動画で学びました。 短い動画でiEmpathyの使い方の説明をしてくれています。

こちらのデモ動画がわかりやすかったです。 https://www.m.empathywriting.com/iempathy

僕は、iEmpathyを初めて使いましたが、わかりやすくて、スムーズに使うことができました。

ちなみに、書籍も関係するのかもしれませんが、僕は読んでいません。

伝えたいことを文章にできる

まあ、最終的に重要なのは、何を書きたかったのか。から脱線せずに文章を仕上げられるということです。

それはすごく重要。

なんとなく、こういうことを伝えたい。というイメージだけはあるのに、何を話せばいいのかわからない時はあります。

でも、このiEmpathyに従って書いていくと、どんどん文章が出来上がっていきます。

質問に答えているだけなのに、何を書けば相手に伝わるのかを考える手間が省けるなあ、と思いました。

以上。

価格の価値観は立場で変わる

ザ・ゴール2を読んでいた。

興味深い話があったから書く。

ザ・ゴール 2 ― 思考プロセス

ザ・ゴール2の中で挙げられている問題で

• 製品に対する市場の価値観は、買ったモノを持つことで得られるメリットで決定される。
• サプライヤーの価値観は、生産コスト+マージンで決定している。

みたいな話が出てくる。

そりゃそうだ。と思ったけど、自分の中で言語化できてなかったから、おもしろいなあと思った。

買う人は手間を買ってるんじゃなくて価値を買ってるのは常識だと思う。

だけど、確かに、これまで見てきた全ての分野で、価格が買う人の視点で決定されていなかったなあと思った。自分も常にそういう視点かどうかは怪しい。

わかりやすい話だと、僕は飲食店で働いてたことがあったけど、飲食店は販売価格を原価率ベースで考えることが多いと思う。それは、原価に手間賃というマージンをのせてると思う。

農業とか土木の領域も『手間賃』という言葉があるような気がして、それは同じように提供する人の都合で価格を決めてるんだろうと思う。

飲食業の中には『おいしい』という価値を買うんじゃなくて、『自分が片付けなくて良い。』とか『自分が作る必要がない。』とか『手間』を売ってるお店があると思う。

その『手間』は、時間に換算しやすいし、時間は、時給を元に価格が想像しやすい。だから原価率で価格を決めるのかもしれないと思った。でないと買う方が妥当に感じれないように思う。

ぼんやり考えてたら、ファーストフードは、手間だけじゃなくて、速さに対して価値を感じてるんだろうなあと思った。

同じ価格と味とメニューで、提供スピードが５倍遅くなったら、価値がすごく低くなる。提供スピードは重要な価値になってる。

提供スピードを速くしつつ、品質を安定させるか、がファーストフードの企業努力なのかなあ、と思った。

あと、飲食業の中でも高級なお店は手間とか、提供スピードは売ってないはず。味とか高級感を売ってるのかなあ。

高級店の価格はどうやって決定されたんだろう？

何はともあれ、価格を考えるとき、マージンではなくて、相手が得る価値で考えないとうまくいかないと思う。

とはいえ自分が定期したい何か、もあるはずで、きちんと自分が提供したい価値を考えないと何をやってるのかわからなくなりそうだなあと思ったりした。

Linuxディストリビューションってなんだろう

Linuxディストリビューションがわかってない。ここではなんとなく知っていることと、知らないことを整理しつつ、インターネットで調べたことを書こうと思う。

写経したら疑問が出てきた

最近、PyQをやってて、思ったことがある。

それは、

• ドキュメントを読んだり、本を読んだりしていても、いまいちプログラムの動きが頭に入ってきてなかったってこと。
• とりあえず写経して動かして見てから、ドキュメントを読むとプログラムの動きが頭に入るってこと。
• ぼーっとあんまり頭を使わずにコードを写経しているだけでも、けっこう力になっている気がするということ。

みたいな話。

ドキュメントを読んで、理解するのもいいんですが、ドキュメントだけ読んでいるとけっこう話が空中戦になっていて、何が起きているのかが想像の中でどんどん膨みます。で、何があってるのかわからなくなりがちです。

でも、一回プログラムをコピーしてみて、動かしてみると、何が起きているかわかったりして、気持ちがいい。

だからチュートリアルとか、既存コードを写経するだけでも実は、理解が進むのかもしれないなーと思ったりしました。

関連して、「もしかして、Djangoのコードを写経してみれば、Djangoについてめちゃくちゃ詳しくなるのでは？」とか思いました。

いや、全部写経するの大変だし、やらなくてもいい気がするんですが、ちょっとでも写経して見たら、何が起きてるのか理解が進むのかなー。って。

というわけで、今日気になったモジュールをとりあえず写経して見た。

それは、 django.db.models.manager

django.db.models.manager | Django documentation | Django

写経して見た感想。

わからないところが多いなと思いました。django.db.modles.managerがわからないというより、Pythonの書き方としてわからない部分があって、一つや二つならコードを読みながら調べたらいいんですが、たくさんあるので、読みながら調べるのは辛そうだなー。って。

これまで、Djangoのソースを見て、いまいちよくわからないなあと思う箇所があったので、それはPythonの書き方でよくわかってない箇所がたくさんあったからだろうなあと改めて思いました。

とりあえず、思った疑問を書いて起きます。

近いうちに調べたい。

• __new__ ってなんだっけ。
• django.db.router ってなんだろう
• django.db.models.query.QuertSet ってなんだろう
• _meta ってなんだろう
• deconstruct ってなんだろう
• getattr / setattr / hasattrが知ってるようで知らない
• inspect.getmembers のpredicate ってなんだろう
• __eq__ ってなんだろう
• __hash__ ってなんだろう
• なんで空のManager があるんだろう
• EmptyManager って何に使うんだろう

ソフトウェア工学の当てはまらない状況

本を読んでいて、ソフトウェア工学はこういう状況には当てはまらない、という話を見つけた。

自分の感じたことに近かった。 興味深かったので書きます。

とは言え、読んでるのはソフトウェア開発の古典みたいな本なので、ソフトウェア工学とか聞いたことない人は読まなくていい記事かと思います。（というか、今だと少し変わってるようにも思うし）

前置き

ソフトウェア工学というものを学んだことがある。

ソフトウェア工学 - Wikipedia

ソフトウェアを工学的に作っていこうという考え方の方法論です。

簡単にいうと、設計と実装やテストを分離して、考えます。

ソフトウェア工学の中には、設計に関する話と生産に関する話があります。

で、僕の知ってるソフトウェア工学は、ウォーターフォール型のドキュメント駆動開発です。

ドキュメント駆動開発では、ドキュメントが全てです。

動くソフトウェアを早く届けることより、矛盾のないドキュメントが重要視されます。

ソフトウェア工学では、設計してから設計に基づいて実装を行います。修正するときも同じです。

やってる方からすると、すごいめんどくさいやり方なので、なんでこんなことになってるの？という疑問を持っていました。

ソフトウェア工学の適用場面

ソフトウェア工学は、以下の状況でソフトウェア開発を成功させるために作られたらしいです。

• プロジェクトメンバーが数百人から１０００人などのプロジェクト（超大規模）
• 開発対象のソフトウェアのバグが人命を脅かすようなプロジェクト（ロケットとか飛行機とか）
• 品質がコストより重要視されるプロジェクト（国家レベルのプロジェクト）
• ハードウェアの製造が遅く、ソフトウェアを開発する時間が十分にあるプロジェクト
• シビアなハードウェア要求があり、汎用ハードウェアは使えないプロジェクト

所感

上記の背景を聞いて、自分の疑問が解消された部分がありました。

とりあえず、今のところはドキュメント駆動で開発しなくて良さそうです。

理由のわからないものは、ずっともやもやと気になってしまいます。

今回、１つ納得できてなかったことが解消できて嬉しいです。

参考文献

ソフトウエア開発プロフェッショナル

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

人月の神話【新装版】

2018年初ブログ

あいさつ

あけましておめでとうございます。

みなさま、どのようなお正月をお過ごしですか？

私は、実家のある和歌山に帰省しています。

年越しは、人生で初めてカウントダウンライブなるものに行きました。

元旦は、初詣に出かけています。

昨年の簡単な振り返り

昨年の振り返りをすることなく、年が明けてしまいました。

簡単に振り返りたいと思います。

• 結婚した
  • 同棲し始めた
  • 両方の親に挨拶に行ったり、諸々の手続きしたり。
  • 二人でいろいろ模索中。
• 転職した
  • ピープラウドで働き出した。Pythonプログラマになった。
  • 勉強の時間が取れるようになって嬉しい
  • プライベートで勉強したことを仕事で使えるの嬉しい
  • いろいろやらせてもらってる。
• 引っ越し検討した
  • いろいろ見たけど決まらず。
• 音楽
  • 友人のシンガーソングライターの音楽制作をしてる
  • 最近、忙しくて、なかなか進まない。
• 投資
  • 人生で初めて投資信託買った。

まあこんな感じです。

全体的に、いろんな決断をしたり、新しいこともいろいろやったなあと思ってます。

今年はもっとスピードあげていきたいです。

今年やりたいこと

基本的に、今年はこれまでやってきたことに力を入れて軌道にのせていくのがやりたいなと思ってます。

• 仕事は、今やってることをキチンと終わらせる。
• 趣味のアプリ開発はショボくて良いので、なんかリリースする。
• 勉強は、ついいろんな分野を深掘りしてしまうので、いい感じに。
• 結婚生活は、まあいろいろいい感じに。
• 日常生活も、いろいろいい感じに。

おわり

まあ、なんだかんだ言いつつ、とりあえず昨年はいい感じになってきたので今年もいい感じになればいいなと思います。（雑）

今年もよろしくおねがいします。