お役立ちコンテンツ | フリーランスエンジニアの案件・求人なら【テクフリ】
様々なところで効率化して生産性を上げろ、と言われていますが、プログラミングにおいても効率化を求める声が高まっています。
しかし、肝心の「効率を上げる方法」はあまり紹介されていないように思います。
その理由としては、各社・各部署・各個人でナレッジとして蓄積されるもので、改めて議論されるようなものではない、というのがあるかもしれません。
さらに言えば、効率化のための方法、テクニックを用いて、“人より早く仕事ができること”を自分の武器にしている人もいますし、そうした方法を情報として提供することで飯を食べている人だっています（いわゆるコンサル）。
そうしたことから、知っている人も簡単に教えてくれない、という現実もあるのかもしれません。
さて、前置きが長くなりましたが、今回はプログラミングの効率化について、私が知っている一般的な方法をご紹介いたします。
ところで、効率化とはどういう意味でしょうか？
単に工数を減らすことを意味しているわけではありませんよね。
工数を減らした分、品質も下げていたら、それは効率化と呼べません。
正解としては“コスト当たりの生産量を上げること”ですが、これには二つの観点があります。
一つ目の観点としては、みなさんが想像しやすい、“単純にかけるコストを下げる”という観点です。
そしてもう一つの方法は“同じコストでより良い成果を出す”ことです。
例えば「大量生産することで、一個当たりの製造コストを下げる」という方法は、一個当たり製造コストという意味では“単純にかけるコストを下げた”ということです。
しかし、同時に同じ製造資金でより多くの個数を作れたという視点に立てば、“同じコストでより良い成果を出せた”ということにもなります。
この二つの観点を軸に「効率化できる対象・タスク」を洗い出し、具体的な対応を計画していくことが重要です。
指定されたセルに値を入力してからマクロ実行ボタンを押すと、入力された値を使ってソースコードが自動で生成されるようなエクセルをツールとして用意しておく方法です。
ロジックは同じですが、パラメーター値が異なるプログラムを大量生成しなくてはならないときによく使われる手法です。
コピー＆ペーストでチマチマ作っていく方法もありますが、何回、何十回とコピー＆ペーストするのも手間がかかりますし、コピー＆ペースト時にミスが発生するリスクがあるため、全量精査が必要になり、非効率です。
一方、マクロ利用であれば、マクロに問題がないという確認を最初に一回すれば、あとは打ち込んだパラメーター値だけの精査になり、効率性が格段に上がります。
プログラミングだけでなく、CLI（キャラクタユーザーインターフェイス）のサーバやネットワーク機器の流し込みようコンフィグ作成でもよく使われる手法です。
会議で集められて、それなりに議論したけれど、結局、なにも決まらなかった、という事態は往々にあります。
あるいは、参加者の予定調整に難航して、なかなか開催できず、WBSの進捗、ひいては案件のスケジュールにまで影響を与えてしまう、ということもあります。
さらにひどいのは、議事録などが残っておらず、「この前の会議でどういう結論になったんだっけ？」という話になり、また一から議論し直す、という無駄な会議も少なくありません。
こうした問題を避ける手段として、よく使われるのはチャットツールやメーリングリストを使った会議です。
実際にインターネット関連技術の国際標準団体であるIETF(The Internet Engineering Task Force) は年三回の定例の会議を除いて、メーリングリストで議論を進めていくことで有名です。
メーリングリストの参加者は誰でも自由に議論ができ、しかも、後からメールのやり取りをたどって、どういった議論がこれまで展開されてきたのかすべて分かるようになっています。
このような進め方で、RFCから始まるIETFが発行する規格の多くは決められてきたのです。
一つこの方法で注意しなくていけないのは、「議題の明確化」と「期限感」です。
だらだらと続いた挙句、決めなくてはならないことが決まっていなかった、という事態にならないようにだけ注意が必要です。
GASとは「Google Apps Script」というGoogleのサービスです。
Googleから提供されたGmailやGoogleカレンダーなど様々なサービスを公私で使っている方は多いと思います。
結構使い勝手が良いとは思いますが、「こういう機能があれば良いのに」と思うところもあるのではないでしょうか？
そうしたGoogleの各種サービスへの不満に対する答えとしてGoogleが用意したのが、“欲しい機能をユーザー自身で開発する機能”です。
そして“Googleのサービスに機能を追加するための開発環境”がGASです。
GASを使えば、例えば、Gmailに定期メルマガ配信機能を実装するといった機能強化や、スプレッドシートに入力した予定をGoogleカレンダーに自動反映させるなど、サービス間連携機能を自力開発し実装することが可能です。
ツールに合わせて組織や自分の行動に合わせるのではなく、組織や自分の行動に合わせて、ツールを変化させることができる、というのはストレスを減らして、プログラミングに集中できるようになる、という意味で非常に重要です。
プログラミングのタイムロスで最も致命的なものは、ソースコードを作成してからの手戻りではないかと思います。
パラメーターやロジックが変更になっているのを知らなかった、そもそも、その機能は不要になっていたなど、いくつかパターンはありますが、そもそもの原因は、情報連携の不備であることがほとんどです。
つまるところ、どのようにして、「関係するメンバーの認識を同じレベルにするのか」あるいは「関係するメンバーの認識が同じレベルになっているか確認するのか」ですが、結局のところ、対面で確認するのが一番、早いように思います。
メールやチャットあるいは書面回覧の場合、開封・既読があっても、実際のところ“読んでいない”ことも多々ありますし、対面であれば表情などから、理解しているかどうかも、ある程度推測することも可能です。
朝会などメンバーで集まる場のある方は、説明の後、特に影響を受けると思われるメンバーや不安なメンバー（そのようなメンバーがいなければ、ランダムでも良いですが）に、「いま、何の説明を受けた？」と質問して、徹底的に認識を植え付けても良いかもしれません。
プログラミングは集中力・気力の仕事であるのは否定できません。
集中力は筋力と同じで、鍛えれば持続力をアップさせることができる反面、使い続けると疲れて消耗してしまいます。
そのため、始業から就業まで、お昼とトイレ以外は席を立たずに画面と睨めっこ、という働き方を否定はしませんが、夕方に間食休憩をとるなど、集中力を維持するための休息を入れることをおススメします。
今回はプログラミングの仕事の効率化について見ていきましたが、おそらく個人や案件ごとに、効率化できるポイントは異なっているはずです。
効率化において真に重要なのは、「この仕事の進め方は非効率だよね」と問題意識を持てるかどうです。
問題意識をもって事態を管理し、整理すれば、解決法や対策はおのずと簡単に導き出されるものが多いです。
まずは、自分やチームのプログラミングに対する取り組み方を整理することが、効率化の肝といっても過言ではありません。
