komagataのブログ

githubでprivateなorganizationリポジトリ（仕事のとかね）は同リポジトリ内に別ブランチを作って、そこからmasterにPRを送るという運用をしてました。

というかそういうとこが多いと思う。

同一リポジトリのbranchからmasterにpull requestする - komagata

@milkcocoa「privateなorganizationなreposからforkしたやつは無料のままprivateでつかえますよ。」

しばらくは"見"に回ってたんですが、自分のrepos（komagata/kowabanaとか）からPRする方式を試しています。どういうのが普通なのかわからないので自分のやり方を晒します。

forkしてきたkomagata/kowabanaをoriginにし、organizationの大本をupstreamというremote名で登録する。

origin内で修正pushして、これでOKとなったらPRを送る

$ git pull-request -b fjordllc:master

これのいいところは複数人で使ってるfjordllc/kowabanaといったorganizationリポジトリのブランチにゴミが残らないこと。pushを含めてPR寸前まで自分のreposの中で作業してるのでゴミがorganizationに行かない。

PRをマージした時DELETEボタンで消す癖を付けておけばいいが、なんだかんだで忘れてたり、いなくなった人がやってたbranchが残ってたりして消していいか迷う。

逆に困る点は、CircleCIやHoundCIなどのpushしたら色々やってくれる系のサービスはfjordllc/kowabanaしか対象じゃないので自分のreopsにpushした時点じゃ動かないところ。

かと言って参加メンバー全員のforkまでCI対象に含めるのもダルい。

なんとかならないかなー。みなさんどうやってるのか教えていただけると嬉しいです。

プログラマーが誰もが知ってる、そして殆どのバグが直るデバッグ方法。しかし消費MPが多いのでテンパッてたり、心が折れてるとできない。

デバッグ方法

ある程度複雑なプログラムに何か修正を加えたら動かなくなったとする。

修正前の動くバージョンを用意する。
動かなくなったバージョンを用意する。
１行（１文字）づつ両方を近づけていく。
動くようになった部分の行（文字）がバグの原因。

デバッグ方法（もうちょっと楽なやり方）

大体、何か自分があまり理解してない機能や構文を追加した時にバグが起こる。

修正前の動くバージョンを用意する。
あまり理解してない機能を他を限界まで全てを取り去って（Hello worldレベルで）動くかどうか確かめる。（ここで動かなかったらそもそもその機能は使えない、もしくはあなたが理解してないので勉強してから出直す）
シンプルバージョンが動いたら、修正前バージョンに近づけていく。

何故このデバッグ方法ができないのか？

殆どのプログラマーはこの方法を知っている。しかし非常に面倒に思えるので（実際はこれやったほうが早く直る場合が多い）一発で直る魔法の方法を探してしまう。もしくは知ってそうな人に聞く（人に聞くのは別に悪いことじゃない）。こういう時は心が折れているので夜であったらさっさと帰って風呂入って寝ると次の日の朝にはこれをやるMPが回復しているのですぐ直ることが多い。

Thomas on Rails。楽しげなメロディーと共に大惨事連発してます。Railsエンジニアのお父さんはお子さんとうっかり見たら心を深くえぐられそうです。

日本語版

Original Version

歌詞（日本語版）

「じこはおこるさ」

スリルなんてちょっとなら楽しみさ
でもイライラすると事故が起きる
へっちゃらさ　なんて知らん顔して
走っているとそんな時

事故がほら起きるよ　いきなり来る
調子乗ってやってるとバチがあたる

事故がほら　起きるよ
いい気になってると
そうさ、よそ見してるその時に
事故は　起きるものさ

思いつきでやると　きっと　失敗するよ
幸運の女神は気まぐれだから
ウキウキしてるとまっさかさま
忘れないで気をつけてね　いつだって

事故がほら起きるよ　突然さ
運が無い時はしょうがない
なんとかしよう

事故がもし起きたら
落ち込まないで
うまくやれるようにがんばろうよ
事故は起きるものさ

”標識はいくつもあるのにさ
大事なモノばかり見落とすね”

そんな時必ずやってくる
二度とやらなければいいけど
事故がほら起きるよ　いきなり来る
調子乗ってやってると
バチがあたる

事故がほら起きるよ
いい気になってると
そうさ、よそ見してるその時に
事故は起きるものさ

事故がほら起きるよ突然さ
運が無い時はしょうがない
なんとかしよう
事故がもし起きたら
落ち込まないで

「まぁ、自信過剰だと集中力なんて
たいがい散漫になっちゃうからね」

事故だ　事故だ
忘れてると事故は起こるさ
ほーら！

Lyrics

"Accidents Will Happen"

Thrills and spills on the railway, it's a life of happiness
But sometimes impatience can lead to carelessness
Some think they are smart cats, and some just know it all
But sooner or later we all find out that

