matobaの備忘録

育児しながら働くあるエンジニアの記録

僕のブログのモチベーションあれこれ

ブログを書くモチベーションが変化したなあ、とふと思った。

気が向いたので、誰が興味あんねん、と思いつつ、振り返りながら書こうと思います。

なお、この記事を通して言いたいこと特にないです。(とりあえず書きたいだけ)

高校生くらい(2005年とか)

自分のバンドのホームページのコンテンツとして書いていた。

毎日書くことが目標だったので、トータル500本くらい書いた気がする。

最初は、とりあえずなんか書くことが目的で、三行のブログとかも多かった。

書いてたことは、普通に音楽をやってる日常のことだった。

次第に、バンド友達で見てくれる人が増えていったのを覚えてる。

個人的にムカついたこととかも書いてたので喧嘩とかした(若い)

知らない人との交流会もあったし、ブログからはじまる人の繋がりもあった。

この時のモチベーションは、コンテンツを作る仕事と人との交流かなあ。

そうこうしてたらmixiとか出てきた。

大学生のとき(2008年とか)

最初のころは、高校のときのブログをバンド友達が見てくれていた。

会う頻度も少なくなっていったので、最近、僕は何をしているかを共有するために書いていた。

あった時に『ブログを読んでるよ。』って言われると嬉しかったし、空気感を共有できている気がした。

話のネタになったから書いてた。と言うのが大きい。

この頃にはmixiが流行ってたので、友人とのコミュニケーションのための記事はmixiに移行された。

ただ、mixiになると、どうでもいい記事が目に入るようになってめんどくさくなっていった。

あと、あんまりステークホルダーが多いと書くことに気を使うので、mixiは嫌だなあという気持ちになっていった。

大学生のとき(2010年とか)

またバンドをはじめて、そのWebサイトのコンテンツとして、mixiとは別でブログを書きはじめた。

当時は、引きこもりでギターを弾く、スタジオに行く、ライブする、たまに学校に行く、みたいなダメ学生だったから、音楽ネタで書くことに困らなかった。

この頃、大学でコンピュータについて学びつつ、家でPC使いながら、音楽作ったりしてた。

当時のDAWについて悩み事も多かったし、情報が少なかったので、自分で試してたり、2chを見たりしながら、それの解決法とかもブログに書いたり。

あとは、作ってる音楽の機材の話もけっこうしてた。

パラメータチューニングもけっこうあったし、時間の限り試行錯誤してたから、その話とか。

その話があったから、機材の使い方を聞かれたり、音楽制作のエンジニアで依頼が来たりした。

バンドをやめたら自分の日記みたいになっていった。

大学院のとき(2012年とか)

この頃は、音楽の信号を分析する研究をしていた。ブログは、WordPressに移行した。

次第に音楽の記事より、IT系の記事が増えていった。というか、9割くらいそういう記事だった。

今だとQiitaに書いてるような記事を書いてた。(ポエマー)

当時、Pythonを使っていた。その前はCとかJavaとか書いてた。

JavaとかCは、やりたいことに対して、書かないといけないことが多いし、よくわからない魔法が多くて、好きじゃなかった。

Pythonは、書いてて気持ちが良いから好きだった。あと、JavaとかCは、既存のコードが動かない時にどうするかで、すごく悩むけど、Pythonはソースがあるから、辿って解決できるのが嬉しかった。

ブログでは、当時は少なかったnumpy、scipy、matplotlibの記事を日本語で書いてた。

virtualboxでけっこう悩んだこともあったのでその記事も多かった。

あと、Webサーバーのレンタル屋で働いてたのもあって、Webサーバーネタとかも多かった気がする。

あ、音声の信号処理を勉強してたのもあって、自作で音声を加工してプログラムを解説したりしてた。

当時、Googleアナリティクスを貼ってたけど、だいたい月間アクセスが1.5万くらいになってた。

そのあたりで、『あー、Pythonとかデータ分析ってすごい検索されるんだなあ』とか思い始めた。

就職したあと(2014年とか)

就職したら、ブログの更新は止まった。会社にいる時間が長くなりすぎて、そもそもブログを書く時間が減った。

さらに会社で、手を動かすことがなかったから、技術的なことでかけることが全然増えなかった。

あと、マネジメントに近い業務をしてると、仕事で悩んだことや解決したことは、だいたい人間関係の話になる。人間関係の悩みや解決をブログに書くのは、あんまり気が進まない部分がある。

