だいたい47度

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

PageTop

時間をつかうことで時間を節約するということ

社内でjavaのペアプログラミングをやらせてもらった。ペアプログラミングとは、2人のエンジニアがペアとなって1台のPCでプログラムを共同開発する手法で、利点としては、互いに相手を見る間は割り込みのない集中した時間をとりやすいこと、見られている意識から妥協のないコードが書けること、知識のトランスファーができることが挙げられる。僕はプログラミングに詳しくないので、スキルの非常に高い人と組ませてもらって知識のトランスファーをしてもらった。

そして、たった半日ペアプログラミングをやっただけで僕は多くのことを学ぶことができた。しかもその内容は技術側ではない人間も意識すべきだと思われるものも多かったので、次の社内会議のときに内容をまとめて発表させてもらうことにした。そこでまず練習がてら内容をここにまとめてみようと思う。前提条件として、僕の会社はベンチャーなので全員仕事に追われているのが常態化していることを覚えておいて欲しい。

僕が学んだことは主に3点だ。

1 手を動かす前に頭を動かす時間をとる
2 一定のタイミングで検証する時間をとる
3 単純作業の練習時間をとる


1 手を動かす前に頭を動かす時間をとる
仕事が振られると、振られたままの形の作業をしたくなる。しかしその前に「なんでこの作業がふられたのか」を考える時間を取り、依頼者が本来望んでいるものを把握するべきだ。すると、たとえ作業時間が足りなかったとしてもポイントを外すことはなくなるし、作業中に不足の事態に陥っても全体の骨格が見えているので立て直しが容易になる。場合によっては、本来頼まれた作業よりも簡単な作業で相手の要望を満たせるかもしれない。

これはプログラミングでいうとインターフェースと実装をきちんとわけることにあたる。僕のような初心者は、最初から少しずつ実際に動くものを書き始めてそれをつないでいくような、直線的なプログラミングをしがちだ。すると、何か途中で間違いがあったり、仕様の変更があったりすると、全体を見返しながら修正やその影響を考えていかなくてはならず、ツギハギだらけの複雑なコードになってしまう。

一方、ペアプログラミングにおいては、まずどういったものを作るかの図を作成し、それぞれのパーツに関して中身のない型(実装のないインターフェース)だけを次々と作っていった。その後型を埋めていく形でプログラミングをしていく形で作成が進んでいく。すると、たとえ戻りが発生しても修正するのは該当パーツの型のまわりだけであり、修正は容易で全体のことを考える必要もほとんどない。

作業時間に追われていると次々と業務をこなしたくなるが、状況を見えるようにする時間を少しとるだけで、むしろ全体的な作業時間は削減することができるのだ。

2 一定のタイミングで検証する時間をとる
一つの仕事を「作成→検証→修正」という流れで見ると、まずは一気に「作成」を終わらせて、全体的に「検証」してから「修正」に入るということがやりたくなる。それが最も「作成」が早く終る=仕事が早く終わったように見えるからだ。しかし、一気通貫で作成を終わらせるのではなく、一部分を作成したら検証・修正を行うことを繰り返しながら、徐々に全体を作り上げていくべきだ。

一気通貫に作成を終わらせてから検証を始めたとしよう。そして問題が見つかったとする。するとまず、何が問題なのか探しだすために全体を走査しなくてはならない。そして次に、直そうとしたときにどこに影響があるのか見極めまくてはならない。更にもっともまずい場合として、直すなら全体的な枠組みを変えなくてはならなくなっていることを見つけるかもしれない。一度完成したものを修正するというのは大変なのだ。

一方、何かを作成するたびに検証を行うフローをいれてみよう。するとまず、間違いを探すのが容易である。今作ったばかりのもののどこかに間違いがあるからだ。次に直すのも容易だ。直すのは同じく今作った範囲だけなのだから。万が一、全体的に間違えているということ=今までの前提条件が間違っていたことが発覚したとしたら、たしかに全部やり直しになるだろう。しかしその場合も、最も早い時点で前提条件の間違えに気づけたことになる。

この短いスパンでの検証は、正直面倒でしょうがないのでルール化しなくては続かない。短期的に見れば作業を遅くしているように感じるし、何より「そんな単純なところで間違うわけがない」とみんな思っているからだ。だが人は驚くほど単純なミスをする。そしてダムに開いた穴のようにそこから決壊する。だから、なにかしらのルールを決めて短いスパンでの検証をおこなうべきだ。プログラミング的には常にコードとテストを並行して作っていった。

3 単純作業の練習時間をとる
仕事を素早くやらなくてはならない場合、自分の持っているスキルだけを使いたくなる。知らないスキルを学習するにはコストが掛かるし、その学習コストもどのくらいかかるのか見えないからだ。しかしその考え方では自分の処理速度は向上せず、いつまでも忙しいままだ。そのため、仕事の中でも学習という観点は持ち続けるべきだが、特に「最も単純な作業」に関しては意識して学習をすすめるべきだ。

「最も単純な作業」を練習するのはつまらないし、効果が薄いように見える。たとえばショートカットキーを使ってできる作業のことを考えてみよう。ショートカットキーのある作業は、ショートカットしなくても数秒でできる一方、慣れていない場合はキーを探すことに時間を取られることになる。つまり、覚えたところで効果は薄いし、覚えるためのコストが作業時間に対して大きいように思える。

しかし、「最も単純な作業」こそ高速化すべきものなのだ。複雑な仕事と違って学習が容易な上、汎用性が高いからだ。ペアプログラミングでは、ショートカットキーがある作業は必ずショートカットを使うというルールを課してみた。すると思っていたより簡単に身体は覚えていくことに気づいた。最初は全く覚えられず間違ったキーを押してしまうが、数回で意識せず実行できるようになる。

プログラミングの設計などは一朝一夕で身につけられなくても、ショートカットキーなら一日で概ね使えるようになる。そして余計なことに時間や頭を使うことがなくなれば、難しいことを理解する時間と余裕が生まれる。学習効率・仕事効率をあげるのに最もよい方法の一つは単純作業の効率化なのだ。数学が苦手な人が最初にやるべきなのは算数のドリルをひたすら解くことだ、というのと同じ理論だ。時間の初期投資を少し掛けることで、最終的なアウトプットは何倍にも膨れ上がる。

まとめ
要するに「長期的な視点で時間を使おう」ということになる。忙しいとどうしても視野が狭くなるし、特に時間に関してはシビアになると思う。しかし、上で見てきたように短期的な時間稼ぎは長期的には損なのだ。

このことはペアプログラミングを行った結果からもいえる。今回のような形のペアプログラミングは、スキルが高い人が僕と組んで作業をするのだから、一時的にその人の作業効率を下げることになる。しかし長期的に見れば僕の書こうとするコードの質は大きく変わっただろうし、プログラミング以外の仕事に関しても示唆が得られて僕の仕事スタイルに大きな影響を与えた。そのことは教えてくれた方にもプラスの効果をもたらすだろう。

そうはいっても時間を作るのは中々難しい。だからこそ、取るべき時間を明示化し仕組み化することが重要であると思う。自分の仕事の中で、特定のタイミングに時間を割く仕組みを作るよう考えてみてはどうだろうか。
関連記事
スポンサーサイト

PageTop

コメント


管理者にだけ表示を許可する
 

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。