両方だいじなんです

よくある議論...

A「コミュニケーションスキルをつけていけないとね」

B「なに!? プログラミングスキルは要らないってのか!?
プログラムが書けないやつなんてなんたらかんたら...」

A「いやいや、誰もプログラミングスキルが
要らないなんて言ってないから」

...

A「マネジメントが大事だ!」
B「技術の方が大事だ!」

A「早いタイピングが大事だ!」
B「じっくり考えて書くことが大事だ!」

...

ぼくがいろいろな議論を聞いてる上で、
いつも言う言葉、

いやいや、両方だいじなんです。

なぜか A or B

どっちか?
という議論になりがちなのは、世の常でしょうか?
少なくとも、プログラミングの世界では、
「どっちか?」に決めたがる人が多いように思えます。

そんなにプログラミング、
というか、システム開発って、簡単なのでしょうか?
ぼくは、つらいつらいシステム開発の現場を
たくさん見てきました。

プログラミング力あふれたメンバーのプロジェクト、
コミュニケーション力あふれたメンバーのプロジェクト、
どちらも苦戦していましたよ。

マネジメントが充実しているプロジェクト、
技術やツールが充実しているプロジェクト、
どちらも苦戦していましたよ。

両方ともハイレベルでうまくコラボしてこそ、
難しい問題が解決するのではないでしょうか?

どっちか?なんて言っている暇はない

その中で、バランスを整えることはあります。

そのときに A が足りてなければ A が大切になる。
逆に B が足りてなければ B が大切になる。
逆になれば逆が大切になる。ただ、それだけ。
どっちか?って、恒久的に決まるものではない。

また、A を大切にしている組織、
もしくは、B を大切にしている組織、
そういうポリシーが明確にあるならわかりやすい。
でも、大抵は A が 100 で B が 0 でいい
ということではない。割合の話。

バランスがたいせつ

バランスは非常に重要。
だから、ときに「なになにが大事」と言うことはあります。

しかし、それに対して、
逆側の主張が敏感に反応することがよくあります。
恐らく自己防衛的な反射に近いもの。

なので人は、多くの場合、前置きを置いてから話します。
「B も大事なんだけど...」

まあ、A が足りてなくてバランスが悪いから、
A が大事なんだよ、という説明は心がけるべきでしょう。
そのバランスを議論すること自体も大事。

ただ、わかりきっていて省略することもあるでしょう。
twitterなら文字数が制限されているから、
あれこれ前置きも書きづらいでしょう。
そもそもあれこれ前置きしてたら、
シンプルさを失って伝える力が弱まるでしょう。

難しいところですね。

コメントを書くのか書かないのか?

昔からずっと思っていたことでしたが、
ふと話題になったことで、
このエントリを書こうと思いました。

「コメントが要らないくらい、
わかりやすいコードを書こう」

「わかりやすいコメントを書こう」

この二つは、矛盾して相反した思想に
思えるかもしれません。
ですが、jflute はそう思っていません。

両方だいじなんです。

コメントが要らないくらいわかりやすいコードを
意識してコーディングするのはとても大切です。
クラス名やメソッド名、変数名などの工夫、
ロジックの最適化やプログラム構造をリファクタリング、

そのために思考のスピード、そして手のスピード、
限られた時間の中なので必要になってきます。
また、方法論を学んだり、自分で考えていくことも大切。
プログラマーとしては、いかに速く仕上げていくか、
追求し続けていく運命にあると言えます。

一方で、すべてのロジックが、
自然言語なしでプログラミングだけで語れるか?
それは現実問題なかなか難しいこと。
プログラミング言語の表現の限界もあれば、
スキルの限界、すべてのプログラマーが
100年の経験を持っているわけではありません。
すべてのプログラマーが成長段階でプログラムを
書いているのです。

そして、なんといっても、やはり限られた時間、
コメントが要らないくらいわかりやすいコードに
仕上げるのに時間が二倍かかるのであれば、
そこはささっとコメントで補完をして、別のところに
時間をかけるほういいという場面もあるでしょう。

そのとき、
しっかりとしたコメントを書けるスキルが必要です。
意外に難しいものです。
書くのに時間をかけたら本末転倒だし、
自然言語ならぜったいわかりやすくなるか?
っていったらそうではないから。
また、プログラミングのメインスキルではないから、
個人差は非常に大きい。なので...
コメントを書くための方法論「も」大事なのです。

また、事業会社だと仕様書をあまり作らないため、
なんでこういう動きをさせているのか?ってのが、
コメント書いておかないと100%わからない、
ということもあります。詳細設計書なんてないし、
人も入れ替わる可能性も高い。
「背景や意図」を伝えるコメントが重宝されます。
要は、どういうスタイルの開発なのか?
によってもそこは大きく変わってくるでしょう。

メンテナンスする人からすれば、
どうしてもコメントないと絶対にわからないだろう、
というときは、もう遠慮なく自然言語に頼って、
そのコードのストーリーを書いておいて欲しい、
というのが願いであったりするでしょう。

コメントを書いたら負け?

どっちでもいいですが、バランスはどこへ?
もし、そうなのでれば負けたときは潔く書きましょう。
負けたら負けたで殿の仕事がその後を左右しますよ。

理想の話は夢の中でするしかありません。
仕事のプログラミングなら、なおさら。
またまた逆に、コメントをすっ飛ばして、
スピードを求めることだってあります。

そもそも「どっちか?」でプログラミングが済むなら、
おそらくそれはあまりおもしろくないものでしょう。
その矛盾をものようなものを抱えて、
バランスを見極めてコーディングしていかないと
いけないくらい難しいから、
単なる道具とは思えない魅力があるのでしょう。

そういえば、こんなエントリも書いたことがありました。

// 一つの問題に対する解決法は単一とは限らない
http://d.hatena.ne.jp/jflute/20110215/solutions

若い人は迷うよね

ずっとずっと昔から、

若い人が先輩に A とか B とか言われて...
若い人が先人たちの本や、ブログ、Twitterなどを見て、
A とか B とか思って...

そして迷って、
jfluteのところに相談しに来ることがよくあります。
ヒアリングして、バランスとニュアンス、
それを踏まえた上で「A も B も大事なんだよ」
で終わることが多々あります。

逆に、すべてが「A も B も」ってわけじゃないことも。
すべてがバランスでもない、A と断定できることだってある。

要は、セオリー。

その A と B の論点はなに?そして、どこ?
その現場で大切にしているポリシーは?