むにえる牧場

毎日むにえるをつくっています

ポモドーロテクニックとGitは相性が良い

最近仕事や趣味の作業時にポモドーロテクニックを利用して集中力を高めています。
我々エンジニアの使うGitととても相性が良いと感じたので布教記事です。

ポモドーロテクニックとは

  1. 達成すべきタスクを1つ決める
  2. タイマーで時間を指定する
  3. タイマーが鳴るまで決めた1つのタスクに集中する。他のことは一切やらない。
  4. タイマーが鳴ったら5〜10分休憩時間を取る
  5. 1〜4の工程を繰り返す
  6. 1〜4の工程を1ポモドーロとして、4ポモドーロ終えたら15〜30分程度長い休憩をとる

仕事の時間の使い方をフレームワーク的に決めることによって高い集中力を保とうとするテクニックです。
半強制的に休憩時間を挟むからペース配分が出来るという利点もあります。

私は

  • 30分作業する
  • 10分休憩
  • 4ポモドーロこなしたら30分休憩

と緩めな設定にしてやっています。
スマートフォンは鞄にしまって、メッセンジャーの類も全て通知を切って行うのがコツです。
スマートウォッチをつけているので、腕時計でタイマーを動かしています。オススメです。

Gitと相性が良い話

Gitでcommitを積み込む際に、粒度が大きくなり過ぎることがよくあると思います。
そんなときにポモドーロテクニックを利用して、1ポモドーロでとりあえず1commit積み込むようにすると良い感じの粒度になります。
大体1ポモドーロ30分程度の作業量になるから、細かいタスク1つ分程度のcommitとなりcommit messageも書きやすくなるのです。

大体粒度が大きくなってしまったり、commit messageに2つ以上の要件が含まれて書きづらいときは、自分の中でも整理しきれていないことが多いので、調整として役立っています。

とはいえ30分で終わらないタスクもあるので、そういうときはとりあえずwip commitとして後でamendでまとめてしまいます。

まとめ

あれもこれもと考えが右往左往してしまう自分にとって、生産性を高める良いテクニックでした。
いろいろなこと考えてるときって頭が疲れるし、進捗も良くないのですよね……

現状ポモドーロを実践していて、8ポモドーロくらいやると集中力の限界がきます。
自分の限界も把握しつつ仕事進められるようになれば効率上げられるかなあと考える次第です。

SIer/SESに未来を感じない

hotchemi.hateblo.jp

Twitterでこの記事が回ってきて読みました。
今現在SESに身を置いているので共感できる部分が多かったです。

読み終わった後によくみてみたら書かれたのが2013年。
5年も前の記事でした。
5年も経っているのに何も状況が変わっていないSIer/SES業界に闇を感じたのでぽえむを書きます。

経歴

この辺りの話って経歴とか立場によるバイアスがかなり強いと思うので、ざっくり経歴を書きます。

  • 現在25歳
  • 情報系大学既卒
  • モバイルゲーム会社に早めに内定をもらい、学部4年から働き始めて、2年半程度
  • モバイルゲーム会社を退職し、現在SES企業

SIer/SESの良くない点

整った文章にするのが難しいので、箇条書きで羅列していきます。
ちなみに私は今N●●の現場でお仕事をしています。

技術力のある人が少ない

