gitのpush前にmerge --squashとpullとrebaseを

gitでどうブランチを切ってコミット・プッシュするかの運用方法については様々な意見というか流派（？）があるように思います。僕自身も複数人数のチームで開発を実際に行う中で、こうしたらいいんじゃないかって思っている方法を書いてみようと思います。

まず開発のタスク管理にはredmineを使っている、という背景があります。gitの共有リポジトリはredmineと連携させていて、共有リポジトリにプッシュしたコミットのメッセージにチケット番号を記載しておくと、自動的にredmineのチケットからリポジトリビューアにリンクされるようになっています。そのような背景から、チケットごとにコミットを1つにまとめています。

さらに、共有リポジトリへプッシュする際は、自分の名前が付けられたブランチにプッシュすることにしています。（masterへのマージはmasterブランチ管理者以外は行わない。）例えば僕はkasaiという名前のブランチを作成して、そこへ自分が担当するチケットを解決するコミットを行い、それを共有リポジトリへプッシュします。

masterブランチ管理者は、共有リポジトリへプッシュされた他の担当者のブランチをローカルリポジトリへプルしてmasterへのマージを行い、改めて共有リポジトリへプッシュします。（つまり、共有リポジトリのmasterへのプッシュを行えるのはmasterブランチ管理者だけです。）

この辺までは結構よくある運用方法でしょうね。ここまで全体的な流れの話を書きましたが、次に、各担当者が個人的に行う運用方法についてです。

僕の場合、ローカルリポジトリにはローカル用ブランチを作って作業しています。ローカル用ブランチは自分のためだけのブランチで、一度行った変更を後のコミットで元に戻したり、試行錯誤の汚い履歴が混在していて、そのまま共有リポジトリにプッシュするなんて考えられない代物です。ちなみに僕はローカル用ブランチには local/yy.mm.dd という名前を付けています（yy.mm.ddは作成時の日付、１日に複数作成した場合はyy.mm.dd-2などとする）。

とういことで、ローカル用ブランチで試行錯誤して、完成したら提出用ブランチ（前述した例ではkasai）にまとめて取り込むという方法を採っています。その際にはmerge --squashを使います。

なお、提出用ブランチにmerge --squashされた後のローカル用ブランチは消してもいいのですが、バックアップの意味もあるし、コードが動かなくなった際に履歴が残っていると原因究明にも役立ったり、元に戻したりできるので残しておくことにしています。

では、提出用ブランチをこのままpushすればいいかというと、ちょっと考えるべき問題があります。pushする前に、共有リポジトリのmasterに、自分が元にした時点から変更がいくつも加わっている場合、コミット内容がmasterと競合しないにもかかわらず、仕様変更によりコードが動かなくなってしまう可能性があります。例えば、他人の担当範囲で定義されていた関数やメソッドを呼び出してコードを書いたが、自分がローカルで作業している間に、その関数やメソッドの挙動を変えるコミットがmasterに既にマージされていた、といった場合です。（この問題に関してはGitユーザマニュアルの「マージコミットの分割が１本線の履歴の分割よりも困難となる理由」の解説が分かりやすいです。）

だから、push直前に、最新のmasterを改めてpullで取得し、その最新のmasterにこれからpushしようとする変更を統合した状態で動作することを確認しておきたいんですね。そのためにrebaseを行ます。つまりpush直前に、自分のブランチをpullで取得した最新のmaster上にrebaseするのです。

こうすることで、上記のようにmaster側に知らないうちに仕様変更が加わっていて、競合が発生しないにもかかわらずコードが動かなくなる、という事態に陥る危険性を（ゼロではないにしても）かなり減らすことができます。また、もしそのような事態になったとしても、rebaseしておくことで原因の究明はぐっとやりやすくなります（当然ながら、これはpush前のコミットだからrebaseしてもいいのであって、たとえ提出用ブランチでも、一旦pushした後のコミットは決してrebaseしてはいけません）。

まとめると、こういう流れになります。

1. ローカル用ブランチを作成し開発を行う。コミットは適宜好きなように行う。
2. 提出用ブランチにてmerge --squash でローカル用ブランチの変更をまとめて取り込む。まとめる単位はredmineのチケット単位とする。
3. masterブランチにてpullで共有リポジトリの最新の状態を取り込む。
4. 提出用ブランチにてrebaseで変更を最新のmaster上に移し替える。
5. rebaseされた提出用ブランチにて共有リポジトリへpushする。
6. (masterブランチ管理者のみ) 各担当者の提出用ブランチブランチをpullし、ローカルでmasterへのマージを行い、共有リポジトリへpushする。