ついでに、会社で関わる技術が、特許とかNDAに囲まれてて身動き取れなかった。

たまに、本読んで試してみたこと書いてたかもしれない。

そうこうしていると、ブログを読んだと感想もらうこともなくなったし、サーバーの更新料ももったいなくなってきたので、2015年の半ばに、一旦ブログは閉じた。

最近のこと(2017年)

転職を機にブログを再開した。

もともと、何の役にもたたない文章書くのも好きだし、自分の考えてることをとりあえず記録に残すのは好きだったし、ブログという形がけっこう好きなので。

あと、手を動かす機会が増えたし、技術的なことに触れる機会も増えたのもある。手を動かす機会が増えると、自分なりに試行錯誤したい気持ちになるから勉強することも増える。

今は主体的に動くことを応援してくれる体制なので、動きたい気持ちにもなった。*1

なんで書いてるかと言うと、情報をアウトプットしたいから、かなあと思った。

別に、ブログを書く時にまとめてないけど、一度ブログに書いたことを別で人に説明すると、多少はまとまっているはず。

あとは、自分で『前も同じことやったような』とか思った時に、ブログを検索すると出てきたりするのも良いなと思ってる。

それは、自分のEvernoteでも良いけど、インターネット上に登録しておくと、もしかしたら他の人も検索できるかもなーというくらいの気持ちでwebに書いてる。

また、そんなこんなで、最近はブログを書いている。

最近は移動中にブログを書いてるから、読んだ本の話が多くなってる。

もうちょっと技術的なことを書きたいなと思ってる。

*1:主体的に動くのが望ましいと言われながらも、主体的に動くと上下左右からたくさんのマサカリが投げ込まれる環境があるのです

ソフトウェアをリファクタリングするということ

リファクタリングについて調べてます。

この記事の続き。

リファクタリングについて調べはじめた - blog.mtb-production.info

キチンとしたリファクタリングのやり方を知りたいと思ってます。*1

というわけで、この本を読んでます。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

本を読んでいて、自分なりにポイントだと思ったことを書いています。最後に所感も書いてます。

リファクタリングの頻度

リファクタリングは定期的にやることではなく、何かをやる時に一緒にやること。

  • Bad:定期的(例えば、二週間に一回)やる。
  • Good:リファクタリングするべきタイミングでやる。

リファクタリングをやること

リファクタリングは目的ではなく、手段である。

リファクタリングのタイミング

次のようなタイミングでやる。

リファクタリングしないとき

次のタイミングでは、リファクタリングを避けます。

  • コードが汚すぎて書き直す方が早いとき
  • 既存コードが動かないとき
  • 締め切りが迫っているとき

なにをリファクタリングするか

  • じゃあ、なにをリファクタリングしたらいいの?ってと言うと、不吉な臭いのするコードリファクタリングする。
  • 不吉なコードを嗅ぎ分けるスキルは経験によって養われる。

所感

この話の中だと、一番良かったのが、何かを対応する中で理解のためにリファクタリングするということ。

ちょうど、開発してるコードでも、新しい機能を作ったら、元のコードで気になる部分が出てきていた。

新しく作っている機能がなかったら気にならなかったけど、新しい機能を追加したら気になることがある。

たとえば、新しい機能があることで既存機能の変数名が誤解を招くとか、無駄な処理があるとか、そもそも、設計が微妙になるとか、そういうやつ。

そういう微妙ななにかは、新しい機能を追加するときにわかるし、それはリファクタリングすべきコードだということがわかった。

そして、リファクタリングした際に、デグレートしてないかを確かめるためにユニットテストが有効に作用する。

ユニットテストがしっかりしていれば、リファクタリングがスムーズにできることがわかってきた。

あと、これまではユニットテストを書くのが遅かったけど、ユニットテストを書くスピードが上がれば、ソフトウェア品質と開発スピードを保ったまま、ソフトウェアを拡張していけることがわかってきた。

これまで、設計した後にコーディングをする。そして、コーディングの段階で、設計を修正しないといけないのがわかったら負け。みたいなマインドがあった。

コーディングする前に、設計が全部わかるわけないでしょ。と思っていたけど、『僕が実力不足なだけで、できる人ならコーディングする前に設計が終わるのかもしれない。』とも思ってた。

