私はプログラムを書くのが好きだけれど、できれば書かずに誰かの困り事が解決する（けど私に感謝してお金をくださる）というのがいいと思っている。だいたいの場合は私の力不足によりプログラムを書くはめになるのだけれど、できれば少ないプログラムで多くの人の役にたってほしい。プログラマとしてどう振舞えばいいだろうか？

いま一番うまくいっていないところを良くする

ザ・ゴールという本にTOC(theory of constraints)というのが提唱されている。何か作るときには作るものを決め、材料を仕入れ、材料を保管、材料を加工、製品を出荷、製品を販売といった工程を経るけれど、一番うまくいっていないところを直さないと、他のところでどんなにがんばってもその工程で詰まってしまい、製品を作ろうと思ってからみなさんの手元に届いて活用される（その対価としてお金をいただける）早さが向上しないというものだ。また、一番うまくいっていないところを解決できたら、その次にうまくいっていないところが、次の「一番うまくいっていないところ」になるので、早さは改善するけれど、次の早さの上限は決まってしまう。つまり一番うまくいっていないところは常にあり、解決するたびに一番うまくいっていない所は移動する。ということが書かれていた。

サービス提供には様々な役割がかかわっている

必要そうなプログラムが探せ、読め、動かせる人向けにはプログラムとドキュメントを書くと助けになる。そうでない人向けには、プログラムでできることを困っている人にお届けしていい感じになってもらうためにもっと多くの役割が必要になる。TOCを参考にするとサービス提供にかかわってくる多くの役割のうち一番うまくいっていないところを良くすれば、私が書くプログラムによる役立ち度合いを大きくできるはずだ。

私が書くプログラムの役立ち度合いを上げる

問題や課題をうまく捉えられていないと、それを解決するためのプログラムを書いても、困っている人が助からない。困っている人を見つけて解法を考える企画という役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

企画したときにプログラムを書いて解決したかったものがあるはずだ。プログラムを書いたとして、それを解決できているかチェックし早くフィードバックがもらえれば、プログラムの修正も容易になるし困っている人にも早く届けられる。プログラムがうまく動いているか検査する品質保証という役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

書いたプログラムはどこかで動くはずだ。動いていないと困っている人を助けられない。だから安定して動く、また不安定な状態を検知して安定状態へと引き戻す、不安定になりそうなものを予防するといった活動は重要だ。そういった保守・運用という役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

書いたプログラムをサービスとして提供するのなら、サービスが存続しそのサービスに関わる人たちが幸せであり続けるだけのお金が必要だ。投資や融資を受ける場合を除けば、お金はだいたい売り上げから得られる。売り上げを得るためには困っている人へ解決策をお伝えし、困りごとを解決して売り上げをいただく営業活動が重要だ。サービスが長く続けば、私が書くプログラムも長く役立つことになる。営業という役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

書いたプログラムで解決できる問題が増えたとして、それはどうやって困っている人に届くか。お知らせをうまくやるとより多くの人に解決手法が広まることになり、助かる人が増える。お知らせをうまくやる広報という役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

もし私が書いたプログラムで解決できそうなものがある人がいたとして、わからないところがあってうまく適用できなかったら解決にはいたらず、プログラムが役にたったとは言えない。わからないところを問い合わせてきてくださったときに解決へと導けることができればプログラムは役にたったと言える。解決をお手伝いするサポートという役割を助けるのは私が書くプログラムの役立ち度合いを上げることにつながる。

もちろん人事、総務、経理を助けることも私が書くプログラムの役立ち度合いを上げることにつながる。他にも私が思いついていないいろんな役割の人を助けることは全てプログラムの役立ち度合いを上げることにつながる。でも私の気力がつきたのでもう書けない。許して。

プログラムはいつ書くのか？

ここまでどの役割を助けるのもプログラマが少ないプログラミングで多くの役立ちを得るために有用だと書いてきた。プログラムはいつ書くのか？原則でいうと一番うまくいっていないところを良くするのにプログラムを書くのが役立つときだ。もちろんプログラミングはが重要であることに疑いはないし、だいたいの場合はプログラムを書ことが一番うまくいっていないところを良くするのに繋がっている。でもプログラムを書いてもサービスが良くなる手応えが少なかったり、そう信じられない場合、プログラミングもサービス全体の役割の一部であるということを思いだして、一番うまくいっていないところを良くしていく活動をしてみるといいことがあるかもしれない。

まとめ

1. 製品を企画してから困っている人に提供し対価をいただくまでの時間は「いま一番うまくいっていないところを良くする」ことでしか改善できない
2. プログラムを書いてサービス提供している場合、どの役割を手助けしても書いたプログラムを多くの人に役立てることにつながる
3. 一番うまくいっていないところはプログラムであることが多いのでプログラミングを頑張るのは初手としては妥当な選択肢だろう
4. プログラミングを頑張っても良くなっている気がしないとき、プログラミングは一番うまくいっていないところではないかもしれない。もしかすると昔はそうだったのかもしれないけど、いつのまにか一番の困りどころは移動してしまっていたのかもしれない。そのときはプログラミングではない、別の一番うまくいっていなさそうところを探して直すのを手伝うのが、結果的には書いたプログラムを多くの人に役立てるのに繋がるかもしれない

ここにあるのは私の経験でもある。プログラムを書いても組織がよりよくなっている感じがしなかったのに、様々な役割の人を助けているうちにプログラムも役立っている感じになってきた。今はまたプログラムを書くと一番うまくいっていないところを良くできそうなのでプログラムを書こうとしている。