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

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

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

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

前置き

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

ソフトウェア工学 - Wikipedia

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

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

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

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

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

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

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

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

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

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

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

所感

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

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

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

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

参考文献

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

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

人月の神話【新装版】

2018年初ブログ

あいさつ

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

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

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

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

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

昨年の簡単な振り返り

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

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

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

まあこんな感じです。

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

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

今年やりたいこと

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

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

おわり

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

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

近況とか

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

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

仕事

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

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

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

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

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

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

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

勉強

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

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

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

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

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

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

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

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

家庭

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

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

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

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

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

音楽制作

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

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

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

ちょっとずつやりたい。

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

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

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

興味

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

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

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

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

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

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

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

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

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

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

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

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

その他

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

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

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

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

機能という言葉のもやもや

システム開発・ソフトウェア開発の設計に関する書籍をいくつか読んだりします。

いろんな書籍を読んでいるなかで、よくわかんないなあと思うことがあります。

わかんないこと

それは、「機能」という言葉の意味です。

「機能」という言葉が出て来た時に、「この本は、今、どういう意味というかどういう粒度で話をしているんだろう」という疑問が出てきます。

そして、なんの話をしているかを間違えると、全然理解が進まないです。

で、それを解消するために、機能って言葉について、もう少し詳しく考えてみたいと思ってます。なんか近い話がどこかに書いてないのかなあ。と思ってインターネットを検索しました。

インターネットで検索しながら、自分が学んだことを書きます。

機能という言葉の定義

機能という言葉について調べていると、以下のことが個人的に重要でした。

• 機能は、ある物が本来備えている働きのこと
• 機能は、全体を構成する個々の部分が果たしている固有の役割のこと

このあたりに書いています。

kotobank.jp

とりあえず、以下の理解が進みました。

• 単体では機能と言わない。
• 複数で全体を構成するから、機能という。
• 誰かがどう動くかを期待している働きを機能と言っている。

機能の単位

機能という言葉で検索していると、いろんな機能が出て来ました。 その機能をどんな単位で決めるかを考えてまとめてみました。

1. 国単位で考える機能（お金の機能、法律の機能、とか。）
2. 組織単位で考える機能（人事の機能、営業の機能、研究の機能とか。）
3. チーム単位で考える機能（予算管理の機能、時間管理の機能とか。）
4. 仕事単位で考える機能（在庫引当機能、レビュー機能、とか。）
5. 行動単位で考える機能（受注を確認する機能、在庫を確認する機能、受注に対して、在庫を引き当てる機能、とか。）

機能にはいろんな単位があるんだなあと思いました。

個人的には、「これ、どういう意味があるんだろう？なんのためにあるんだろう？」とかを考えたり、それを知ったりするのが好きです。

だから、色々考えたりします。それって、機能を自分なりに考えてたんだなあ、と思いました。

機能の階層

システムの機能の粒度の話を検索してたら、機能の階層という話が出て来た。

階層があるのかあ、なるほど。と思いながら、ぼんやり考えていました。

すると、ここに書いてあるシステム開発って、仕事の単位でシステムを開発しようとしているケースが多いなあ。と思いました。

そして、仕事の単位を一つのプロジェクトにして、システムを開発していくことが多いのかもなあ。そして、その一つ一つを実現する小さい何かを、ソフトウェアで実装していくのかなあ、とか思ったりしました。

参考：見てたページ

• 機能要件は3階層で整理 | 日経クロステック（xTECH）
• 第9回 SOAによる情報システム構築のポイント②サービスの抽出と階層化：機能と技術からわかる！システム基盤の実力｜gihyo.jp … 技術評論社
• 機能一覧表とI/O関連図 | Think IT（シンクイット）
• 第３６１回 「業務機能粒度のとらえ方」｜１７．見える化コーチング｜メルマガバックナンバー｜情報戦略モデル研究所（ISMリサーチ）メルマガ・バックナンバー

で？

ちょっと脱線しました。

結局のところ、機能という言葉の意味は、定義のところに書いたとおりです。

そして、モヤモヤ色々考えた結果、話をしている目的によって、機能という言葉の意味は変わるのかな、というのが今の僕の理解です。

例えば、「ソフトウェアをどう作るか？」を考えていて、機能の話が出て来たら、それは、ソフトウェアで作るものに何が必要かの話だと思います。

「ソフトウェアをどう使うか？」の話をしていたら、「ソフトウェアでどんな仕事をしようとしているか」が機能なのかなあ、とも思いました。

あと、「ソフトウェアで何がしたいのか？」の話をしていたら、「ソフトウェアで解決したい問題」が機能なのかなあ、とも思いました。