ただ、この本を読みつつ仕事をしてる中で真実はこうでは?と思ってることがある。

  • 設計してからコーディングした方が良い。(必須ではない。規模、複雑さ、何回使いまわすか、による。)
  • コーディングする前に設計が完了するときもある(だいたい作ったことがあるシステムと、全く同じものを作る場合は近いかもしれない。ただ、ホントにそんなことある?チュートリアルか?)
  • 設計してからコーディングして、その後に設計を修正することはある。(必ずではない。コードの目的が何なのかによる。)
  • 前は良かった設計が、新しい機能追加によって悪い設計になるときがある(拡張性が高ければ良い設計ではない。拡張されないのに、拡張ポイントを作ると、逆に読みにくいコードになる。コードが読みにくいければ良い設計とは言えない。)
  • 時間と共に設計は、腐っていくので改善しないといけない。(周辺環境によって、設計が良いか悪いかは変化するし、周辺環境は時間と共に変化していくので、それに合わせたリファクタリングが必須。)

とりあえずおわり。

*1:キチンとした、ってなんか型にハマってて、書いてあることしかやらなさそうな響きが個人的には好きじゃないんだけど、そういうのはとりあえず基本をしっかりしてから言う事な気がしてるのでとりあえず基本的なことをやりたい気持ち。

プロジェクトと停滞と復活

僕が前に書いてたメモを見つけた。こんなこと書いてた。

プロジェクトが詰まった時にどうすれば復活できるか?

まあ気が向いたので、ちょっと調べてみた。*1

調べてみたら色々出てくるもんなんだなあ。と思った。*2

PMOの視点

こんな記事が出てきた。

www.pm-portal.jp

書いてあったこと。

  • 体制、役割、期待値の明確化
  • プロジェクト全体スケジュール策定
  • チームWBS策定
  • 会議体整理

PMOっぽいと思った。PMOと言うのは、Project Management Officeと言うやつで、その組織の中でいくつも走っているプロジェクトがいい感じになるように色々やる人。プロジェクトが炎上してないかをチェックしてたり、炎上してるプロジェクトの火消ししたり、プロジェクトがうまく回りそうに後ろで色々動く人たち。いわゆるプロジェクトリーダーの相談役みたいポジション。

個人レベルの視点

関連キーワードで検索してたら、こんな記事が出てきた。

orangewind.hatenadiary.jp

GTDの話。GTDについては、原著読むほうがいいと思うので、書かない。

全面改訂版 はじめてのGTD ストレスフリーの整理術

全面改訂版 はじめてのGTD ストレスフリーの整理術

僕もGTDやってるけど、GTDに定期点検は必須だと思う。*3

とは言え、止まってるプロジェクトとかあるよなあ。止まったら嫌なプロジェクトは、定期的に「見直し」みたいなタスクがあがるようにして、少しずつ前に進むように工夫してるなあ。とか思い出した。

プロジェクトリーダーの視点

別のキーワードで検索してたら、出てきた。

xlinkpat.jp

書いてあったこと。

  • プロジェクト全体を俯瞰する
  • 頭より手を動かす
  • 新メンバーを入れる
  • 専門家の手を借りる
  • 三人寄れば文殊の知恵

終わり

調べてる途中で思ったけど、こう言うのって、当事者にならないとイマイチわからないなあ。*4

後、個人的には、自分がどう言う役割なのか、を考えて頑張るんじゃなくて、誰でもいいから前に進めよう、と言う感じの混沌としたスタイルの方が好きだと思った。*5

それから、プロジェクトによって状況は変わるから、なんとも言えないよなあ。とかぼんやり考えていた。

*1:ただ単に、メモから削除したい気持ちがあったけど、せっかくメモしてたから多少調べてみようと思った。

*2:僕が関わっていたプロジェクトに行き詰まりを感じたこともあったし、そう言う時にどうすればスムーズに復活できるんだろうと考えたりしたけど、ググったらよかったんだなと思った。

*3:基本的にタスクがモリモリ増えていくから、定期点検しないと埋もれてしまう。

*4:と言うか、当事者じゃないと真剣に考えられない。。。

*5:役割分担が厳密に定義されたとしても、それをみんなが同じように認識するまでだいぶ時間がかカルシ、同じように認識したからできるわけじゃないし、その時間いるの?って思ったりするから。それなら泥臭くても前に進める方が良さそう

もっともっと手を動かす時間を増やしたいと思った話

絵はすぐに上手くならない。って本を読んでいる。この本がものすごく面白い。

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

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