Accidents happen now and again, just when you least expect
Just when you think that life is okay, fate comes to collect
Accidents happen now and again, when people or trains get smart
If you don't concentrate on the thing that you're doing
Accidents will happen, just like that

Your best-laid plans can turn upside down if you get too confident
Sometimes you will slip and slide if that's Lady Luck's intent
One minute you're riding high, the next you're on the ground
But please remember, whatever the weather
You must take care 'cause

Accidents happen now and again, sometimes just by chance
You gotta pick yourself up and dust yourself down
Put it down to experience
Accidents happen now and again
Just don't take it all to heart
If you don't concentrate on the thing that you're doing
Accidents will happen, just like that

The warning signs are there for us to see most of the time
But sometimes we take chances and ignore the danger signs
Fate can surprise you, with no reason or rhyme
Make sure you learn your lesson you'll know better next time

Accidents happen now and again
Sometimes just by chance
You gotta pick yourself up and dust yourself down
Put it down to experience
Accidents happen now and again
Just don't take it all to heart
If you don't concentrate on the thing that you're doing
And whatever you're doin' is not what you're thinking
Accidents, incidents
Accidents, incidents, accidents happen, just like that!

kinesisでC-zがあまりに押しにくいのでscreenのキーをzからtに変えてみた。

それまでは@hrysdのtを

「ないわー、tとかないわー」

などと言っていましたが、変えてみた結果。

m(_ _)m 大変申し訳なく・・・

非常に快適です。tパねー。

考えてみると20才から職業プログラマーとして働き始めて今年で14年目になります。viとgrepは10年使えたし、今後10年も使えるとおもいます。screenはどうかな？

プロジェクト名に愛が無い

そしてリポジトリ名がncrm（多分New CRMの略）。だったら更に新しいの出たら何になるのか。nncrmか？nnncrm、n5crmとかschemeの仕様みたいになっていくのかと小一時間（略

テストが無い

テストぉ？そんなお上品なもんなんざぁ、とんとお目にかかったことねーなぁ？

バリデーションが無い

バリデーション？そんなお上品なもんなんざぁ（略

サーバーがrootログインの許可＋IP制限している

セキュリティを高めたいのか低めたいのかどっちなのか。使い辛いわ。

バージョン管理システムがよくわかってない

なぜトップにぶち撒けられてる？trunkはどこ？branchesとtagsはなぜ空？

メソッドが大文字から始まる

あんた絶対Windows畑から来たね？同じ調子でPHP書かれても困るんだヨォ。

全テーブルに共通のプレフィックスが付いている

いや、データベース名があるからわかるよ。

テーブル名に型が付いている

はいはい、mはマスターでtはトランザクションね。データベース版ハンガリアン記法。

テーブル名が日本語

逆に分かり辛い。

テーブル名が日本語の複数形

「フレームワークの規約で複・・・」シャラップ！！みなまで言うな！！

テーブル名がその全部だ

もう何が何やら・・・

レガシー改善仲間募集

「これはひどい」といっても実際にはそこら中にいっぱいありますよね、こういうプロジェクト。ひとしきり毒づいたあとは一つづつ地道に改善していけばいいんです！

僕が現在関わっているプロジェクトではこういったレガシーPHPを改善してださるPHPプログラマー仲間を募集しております。くわしくはコチラ

phpプログラマーの募集 - komagata

ほんとたすけてくだしあ・・・

関連：レガシーPHP改善日記シリーズ

受託開発から離れた理由というエントリーを書きましたが、

「新卒の時からウォーターフォール開発じゃあ既になかった。」

というアジャイルネイティブ（コンチクショウ！）な方には少し分かり辛いかなと思い少し補足を。

受託開発から離れた理由 - komagata

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

「開発会社とクライアント（開発を依頼した会社）の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。

下記は全てフィクションです

開発会社が論文検索システムを4人月（1人月＝100万円）と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数（というか土日で仕様の70%を満たしたプロトタイプが出来てしまった。）で出来そうだということが判明した。

当初の予定であった商用パッケージはより機能が豊富だが、今回の案件の規模にはオーバースペック気味で、検索UIには少し制限があり微妙に使い辛く、デザインがダサくなる。対応表明しているハードウェアやOSのバージョンが若干古く、運用も少し面倒そうだ。

要するに、「半分の値段・期間でより良いものが出来そうだ」ということが契約後に判明した。

見積りと契約にはクライアントも納得していたし、採用実績の多い商用パッケージに比べて初採用するならSolrを使うことには多少のリスクを伴う。

ちなみに現在期末であり、当案件の受注を獲得した営業担当にとっては受注金額の半減が決定した時点で今期目標の未達が確定する（笑）

さてここでこの開発会社が取るべき選択肢はどれ？

