眠る開発屋blog

他人が作ったプログラムをごにょごにょ改造する仕事ってのが、
年に１度くらいはある気がして、
アクションとかロジックの部分になるべく手を入れたくないから、
JavaScriptでごにょごにょすることが多い。
でも、ベースの思想とかなかなか見え難いから、jQueryとか導入しにくいんだよね。
なのでベタベタなJavaScriptとかに。

あと文字コードがあれれ？ってのも相当よく見かけるのだけど、
Linux上で動作しているハズなのに内部のコメントはSJISだったりとか、
そういうのってカンベンしてほしいなぁというか、
昭和のプログラムというか、３、４年前の書き方のような気もするんだが、なんかいい表現方法ないかしら。

SJISになってしまうのって、Windows上で開発したものをそのまま納品とかしたりするのだろうか。
まぁ本番環境もWindowsであれば問題ないんだろうけどさぁ。

ちょっと厳し目のスケジュールでシステム開発を相談されたとき、
バッファを見て、大体１．５倍ぐらいの納期で答えるのもYesだと思うのだけど、
如何にして作業期間を圧縮するか？と自問自答するのもYesだと思うんだよね。

短い工期だとそれだけ売上が低くなる・・・ってのはまた微妙な話で、
あとは営業がクライアントの懐具合を確認しつつ、向こうが納得できそうな数字を出してくれ、とかそんな感じ。
工期はあくまで参考数字程度にすべきじゃないの、ぐらいにしか思わないのだが。

「システム開発の費用が安過ぎる」と嘆きたくなるときもあるけど、
１０分の１の労力で行えば、相場の２分の１でも利益を上げれる筈だし、
「じゃあどうすれば１０分の１の労力で行うことができるのか？」
「こうすれば早く開発できる！」
とか日々頭を悩まし続けるのもいいんじゃないの、とか思う。

プロデューサーでもディレクターでもいいんだけど、
「お願いしたページ制作が終わるまで帰れない。今日もタクシーかぁ」
ってのがあったりすると思うけど、
もし職場の外からでもチェックできる体制になっているのであれば、
出来上がりを職場で待たずにとっとと帰っていいとは思う。

制作の立場からすると「一緒に残って頑張ってほしい」ってのが本音ではあるけど、
「サイトがアップするまで帰ってはいけない」ってなると、
職場の不夜城化が一気に進んで、夜遅くまで職場で働くのが当たり前の雰囲気になるんだよね。
生産性のピークが夜中になっちゃって、夜のほうが仕事がはかどる会社体質になるとか。
社員の健康上よくないし、タクシー代が経費を圧迫するようになるし、あまりよいことではない。

だからまぁ帰れる人はなるべく早く帰るのがみんなの為です。
「遅くまで働けばそれだけ売上や利益が上がる」ってこともありえないしね。

たまにだけど、会社とかでも「先生みたいに怒る人」ってのを見かける。
いや、「怒る」じゃなくて「叱る」だな。
物言いがどうしても説教臭くなるというか、「君はこうしなきゃだめだよ」と言っちゃうというか。

説教臭いのって「上から目線」なのがどうもイヤなんだよね。
怒られるほうが「同等の目線」なのでまだいい。

といいますか、「説教臭い」のが普通になってそれが当たり前になると、
どうももやもやしてうまい言葉が見つからないが、
「言われてことを素直にこなす忠実な人」は育てられるかもしれないが、
「会社の価値ややるべき事を理解し、効率よくそれを成し遂げようとする人」は育たない気がする。
育成が困難なのは後者のほうだから、だから「叱る」のはあまりよくないとは思うのだけど。

それから、残念ながら、
学校の先生みたいに叱らなくてはならないような人が、説教され続けて変化して立派になったというのは見たことないんだよね。
「言われたことを素直にこなす忠実な人」が向いているようなルーチンワークに最終的には回されてしまうのが殆どかも。

トルシエ監督のインタビューをなんかで読んだのだけど、日本代表について、
「まず一旦おごりをなくさせる為、徹底的に否定し、そのあと代表としてのプライドをつけさせる」
「ゲーム禁止とかにしたのもその為」
「地域のボランティアには絶対に参加させる。代表としても高いプライドを持ってほしいため」
とかなんとか書いてあった気がする。

WBCで原監督が選手に黒髪にさせたのも似たような感じなのか。
「巨人軍は紳士たれ」をWBCでも敢行したというところか。

ダメとは言うけど後でとか

続きっぽいこと。

ある営業があるエンジニアと仕事の相談をしていて、否定的なことばかり言われて、げんなりしてしまったようだ。
打ち合わせの後にそのこちらに言ってきたグチ。
「同じ会社の仲間のはずなのにこっちのこと敵かなんかだと勘違いしてない？『プロジェクトを成功させる』って目的は共有するべきなのに、これじゃあダメだよなぁ。。。」

GEの幹部が言ったことで、
「我が社のバリューを理解していなければ、どんなにスキルの高い人間でもいらない」
ってのが確かあったような気がする。

エンジニアなどバックヤードの人間がバリューを共有できていない、
と言い切ってしまうと話は簡単なのだが、バックヤード側の視点に立てば、
「バリューどころか案件の意味を知らされずに切れ切れで話が飛んでくるので、どうしても他人事としてしか感じられない」
ってことなんだろう。

自分の話だが、
こちらが気付けなかったミスで（そもそも気付けたらミスしないけど）、「なんで意識が低いの？」みたいに詰問されて、逆にブチ切れたことがある。
「『何の為にやるか？』ってことを知らされずにあれやらこれやれみたいに一方的に言われて当事者意識を持てるわけないだろ！」って。