読んでいて、そりゃそうだ!と思うようなことがたくさんあった。 気づきもたくさんあった。書きます。

2つのうまさ

本に書いてあったことから学んだこと。

  • 絵には二つのうまさがある。
  • 1つ目は、技術的なうまさ。何が良くて何が良くないのかわかり、表現力が高いこと。
  • 2つ目は、引き出しの多さ。何かを描こうとした際に、すぐに描けること。

音楽やプログラミングでも同じような話があると思う。 そして、引き出しの多さは、制作のスピード感に関係があるとのこと。 レベルが低くてもすぐに描けないと情熱が薄れてしまうという話。 そして、僕は、音楽にしてもプログラミングにしても引き出しが少ないことに気づいた。

上手さと学校

本に書いてあったことから学んだこと。

  • 真実:絵が上手いから美大に入れた
  • 間違い:美大に入ったから絵が上手い

音楽でも、近いことが言えそうだあ、とか。色々、似たようなことを考えた。 環境は人を育てるけど、その環境に受け入れられるかどうかは人次第。

上手さと書きやすさ

本に書いてあったことから学んだこと。

  • 真実:絵が上手い人も必死で形をとって遠くから何度も眺めて形を整えながら絵を描いている。
  • 間違い:絵が上手い人は、いつも鼻歌を歌いながらササっと絵を描ける。

音楽とかプログラミングとか、映像とか、クリエイティブなことは全体的に同じことが当てはまりそうだなあと思った。

音楽とかプログラミングをやるときに、もっとサササッと作れるようになりたいと思ってたけど、そういうタイミング来ないんだ。。。という気持ちになった。そう言えば、すごい人もみんな必死な顔して音楽やプログラミングしてる。

デッサンと上達

本に書いてあったことから学んだこと。

  • 真実:デッサンをやったら上手くなる
  • 間違い:デッサンをやらないと上手くならない。
  • 真実:デッサンをやらなくても、他のトレーニング(たくさん絵を描く等)をすれば上手くなる。
  • 間違い:デッサンをやらずに、他のトレーニング(たくさん絵を描く等)をしなければ上手くならない。

デッサンは、絵を描くために使う能力を効率的にトレーニングの一つであって、絶対にやらなきゃダメなことではない。 ただし、何をやりたいかわからないなら、デッサンやる方が汎用性が高い。との話。

これも、音楽とかプログラミングで同じこと言えそうだなあ・・・と思った。 例えば、音楽なら、「音楽理論を勉強すべき」vs「譜面も読めない音楽家がいるしやる必要はない」の議論をたくさん見たけど、同じ話だと思った。

絵とトレーニング

本に書いてあって学んだこと

  • 間違い:いろんなスキルや工程があって、一つずつクリアして行くと最終的に絵が描けるようになる
  • 真実:いろんなレベルのスキルや工程がぐちゃぐちゃしていて、クリアとかない。
  • 現実:スキルを整理して、全体的にレベルアップしやすくしている。

ソフトウェア開発や音楽制作も同じかなーという気持ち。

レベルと作品制作

本に書いてあって学んだこと

  • どんなレベルであったとしても作品制作はすぐ始めること
  • 上手くなってから始めようとしても、自分で自分のことを上手くなったと思う日はない。
  • 勉強が終わってから始めようとしても、勉強は終わらない。

とりあえず、作ろう。という話。能書きはいらない。

トレーニングと作品制作

本に書いてあって学んだこと

  • 作品制作は、頭の中にある世界を描いて絵にする。
  • トレーニングは、目で見たことを絵にする。

僕、音楽にしてもプログラミングにしても頭の中にあるものを具体的にアウトプットするために、めちゃくちゃ時間がかかって、心折れそうになるんだけど、それってトレーニングが足りてないんだ。。。ということがわかった。 トレーニングします。

トレーニングの種類

本に書いてあって学んだこと

  • 平面に書いてある絵を平面に写すトレーニング。比較的、簡単。線を描くスキルが必要。
  • 現実にある立体的なものを平面に書くトレーニング。比較的、難しい。線を描くスキルに加えて、構図を考えたり、陰影をつけたりするスキルも必要になってくる。

音楽だと、譜面に書いてある音楽をコピーするのと、流れている音楽を耳コピするのの違いかなあと思った。 プログラミングだと、ソースコードを写経する、仕様からコードを書く、要求から仕様を決めてコードを書く、とか段階がありそうだなあと思った。