これが今のところいいんじゃないかと思っている方法です。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミング言語のバイリンガル以上を

現在僕が関わっているプロジェクトは1つはRuby、もう1つがPHPをメインの言語として採用しています。自分自身の経験としても、PHPとRubyは得意とする言語なので両方とも言語を使うこと自体に苦労はありません。その他にもJavascriptは両方のプロジェクトで多用していますし、補助的にPythonも少しだけ使っています。あとは汎用言語ではありませんがシェルスクリプトも駆使します。HTML・CSSの知識は言うまでもありません。

実際プロジェクトの開発を進めてて思うんですが、２つ以上の得意な汎用言語を持っておくと色々メリットが有るんですよね。別にRubyとPHPじゃなくてPythonでもC#でもJavaでもPerlでも何でもいいんですけどね。とにかく2つあれば、色々比較ができるわけで、両方の言語を実際に使って開発した体験・経験を比べることによって言語の特徴が体感覚として分かるわけですよ。

例えば片方の言語で慣れたやり方を、もう一方の言語で実装しようとした時にすんなり行かないことがあったら、そこで言語の強みと弱みが分かります。また、そこでもう一方の言語で実装するときの最適解を考えますから、これも力になります。

それに、複数の言語での実装を知っていると、より汎用的なロジックを考えられるようになります。特定の言語に依存したロジックではく、別の言語でも問題なく実装できるようなロジックを考える傾向がつきます。その方がバグも出にくく、品質の工場にも寄与すると考えられますね。

ともあれ、プログラミング言語はバイリンガルになっておくと色々得をします。もちろん2つに留まらず、3つ4つと大いに越したことはありませんが、まずは2つを目指すとよいでしょうね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

ググっても解決しない問題にこそ力を注ぐ

今のソフトウェア開発ってフリーソフトとかオープンソースとか皆が共通に利用できる資源が整ってまして、仕事で使うソフトウェアも手に入ります。その結果優れたソフトウェアは皆が同じものを使うようになります。得られたノウハウもウェブページやブログや各種SNSで公開していくために、困ったことがあればググればほとんど解決できるんですよね。その意味でネットが無ければ仕事になりません。

だから知識は重要だし、他人が既に見つけた問題の解決策を素早く見つけることも必要ではあることは確かです。僕も散々そう言ってますし。でも、そこには当然ながら限界がありまして、仕事をしていれば必ず、そう"必ず"いくらググっても解決策を見つけられない問題にぶちあたるものなのですね。

その時こそが本当に力を注ぐべき時です。ググって解決できるものをサッサと片付けるのは、この"いくらググっても解決策を見つけられない問題"に時間を掛けるためだと言っても過言ではありません。

ちなみに僕は"いくらググっても解決策を見つけられない問題"にぶちあたるのを、いつも楽しみにしてます。まあ、ググってサクサク問題を片付けるのもシューティングゲームみたいで楽しくはありますが、やはり本気で頭を使う時が一番楽しかったりするので。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

コーディングには自分なりのポリシーを持つ

ソフトウェア開発をしておりますと、人の個性が出る作業の代表格はプログラムのコーディングでしょう。

性格も出る気がしますし。注意すべきなのは、面と向かって話している時に感じる印象と、プログラムをコーディングしている時に、そのソースコードに現れる印象は違うことがあるということです。

ともあれ、それぞれの個性というのはありますが、その中においても、やはり各自が自分なりのポリシーを持つべきだと思います。

僕だったら、
・コードの簡潔さより、長くても読んで分かりやすい方を優先する
・コメントは積極的に入れる

などですね。自分なりのポリシーを持ち、その運用を改善していくことにおって、コーディング自体のスキルも上がると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

ボツになるコードを書く勇気

仕様書通りに動くプログラミングをするのが
我々ソフトウェア開発者にとって仕事の基本ですが
ただ言われた通りのものを作るだけじゃ面白くないわけでしてね。
改善提案をしたいわけですよ。

ところが、人間ってのは実際自分の目で見て動作を実感しないことには
口で行っただけでは提案した改善の効果が伝わらなかったりする、
なんてことが多いです。

そういう場合に、たまに僕がやる手段は、
ボツになるかもしれないのを覚悟で改善提案のコードを
書いてしまうことです。そして目の前で実際に動かしてみせるのです。
もちろんボツになったこともありますが、意外に採用してくれる
ことが多いですね。