二つ目は、シナリオ。 三つ目は、ストーリー。とか書いた方がわかりやすいんじゃないかな、とか思いました。 一つ目は、、、、なんだろう。モジュール？なんか違うような。 機能かなー、うーん。って思ったのが僕の今のところの話です。

Gitが大切にしていること、成り立ち、他との違い

僕は、やっぱりツールを使っていて、「中身がブラックボックスなのは、気持ちが悪いなあ。」と思ってしまうたちのようです。

だって、よくわかんないんだもの。気持ち悪い。

という訳で、Gitについて、もっと詳しくなりたいと思いました。

ProGitを読んでいます。ここでは、個人的な発見を記します。

Pro Git 日本語版電子書籍公開サイト

CVCSの問題とDVCSの成り立ち

個人的には、以下の３点が重要でした。

• CVCS（集中バージョン管理システム）は、中央サーバーが単一障害点になるのがよくなかった
• 中央サーバーを作らなきゃいんだ。ということでDVCS (分散バージョン管理システム）が誕生した。
• CVCSで出来なくて、DVCSで出来るワークフローがあるが、それらは、各DVCSの階層モデルによる副次的な産物だった。

この辺りに書いてます。

Git - バージョン管理に関して

Gitで大切にされていること

個人的には、以下の５点を目標に開発されているとの話が、重要だと思いました。

• スピード
• シンプルな設計
• ノンリニア開発(数千の並列ブランチ)への強力なサポート
• 完全な分散
• Linux カーネルのような大規模プロジェクトを(スピードとデータサイズで)効率的に取り扱い可能

以下に書いてます。

Git - Git略史

これを見て、他のDVCSやCVCSは、以下のような特徴を持っていたことがわかります。

• Gitに比べて、スピードが遅かった
• Gitに比べて、設計がシンプルではなかった
• Gitに比べて、ノンリニア開発へのサポートが貧弱
• Gitに比べて、完全に分散しているといえなかった
• Gitに比べて、プロジェクトが大規模になると効率的に取り扱えなかった

そして、Gitの5つの目標を達成するために、Gitの各コマンドが作られていると思うので、その気持ちで読み進めていきます。（僕はプロダクトのコンセプトを知ることが、プロダクトの一つ一つの機能を理解するためのいちばんの近道だと思ってます。）

他のCVCSとGit

以下のページにある「GitはSubversionと情報の格納の仕方が違う」という情報は、僕にとって、すごく重要でした。

Git - Gitの基本

なぜなら、僕は、Subversionを利用していましたし、Subversionの情報の持ち方を理解していたので、「Gitもきっと同じだろう」と思っていました。それが混乱を加速させていました。

僕にとって、衝撃だったのは、Gitはスナップショットを保持していて、差分を保持していない。ということでした。

それによって僕が、Gitを利用していて違和感を感じていた以下のような疑問が解消されました。

git cloneが遅い？

疑問その１：なぜ、これくらいのテキストファイルしか入っていないGitリポジトリをローカルにコピーしてくるだけなのに、こんなに時間がかかるのか？裏で何が動いているのか？SVNのリポジトリで、もっと大容量のファイルを管理していたことはあったが、チェックアウトはもっと高速だった。当時の環境と比較して現在の環境のネットワークが低速だとは思えない。Mercurialをcloneした時ももっと速いような気がしてる。git cloneでは何が起きているんだろう？

答え１：Gitリポジトリをcloneするということは、これまでの履歴も含めて全ての情報をコピーするということ。しかもGitリポジトリには、履歴がスナップショットで格納されているので、変更回数の増加とリポジトリの肥大化のスピードは、SVNやMercurialの比ではない。ただし、それは、開発中のスピードダウンではなく、開発を開始する前に時間がかかるだけである。Gitは開発者がストレスフリーに開発が行えるために作られたバージョン管理システムであって、管理者がリソースを効率的に利用して、新しい環境を作るコストを抑えるために作られたバージョン管理システムではない。ということ。

gitのbranch切り替えが高速すぎる？

疑問その２：Gitでbranchを変更した際に、切り替えが高速すぎて、本当に切り替わっているのか不安になる。例えば、ブランチの切り替えでは、ファイルが切り替わるが、切り替えが実施されているのかどうかもわからないほど高速で切り替わっている。何が起きているのかわからないような感覚になる。これは何が動いているのか？僕が思っているbranch切り替えとgitのbranch切り替えは違うように思えるが、これまでの経験は、全て使えないのか、一部使えないのかどちらだろうか。

答え２：Gitは差分を管理しているわけではなく、スナップショットを管理している。言い換えるなら、「このコミットが行われた時に配置されていたファイルは何か」という情報を管理している。branchが切り替わっても、ただ単にその時に配置されていたファイルの情報と現在配置されているファイルの情報の差分を見て、違うファイルを差し替えるだけである。だから、その間にたくさんのコミットがあったとしても、関係がないし、切り替えが高速になる。これまでの経験が、全て使えないとは言えないが、仕組みが違うということは頭に入れておいた方が良さそう。

gitのrebaseでなぜマージ処理が走る？

疑問３：gitでは、rebaseした際にコミットが実行されているように見える。rebaseの際は、マージもされているように見えるが、何か違和感がある。rebaseが自分のイメージしている動きと何か違う気がする。処理速度が、自分の思っているスピードと違う。これまでに使っていたSVNと同じように使っていると何か地雷を踏みそうな予感がする。マージしているつもりが、マージされていない。などの問題がどこかで起きていないのか不安だ。後ろで何が行われているんだろう？自分が何を勘違いしているのだろうか。

答え３：gitは、rebaseが行われた際、指定されたポイントから、現在のブランチに行われたコミットを一つ一つ確認しながら、ファイル状態をマージしていく。gitは、差分を持っているわけではなく、スナップショットで管理しているので、rebaseが実施されたタイミングで、同じファイルが更新されれば、それらのスナップショットを元に、一つ一つのファイルと差分を取り、マージ作業を行なっていく。rebaseのタイミングでファイルがマージが行われるということは注意した方が良い。

Gitのコミットの完全性

僕にとって、こある意味で衝撃的だった話は以下です。

• Gitのほとんどすべてのコマンドが、データを追加するだけ。
• Gitでは、UNDOを実行したり、データを消去することは困難である。

ただ、これは次のように紹介されていたのも印象的です。

激しく物事をもみくちゃにする危険なしに試行錯誤を行なえるため、これはGitの利用を喜びに変えます。

引用元： Git - Gitの基本

どのあたりが、危険なしに試行錯誤を行えるんだろう・・・というのはよくわかっていない。今のところ、gitはすぐにぐちゃぐちゃになるなあ。と思っている。

時間が来たので、一旦ここで。続きは、そのうち読む。

DjangoのViewってなんなんですか？

タイトルのような質問をされたらどうしますか？

僕は、なんて答えたら良いんだろう、と思いました。

そもそもの話をすると、DjangoのViewのテストについて考えていた時、『これはViewでやることか、Modelでやることがどっちだろう？』とか『apiとして外だしするのが良いのだろうか？』とか『formとの関係性は、、、？』とか、もやもやが出てきて、「あー自分の中で、DjangoのViewが何かわかってないんだなー」と思いました。

で思った質問が『結局、DjangoのViewってなんなんですか？』ってこと。

もやってても、解決しないので、調べてみよう。

DjangoのView

DjangoのViewについて調べてみると次のことがわかりました。

ビュー関数、つまり view は、単にWeb リクエストを受け取って Web レスポンスを返すPython 関数です。

参考：ビューを記述する | Django documentation | Django

なるほど。

ここでいう、Webリクエスト、Webレスポンスって何だろう。

Webリクエスト、Webレスポンス

DjangoのViewを詳しく見てみると、Webリクエスト、というのは、django.http.HttpRequest のインスタンス。Webレスポンスというのは、django.http.HttpRequest のインスタンスだとわかりました。

そりゃそうだ。

じゃあ、django.http.HttpRequest と django.http.HttpRequest ってなんだっけ。。

django.http.HttpRequest,HttpRequest

改めて調べてみると、ここをみると書いてます。

リクエストとレスポンスのオブジェクト | Django documentation | Django

当たり前ですが、django.http.HttpRequestはHTTPリクエストをPythonのオブジェクトにマッピングした何か、django.http.HttpRequestHTTPレスポンスをPythonのオブジェクトにマッピングした何か。でした。

はい。まあ名前見たらわかるよね。と言う話です。当たり前でした。はい。

追加の疑問

Viewは、HTTPリクエストオブジェクトを受け取って、HTTPレスポンスオブジェクトを返すことがわかりました。

追加で以下のような疑問が出てきました。

• じゃあDjangoって、HTTPのリクエストをパースして、Pythonのオブジェクトにマッピングしてるんだっけ。
• gunicornとかWSGIってなんだっけ。。。
• Djangoのミドルウェアってどこでどういう仕事してるんですか？
• ViewとURLディスパッチャはどういう関係と思えば良いんだっけ。。URLディスディスパッチャはテストとかいらないんだっけ？
• QueryDict オブジェクトというのがあったけど、これは何ですか。 https://docs.djangoproject.com/ja/2.0/ref/request-response/#querydict-objects

よくわかってないのでそのうち調べます。

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

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

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

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

高校生くらい（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:主体的に動くのが望ましいと言われながらも、主体的に動くと上下左右からたくさんのマサカリが投げ込まれる環境があるのです