終わり

全体的に、僕は、いきなり全部やろうとして、時間がかかりすぎてあっぷあっぷしてる感じがある。もっと下からレベルを上げていきたい。下積みを増やしたい。

プログラミングならソースコード写経のレベルをあげていこう。 音楽なら、譜面をコピーしまくろう。

もっと手を動かす時間を増やそう。

集中する時間はどうするのがよいか

朝の通勤時間に考えてたことを、書きます。

それは、集中する時間はどうなるのがいいんだろう?って話です。別に結論はありません。

集中する時間とは

ここでいう集中する時間は、1つのことに取り組んでいる時間です。

何かをはじめたら開始。別のことをはじめたら終了。別のことを考え始めても終了。です。

なぜ集中する時間を増やしたいか

なんとなく、仕事が早く進みそうに思うから。

と言うか僕は、複数のことを同時にやるとパフォーマンスがどんどん下がっていくようなので、同時にやることは一つに絞りたいです。

自分だけで完結せず並行してタスクが動くときは、jobリストを作って、定期的にそのリストをポーリングする方がストレスフリーですし、パフォーマンスあがります。これは人それぞれな気がします。

集中する時間の測り方

今のところ、アプリを使って測っています。

何かを始める前に、タイマーをスタートして、終わったらタイマーをとめる。

タイマーが動いているときは、一つのことしかできない。と考えてタイマーの開始ボタンを押します。別のことが気になってきたら、停止ボタンを押します。

つまり、タイマーが動いているときは、一つの事しかやってない。ということです。

このやり方だと、何をやるか、を決めないと集中を開始できないことになってます。

僕は、今、Togglというアプリで測っています。TimeCrowdというアプリでもいいかもしれません。もっと他に良いアプリがあるかもしれません。

集中する時間の増減

時間を測って分析すると次のようなことがわかります。

  • 合計でどれくらいの時間、集中したか
  • その集中時間がどれくらい長いか短いか
  • 集中している時間の割合はどうか
  • 全体のパフォーマンスと集中時間に関係はあるか
  • どんなタスクだと集中できたか

集中する時間の密度

集中する時間にも密度があるはず。

1つのことをやってるとき、ものすごく集中してることもあれば、とりあえず1つのことをやってることもある。

集中力には、集中度合いがあるはず。

集中力の総量

1人の人が1日に使える集中力の総量があるはず。

どれくらい集中しているかを集中度、と言うすると、1人の人が1日に使える集中力は、集中度と集中した時間の掛け算の積になると思う。

集中する時間の量

集中する時間は、多い方が良いのか短い方が良いのか。

1人が1日に使える集中力に上限があるとすれば、毎日その限界まで使う方が良いようなきがする。でも集中力って毎日上限まで使って大丈夫なのかな。

とりあえず、1日あたり適切な集中力のバランスがある気がす。

おわり

とりあえず時間がきたのでおわります。

まとまりのない文を読んでくれてありがとうございました。

では。

レベルがあがるってなんだろう

上手い。ってなんなんだろう?

何かしらのレベルの高さを示す言葉な気がする。

経験から考えてみて、音楽制作にしてもソフトウェア開発にしても、かけた時間とレベルが一致するわけじゃない。

例えば、僕より音楽制作に使った時間が少ない人が僕より音楽制作が上手いことはある。その逆もある。

つまり、同じだけ時間を消費しても上手くなり度合いが違う、という事。時間をかけてない人が上手いことはないので、時間とレベルには相関があるけど、他の要因も関係してると思う。

じゃあ、何が理由で違うんだろう。

というか、単純に、同じだけ時間をかけたのにAさんは上手くなって、自分は上手くならなかった。という状況は納得がいかない気持ちがある。

かけた時間が少なかったから上手くならなかった。という話なら、努力が足りない。という話になるし、努力の話になってくると、まあ納得いく気持ちがある。でも、時間じゃなさそう、となると、時間をかける気持ちが薄れる。

その理由がわからないと、また同じように時間をかけたのにあんまりレベルがあがらない状況になるんじゃないか、と思ってしまう。

そんなことを考えてたら、1つの本を見つけた。

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

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

買った。(まだ読んでない)

上手くなる。ということについて本1冊書いてるのは興味がある。

まだ目次をパラパラしただけだけど、いろいろ気になることは書いてありそう。

読み終わったら、感想をブログに書こうかなーという気持ち。