読者です 読者をやめる 読者になる 読者になる

Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

生産性をあげて、定時で帰宅しよう!プログラマに限らず生産性をあげる方法<心構え編>10選!

 なかなか仕事が終わらず、残業続きの毎日でしょうか?
こんな時代ですから、なるべく仕事を定時で終わらせて、自分の時間を多く取りたいですよね。
 ここでは、(主にプログラマですが)プログラマに限らず生産性をあげる心構えを10選、自分なりに挙げてみました。

<心構え編>

①定時で帰るという確固たる決意(Determination)

 飲み会がある場合に必ず仕事を切り上げる方は多いと思います。それと同じ原理。子供が保育園に行っているので迎えにいかなくてはならない、も同じですね。Mustすぎる。

②大きなタスクを分割する。タスクにとりかかる前に締切時間を決める。(Divide and Conquer)

 分割統治法です。難しい問題は簡単に見えるまで細分化してみます。
細分化した上で個々に締切時間を決めます。

 締切を設けるコツは、自分で考えた見積もりの80%以内にすること。ここは少し自分に厳しく。少なくとも80%を目指さないと、割り込みとかで結局遅れちゃいますからね。

③仕事を定義しなおす(目的を問う)

 その仕事が本当にユーザやお客様の価値になるものか、問います。価値にならないのなら、その仕事は無意味です。

P・F・ドラッカーは「プロフェッショナルの条件」に以下のように書いています。

「手っ取り早く、しかもおそらくもっとも効果的に知識労働の生産性を向上させる方法は、仕事を定義し直すことである。特に、行う必要のない仕事をやめることである。」

 これは、「主体的に動く」ということとも繋がります。主体的に動くと自分の仕事である、という意識が強く働き、仕事が楽しくなるという効果もあります。

④ハマった場合は、他のタスクに切り替える。(自分が今ハマっているな、という感覚を持つ)

 「ハマっている」という感覚はどうやったら身につくのでしょうか。おそらく②で締切を設けることによって、自分のコスト感覚みたいなものが芽生えるのではないかな、と。
 で、「ハマった」場合は、気分転換が有効です。その日は諦めて帰ったり、仕事中だけど散歩してみたり、隣の人にハマっている内容を話してみたり。
睡眠・運動・会話は、いずれも脳を整理してくれる作用があるそうです。
 今日の自分には解けなくても明日の自分なら解ける。

⑤適材適所を心がける(ツールの選定)

 ここで言っているのは、ツールの選定です。「設計書」なのにExcel使っていませんか(Excel方眼紙好きな人ごめんなさい)?
 よく見るのはExcelを本当に素晴らしいぐらいに使いこなしている方ですね。・・・うーんと唸っちゃいます。スプレッドシートは、単純な表以上のことを表現しないほうが良いです。セル結合も控え目に。。。理由は、⑥⑨に繋がらなくなるからです。

⑥情報はプレインテキストに表現するよう心がける

 ExcelやWordなどのバイナリー形式は、プログラム(やスクリプト)から読みづらいので、データの解析・加工が容易ではありません。
 「達人プログラマー」では、プレインテキストによるメリットは以下のように述べられています。

  • 透明性が保証される(人間が読みやすいように構造化する必要はあります。HTMLやXMLは良い例です)
  • さまざまな活用ができる(Diffが取りやすくなる。コードやテストコードの自動生成のインプットとして使える)
  • テストが容易になる(テストデータの自動生成)

 いずれも桁違いの効力を生みます。

DRY原則を忠実に守る

 同じ知識を2箇所以上に記述しないようにしたいですね。コードの重複はもってのほかですが、コードとコメントも然り。コードと設計書(UMLなども)も然りです。

DRY原則にしたがえば、低水準の知識はコードに任せて、高水準な解説をコメントで記述する、ということになります」 達人プログラマーより

⑧自動化を心がける

 xUnitによる単体テストはもはや常識のようになりました。10年ほど前は名前も知らなかったかも知れません。JUnitはあったかな。
 自動化は、何も単体テストの実行やCIによるビルドだけではありません。⑥によるテキストからコードを生成したり、データベースを扱うシステムであれば、データベーススキーマやデータからコードを生成(scaffold)も可能です。
 私はSQLでコードを作るのが好きです。Soapであれば、WebServiceの定義からクラスを生成してもいいかも知れません(WCFはそうなっていますが)。

⑨T4やVelocityなどのコード生成スクリプトを利用できるクラス・アーキテクチャにする

 ⑧の続きになりますが、自動生成したものに対して人の手を加えてしまうと、次の自動生成時に厄介です。
 O/RマッパーのHibernateなどでも利用されているデザインパターンですが、GenerationGap的なパターンは覚えておくといいと思います。

デザインパターン紹介

 すべてがすべて自動生成では、アプリケーションはできないです。MDAアプローチ(MDDではなく)でも、最後に少し人の手が入ります。完璧な自動生成は、残念ながらまだ出来ないのです。
自動生成や保守運用を見越したクラス・アーキテクチャが組み込まれると、そのプロジェクトの生産性は大幅にアップします。

車輪の再発明をしない

 これだけオープンソースな世界になってきたので、自分がつくろうとしているものは、形は違えどどこかにあるはずです。まずは幅広い情報収集が不可欠ですね。
 また、既存品をなるべく使うという意識も重要です。.NETのWPFだと、UserControlが継承しやすかったり見た目のデザインを変えやすかったりするのですが、ちょっと変えちゃうと様々なことを考慮する必要が出てくるので、本当に、なるべくなら、既存品の組み合わせがいいですね。プレインなまま使いたい・・・のですが、お客様のご要望に答えない訳にもいかない。苦しいところですが、③と併用してネゴですね。

まとめ

 以上、長々と書いてしまいましたが、どれか一つでもお役に立てれば幸いです。定時で帰ってスマートなライフを!