言われたことだけ、仕様書に書いてあることだけを創っていては
見えてこない物があると思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

次々に出る新技術とどう向き合うか

この記事『「新技術の習得」は麻薬だ 』を読んだんですが、共感するところが多いですね。次々と有象無象の新しい技術が出てきて、まるで「よどみにうかぶうたかた」のようにボコボコと出現しては消えていくわけですが、追いかけまくっていればそれだけで気持よくなってしまうかもしれません。

実際、技術者同士で話をしていると、知識が膨大にあるというだけで表面上は優秀に見えたりするし、相手の知らないことを自分が知っているという状況の優越感は理解はできます。でもそれが実際の仕事につながるかと問われれば、かなり怪しいですね。

僕の考えとしては、「自分が実際に今使っている、あるいはこれから仕事で使う技術」について徹底的に掘り下げて追求し、その過程で関連する新技術があれば吸収していくべきだと思っています。

注意すべきは、新技術の吸収よりも、現在使っている技術の掘り下げのほうが先だということです。実は、実際に仕事で使っているにもかかわらず、深く知っている、あるいは深く知ろうとする人って意外にも少ないです。

もちろん「深く」ってのもやりだしたらキリがないし、無意味な領域まで言ってしまっては仕方ないです。例えばWebアプリケーションの開発が仕事なのに、CPUのアーキテクチャに詳しくなっても、ちょっとそれは深く掘りすぎて反対側に突き抜けてしまった感があります。

でも、例えば自分が使っているフレームワークのソースコードを読んでみるとか、自分が使っている言語の解説本に徹底的に目を通してみるとか、そういう類のことならば少なくとも新技術を追いまくるよりは余程確実に役に立つし、実力の向上につながると思うんですよね。

そうやって、今使っている技術を掘り下げる中で関連する新技術に遭遇したならば、そこで初めて新技術を吸収すればいいと思います。そうすれば、実際の仕事に直結する形で新技術を勉強することになり、より有意義な勉強になるはずです。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

たまには「手を動かさないこと」も必要

よく手を動かすことが重要だって言われますよね。特にエンジニアの世界ですと、コマンドを覚えるとか、プログラミング言語を習得するとか、新しいツールを使うとか、ドキュメントを書くとか、そういう文脈で使われる言葉が「手を動かせ」です。確かにその通りであって、手を動かすこと重要である、という意見を否定しようだとは全く思いません。

でもしかし、いついかなる時も手を止めないことが良いことだ、とは僕は思わないわけですよ。たまには、手を止めて静かに深く黙考することも、これまた非常に大事なことだろうと思うのですね。別に長くそうしろとも言いません。1分とか2分とか、場合によっては30秒でいいから、集中的に思考する時間が必要なときもあります。

例えばプログラミングの前の設計を行うことを考えてみます。全体の構想を考えているとして、最初は図に書き出していくわけですよ。思いつくことを色々と。僕は紙に書き出すのが好きなのでマインドマップ形式で描いたりします。

で、しばらくすると全部書き尽くすわけですね。「手が止まる」わけですよ。そこで次の段階に移行して再び手を動かす作業を再開する、のではちょっと甘いのですね。そこはむしろ、描いたものを眺め直して、頭の中でイメージを作り、足りないものが無いか、もっと掘り下げて細かく書いておくべき点はないか、などを検討することで、完成度が上がるのです。その時こそ、手を動かさずに静かに深く考えるべきタイミングですよね。時間にしたらわずかに1・2分かも知れませんが、この時間を取るか取らないかの差は大きいはずです。

ちなみに手を止めて黙考していると「ほら、手が止まってるよ」とか何とか言って文句をつけてくる人が居たりするかもしれません。手を動かしていないと仕事してないと思ってたみたいです。そういう人は分かってないので、無視しておきましょう。僕も過去の職場にいましたね。その人は自分を忙しくするのが得意でいつも悲劇の主人公気取りの人でした。相手にするだけ無意味です。

もちろん、あまり長い黙考は疲れるし意味が無いので、僕が言っているのはせいぜい数十秒から数分間程度のことです。でも、それが重要な時もある、ってことは理解しておかなければいけないと思います。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングのアイデアが仕事中以外も降りてきた

仕事中でなくて家に帰って仕事以外のことを考えている時でも、突如としてアイデアがまるで降ってくるように湧いてくることがありますね。なんか昨日もそんなことがあって、次の日仕事に出たら早速その部分に取り組んだりしてました。