「できない」と言ってしまうエンジニアについてだけど、
無理を言ってくる営業に対して、「これはなんらかの考えがあってこう言っているのだ」とエンジニアが深読みするぐらい信頼関係があれば、「できない」とは言わないかもしれない。
もしかすると、「お互いに信頼しないと生産性が上がらないのであれば信頼するしかないじゃない」という開き直りに近いかも。
ただ、そこまで到達できてない場合・・・、「できない」を連発するエンジニアがいて困っているのであれば、「案件をやる意味を徹底的に伝える努力」が必要なんじゃないかな、とは思う。
ちゃんと話せば理解してくれるだろうし、１度で理解しなければ、２度３度と言ってもいいんじゃないかと。
言い過ぎるぐらいに言わないとバックヤードまでなかなか案件の意味は伝わらない。
「分かった」と口に出して言わなくても、態度が段々変ってくることもあるだろうし。

経営的効率を考えれば、必要なスキルを有したフリーランサーを集めてしまえば、それで企業以上の生産性は成立してしまう気がする。
福利厚生費用とか安くすませられるし。
でもフリーランサー集団の弱点は個々の目的がバラバラという点で「局所最適に陥りがち」という点だろう。
バリューを共有すれば、全体最適を意識できる。そうすることで初めて企業はフリーランサー集団の生産性を超えられる、とは思うのですけど、どうなんだろ。

ってかさ、意識教育って営業ってよりかはエンジニアの上長の仕事ではあると思うのだけどね。ぶっちゃけ。

うだうだ。

「有名大学の女子大生を１００人ぐらい集めてガールズブログっての立ち上げようと思うだけど、どれくらいでシステムできる？」
なんて相談を受けても、とりあえず「できる方法」と「よりよくする提案」とかをして、質問には答える。
「そんなもん成功するわけないし、コストのムダだろ」
という道を誤らせない批判もきちんと伝える必要があるのだが、それは前向きな話をした後に付け加えておく。

そもそも、ガールズブログの勝算が提案者にはあって、こちらではそれに気付けていないだけかもしれない。
或いは自分で失敗を自覚するまで納得できない人かもしれない。

「エンジニアはできる手段を考えずに、できない理由しか言わない」
ってのは結構タコ耳に聞くことなんだけども、
まぁそういうエンジニアがゴロゴロいる間は前述した心構えを守るだけで優位に立てるのではないか？という気がする。
「安請け合いばかりすると便利屋になっちゃうよ」って話もあるだろうけど、
全てにおいて自分の手を動かす必要はないだろうし。
「できる」と宣言しつつ、実務は他人に振る人が「要領がいい」って言われるのだろうね。

「自分で失敗を自覚するまで納得しない人」ってのは、おそらくエンジニアでも多くて、「とにかく新しいソリューションを導入したい」性向の人ってこういうことなのだろうな、とか。
「やるな」という否定をせずにある程度は目を瞑ってもいいんじゃないのかね。
モチベーションの芽を潰すことはないだろし、仕事に対して前のめりになれるのであれば、それはそれでよし。

これまたどうでもよいこと。

他の会社が構築したシステムを引き継いで、保守することとかあるのだけど、
ビジネスロジックとかバリューオブジェクトとかきっちり分かれていて、構造的には美しいのだろうけど、
ハッキリ言ってメンテナンスしにくい。
自分自身のコードリーディングの力が不足しているのか？感覚の違いか？
でもWordPressみたいなソースコードのほうがまだ追いやすい印象があるというのはやはり否めない。
個人的に個々のオブジェクトの責務に厳格になりすぎて詳細なレベルで処理を区分するのはあまり好きじゃないんだよね。

エンジニアがタイトル買い、著者買いすべき本

「エンタープライズアプリケーションアーキテクチャーパターン」とか良本だと思うけど、
ファウラーの言うことってOOPの設計屋宗教みたいなところあるよなぁ。
「読みにくい」といったシステムもまさしくそれを踏襲した感じ。
「美しい構造」と「読みやすい構造」と「保守しやすい構造」は違うのかもしれない。
設計ドリブンになると「設計の為にコードが記述される」って性質が強くなり、コードそのものの可読性は下がるのではないだろうか。
設計書がしっかりしてればいい、みたいに言う人もいるだろうけど、「設計書を理解し、コードを理解する」ってのは単に二度手間じゃないの、とか。

正直、設計屋いらない。
大規模は設計屋がいないと難しいというなら、そんな規模の仕事はやらないことにしよう。
そもそも大規模って上流工程でやらないとそれほど儲からないし。
ってか、「大規模」ってウチの職場が手がけることとかあまりないから関係ないだろうし。

どうでもよいこと。

ニコニコ大百科のアーキテクチャ

こういう優れた発想が出てきたのは、「そういう発想のできるエンジニアがいたから」っていうのも大きいのだろうけど、
でもこれって半分しか正解じゃないだろうな。
もう半分は「そういう試みを歓迎し、継続できる職場だから」ってところだろう。

一般的なシステム開発の現場ではこういう発想は出てこないのか。
でもそれは受託仕事であれば、どんなに高いハードを揃えてもクライアントの出費が嵩むだけで、自分達は関係ないってことも大きいだろうし、
もしも自分達のお金で自分達のサービスをやるのであれば、似たようなアプローチを模索するのではないだろうかね。

ここ最近はどうもばたばたしていて何かと忙しい。

充実している！ってわけでもないんだけどね。
なんだろうか。

忙しいっていうのは結構ワナ度が高くて、
緊急じゃないけど重要なことがどんどん後回しになっていく傾向がある。
同じところをぐるぐる回っていても仕方がないとは思うのだけどさ。