プログラマとして「プログラムを書くこと」以外に許容できる仕事、許容できない仕事

まーたフローチャートが云々みたいな話でツイッターのタイムラインが盛り上がっていたので所感を書いておきます。

今日はルノアールで書いています。

プログラマはプログラムだけ書いていればいい仕事ではないというのが万人の共通認識だと思うが、そうはいってもやりたくないものはやりたくないものである。

僕の中でやりたくない仕事ははっきりしていて「実装の進行に一切寄与しないもの」である。

具体的に一つ挙げると「このタスクには具体的に何時間ぐらいかかるか」のような見積もりを細かく切る仕事である。

勘違いしないで欲しいのが、「大目標に対してタスクを細分化する」ことはむしろ重要であると僕は考えているということだ。

当然ながら、多くのタスクは手順を明らかにしないとそもそも手を動かせないということが多いためだ。

では何がいやかというと、それに対して「これとこれとこれで何時間ぐらいかかるから合計で何時間です！！！」みたいなことをいちいちタスク管理ツールに入力していく作業である。

ぶっちゃけ、タスク管理なんて全体の開始と終了さえ合っていれば後はどうでもいいと考えているし、見積もりをせよと言われてもその通りに行くことは絶対にありえないし、その見積もりをしたところで実装には一切寄与しない。
せいぜいプロジェクトの管理者が安心感を得られるだけであろう。

その代わり、僕は思っていたよりも作業が遅延しそうだと思ったら具体的にどういう理由で遅れそうで、それが致命的でないかどうかをすぐに共有するようにしている。

まあもちろん人によってやりやすいやり方は違うだろうけど、個人的には管理者にやり方を押し付けられるのはとても窮屈だし、信頼されてないかのように感じることもある。
ちなみにこういう話をすると、素直にそうですねと納得してくれるプロジェクトマネージャは半々ぐらいである。(とても意外だった)
余計な仕事が減るしむしろありがたがられると思っていたんだけども・・・。まあこればっかりは僕がプロジェクトマネジメントをやったことがないので何も言えないところではある。(とはいえ、仕事を進めていくうちに信頼してもらえるようにもちろん努力はするが)

フローチャートの話にも触れてみる。
僕はフローチャートに対しては半々といったところだと思う。

僕は実装する側であることが殆どなので、ぶっちゃけるとフローチャートなぞ実装する暇があったらさっさとコードを書いてしまうほうがいいだろとは思うけど、フローチャートそのものにはメリットもあると思う。

それは、実装に着手する前にコードを書かない人と「このプロダクトにはどういう処理がどのぐらい含まれているのか」の大まかな認識を合わせるためという役割に対してである。

アーキテクチャ図とかER図の「矢印」の中身が具体的にどういう処理を想定していて、どれぐらいの時間が掛かりそうかを擦り合わせるために使うのであれば非常に有用であると思う。
よって、フローチャートとは「非エンジニアレイヤーの人が全体の実装量を把握するために書く」ものであるうちは有用であるというのが僕の考えである。

もう半分の否定については、「実装者がフローチャートを書くこと」は無駄極まりないと思う。

実装者の視点でフローチャートを書いたとしても、そこから得られる視点はほぼ何もないといっても過言ではない。せいぜい「全部でファイル数はこんなもんぐらいになるかしら」という予測がなんとなく立つかなぁぐらいである。
ていうかそんなもん実装に着手したらなんとなくわかるだろと思っているのでやはりメリットは感じない。

ところで、フローチャートの話題の発端になってたツイートの前後で「基本情報が云々」という話も見掛けたけど、要は「仕事の共通言語を持っておくことは大事だよね～」という程度の話でしかないと思っているので、基本情報云々はあまり関係ないんじゃないかな・・・。
基本情報を取得することで最低限の共通認識が通じるという証明になるというのはそうだと思うけど、そのレベルで何も知らないジュニアの人に対してはきちんと教育してあげるのが筋だと思うんだよな・・・。

というわけで全体通して何が言いたかったかというと、

一緒に仕事をする人間とはきちんとコミュニケーションを取りましょう

ということでした、以上です。