よく、アイデアを思いつくのは「4B」（「バー」「バス（風呂）」「バス（乗り物）」「ベッド」）と言われてますけれども、昨日はトイレの中だったんで、広い意味では「バスルーム」でしょうかね。ともあれ、リラックスした環境ってのはアイデアがでる環境ではあります。

とはいうものの、最初からリラックスしてればアイデアが出るのか、というと全く違うとは思いますね。その前に、集中して徹底的に考え、出し尽くせるアイデアを全て出し尽くす過程を経て初めて、上記の「4B」でのあのひらめきが発動する条件が整うと僕は考えています。

例えば冒頭に挙げたプログラミングの例にしても、その前に仕事中には全てやりつくすところまでやったと思えるレベルまで仕上げているんですよ。意識でできることを全てやったからこそ、潜在意識が開放されて、リラックスした状態の時に動いてくれる、というのが僕の考えです。

結局、仕事時間中に全力を尽くしましょうという、何の変哲もない結論になってしまいますが、まあ、仕事時間以外のひらめきというものは、そこまでやった人へのいわばご褒美みたいなものかな、と思ってます。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プログラミングでハマった時にやること

とりあえず思いつくことは全部やってみた。さらに思いついた全てのキーワードでもググってみて、手元にある技術書でも関連しそうな部分を全部あたってみた。それでもまだ解決しない。しかし次の手立ては、今のところない。プログラミングをしていると、たまーにそういう時ってありますよね。いわゆる「ハマった」ってやつです。そんな時に僕がどうしているかって話なんですけれども。

こういう書き出し方をすると、なにかメソッドとか決まったパターンでもあるのかと期待された方には申し訳ありませんが、ないんですよねぇ。結局やることは「あがく」という極めて単純な方法です。

もう一度自分の書いたコードを読みなおす。ロジックの流れを最初から追う。頭の中を整理するため、いま分かっていることを紙に書き出してみる。黙考する。途中で変数の値を出力してみる。わざと仕様とは違う動作をさせる仮のコードを入れる。わざとエラーを起こさせてみる。同じ動作をする別のコードの書き方に変えてみる。大きなコードのまとまりを小さなコードに分割して、１つずつ検証してみる。・・・などなど。

いままで見過ごしていた事実があるからハマっているわけで、見過ごしていたということは意識の外にあるわけで、となれば、自分が今まで省略してたこととか前提にしていたことをわざとやり直すとか、当然結果はこうなるはずだと思っていた部分をあえて検証するとか、手当たり次第にパターンを変えてやってみるしか無いと思うんですよ。

たいていは、その過程で解決策が見つかるものですが、それもダメなら諦めて帰って寝て翌日改めて取り組んでみると、頭が整理されてポンと簡単に解決できたりします。万が一にもそれでもダメなら、他人の助けを求めることになるでしょう。しかしそこまで自力で解決できなかった問題は、僕の経験上極めて少ないです。「あがく」ことで何とかなります。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

VimとEmacs両方に慣れておくべき理由

エディタ界の２大巨塔といえば、言わずと知れた Vim と Emacs でございますが、まあ僕は不毛な宗教論争に関わるつもりはありませんので、どっちを使うべきだなんて言うつもりは毛頭ございません。

学生時代にUnix/Linuxに触って最初に使ったエディタがEmacsでした。その頃はVimは全く使わず、Emacsで全てのテキスト編集を行っていた時期が２年くらい続いたと思います。Lispでカスタマイズも色々やりました。

ある時とある先輩にVimを強力にお勧めされて使い始め、慣れるために卒論を全部Vimで書いたことでVim使いになりました。慣れるまでには結構苦労しましたけど、慣れると便利ですよね。プログラミングをするなら断然Vim派です。普段使うエディタはVimになっていきました。

こんな経緯があって、両方のキー操作の流儀を身に付けたんですが、普段エディタとしてはVimを使っていますが、Emacsのキー操作でテキストを編集することも結構あるのです。

例えばメールを書く時は、昔はメーラー、今はGmailを使いますけれども、この時はEmacsのキー操作を使います。WindowsでしたらAutoHotKeyなんかで結構簡単に実現できますし、MacだとデフォルトでEmacs風のキー操作を受け付けてくれます。。それに限らず、テキストエディタ以外の部分でのテキスト入力はほぼすべてEmacsのキー操作でやっています。