現在既存システムの改修という形で仕事をしているのですが、使われているフレームワークとかコードの構成がどうとか把握できている人間がいません。
システムの歴史が古い影響もあるので、仕方がない点もあると思うのですが、現場で書かれているコードを見ると、
そこら中にあるtypo / 深いネスト / ずれるインデント / ファイルの中にタブとスペースが混在 / 1つのメソッドが100行超え / 実行されないコード / 共通モジュールと言う名の神クラス / ドキュメントは書かれているものの間違っている / 使われていないドキュメント / コメントが信じられない / 役に立たないコメント(// xxにyy代入するみたいな)
と巷でクソコードと呼ばれるものの役満をいっている感じでした。

社員の人に 「この会社で向上心を持っている人なんていない。とりあえず動けば良い」 と明言されて僕の心は崩壊しました。
読書会とかしようと提案しても乗ってくる人はいません。
反応もらえたとしても「できたらいいよね〜」だけです。

IT技術を利用していない

たしかにプログラミングして、アプリケーション作って、それが世の中で使われているのですが、何かIT技術というものを勘違いしているような気がしてなりません。

例えばテストについて

エンドユーザーとなるお客様がいて納品する形式になるので、テスト、もとい試験と呼ばれるものは重要です。
ですが、なぜ手作業で試験を行うのでしょうか……
しかも試験書と呼ばれるものは紙で出てきます。 単体試験から、結合試験まで紙とペンを利用して行われます。
ネット上で噂には聞いていましたが、実際に目にすると目眩がする状況でした。
品質を高めるため、バグを減らすためのテストではなく、カバレッジエビデンスを出すためだけにテストが行われています。
目的と手段をはき違えてしまっている。そんな印象を受けました。

嫌われる自動化

私はプログラミングにおいて自動化に著しい興味関心を覚えています。
ですが、SIer/SES業界では自動化は好まれていないようです。
人月という制度によって自動化して効率化してしまうと、SES会社が困るという話もありますし、
そもそも自動化という概念が頭から抜け落ちている人が多いように感じてしまいます。

手作業バージョン管理

20181013第一版.xlsx みたいなファイル命名で管理されてます。
gitなんて使われません。svnすら怪しいです。
なぜ使われないのか聞いてみたのですが、
「社員に覚えさせるコストが高いから」「現状の形でなんとかなってる」「セキュリティ上の問題で使えない」
といった言葉が返ってきました。
些細な抵抗として、私はローカルでgitを立ち上げて自分の作業だけ管理してます。
頭で覚える必要がないから楽です。

情報共有が行われない

まだ何故なのかまでは把握できていないのですが、情報共有が一切行われません。
誰が何の仕事をしているのか、どの仕事がいつ終わるのか、xxのことは誰に聞けばいいのか
そういった情報が全く出回らないのです。
もちろんSlackのような社内チャットツールのようなものも存在しないので、情報共有する場が整っていないという点もあります。

何故5年前から何も変わっていないのか

ここまでほぼ愚痴のような形でSIer/SESのダメな点を書いてきましたが、「何故ダメだとわかっているのに変わらないのか」
ここに関して気づいたことを書きます。

変化を嫌う体質

SIer/SESは比較的古く、大きい企業が多いようです。
そのためか変化を嫌う傾向がつよく感じます。
たとえ改善活動といっても何かをするには許可を取らなければいけない仕組みが出来上がってしまっています。
そしてその許可は降りないか、降りるとしても長い時間がかかります。

個人的には、なにか問題が起きるとしたら、そもそも問題が起きないようにする のも大事なのですが、 それ以上に 問題が起きた時にカバーできる仕組みや力をつける の方が大事だと思っています。

「許可を求めるな謝罪せよ。」

この精神を忘れずに生きていきたい。

向上心がない

前項で書いた通り、勉強熱心な人間がほぼいないようです。
向上心がなかったら改善も発生しないので、何も変わらないでしょう。

何故向上心が生まれないのか考えてみましたが、良くも悪くも 仕組みが出来上がってしまっているから このように感じます。
例えば人月計算のSES企業の場合、極端な話何もしなくてもその場にいれば賃金が発生します。
向上心を持って勉強しなくても生活できてしまうから焦りといったものも発生しないのです。
これが悪いことだとは言いませんが、私は居心地悪く感じてしまいました。

さいごに

ほぼほぼ愚痴みたいな形でぽえむを書いてしまいましたが、この業界があること自体は悪いとは思っていません。
未経験に対して広く窓口を開けているのも業界全体の人口を増やすのに繋がっているだろうし、悪いことだけではないはずです。
(未経験が給料安くて……みたいな話はまた別として)
ただただ改善や変化といったことを嫌う傾向があるといった点だけ残念でなりません。

最初にあげた記事が、5年前の記事。
そして記事内で10年前から何も変わっていないと言われているため15年になります。
15年経って変化がないというのは、そういうことでしょう。

まだ2ヶ月程度しか業界に身を置いてませんが、エンジニアとしてこの業界に慣れてしまっては今後が危ういと感じたため、転職活動をはじめました。
すぐに転職できるとは思っていないので、いろいろインプット/アウトプットしつつ、自分の成長を促してより良い環境を求めています。

完全SIer脱出マニュアルを読んだ

概要

技術書典5にて手に入れた完全SIer脱出マニュアルを読んだので、備忘録兼感想です。

ざっくりと感想書くと、とても良い本でした。
ただ、立場によって内容が楽しめるかどうかかなりバイアスがかかる気がします。

  • SIer/SESにいる
  • SIer/SES関わらず現状環境に不満がある
  • IT業界に入ろうとしてる学生

こんな人にとって、とてもためになる本だと感じます。

章ごとに感想箇条書き

第1章 なぜエンジニアはSIerを去るのか

  • SIerのダメ(?)なところを精神論ではなく、具体的な言葉で示している。
  • 中立の目線で書かれていてとても良い。
  • わざとポジティブな意見で書き換えられている箇所があって、転職時の言葉選びの参考になる。

第2章 自分や環境を変えるための前提知識

  • IT業界の構造を理解できる。
  • 転職は怖くない。
  • 20代で複数回転職する人もざらにいるという言葉に少し救われる。

3章 完全SIer脱出マニュアル

  • 転職を複数回繰り返すことで徐々に状況を改善していくという選択肢

  • インプット/アウトプット、勉強会の参加の仕方をレベル別に分けて買いているの素晴らしかった。

  • wantedlyアカウント作るべき??

    • 早速作りました
  • ブログやTwitterの情報発信はどんどん増やそう。

  • tutorialレベルでも気になったこと学びになったことはとりあえず文章化しよう。

  • 転職エージェントと転職サイトの違いを細やかに書いてある。

  • キュレーションサイトでも似たような内容あるけど、実体験も含めて書いてあるから信頼感がある。

「面接の場を少しも楽しめないような会社では、楽しく働くことはできません」

まとめ

どんどん転職したくなってきた……

アウトプットを続けていって、自分の理想の環境にたどり着けるよう努力を続けたいなという気持ちが増し増しになりました。

触発されてwantedlyアカウント作ったり、
twitterにて転職活動してみたりしましたが、
早速いくつかの企業とお話できそうです。

技術書典5に参加してきた

人生初の同人誌イベント参加が技術書典5になりました。
同人誌イベントを完全に舐めていて、ボディバック1つで行ったのが後悔した点です……

戦利品

f:id:jalemy:20181009210821j:plain

初めての参加だったのもあって日和つつ買い物進めて4冊だけ購入しました。

DNSをはじめよう/AWSをはじめよう

この2冊は、¥1,000- と ¥1,500- の本だったのですが、抱き合わせで ¥2,000- になるということで両方とも購入。
装丁も内容も普通に書店で売っている本と違いがわからないレベルで即購入しました。

mochikoastech.booth.pm

Chromeデベロッパーツールを使いこなそう

仕事でjavascriptを書くことがあってちょくちょくChromeデベロッパーツールを使うことがあるので購入。
細かく画像付きで解説してくれてるので初心者に優しい本でした。
javascriptは型がない影響でいろいろとわかりづらいから助かります……
きっとすぐこの本のお世話になります。

完全SIer脱出マニュアル

最後に前評判が凄まじく、タイトルだけで心惹かれるこの一冊。
最近SES企業に故あって転職したのですが、早速脱出したくなっている僕へ突き刺さる内容です。
早速半分ほど読み進めましたが、SIer/SESではなくても心にグッとくる内容が多くオススメの一冊です。
これから就活する学生さんが読んでも業界勉強になって良いかもしれない。

本当は紙の本が欲しかったのですが、同人誌イベントの勢いを完全に舐めていて売り切れてました。

shiganai.org

当日の流れ備忘録

時刻 やったこと
11:00 某東京の西の端の街を出発
12:15 池袋に到着してちょっと迷う
12:40 入場して、人の多さに圧倒される
13:00 DNS/AWS本、Chromeデベロッパーツール本を購入
14:00 昼食休憩を挟む
14:30 もう一周して、完全SIer脱出マニュアルを購入
15:00 離脱

という感じでした。

反省点

  • 本を入れるためのリュックか手提げを持っていくこと
  • 予算決めて1,000円札とか崩した状態で持っていくこと(今回は偶然なんとかなりました)
  • 紙の本を手に入れるためにもっと早くいくこと
  • 人混みに負けないように体力補給しておくこと

まとめ

人生初の同人誌イベントでしたが、かなり楽しめました。
本を書く中の人たちが物凄い楽しそうだったので、サークル活動とかちょっと心惹かれてます。

次回もぜひ行きたい。

プリンシプルオブプログラミングを読んだ

通勤時間を使ってプリンシプルオブプログラミングを読み終えたので感想もといメモ書きです。 Kindleでセールになっていて、 ¥1,069- でした。安い。

概要

書籍のタイトルの通りプログラミングについての 原理・原則 を書き連ねた本になります。
具体的なコードでの記述などはありません。
そのため、実際に開発に携わったことのある身でないと実感は得られないように思えます。

プログラミングだけではなく、プログラマーとしての仕事の仕方、生き様についても書かれています。
ちょうど僕自身が業界3年目になるので、働き方の指針となるものを手に入れることができる良書でした。

プログラミングにおける「原理・原則」とは

「密結合なコードは良くない」
命名がダメ」
「xxxという法則に乗っ取って書くべき〜」

プログラミングという仕事に携わっていると、上記のようなダメ出しを言われることが稀に良くあります。
概念としてはわかるのですが、 何がどうなったら密結合とみなすのか、その具体的な線引きはどこにあるのか
といったことが、正直わかっていませんでした。
この書籍では、そんな部分を具体的にレベル分けして説明してくれます。

例えば密結合の部分に関して、もとい凝集度に関しては、

  • レベル1 暗合的強度
  • レベル2 論理的強度
  • レベル3 時間的強度
  • レベル4 手順的強度
  • レベル5 連絡的強度
  • レベル6 情報的強度
  • レベル7 機能的強度

と、段階に分けられています。
そして実務においてどのレベルを目指すべきか、その妥協点において書かれているのがありがたいです。(もちろんレベル7が一番良いのですが……)

気をつけようと思ったこと箇条書き

書籍を読んで気をつけようと思った点を箇条書きにしてみる。

  • 常にコードを読む人間を意識して書く
  • コードを書く時間と読む時間。圧倒的に読む時間の方が多い。
  • 複数のことを並行して解決しようとしない
  • 人間の短期記憶は拙い。メモやTODOコメントを活用すること。
  • 困った時はUNIXを思い出し、CLIに戻る
  • 人間には感情がある。いかに感情を殺して原則に乗っ取れるか。大事。

まとめ

原理原則について書かれている書籍なので、箇条書きにするのが難しい……
というか書籍の感想書くのってとても難しいですね。目次を全て書き出してしまいそうになります。

冒頭にも書いた通り、実務経験がない人にとっては少し実感が得られにくい本だと思います。
またこの本を読む前に、リーダブルコードあたりの本は目を通しておいた方が良さそうです。

プリンシプルオブプログラミングの中で関連書籍をいろいろとオススメしてくれているので、次はそのあたりを読もうかなと。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

iOS12 ショートカットアプリでノイズレスサーチできるようにする

概要

togetter.com

このあたりの話が盛り上がっていて、実際自分でも料理のレシピ検索などノイズが多いなと感じていました。
ということで

pasokatu.com

こちらのノイズレスサーチをiPhoneから利用しやすいようにショートカットを作ってみました。

つくったもの

f:id:jalemy:20181001223805p:plain

  1. テキストを入力
  2. スペースが入っているとURLではエラーになるので、 %20 に置換
  3. URLに埋め込んで
  4. Chromeで開く

という感じです。

まとめ

このショートカットをホーム画面においておけば、ボタン一つでノイズレスサーチができます。

日々繰り返し行なっている動作を少しずつショートカットアプリで置き換えてます。
ToDo管理やSNS周りも自動化できそうだなと思っている今日この頃。

iOS12 ショートカットアプリでevernoteの日記作成を自動化してみた

概要

iOS12で追加されたショートカットアプリが想像以上に遊べる代物だったので、ひとまずevernoteへの日記作成を自動化してみました。

毎日evernote

タイトル 2018/9/29

時間 内容
6:00 朝ごはんにトースト食べた
8:00 本6章まで読んだ

みたいな感じで日記もとい行動記録のようなものをつけています。
この日記を書くにあたって
* 今日の日付でevernoteにノートを作る
というのが自動化できそうだなと思っていたところ、iOS12のショートカットに目をつけたという感じです。

つくったもの

ショートカットがプログラミングコードみたいにテキストベースで表現できなかったので画像をそのままぺたり

f:id:jalemy:20180929120705p:plain

一部編集で画像ぼやけてますがご了承ください

  1. evernoteのタイトル検索で、今日の日付のノートを取得
  2. ノートを取得できたかどうか判定

ノートが取得できた場合

  1. 取得できたら、ノートのリンクを取得
  2. リンクをもとにevernoteアプリで取得したノートを開く

ノートが取得できなかった場合

  1. 取得できなかったら今日の日付のノートがないということなので、新規ノートを今日の日付で作成
  2. わかりやすいように通知ダイアログを出す
  3. ノートのリンクを取得
  4. 作成したノートをevernoteアプリで開く

といった感じです。

まとめ

今まで手作業でノートつくって、開いて、と面倒な作業していた部分が自動化できました。
ショートカットアプリは他にもカレンダーや地図周りの処理もできます。
既に話題になってましたが、sshcurlを利用しての処理も作れるみたいなので、かなり遊べる気がしています。