気が付けばもう、7月後半。
個人事業主として仕事を始めてから、半年が経ちました。

この半年を振り返ってみると、やはり成功した点より、失敗した点の方が多く思い出されます。
その中でも特に苦労しているのが、『浮き彫りになった問題点を１人で検討すること』です。

自分で言うのもなんですが、開発作業をしていて『どうやって実現すればいいか分からない』ということは、ほぼないです。
やったことのない手法でも、インターネットで軽く検索をかければ、参考例や公式マニュアルがヒットしますので、それを元に組み立てられます。

しかし、『どの方法がベストか決まらない』という状況は、何回もありました。

実現の方法は分かる。
それぞれのメリット、デメリットも分かる。
じゃあ、このプログラムでベストな選択はどれだ？

もしかしたら、この悩みを検討している時間が、一番長かったかもしれません。

会社員時代であれば、プロジェクト単位で仕事をしていましたので、周囲のデスクにはプロジェクトメンバーのエンジニアがいました。
ですので、気軽に声をかけて、考えをまとめるために相談したり、別の視点からの意見を聞くことができました。

が、１人での開発となると、そのような相手はいません。
ブツブツと独り言を呟きながら、自分の中の自分とミーティングしたりしますが、やはり本当の別人と話すのに比べると、中々決定打となる意見が出ません。

結果として、当初の見積もりより時間がかかってしまうことが、何度もありました。

以前の記事でも、『情報処理試験で、どの問題もある程度わかることが原因で、解答に必要な時間を浪費してしまった』というお話をしました。
この半年の仕事ぶり思い返してみると、やはりそれと同じことが、仕事でも起こっていました。

もし、私が情報セキュリティについて十分な知識を持っていなかったら、最初の設計ができた時点で、そのまま製造、テストと進んでいたと思います。
ですが、実際の私は、様々なセキュリティリスクや脅威を学びましたので、設計ができた後でレビュー（作文でいう推敲のようなもの）をしていると、新たな問題に気づくことがあります。

問題があると分かったなら、当然、その危険性を評価しなければなりません。
無視できるほど軽微なものであればそのまま進めますが、一定以上の影響があるとなれば、対応策を考えることになります。

もちろん、最初の設計の段階で、問題点の洗い出しなどは行っています。
ただ、それを他の人にレビューしてもらう機会というのがないため、どうしても『個人の死角』になっている部分には気づきにくくなります。
そのような点が、実際に作業に入った後で浮き彫りになってくるというパターンが多くありました。

昨今の小規模開発では、「アジャイル開発」というものが「理想形」として語られます。
詳細は今回は割愛しますが、その中のベストプラクティス（うまくいくコツ）として、「ペアプログラミング」という手法があります。

これはその名の通り、ペア（2人）でプログラミングを行うというテクニックです。
意図としては、まさに私が陥っているような、『検討の堂々巡り』を防いで生産性を向上させたり、作業が誤った方向に進まないように牽制／修正しあうことなどが挙げられます。

ブツブツと独り言を言っているのも、口に出すことで考えを整理したり、誰かにレビューしてもらっていると想定して制作したものを説明することで、矛盾や欠陥に気づきやすくするためのテクニックです。
海外では一時期、ディスプレイの横に『幼児がお風呂場で遊ぶために使うアヒルの人形』を置いて、それに向かって説明するというテクニックが話題になったりもしました。
私がイメージだけで行っていたものを、具現化した感じですね。

他にも、１人で作業をした場合のリスクに対する対抗策は、知識としては色々とあります。
事前にある程度のリスクは想定していたので、多少の防衛線を張ってはいましたが、この半年を振り返ると、どうやら十分ではなかったようです。

そんなわけで、半年間の振り返りは、反省点の多いものとなりました。
ただ、問題点に気づけないまま納品し、クライアントさん側で何らかの被害が発生するよりは、予定より時間がかかっても、しっかりと問題を議論することが重要だと思います。
結果として、会社員時代から今も含めて、『山本くんは、作業も早いしバグも少ない。成果物の完成度も非常に高い』という評価をいただいております。
先日参加させていただいた同社の納涼会でも、今年最初の案件で作ったシステムについて様々な方から好評をいただき、とても嬉しく感じました。

ちなみに、作業が早いという理由には、『問題に早く気づけるので、後から作業を遡って修正することが少ない』という点も含まれています。
設計の段階で気づけば、修正するのは設計作業だけで済みますが、テストまで進んで気づいた場合、設計、プログラミング、テストと全てがやり直しになってしまいます。
この点で、『多少予定をオーバーしても、設計の段階でしっかり考えること』というのは、非常に大切なことだと思います。

ただ、私が受注しているような小規模な開発の場合、予備費というのはあまりないので、ある作業に時間がかかれば、別の作業に使える時間を削ることになります。
そうなると、急ぎ働きで欠陥に気づけなくなる可能性や、予定より作業時間が多くなり、収益性が悪化してしまいます。

中々どうして、この辺のバランスをとるのは難しいですね。

それでは、いつも見えない誰かとミーティングしている、山本慎一郎でした。