その上で、テキストエディタはVimですね。カーソル移動やコピー＆ペースト、入力などを使いこなすと非常に便利で、繰り返しになりますけれどもプログラミングをするなら断然Vimが快適です。

ということで、Emacs風のキー操作とVim風のキー操作の両方に慣れておくと、状況に応じて使い分けられて便利ですよ、という話でした。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

プラスアルファでググる

よく仕事中には技術情報をググって検索したりしますよね。そこで、目的の情報を探し当てた段階でそこで満足するのは、少々勿体無いです。

関連情報をついでに１つ調べるようにしてみると、知識を広める良い機会となりますよ。

ちなみに、直ぐに役に立たない情報を調べるのに意味は無いと思われるかもしれませんが、こういう時についでに得た情報が、何かのタイミングで役に立ったりするものです。

プラスアルファでググることを心がけるといいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうぞ。

技術書の読み方・使い方

プロジェクトを本格的に進めていくにあたり、Rubyの専門書が１つ欲しかったので、内容が新しくかつ網羅的だと感じた「パーフェクトRuby」（技術評論社）を買いました。これから読もうと思います。そこで関連して今回は、技術書全般について読み方・使い方について僕の考えを書いてみたいと思います。

特にプログラミングだとこの傾向は強いと思うのですが、よく使う技術に関しては、わからないことを辞書的に調べる「リファレンス本」を持っているべきだと言われます。これはその通りです。ネットでもかなりの情報は得られますけれども、体系的かつ信頼性のある情報を参照できる書籍を持っていることの意義は大きいと思ってます。

ただ、そのリファレンス本としての技術書に関してはこんな言われ方をすることがあります。

「最初に目次にざっと目を通して、すぐに使いそうな部分だけを読み、残りは読む必要はない。実際に別の部分に関連することをやる時になったら、その時に改めて必要な部分を読めばいい。使えるところだけ使えばいい。」

この説について、僕は賛同していません。これでは、せっかくの技術書の真の恩恵を受けられないと考えているからです。僕のお勧めする読み方はこうです。

「最初にひと通り、とりあえず最初から最後まで全部読む。ただし、内容を憶えようとする必要はない。ただ理解しておけば良い。理解したら一旦忘れて構わない。」

こう言うと、ひと通り全部読むのは時間がかかるとか、忘れたら意味ないんじゃないの？とか思われるかもしれませんが、この読み方には目的があるのです。それは、「頭の中にインデックスを作る事」なんです。ここでインデックスと言っているのは、「この本にこんな内容のことが書いてあった」と連想するための目印のようなものです。そのためには理解して納得しておくことが非常に重要なのです。

例えば、プログラミングをしていて、ちょっと分からない問題が出てきたとします。技術書を理解して読んでおいた人は、「あれ？この問題って、あの本に書いてなかったかな？」と本を読んだことを思い出すんですね。そして、本を手に取ってパラパラめくっていると、１回全部読んでいる人は本の内容の流れをたどっていますから、パラパラめくるうちにどの辺に何が書いてあったかを思い出していきます。すると「あの問題はこのへんだな」と実際に今直面する問題についての記述を簡単に探し当てることができます。

つまり、理解して納得しているからこそ、問題に直面した時に、本に書いてあったことだと思い出すことができるし、ひと通り全部読んでいるからこそ、パラパラめくるだけで問題に該当する箇所がどこだったかを簡単に探し出せるのです。もし特定の箇所だけ読んで、しかも中途半端な理解だったら、このような使い方はできませんよね。

なので、技術書を読み終わった時に、最初の方の内容は忘れていたりします。でもそれで全然構わないのです。実際に問題に直面した時に、それまで忘れていても「あ、あの本に書いてあった」と連想して「書いてあったという事実」思い出せますからね。この時点ではまだ内容までは思い出してませんが、本を開いてページをめくり、該当するページを開いた時に一気に思い出します。

ということで、技術書は「一通り最初から最後まで読み、理解し、そして忘れる。」という読み方がおすすめです。まあ、全部ってのはキツくても、読んでおく範囲をなるべく広げておくと、その分脳内インデックスを広く作っておけるので良いと思いますよ。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

いつでもプロジェクトを引き継げるように意識する

まだプロジェクトの初期段階で、画面設計やらフレームワークの準備も手を付け始めた所ですけれども、僕が最初から意識しているのは「いつプロジェクトを別の人に引き継ぐことになってもいいようにする」ってことです。

