おもしろいというか、「ああぁ」という記事を発見。 // 残念なソフトウェア開発の現場は、 // 沈みかけの巨大な船に乗った航海に似ている http://anond.hatelabo.jp/20130310152356 かなり的を得ている物語になってるなー、って。 jflute自身は、その昔はわりと見てきましたが、 幸運ながら最近はこういう現場はあまり見かけません。 (なので、この話の記憶は 5, 6 年以上も前の感覚) が、DBFluteユーザーの集いとかでめちゃ話に聞き、 その度に脱力します。 「まだ、そういう現場あるんだなぁ...」 って。 また、話に出てくる「彼」と大昔のjfluteがリンクして、 ちょっと悲しい気分にもなります。 明らかにスピードの出ない効率の悪いやり方で、 でもそれが効率が悪いと誰もわからず、 決定権のある人も全くそんなことは気にせず、 というか誰もその仕組みをわかっておらず、 「今まで同じようにじゃないと」という呪縛から 逃れられない開発現場。 いや、もちろん、途中から舵を切るのはとても大変。 だから「今までと同じように」は一方で大事なこと。 でも、ここでも 1 or 0 の論理が働き。 「完全に改善するか or 完全に今まで通りか」 という極論に。すると後者になること請け合い。 ただ、jfluteは「彼」と違って謙虚ではないので、 少しでも改善を推進した方かもしれませんね（＞＜。 1 or 0 じゃなくて、0.3 とか 0.7 って、 バランス指向な選択肢を探して。 決定権のある人とバトルして（＾＾若気の至り...。 でないと、いざ黒船が出てきたときに追いつけないから。 その準備ができてないのに、 黒船が出てから一生懸命こいでもスピードは出ない。 うん、実際に何十人でこいでもスピードは出なかったよ。 ほんの少しだけでいい。ほんの少しだけ振り返って、 「本当の勝負のときの強さ」を、 システムと人(ひと)が身に付けていかないと、ね。
jfluteは、プロトタイプ実装が大事だといつも思ってます。 一つだけ「作りとして完璧な画面」を作るってのを。 ここ最近からではありますが、今も実践しています。 みんなは、それを参考に自分の画面を作っていくと。 当たり前と思われるかもしれませんが、 実は現場ではあまり見かけません。 みんな参考にしているプログラムはバラバラ。 だから、作りはどんどんバラバラに。 途中からでもいい、一つだけ作る。 既存の画面も修正タイミングで合わせられるなら合わせる。 でも無理はしない。ただ、新しい画面はその通りに作る。 単純に目に見える効率化だけでなく、 プログラマから迷いを少しでも消すことが重要。 「どう作ったらいいのか...」という迷いは、 開発者の思考のリズムを奪い、スピードを鈍らせ、 そして、そのプログラムに対して無責任にさせていきます 物理的にも潜在的にも迷いはマイナスです。 これは実装の自由という概念と相反する話ではありません。 コラボレーションするものだと考えます。 縛りすぎても自由すぎてもよくないと、バランスが大事。 どのみち一つだけじゃ、全ての作りを示すことはできない。 でも、最低限の土台のポリシーがあってこそ、 その上で自由な発想を活かせると考えます。 最低限の土台から、自然と応用ができてくると考えます。 一つだけでいいから、 「このプロジェクトではこう作っていくんだよ」 っていうことが示せるプログラム、作ってみませんか？ > 船底では、今も浸水を塞いでいる船員がいるのだ。 > 善良な彼も、つい冷笑を浮かべてしまった。 もう、いやですね、そんな思いをするのは、二度と。
