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プログラマになった。
  • 勉強の時間が取れるようになって嬉しい
  • プライベートで勉強したことを仕事で使えるの嬉しい
  • いろいろやらせてもらってる。
• 引っ越し検討した
  • いろいろ見たけど決まらず。
• 音楽
  • 友人のシンガーソングライターの音楽制作をしてる
  • 最近、忙しくて、なかなか進まない。
• 投資
  • 人生で初めて投資信託買った。

まあこんな感じです。

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

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

今年やりたいこと

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

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

おわり

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

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

近況とか

そう言えば、近況報告とかブログに書いてないな。と思いました。書きます。

で、近況っていつでしょう。んー、とりあえず1週間から１か月くらいです。とりあえず書きます。

仕事

仕事してます。悩み事はあります。たくさん。

とは言え、何度かアドバイスもらううちにだいたい以下のパターンが見えてきたような気がしてます。

• 問題を大きく捉えすぎ。問題を分解しよう
• アドバイスを一般化して捉えすぎ

これも一般化しすぎかもしれません。わからん。

まあ、焦らず、細かくして、１つずつ解決していきたいです。

日々、紙に書いて、『具体的には？』って言うのを分解中。

もっと強くなりたい（これまた漠然とした気持ち）

勉強

家でプログラミングを勉強してます。

ここ一週間くらいに、やってたのは、

• リファクタリングの本を読む
• PyQのDjangoのあたりをやる
• Pythonエンジニアファーストブック読む

Pythonエンジニア ファーストブック

とかですかねえ。 それぞれ、まだやってる最中です。

自分は前職のやり方と雑な我流が混ざって、色んな領域のスキルがいびつに伸びてるようなのな気がするので、とりあえず実装周りの基本的なことをキチンと整理して理解したいという気持ちです。

スキルがいびつなせいで、全部できそうな気がするけど、全部すごい時間がかかるし、結局何ができるのかわからんけど、何もできないわけじゃない。みたいなわかりにくい状況になりがち。とりあえず１つずつ倒していく。

自分で作りたいものもあるんですが、クソコードができて辛くなるので、とりあえずコードは書いてない。

家庭

簡単な報告になりますが、先月結婚しました。

僕は、家で勉強してたり自分のことしてること多いですが、嫁さんも自分のことしてる時間多いので、まあそういう感じです。

僕が家でご飯作る時もありますが嫁さんが作ってくれる時もあり、作ってくれた時はすごい嬉しいです。あと、帰宅して家に人がいるのも嬉しい。

そう言えば、東京西川の良いマットレスを買ったんですが、かなり良いのでオススメです。朝の目覚めがすごく良いです。疲れが翌日に持ち越さない。

あと、タンス買いました。これは、まだ家に届いてません。

音楽制作

趣味の音楽活動は、二週間ほどストップ中。

今は、仕事でやってることの気になるやつを解決したい気持ち。

制作の途中でミキシングやらなきゃなんですが、久しぶりのミキシングで集中力と時間がいるのでちょっと今はできなさそう。

ちょっとずつやりたい。

あ、そう言えば、趣味で作ってる曲にも、仮歌を入れて様子みたい気持ちがあります。

今、あんまり時間ないのでは音楽制作フレンドと一緒にあーだこーだ言うより『このオケに、こんなイメージの歌詞つけて、こんなイメージの歌をいれてほしい。報酬は相場くらい。』みたいなのを投げたい状況。

そのうちWebサービス経由で依頼しようと思ってます。

興味

こないだちょっと読んだ『絵はすぐにうまくならない』って本が面白い。

絵はすぐに上手くならない

クリエイティブスキルを分解してくれてる感じです。

面白かったのが、『立体を把握する力』とか『形状スタッフ』とかスキルを分解してる話。

クリエイティブなスキルの話をする時、見る目があるとか、引き出しが多いとか、そう言うスキルが出てくるけど、あれのことだ！ってなってます。

僕はプログラミングで言うと、引き出しの数が少ないなあとか思ったりもしました。他も低いんですけど、まあそれはおいといて、一番気になるのが何かと言うと、と言う話です。

まあ、これも今のところ、おいといてますが、もうちょっと読んで消化したい。

あと、これも気が向いた時に読んでる本ですが、コンテンツの秘密って本も面白いです。

コンテンツの秘密 ぼくがジブリで考えたこと (NHK出版新書)

コンテンツってなんなの？クリエイティブってなんなの？面白いってなんなの？みたいな話について考えた本。

映画はどこから作られるのか、みたいな話が個人的に面白い。

ジブリ映画は、シーンから作られるみたいな話があったりなかったり、とりあえず僕の想像は余裕で超えていきました。（僕の想像がショボいと言う話はおいといてください）

その他

嫁さんの恩師の大学教授の焼肉を食べに行きました。

日本語学の研究者ですが、日本語学のリサーチの話を聞いてる全て手作業で、泥臭さがとんでもないし、それをやりきるのもすごいし、いろいろすごい。っとなりました。

話をしながら、なるほど〜、こういうところに価値を見出すのかあ、とか思ってたりしました。

だいたいこんな感じです。 あいわからず散らかってるなー