それは例えば、僕の頭の中にしか無い事柄をなるべく少なくするということ。つまり必要事項をきちんと文章に残すという意味です。もちろん、全てのノウハウを書く時間の余裕はないですけれども、例えばネットで調べればそれほど苦労せず辿り着くようなことは書かなくていいわけで、そうではなくて僕がメモを残さないと、ネットで調べても意味不明になってしまうようなことに関しては、きちんとメモを残すということです。

他にも例えば、情報が分散しないようにすること。あることについて書いたドキュメントが複数の場所に散らばらないようにしますし、もしどうしても場所を分散する必要があるなら一箇所のファイルにどの情報がどの場所にあるのか一覧をつくります。

ドキュメントだけでなく、プログラムの構成もそうですね。見通しを良くするというと。例えばファイルの命名規則やディレクトリ構成を、初めて見た人でも分かりやすいように意識します。標準的によく使われる構成があるならそれに従うようにします。それでもわかりにくいようなら、ドキュメントに一言メモを書いておきます。

もちろん、本当に今からいきなりプロジェクトを引き継ぐことになる可能性は低いわけですけれども、いつでも引き継げるような体制をとることは、様々なメリットを生み出します。自分でもプロジェクトの細部に渡るまでしっかり把握するよう意識しますし、抜け漏れやあやふやな点もないように努力もしますからね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

仕様書を書きつつ別作業

現在プロジェクトの初期段階にあり、仕様書を書いておりますけれども、ドキュメントをずーっと書いてるとさすがに飽きてきますし、かなり脳味噌を使うので疲れるということもあります。

そこで仕様書を書きつつ、区切りのいいところで後の作業で必要になるサーバの構築・設定とか使う言語やフレームワークについて調べたりとか、ドキュメンテーション以外の作業を挟むようにしてます。

これがコーディングですと結構長時間どころか何日も集中して作業し続けたりできるんですがね。不思議なもんです。脳の使う部分が違うんでしょうね。ドキュメンテーションもコーディングもどちらも面白くて頭を使う作業ではありますけれども。

ということで、ドキュメンテーション以外にも色々やることはあるので適当に時間を配分しつつ進めていこうと思います。この辺の作業への時間配分が自由にできる今の環境はありがたいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。

エンジニアのための「セーブポイント」仕事術

よくロールプレイングゲームだとセーブポイントってあるじゃないですか。最近のゲームはいつでもセーブできるものが多いと思いますけど、昔は特定の場所でしかセーブが出来なくて、それをセーブポイントと呼んだわけですよ。うっかり失敗して全滅して、セーブポイントまで戻らざるを得なくなった、なんて経験した諸氏も多くいらっしゃることでしょう。あれは実に時間を奪ってくれましたよね。

さて、ITエンジニアとして仕事してますと、なんか仕事にも「セーブポイント」に似たようなものがあると感じるんですよね。例えばプログラミングだったら、とあるモジュールのコードを書いていて、最後まで書き終わればそれで「セーブポイント」に達したようなもので、そこで仕事をやめても次から続きをすんなり開始できるわけですが、途中でやめて帰ると、次の日前日にやってたことを思い出さなくちゃいけなくなり、結局前日に書いたコードを読み直さないといけなくなってしまうので、それが以前の「セーブポイント」まで戻される感覚に近いわけです。他の仕事、例えば事務作業なんかだと別にいつ仕事を中断しても続きから始められるのかもしれませんが、エンジニアの仕事だとそうは行かないと思います。

その意味で、自分の仕事はどこまでやったら「セーブポイント」なのか常に意識しておくと仕事の効率を上げることができます。例えば、帰る予定の時刻まで残り１時間しかない状況で、「セーブポイント」まで２時間かかりそうな仕事を始めると、結局「セーブポイント」に達する前に帰る時刻になってしまい、無駄が生じるわけですよ。

ここで注意していただきたいのは、「セーブポイント」と言っているのは仕事の全体量を言っているのではないってことです。上で挙げた例でも、残り１時間だから「１時間で終わる仕事をしよう」と言いたいのではないのです。例えば全体が６時間かかる仕事でも、「セーブポイント」が１時間おきにあるのであれば問題ないわけですね。

もしフレックスタイム制など時間の調整の自由が効くのであれば、日々の勤務時間を「セーブポイント」のキリの良い時間に合わせるという手も使えます。そうすれば仕事の効率をかなり上げることができます。

ということで、普段から仕事をする上でも「セーブポイント」を見つけるようにしておくといいですね。

※この記事について指摘・意見・提案・感想などありましたら下のコメント欄にどうそ。