クライアントにも理解できる言葉で全てを説明した上で再度決定を促す。
わざわざ損を取る馬鹿がいるか。当初の契約通り行く。契約書の内容と照らし合わせても合法行為である。
ウヒョー！クライアントには「商用パッケージと同機能のオープンソースパッケージがありました。ライセンス料を考えたら後者をお勧めします。」と言ってライセンス料だけ引いた金額で再契約すれば、更に2人月別の案件に投入出来て売上アップだぜ！
この案件は既存の論文検索システムが使い辛いとのエンドユーザー（学会会員）からの多数のクレームから始まったシステムリニューアルの案件だ。エンドユーザーにとって一番使い易いシステムと柔軟なUIが構築できる可能性が高いSolrを採用した再提案をすべき。
仕様も期間もそのまま、人月50万で下請けに流す。

ではどうすべきか

前述のエントリーは本文を読んでいただければわかりますが、「受託が嫌だから離れたよ」という話だけではなくて、「過去離れたけど今戻ってきて勉強中だよ」というお話です。

どの選択をすべきかという点については僕にはまだわかりません。

ただ、「開発者にとっては受け入れがたいが、ビジネス上反論できない選択肢が存在する」というジレンマがあるため、多くの開発者が悩み、それを解消すべくアジャイル開発などの方法論の開発や経営を含めた契約形態の模索が行われている。アジャイル開発には商売上、受託開発最大のメリットである「商品を作る前から買い手と値段が決まっている」という点と真正面から対立するというこれまたジレンマが存在する。という認識です。

既に、「昨今ではそういう問題は解決してて、普通はこうやってるよ。例えばこの本読めば分かるよ。」みたいなのがあれば教えていただけると非常にありがたいです。また、そういった勉強会を行われている方や実際に答えを持っている方が居らっしゃれば是非、お話を伺いに参りたいです！

数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今（FJORD, LLC）に至ります。

上記のような事を思った切欠は下記の様なことがあったからです。

中規模の案件

その時、僕はコンシューマ向けのWebシステムの案件を５〜６人ぐらいのチームで取り組んでいました。データベースに保存されたデータをPHPでXMLを返すAPIを作り、Flashで表示するサイトで、時代が時代だったので「このトラフィックをPHPで構築するなんて。Javaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。

サーバーとFlashクライアントが連携するのでAPI（XMLのSchema）に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバーも普通にいて、

「余裕という程では無いにしてもどうやら無事リリースできそうだな」

なんて考えていました。

そんな時、Flashクライントも担当していたデザイナーの@946さんから、

「この部分のUIはこう変更した方が使い易いのではないか？」

という提案がありました。それに対して僕は、

「確かに改善案はもっともですね。僕も使い易くなると思います。しかし、今までのやり取りの感じだとクライアントはその分の工数追加を認めないでしょう。」

と答えました。

そしてその後凄く落ち込みました。

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

受託開発という商売

商売の仕組みとして受託開発はとても凄い。ソフトウェアを開発する前から買い手と値段が決まっているんだから。皆がこぞってやるのも当たり前だ。世の中に需要が一定数あるかぎり、ローリスク・ミドルリターン？のとても手堅い商売だ。

僕もその時まではデマルコやワインバーグに始まってAgile関係の書籍を読んだり実践したりして、受託開発がより良く進化していくことに期待していた。しかし「はじめの契約形態、要は契約書になんて書くの？」が解決しない限り本質的に問題は解決しない。（何度か受託でAgile開発系のイベントに行って質問したが、決まって「業務請負契約にしてもらっています」という答えだった。これは僕には妥協に感じられた。）

実際に昨今では永和システムマネジメントの価値創造契約など、その問題に正面から取り組んだ企業出てきた。（これは僕のように逃げずに真正面から受託開発に取り組む本当に素晴らしい姿勢だと思う。）

しかし、そういった問題は経営から考え方を刷新しないと無理だ。その時点で平凡なプログラマーである僕には「まず確実に5年はこの状況がかわることは無いだろう」と考え（実際に5年たったが変わってない）、「ならばエンドユーザーと直接金銭をやり取りする自社製品・サービスを作る仕事をしよう」と考えて転職した。（要は逃げた）

そして現在

現在のFJORD, LLCでも自社サービス（怖話）で利益を上げようと頑張っているが、それだけで食べていける状態に達していないので受託開発も承っているが、僕は上記の様に受託開発を良くしようとする方法論の進化から遠ざかっていた。しかし、下記の2点からまた勉強を始めました。

5年ぐらいたっているので僕の知らないだけで上記の問題が解決しているのではないか？
メンバー2人でもAgile開発の恩恵が無視できない。

「ニワカほどよく語る」と申しますが、恥をかくのは得意なので、Agile開発について勉強したこと、疑問なども書いていこうと思います。

追記

新卒時を除いて、僕の経験した受託開発とはほとんどがコンシューマー向けWebシステムなので、エンタープライズシステムのゼネコン体質などといった、更に難しい問題が無かったのは幸運でした。