ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

冷たい方程式(19) 指揮官不在のチーム

»

 幸いムツミさんは、めまいと貧血を起こしただけで、たいしたことはなかった。ただし真面目で責任感も強い彼女のことなので、自分の病状について過少申告している可能性は十分にある。寝不足、ストレス、少ない食事、プレッシャーなどなど、体調を崩す要因を、特売セールが開けるほど抱えているのだから。

 「とにかく、今日は帰ってゆっくり休みなよ」

 そういうあたしの勧告に、ムツミさんは素直にうなずき、ホライゾンチームのメンバーたちに何とかいくつかの指示を出した後、申しわけなさそうに開発室を出た。

 あたしは受付に電話して、タクシーを呼んでもらった。すぐ近くに営業所があるので、数分で到着するはずだ。エントランスまでムツミさんを送っていき、タクシーが来るまで付き添っていた。

 「サオリさん、ご迷惑をおかけしてすみません」ムツミさんはかすれた声でつぶやくように謝った。

 「いいから。疲労が出たんだよ、きっと。こっちのことは心配しないでね。明日も無理しなくていいから」

 「はい」

 ムツミさんがタクシーで帰っていった後、あたしはITマネジメント課に戻って、渕上マネージャに顛末を報告した。渕上マネージャは無表情でうなずいた。

 「今日は、君がホライゾンの人たちをフォローしたまえ」渕上マネージャはそう言うと受話器を取った。「私はホライゾンに人員の補充が可能かどうか聞いてみる」

 ――心配してるフリぐらいすればいいのに

 あたしはむかっ腹をたてながら、臨時開発室へ向かった。ドアを開けると、3人のホライゾンメンバーが一カ所に固まって、何やらヒソヒソ話をしていたが、あたしの顔を見ると、慌てて各自の席に散っていった。

 中坊か、こいつらは、と思いつつ、あたしは笑顔を作って話しかけた。

 「皆さん、自分のタスクについては分かっていますか?」

 彼らは顔を見合わせたが、1人がおずおずとあたしを見た。

 「担当のタスクはありますが……」

 発言したのは、みたところ一番年長に見える男性だ。年長といっても、せいぜい25、6歳といったところだろう。臨時入館証の名前は近藤となっている。

 「じゃあ、今日はそれを続けてください。何か問題点がある場合は、私か、いなければ亀井に聞いてください」

 3人はそれぞれうなずくと、不安そうな視線を交わしながらも、それぞれの担当作業に戻っていった。あたしはそれを確認すると臨時開発室を出た。

 自席に戻ると、亀井くんが心配そうな顔で寄ってきた。

 「片寄さん、大丈夫ですか?」

 「まあ、自分で歩いてたし、熱もないようだったから、たいしたことはないと思うけど」

 「そうですか」亀井くんはそわそわしていた。「お見舞いに行った方がいいですかね」

 「あんたねえ」あたしは亀井くんを睨んだ。「1人暮らしの女性の家に何しにいくつもり?」

 「でも心配じゃないですか。1人で熱出して倒れてたらどうするんですか。先輩、心配じゃないんですか?」

 「心配だけど、私たちの出る幕じゃないでしょ。ホライゾンシステムの方でどうにかするだろうし」あたしは、あえて冷たく突き放した。「いいから、仕事しろ」

 渋々、亀井くんは仕事に戻った。

 あたしもやりかけのシフト管理機能の設計を続けたが、1分も経たないうちに、ホライゾンチームのメンバーが入ってきて中断させられた。さっき、ムツミさんが倒れたことを告げに来た男性だ。

 「あの、よろしいでしょうか」

 早速来たか。あたしは笑顔で応じた。

 「なんでしょう」

 「社員権限マスタメンテ画面をやってるんですが、上位職位の勤怠情報の参照権限がうまく出ないんですけど」

 あたしは意味がよく分からず相手の顔を見た。胸にぶらさげている臨時入館証には「鈴木」と印刷されている。

 「うまく出ないって、どういう意味ですか?」あたしは社員権限マスタのレイアウトを思い浮かべながら聞き返した。「選択肢が画面に表示されないということ?」

 「ラジオボタンが表示されなくて……」

 「ラジオボタンが?」ひょっとして選択肢データが、テーブルにないんだろうか。「選択肢データのレコードは?」

 返ってきたのは沈黙だけだった。

 「まあいいか。ちょっと見ましょうか」

 あたしは先に立って臨時開発室に入った。残りの2人に「おつかれさま」とあいさつしつつ、鈴木くんの席に座った。

 まず、teratermを起動して、DBサーバにpostgresユーザーでログインした。psql でデータベースを開き、選択肢データをselectしてみた。

Psql

 「うん。データはちゃんとありますね」あたしはつぶやいた。鈴木くんは、背後霊のようにあたしの後ろに立って、遠慮がちにモニタを覗き込んでいる。

 あたしは、DBサーバからログアウトしてから、Eclipseに切り替え、メンテナンス画面のHTMLソースを開いた。とたんにため息が出た。

Html191

 「ああ、これじゃ出ないですね」あたしはマウスで、該当行を反転表示させた。「ラジオボタンの場合は、radio に直接id を振るんじゃなくて、その外側のspanタグにidを振らないと」

 「あ、そうなんですか」相手は感心したように言った。「知らなかったです」

 「え?」あたしは愕然として椅子ごと振り向いた。「知らない? 今頃?」

 「はあ……」

 あたしは呆然と相手を見た。

 「本当に知らないの?」笑顔も丁寧語も忘れて、念のために確認してみたが、鈴木くんはこくこくとうなずくだけだった。あたしは言い様のない脱力感に襲われた。

 ――単なるケアレスミスじゃなかったのかよ

 「え、ちょっと待って。ラジオボタンがある画面は、これだけじゃないよね。これまで、どうやってたの?」

 「ええと……」鈴木くんはうろたえたように視線をキョロキョロとさまよわせた。「普通にタグに書いて……」

 「普通って……ちょっと、前に作った画面のHTMLを何でもいいから開いてみてくれる?」

 あたしは席を譲って、後ろに立った。

 鈴木くんは不安そうにあたしを一瞥すると、マウスでHTMLテンプレートの1つを選んで表示した。休憩時間設定マスタのメンテナンス画面だ。この画面にも複数の項目で、ラジオボタンを使用していて、その選択肢はテーブルから取得しているはず。

 HTMLテンプレートは正しく記述されていた。一応、対応するPageクラスに切り替えてみたが、正しく定義されている。

Page192

 「ちゃんとできてるじゃない」あたしはソースを指した。「これと同じようにやれば出るはずだけど」

 「あ、そうですか」鈴木くんは安心したような笑顔になった。「じゃあ、それでやってみます」

 あたしはうなずいて戻ろうとしたが、何かが引っかかった。

 「一応聞くけど」あたしはドアのところで、顔だけ振り向いて聞いた。「今のソースは、鈴木さんが書いたソースだよね?」

 「はい。半分ぐらいですけど」

 ――半分?

 あたしは戻るのを中断して、向き直った。

 「半分って、残りの半分は誰が書いたの?」

 「片寄先輩ですけど……」それがどうかしたか、という顔だ。

 「ちょっともう1回見せて」

 あたしは鈴木くんを押しのけるように座ると、バージョン管理システムからソースの変更履歴を呼び出した。1日に3回コミットすること、という、渕上マネージャが決めたルールは厳密に守られているようで、所定の時刻に更新されている。適当に2日前ぐらいのHTMLソースを開いてみた。

Html193

 これでは、HTML上の値を表示しているだけだ。idも振ってないので、Pageクラスとの関連付けがない。

 その数回後の変更履歴を開くと、

Html194

 と正しくコーディングされている。その最終更新者はムツミさんのユーザーになっていた。

 「そういうこと……」あたしは小声でつぶやいた。

 どういうことか、わかってきた気がする。

 この3名は、Teedaをほとんど理解できていない。idの意味も、Pageクラスの意味も分からないまま実装していたんだろう。

 おそらくムツミさんは、というか、ホライゾンシステムは、このプロジェクトにアサインした開発要員に、十分な事前教育を受けさせることができなかったんじゃないだろうか。それとも、他の開発案件に要員を取られてしまったのか、それはホライゾンシステムの内部事情なので分からないけど。それでも、対外的には、つまり、うちに対しては、ムツミさんをリーダーとする数名は、みなTeeda ができることにして開発を進めていた。

 最初は、それでもうまく進んでいたのだと思う。ムツミさんがうまく割り振って、他のメンバーにはpure javaの範囲で済むようなロジック部分を実装させる。ムツミさん自身は、それらを片っ端からTeeda仕様に適合させていく、という方法で。要するに、ムツミさんがフィルタリングすることによって、各メンバーがそれぞれの画面を実装しているように見せかけていたわけだ。

 ――そりゃ寝る時間なくなるわ

 あたしは思わずうなった。3人のホライゾンメンバーの顔に、一様に不安そうな表情が浮かぶのが見えたが、それを気にかけているどころではなかった。

 ――これはちょっとまずいなあ

 これが渕上マネージャにわかったら、どういう事態になるんだろうか。頭から湯気を出して怒り狂う、というのは、ちょっと想像できない。むしろ、冷酷にホライゾンシステムにペナルティを課す、という方がありそうだ。取りあえず、このことは黙っていることにした。

 「ちょっと聞きたいんだけど」あたしは鈴木くんに、というより3人全員に向かって聞いた。「今まで、ホライゾンシステムさんでは、どういう開発方法を取ってきたの?」

 「どんなと言われても……」鈴木くんは困惑した表情を浮かべていた。

 「えーと、SuperControllerというのがあるんです」近藤くんが答えた。「社長が昔作ったらしいんですけど。それを使って開発してました」

 「SuperController? なに、それ?」

 そのメンバーがたどたどしく説明してくれたところによると、1つのサーブレットに対して、パラメータによって画面を遷移させる仕組みがあるらしい。例えば、gamenKey=A01&action=C011 のように。これによって、プロパティファイルに定義したクラスがロードされ、実行され、結果が返される。結果によって遷移先が決まるようだ。

 最初に八木社長が独自のフレームワークを使わせてくれ、と言っていたのは、これのことだったのだろうか。

 「何しろ、ずっとそればかりでしたから、SeasarとかTeedaなんて初めてやりました」

 「なるほどね」

 ひょっとすると、このいかにも頼りなさそうな3人も、そのSuperControllerとやらを使って開発を行う分には、十分、優秀なのかもしれない。八木社長があれだけ安い見積もりを提示できたのも、SuperControllerを使う、というもくろみがあってのことだったということなのか。

 あたしは、途方に暮れて3人の顔を見たが、そこに見いだしたのは、同じように途方に暮れている顔だった。

(続く)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。

Comment(78)

コメント

Edosson

東海林さんの出番はなしか。
しかし、このザマじゃ、東海林さんがホワイトナイトって展開もなさそうだな。

tis

相変わらず関係ない自分まで胃が痛くなる展開ですね

通りすがり

なるほど。ホライゾンの新メンバーのスキルが良くわかった、個人的にはGoodな回でした。
東海林さんも渕上マネージャも出てこなかったので、ものたりなかった人も多いのかな。

ムツミさんは、やはりタスクを再分割してメンバーに割り振り直してたみたいですね。で、メンバーができない所を自分で全てやると。
やはり、勉強会して新メンバーが画面単位で実装できるようにすべきだったよなあと思うんですが、やったんだがメンバーが全然理解できなくてムツミさんがあきらめた可能性もありますね。

ただ、今回の内容からすると、ホライゾンチームが遅れ過ぎなのがいまいちピンと来ません。
新メンバーは実はJavaすらおぼつかないド素人じゃないのとか思ってたんですが、どうもそうではないようです。
残業すればスケジュールに追いつきそうな感じなんですが、ド素人道は奥が深いです。

以降、蛇足。

画面毎に担当させることを問題視していた人が今回の内容を読んでわかったかどうかわかりませんが、実は画面毎に一人で全て実装するというのが、実装方法としては最も簡単なんですね。
Modelが正しいデータを生成したかどうかを確認するのは、画面に表示させるのが最も手っ取り早い。また、ブラウザからのSubmitやRadioボタンの変更イベントのサーバ側のロジックの実装も、ブラウザで操作しながら結果を確認するのが最も簡単。
(簡単だけど、最良の方法では無い)

それから作者が意図的にそう記述したのかどうか定かではありませんが、主人公のPostgreSQL初心者ぶりもみごとに表現されてました。

fgn

いやぁ・・話の内容から見るに、メンバーで集まって勉強会開いてる暇なんてないでしょう・・。
まぁ、ホライゾンメンバー個々に学ぼうとする意志が薄すぎるのは問題ですね。

通りすがり

> fgn

勉強会の件は、前回だか前々回だかの回でコメントしたんですが、この状況にならないようにするのはどうすべきだったかという話の流れで、できればプロジェクトが始まる前に、それが無理でもメンバーの知識レベルがダメダメだとわかった時点でやればこんな状況にならなかったのでは、という想像です。
個人的には1日でも集中的にやれば全然違ったのではと思います。

ただ、半端じゃないダメさ加減なので、やっても無駄だった可能性も…。

saboten

なんでタスクがうまく回らないのか原因が見えてきましたね。
これだとせいぜい3人分の生産性しかでないでしょう。

ホライゾンに現状を話して一人増員させるか、
タスクを再分配するかしたいところですが…。
主人公はふっちーへ報告しないようですし、
ムツミさんがいないと詰みそうだし、
先行き不安ですねー。

>画面毎に担当させることを問題視していた人~
問題は、画面毎に一人で実装できる状態にないのに、
表面上そうさせている状態であって、
できないなら臨機応変に変えないとダメだよねってことじゃないですかね。

>実装方法としては最も簡単なんですね。
今回はあまり機能してないようですね。

ポスグレ

>それから作者が意図的にそう記述したのかどうか定かではありませんが、主人公のPostgreSQL初心者ぶりもみごとに表現されてました。

これ意味がよくわからない。
亀井くんとかならわかるけど。

通りすがり

> saboten
> できないなら臨機応変に変えないとダメだよねってことじゃないですかね。

うん?臨機応変に変えた結果が今の状況では?

> 今回はあまり機能してないようですね。

ひょっとしたら言いたいことが伝わってないかも。
画面毎に実装するという手法そのものが問題がある手法なんじゃないよ、ということを言いたかったんですが。方向性は正しいよってこと。

まさと

読んでいてハラハラする展開です。
渕上さんが介入せず、主人公たちがホライゾンとこのまま開発を続けていたら、どうなったんでしょうか。

対する渕上さんは、マイクロマネジメントの問題はありますが、今のところ下手を打っていないようにも思えます。
渕上さんのコストカッターという評判は、サードアイを見つけてきたように、一時的に費用がかかっても人材や技術に金を払って総額はきっちり小さくおさめるのかな、と思いました。

通りすがり

> ポスグレ
> これ意味がよくわからない。

うがちすぎかもしれませんが、私が気になった点。

・データ確認は普通EclipseでやるかpgAdminでやる(それらを使ってないなら使うよう言う)
・普通ならpostgreユーザで作業しようなんて思わない
・Teedaが要求してるのかもしれませんが、PostgreSQLでは普通はテーブル名をcamelCaseにしない(camelCaseにするとテーブル名を""でくくる必要があり、"を至る所でエスケープするはめになったりする)

あとは、全員が一つのデータベースを使ってるというのが良くないですね(個人的意見)。知らない間に自分が使ってるマスターの内容が変わる状況では開発しづらいです。
PostgreSQLでは一つのサーバプロセスで複数のデータベースが使えるので、数人レベルの開発環境では開発者ごとにデータベースを作っても問題ありません。

saboten

>通りすがりさん
>臨機応変に変えた結果が今の状況では?
今の状況はふっちーの技術力を無視したタスク振りに対して、
止む負えずムツミさんが対応した歪な状況でしょう?

私が臨機応変にするなら、
まずムツミさんと相談して、タスクが遅れている原因をヒアリングし、
ムツミさんに全画面のTeeda化対応とレビューをするように勧めて、
ムツミさん実装作業分のマンパワーをホライゾン側に追加するけど。

>画面毎に実装するという手法そのものが問題がある手法なんじゃないよ
そうですね。
でも、それが進捗の遅れに繋がるなら機能してない(方向性が間違ってる)んじゃないですかね。

>渕上さんが介入せず、主人公たちがホライゾンとこのまま開発を続けていたら、どうなったんでしょうか。
自社フレームワークでそこそこの生産性は出るんじゃないかと予想。

通りすがり

> saboten
> 私が臨機応変にするなら、

うーん、話がかみ合わない。
「ムツミさんがやった臨機応変」の結果がこうだったよねということなんですが。

> でも、それが進捗の遅れに繋がるなら機能してない(方向性が間違ってる)んじゃないですかね。

こっちは逆に結果論の話をしているんじゃなくて、手法として間違ってるかどうかの話なんですが…。

通りすがり

> saboten

本当は、この件についてあまり議論したくないんですが、もうちょっとだけ。

sabotenさん、逆に「画面出力部分は分担すべし」と強要されたらどうなるかわかりますか?
Modelが正しいデータを生成したかどうかどうやって確認します?
ブラウザのSubmitの処理の実装が正しいかどうかどうやって確認します?(どうやってトリガーします?)
Ajaxを使ってTeeda側でそのハンドラを実装する場合、それが正しいかどうやって確認します?
分担したら、一般には余計サーバ側の実装は大変になったりします。

まさと

> 自社フレームワークでそこそこの生産性は出るんじゃないかと予想。

フレームワークをわかってないのでぼけた質問だと思いますが、
今回出てきた SuperController はホライゾンの内部開発物ですよね。

ホライゾンが押し切ってこのフレームワークを使ったとして、技術移転や解析なしで主人公たちがメンテできるようなものでしょうか?
(主人公が機構をすぐに理解してるから、大丈夫なのかな)

みゃ

主語を省略してしまうと、意図が食い違ってしまいますねぇ
臨機応変に対応した(つもりの)人、臨機応変に対応すべき人、
色々いますからね

タスクを画面単位で割り振るやり方も、
ある程度スキルの揃ってる人員、という前提条件であれば有効でしょう
っていうか通常のやり方かな?
今回のメンバーのスキルを前提条件にすると、ちょっと厳しいかな

なんだかstaticおじさんや炎上社長を思い出しました。

saboten

>通りすがりさん
>「ムツミさんがやった臨機応変」の結果がこうだったよねということなんですが。
ええ、こっちが「ふっちーに臨機応変な行動が必要」だと言ったことに対して、
今の状況は臨機応変では、と返ってきたので知ってます。
それを踏まえたうえで、
ムツミさんの現状とふっちーがとるべき方法を書きました。

>>画面毎に実装するという手法そのものが問題がある手法なんじゃないよ
>そうですね。
>でも、それが進捗の遅れに繋がるなら機能してない(方向性が間違ってる)んじゃないですかね。
一般的な手法は肯定した上で、今回は相応しくないのではと言っておりまする。

saboten

>逆に「画面出力部分は分担すべし」と強要されたらどうなるかわかりますか?
そうですね。通りすがりさんの言うとおり難しいですね。
が、何事も例外あります。今回はTeedaが使えない人がいるとかね。
そういう場合は臨機応変にした方が良いということです。

>ホライゾンが押し切ってこのフレームワークを使ったとして、技術移転や解析なしで主人公たちがメンテできるようなものでしょうか?
思うに、保守で稼ぐためのホライゾンの戦略ですね。
私なら自社フレームワークと言われたら若干拒否反応を起こしますね。

通りすがり

> saboten

sabotenさんと私の思いが同じベクトルなのかどうかわかりませんが、とりあえずこの話はこの辺で。

話は変わりますが、ホライゾンチームの現状をしってしまった主人公の行動はいただけませんねえ。もしこのプロジェクトが失敗に終わるなら、今回の主人公の行動がその敗因の大きな一因になると思います。

puser

postgresql の件に反応。

>通りすがりさん
>・Teedaが要求してるのかもしれませんが、PostgreSQLでは普通はテーブル名
>をcamelCaseにしない(camelCaseにするとテーブル名を""でくくる必要があり、
>"を至る所でエスケープするはめになったりする)

そうですか?
たまたま手元にpostgresql があったので試してみましたが、

test1=# create table testData (
test1(# id integer
test1(# ,data text
test1(# );
CREATE TABLE

test1=# \d
List of relations
Schema | Name | Type | Owner
--------+----------+-------+----------
public | testdata | table | postgres
(1 row)

test1=# select * from testData;
id | data
----+------
(0 rows)

test1=# select * from testdata;
id | data
----+------
(0 rows)

と、大文字小文字のどちらでも問題ないようですが。


>普通ならpostgreユーザで作業しようなんて思わない
そうでしたか。私はたいていpostgresユーザで作業しちゃってます。
普通はどうやるんでしょうか。

>あとは、全員が一つのデータベースを使ってるというのが良くないですね(個人的意見)。
>知らない間に自分が使ってるマスターの内容が変わる状況では開発しづらいです。
これは同意。とはいえ、データベースが増えると、テーブル構造の変更の反映を全部にやらないといけないので、DBAの手間が増えるので、ケースバイケースだとは思いますが。

通りすがり

> puser
> たまたま手元にpostgresql があったので試してみましたが、

なるほど、盲点でした。私の勘違いです。

ちなみに、そのやりかただと、\dの出力通り全て小文字のテーブルができていて、たしかにテーブル名にcamelCaseを使ったQueryでも問題ありません。実際に"testData"というテーブル名だった場合は、Queryで""を使わないとエラーになります。

ムツミさんはJavaの人だから、つい癖でcamelCaseにしたのかな。

> 普通はどうやるんでしょうか。

普通は、個人毎のアカウントを作って、データベースのロールを作って、psql -U hoge dbnameとするか、アカウントと一致するデータベースのロールを作ってpsql dbnameとします。
設定ファイルを書き換えることができたり、/var/lib/pgsql以下のファイルを消すことができるpostgresユーザは、それが必要になる場合に限り使うべきです。

通りすがり

あ、ムツミさんじゃなくて、主人公だったか。

elseorand

>>puserさん >>>普通ならpostgreユーザで作業しようなんて思わない
これは私の若い頃のしょーもない話ですが、
できの悪い人のテストを代わりに行うことになりました。
バッチの異常系テストとして二重起動テストをしたところ、
高頻度のデータが壊れるパターンがあると。

でソースを覗いてみると一時変数代わりに、
グローバルなDROP TABLE, CREATE TABLEがされていました。
それもあって基本、
必要なSELECT,INSERT,UPDATE権限以外はないDBユーザーを、
開発時には設定させています。
(性能強化のためにストアドプロシージャーにせざるを得ない場合は、例外です。)

puser

>通りすがりさん
>ムツミさんはJavaの人だから、つい癖でcamelCaseにしたのかな。
私の場合、癖というより、入力ミスを防止するために、camelCase にしますね。
アカウントの件は、ありがとうございます。
私の会社の場合、開発者全員がDBMみたいなものなので、postgresユーザでやってます(^^;

saboten

>ホライゾンチームの現状をしってしまった主人公の行動はいただけませんねえ。
これが単純にコミュ面倒って人ならダメだこいつってなるんですけど、
主人公はふっちーに話したら状況が悪化すると思ったんでしょうね。

ホウレンソウは大事だけど
ホウレンソウしやすい環境を作るのも大事ってところですね。

昔々のエンジニア

>「1人暮らしの女性の家に何しにいくつもり?」

カレシが居て、ドアから顔を見せるんだよ。
相手に迷惑だから、止めときナ。くすっ。

えー、さて。
PMに協力会社の力量と実情を知らせないのは、普通は良くない。
早急に第三の協力会社に換えるとか、手を討たないと使い物にならんぜ、これは。
マイクロ・マネジメントのふっちーには想定内かな、そうあるべきなんだが。

しかし、報告しても最初に協力会社の選定を行った影の薄い課長などに、ふっちーのペナルティが~。
まあ、最終的責任はふっちーが取るのですけど。

開発チームの現状は「五里霧中」です。

ところで。
WEB技術や開発は、ほとんど未経験で無知なので、新鮮です。
途方にくれた顔で事態を見詰める人物がここにも一人。
古臭くなったなあ、オレ。

週刊漫画誌の連載のごとく、
毎回毎回きっちり盛り上げてくれますねえ。

今回、どう考えても渕上さんを悪役にできない状況になったので、
コメント欄の盛り上がりも一段落かと思いきや。
さっそく盛り上がってますね。
もうそういう問題ではないのか。

ここまで、伏線的にはともかく物語の流れ的には渕上さんが悪役をほぼ一手に引き受けてきましたが。
いよいよ返す刀でホライゾンが切られる流れになってきましたね。

さて。右も左もダメな所ばかりに囲まれて、主人公はこれからどう行動するのか、
東海林さんはどういう登場をするのか。
ますます目が離せなくなって来ましたねえ。


しかしこの流れで主人公はなお、
非難する側の立ち位置を確保し続けているのですね。
この調子だと、主役特権で最後まで主人公だけは悪くない流れになるのだろうか。

別の通りすがり

具体的なできなさを見せつけられると、物語だとわかってても暗い気持ちになってしまう。
ハッピーエンドになるのかなー。なってほしいなー。

一介の派遣

>この調子だと、主役特権で最後まで主人公だけは悪くない流れになるのだろうか。

どうでしょう。。。主人公がもう少しきっちりしていれば、とも思いますけどね。

>>3話
もともとの約束通り、Teedaでやってくれ、と言うのは簡単なのだけど、それならば再見積という話になりかねない。そうなると、最初の選定理由は何だったのか、ということを会社に説明する必要も出てくるだろう。そのつじつまを合わせるのも面倒だ。

>>5話
「フレームワークもうちが指定したものだな」
「あ、いえ、それは」しまった。フレームワークの件を、報告書に書こうと思って忘れていた。「ちょっと先方の都合で、別のフレームワークでやることに……」
「きちんと報告書に書いておくように」

ギギアル

>>通りすがり

>>Teedaが要求してるのかもしれませんが、PostgreSQLでは普通はテーブル名をcamelCaseにしない(camelCaseにするとテーブル名を""でくくる必要があり、"を至る所でエスケープするはめになったりする)

pgAdminでGUIでテーブル定義して、DDL文の確認せずに直接流してるだろ(w

SQLの仕様で大文字小文字は関係ない。

pgAdminが勝手にエスケープしてしまうだけ
(つまり、定義時にきちんと定義すれば、camelCaseでSQLを記述できる。
その方が可読性も上がる)。

pgAdminユーザが陥りやすい罠なので。

ま、と言っても私も昔やってしまったんですけどね。

あとは、telnetログインは楽です軽いのでパッと確認したいとこは
ちょうどいい。Eclipseでデータ確認できるニーズはあるかも知れませんが
態々、pgAdmin入れる必要性はないと思う(認証串環境だと、アップデートが
面倒だし、インストールも面倒。)。

SQL92覚えていればCUIでpostgresは使える(まぁ、インデックスとかの
問題がありますが、この辺は我々インフラ屋さんの仕事でしょ)ので、
pgAdminは要らない子だと思う。

PG

>どうでしょう。。。主人公がもう少しきっちりしていれば、とも思いますけどね。
確かにその辺りのうっかりは致命的ですよねえ

今回の描写でホライゾンシステム、と言うか八木社長の目論見は大体判明した感じなのかな?
安く受注→自社製フレームワークを使わせてもらうように頼む→コスト低めだし受けてくれる可能性は高い→当然自社製なので他社と比較してのアドバンテージは格別→フレームワークの都合もあるし次回以降も受注できる!
みたいな想定は合ったんでしょうね
で、実際受注後に自社製フレームワークを認めてもらうも、確定させておけなかったばかりに酷い目に…詰めが甘いのか、主人公のうっかりは想定外だったのかw

まあこのやり口をやり手と思うか卑劣と思うかは個人次第ですが、実際問題として自社製フレームワークという選択肢はやはり拒否感がある人が多いでしょうし危ない橋ですよね


一応本当に駄目元だったのではなくある程度の勝算は有ったのでしょうが、フレームワーク変更の時点で十分な人材が確保できないと思ったら引いておくべきでしたねえ…

k

顧客側の担当者がヌルいと、業者に提示する要件/納品物もヌルくなる。
業者も業者で真に受けてヌルい見積/ヌルい要員を用意して、はいスタートとなったところで顧客側の担当者交代!

新担当者「んなわきゃねーだろ」
業者「で…ですよねー!?」

これもよくありますねー。

ホライゾンにはヌルい要件のまま進めさせて、ホライゾン担当分を別業者にも発注して、ホライゾン成果物は完成次第捨てちゃうぐらいのほうがトータルでお得だったかも。

それにしても今回の業者側である八木の交渉能力が微妙過ぎる感。
彼が交渉して勝ち得たものって、主人公相手に自社フレームワークの使用を認めさせたことぐらい(その後即却下)で、あとはほぼ全敗。

k

八木にとって災難だったのは、前任の担当者、即ち主人公がどこに飛ばされたわけでもなかったこと。
前任の担当者がどこぞに飛ばされて、完全にお他所の人になってくれていれば、その後様々な交渉時に
「いやそれは前任の日比野さんと決めたことで…」
をベースにして再見積させてくれだとか、追加費用が発生しますだとか、割と気楽に言える。

でも無理。w
その場に一緒に座ってるんだもの。w
前任の担当者が。ちっこくなって。
自分が迂闊なことを口走ると、目の前に座っている彼女の立場を危うくしてしまう。
口走る内容如何では彼女に何かペナルティまで課されるかもしれない。
心理的にこれは言い難い。

まあそれでも言わなきゃダメだったんでしょうけど。

加納

今回も渕上さん的「高度な管理業務」のくだらない面が満載でしたね。

(1)1日3回コミットの無意味さ

1日3回コミットする理由は「私が君たちの作業の進捗状態をチェック
するためだ」とありましたが、何もチェックしていないようですね。

ちゃんとチェックしているのであれば、主人公が見たように、
片寄さんがteeda用に修正しているのをわかっていたはずです。

作業量がその時点でかなり増えていて、片寄さんが、倒れる
可能性もわかっていたはずです。

が、当然ながら、何も分かっていないんでしょうね。。。
物語では出でこないので、詳しい状況は分かりませんが。

分かっていたら、主人公に「フォローしろ」とは言えないでしょう。
膨大な作業量なんだから。

管理に使わないのなら、1日3回もコミットする意味ないんじゃ。。

(2)進捗管理を個別にしてしまったので、主人公が「フォローをやれ」と
いわれて「誤解」している件

「フォロー」=>× 「1,2分 質問を受ける」
       ○「teedaの実装も含め、各個人の半分を実装する」

進捗会議を個別にやってしまってるので、主人公がホライゾンが
どのようになってるか把握してない。
主人公が把握していれば、すこしは、してあげられることが
あったかもしれないのに。 

確かに主人公の能力は、たいしたことはないので、
大きく改善することはないのでしょうが、だからって
PMが先に可能性を狭めてどうするんだ。。。

(3)PMを全くやっていない件

片寄さんへの手当てを見ても、本来のPMは主人公でしょ。
普通のPMなら「大丈夫だろうか、連絡がついたら体のほうを大事にするように、
と言っておいてくれ」というのが普通ですね。

請負だから、関係ないとでも思ってるのでしょうかね。。

別の通りすがり

>ギギアルさん
通りすがりさんじゃないけど。
pgAdminIIIを使わなくったって大文字小文字を区別したテーブル名付けられるよ。で、つけちゃうと後が面倒。
あとねぇ、postgresでtelnetでログインなんて、はっきり言ってど素人だから。基本も基本、超基本。

別の通りすがり

いやまてよ、自分のアカウントでログインできない理由があったということも考えられるな。
ごめん、ど素人呼ばわりは取り消す。すまん。

たまたま見たけど

telnetでログインってのはプロでも有りですよ。
むしろ素人はそういうこと思いつかないでしょ。
DBサーバの設定として、接続可能な端末を限定している場合もあります。
本番環境に近い構成では、面倒でも一旦ウェブサーバ役に
telnetで繋いで、なんてことをしたりしてます。

別の通りすがり

え、開発用PCからデータベースに繋げないの?
だとしたら、俺すげー勘違いしてるわ。
まあ、それでも、特別な理由がない限り、telnetでpostgresでログインなんてありえんわー。

ハイ

telnetも使えないような、もっと言えばGUIしか使えないようなSEは、いざというとき、頼りにならんね。
確かにpgAdminは、素人でも使いやすいけどさ。
客先の本番環境じゃ、そんなの入れてない場合だってあるからね。
オレに言わせれば、pgadminがデフォなんて奴こそ、素人っぽく見えてしまう。

前作で橋本氏が、カラム追加するのに、わざわざEM起動してたのと同じだね。

wm

・telnetでログインはあり。でも、データベースの操作の為に日常的に使用するのはあまり無いかと。(やはりコマンドラインだと誤操作が怖いし)
・カラムの大文字小文字については、データベース抽象化の時点で吸収されている。(確か、オプションで強制的に全て大文字とか小文字とかあった。そういったオプション自体がDB側にあるものもあった気がする。)
・自分の感想としては、淵上さんが居なくてもそれなりにプロジェクト進んでいた気がする。まぁ、現場を見てみないと分からんけど。

おっさん(3)

こんにちは。

物語の展開がうますぎる・・・
回を重ねるたびに上手くなっている気がします。


つぎを!早く次を読ませて~


しかし、誰が良いとか悪いとかはさておき、記事のような状況ありますね。
(思い出したくもないですが。)


○○言語での開発経験者を集めて、プロジェクトをスタート。
(数名どころではありません。数百人規模だったり…)

ある人は、○○言語の基礎からDeepな事まで、相当に知っている。(少ない)

またある人は、○○言語で作られたフレームワークやパラダイムを使った事があるのみ。(多い)
悪く言えば、その言語を使うルーチンワークしかできない。させてもらっていない過去がある等
(基礎を知らないので応用が利かない。)

どちらも「○○言語での開発経験者」とひとくくりにされる。

で、開発がスタートしてしばらくすると…
各チーム毎のキーパーソンや会社毎のキーパーソンに負荷が集中して…


ある意味画期的と言われる手法やアーキテクチャを取り入れたとしても、それを理解できなければ結果は…


あるある(><)ありますね。
この記事のような事が現実に沢山(TT)


事前に、細かなスキル調査を行えばよいのでしょうけど、そうすると、孫・曾孫~の請負会社は利益が出ず。
抱き合わせて云々なんていう事になり。

結果・・・やっぱり、誰かに集中し・・・

やはり、人月仕事や業界構造の暗黒面のせいなのでしょうか・・・

リーベルG氏は、そういった暗黒面に対して、何かを問いかけたいとう考えもあるのかな・・・なんて思い読んでいます。

次を早く次を読ませてくれ~!

通りすがり

んー、なんか変な方向に話が進んでますが…。

PostgreSQL初心者の主人公が、まずteratermでサーバにログインしてデータを確認したという記述を見て、PostgreSQLではデファクトスタンダードなpgAdminを知らないということなのかなと受け取ったということです。

自分の知らないデータベースを使い始めたときにありがちなんですよ。isqlやosqlやpsqlというコマンドがあるというのを知ると、とりあえずそれ使っとくみたいな。

> ギギアル
> あとは、telnetログインは楽です軽いのでパッと確認したいとこはちょうどいい。

ツールがインストールされてるなら、数クリック、数秒でデータの確認が出来ますが…。

> (認証串環境だと、アップデートが面倒だし、インストールも面倒。)。

PostgreSQLがホストするFTPサーバからpgAdmin単体でダウンロードできますよ。

> pgAdminは要らない子だと思う。

スロークエリを解決するのに、グラフィカルに表示される実行計画はとても便利で手が離せません。

通りすがり

あと全然関係無いんですが、みなさんtelnet使ってるんですか?
telnetなんてもう死滅したんじゃないかと思ってました。

Edosson

逆に聞きたいですが、マシンを遠隔操作したい場合はどうしてるんですか?

マシンがすぐ側にある、って場合ばかりじゃ無し。
別敷地は論外として、サーバールームが別の階にあるってだけでも、
移動は面倒くさいし。

私も、Eclipseは使いいますが、
Tomcatの起動再起動はコマンドラインからやる派です。
Antを書いて、WARファイルを生成するようにしています。
データベースも、初期設定やらなんやら、可能な限りのものをスクリプトに記述して、
コマンドラインから実行できるように心がけています。

そうしておけば、本番環境に、
セットアップにしか役立たない開発環境を構築する必要も無いですし。

通りすがり

> Edosson
> 逆に聞きたいですが、マシンを遠隔操作したい場合はどうしてるんですか?

私への質問ですか?普通にログインして作業しますけど。

ちなみに私は前にも書いた気がするけどCI派で完全自動デプロイです。

Edosson

だったら、telnetは死滅、なんて書かなくてもいいんじゃ。

GUIは便利だっつっても、使うのが必須って訳で無し。

ほったて

データが入っているかを確認したいだけの作業で、

>> pgAdminは要らない子だと思う。
>
> スロークエリを解決するのに、グラフィカルに表示される実行計画はとても便利で手が離せません。

は要らないと思われ。「pgAdminは要らない子だと思う。」はそういう意図だと思いました。
(もちろん、チューニングが必要なときには pgAdmin を使うんでしょうが)

通りすがり

> Edosson
> だったら、telnetは死滅、なんて書かなくてもいいんじゃ。

いつもどこまで事前説明すればいいのか迷うところです。
CentOSは(多分RHEL系全部)、telnetdはデフォルトでインストールされていないか、サービスが起動されていないか、ポートが空けられていません。標準はsshです。

telnetを使うには何らかの動機が必要で(例えばWindowsでsshを使えるツールインスト-ル禁止など)、そうでも無い限りもうここ何年かはsshが普通だと思ってたんですが、どうやら世間ではtelnetがまだ良く使われている感じなので質問してみました。

> ほったて

なんだか、pgAdminちゃんが全否定された気がしたので書いてみました。

Edosson

そんなの、telnetだsshだって、こだわらなきゃならないような話じゃ無いじゃん。

俺が釣られただけか。お呼びでなかったのか。
こりゃまた失礼いたしました。

teller

そもそも、本文中には、「teratermで」とあるだけで、telnet とは書いてない。
ssh でアクセスしてるかもしれないですね。

通りすがり

> Edosson

何か私に恨みがあるでしょ。
私もあなたへは自らコメントしないので、あなたもそうすることをお勧めします。

> teller

だんだんめんどくさくなってきたんですが、主人公がtelnetしてるなんて一言も言ってませんよ。
普通にsshでログインしたんだろうなと想像したんですが、コメント欄でtelnet, telnetと言われてたので質問したんです。全然関係ないんですが、と断って。

通りすがり

> Edosson

とかいいつつ、少しだけコメントします。
これが多分あなたへの最後のコメント。

> そんなの、telnetだsshだって、こだわらなきゃならないような話じゃ無いじゃん。

自分が普段普通と思っていることがそうではないかもしれないと感じたとき、人は不安になります。

何年か前なら、周りのみんながrlogin, rloginと言ってるのを聞いたら、え?rloginなんて死滅したんじゃないの?と思ったことでしょう(という喩えもピンとくるかどうかわかりませんが)。

私としては、そんな感じで、え、telnetって死滅したんじゃないの、と思ったんですよ。
ただそれだけ。

さそうたける

telnetかsshかなんて瑣末な話なので、
どなたの味方をするつもりもありませんが、
確かに「telnet」という言葉が話題に挙がってくることには違和感を感じました。

自分は10年近く前、大学生だった頃に
「telnetはセキュリティリスクがあるから使っちゃダメ!ssh使え!」
と教授や先輩方に習ってきており、
ちょうどWindows98からWindows2000に乗り換えるのと同じくらいのタイミングでtelnetを捨てているので、
「telnet」という単語を聞くと「Windows98」という単語を聞くのと同じ様な
「うわー懐かしいー、まだ現役なんだー」
という感想を抱きました。

別にtelnetを使うのが善いとか悪いとかいうつもりは無く、
単純にジェネレーションギャップを感じるってくらいでしょうか。

通りすがり

> さそうたける

ああ、なんかほっとしました。

> 別にtelnetを使うのが善いとか悪いとかいうつもりは無く、

私も良いとか悪いとか言ってないんですが、悪いと言ってると受け取られたのかなあとちょっと反省。
でも、管理ユーザでログインすべきでないという信念は変わらず。

saboten

10年来の選手が多くいる会社だとtelnet使ってますね。
重要なのは便利ツールは便利だけど、客先で困るかもしれないので、
開発環境が違っても咄嗟に使えそうな技術を抑えることだと思いますね。

管理ユーザでログインすべきかどうか等の細かいルールは、
運用しだいな気がするので、メンバー内で最も熟練した技術者が提案するのが吉か。

主人公はPostgreSQLをdeepに使ってるわけではないにしろ、
sql初心者ではないという印象ですね。

さそうたける

> 通りすがりさん

>私も良いとか悪いとか言ってないんですが、悪いと言ってると受け取られたのかなあとちょっと反省。

まあ、単にリモートからCUI操作する手段を表現する際に「telnetという単語で表現する」「telnetという単語は使わない」という文化的・世代的な違いがお互いにあって、意思疎通が上手くいかなかっただけでしょう。

> sabotenさん

> 重要なのは便利ツールは便利だけど、客先で困るかもしれないので、
> 開発環境が違っても咄嗟に使えそうな技術を抑えることだと思いますね。

おっしゃるとおりですね。
選択肢を多く持っているのは重要で、さらに言うと状況に応じて適切な選択肢を選ぶ判断基準を持って優先順位付けできることが大切ですね。
例えば「sshの方がセキュリティリスクが低いのに、なぜ敢えてtelnetを使うのか?」みたいな質問をされた時に
「いやー、なんとなく?」
みたいな回答をすると、お客さんからも同業者からも白い目で見られるでしょうし。

特に同業者の目は怖いですね。
「管理ユーザーでログインは是か非か」
みたいな細かい事がルールで定められてなかったりすると、
無意識に普段のやり方が出てしまって、
そういった細かいやり方・ツールの選び方・用語の選び方で、
己の技術レベルや仕事意識を評価されてしまうケースがたまにあるので。
だから「管理ユーザーでログインすべきじゃない」とかは信念とかではなく、
当たり前の事としておくのがいいのかなーと思います。

まあ、登場人物達が何気なく使うツール・用語で、登場人物のスキルや背景を表現するのはレベルの高い表現方法だし、
そういった表現だと解釈して楽しむのも玄人的な楽しみ方で、
個人的には好きです。

別の通りすがり

管理ユーザでログインなんてあり得ないもいいとこだというのが俺の常識だったんだが、最近はそうでもないようだな。
そういう事実は噛みしめとく必要があるな。

PG

なんか全然本筋とは違う話ですが盛り上がってますねえ…
結局本文中ではtelnetとかsshとか出てすらいないのに

telnetを使うのは昔のSolarisとかUnix開発やってて環境的にssh使ってなかった人が多いイメージがありますね
なんだかんだでシステム更改などで新旧のマシンにログインする場合、どちらにログインする場合も通じるような手順を確立した方がやりやすい、ということもあるようですし
自分はほとんど最近のLinuxサーバばかりだったので逆にtelnetに慣れない(手癖でssh打っちゃう)感じです
ftpとscpでも似たような好みはありますね


本文中でpostgreユーザでログインしてるのは話の都合上分かりやすいからではないかと身も蓋もない推測をしてみたり
多分この辺は好き好きであってこれをもって登場人物のスキルを云々言うところではないんじゃないですかね
どうしても筆者の文化に依存する部分もありますし

昔々のエンジニア

何か違和感を感じると思ったら、わからない事は、すでに同じような実装をしているソースコードを参照して、真似をして覚える方が、早いのではなかったかなと。

上達の早道は、デキるヤツの真似から始まると思うのだけど。

特にHTML系は、かつての帳票オーバーレイや画面作成支援ソフト(古っ!!)に似て、プロパティやパラメーターの設定を変えて、試行錯誤するのが簡単なのだし。

ふっちーの過剰管理が技術の連鎖反応を邪魔しているのか、単純にホライズンの若者達が、揃ってダメっと君なのか。

まあ、こういうのって、よくある事だけどね。

名無し

急に書き込みが少なくなったね。
みんな同時にいそがしくなったのかな。
これまで普通に仕事してる時間にもはげしく書き込まれていたのに。

なんか一人N役で盛り上がったみたいなw

通りすがり

書き込みを活性化させていた燃料になってた人はいたよね

fgn

傍目から見てる分には、油のかけ合いしてた気が・・

Edosson

呼びましたか?

さて、ちょっと前に、自分はコメントしないから、
自分にもコメントすんな、と書かれたんだが、さて相手は誰だったかな。

俺の目的はネズミ叩きだから、そのための燃料が
補給されなかったら、もう出てこないよ。

また別の通りすがり

通りすがり、って名前で書き込みしてる人が果たして何人いるのかね
もしかして全部同一人物と思ってるのかなw
ていうかネズミ叩きと関係ない書き込みに釣られて出てきてる件

また別の通りすがり

Edo何とかにコメントしない、って書き込んだ通りすがりさんにはごめんね

Edosson

>もしかして全部同一人物と思ってるのかなw

どうでもいいよ。
区別できないものなら、十把一絡げに扱うまでのこと。

AM

毎回毎回一人づつご丁寧に返信しておきながら通りすがりを名乗っている事に違和感を感じますが・・・・。

後これを書いておいてあれなんですが、物語の内容と全く関係のないことで争うのはどうなんでしょう。
あまり酷いとコメント欄がなくなるかもしれませんよ。

error401(通りすがり)

> AM
> 毎回毎回一人づつご丁寧に返信しておきながら通りすがりを名乗っている事に違和感を感じますが・・・・。

思った以上にコメントしたくなってしまって、つい書き込みが増えてしまいました。私の書き込みで不愉快に思った人がいたとしたら、Edosson氏を除いて謝ります。すみません。

次にコメントする機会がある場合は、今回の蛇足的な話はもうしません。
渕上dis的な人にコメントすることももうないので、書き込みはしなくなるかもしれませんが一応名前だけつけときます。

通りすがり

渕上氏はDisられても当然な気はしますけどね、もちろん主人公たちにも非はあると思いますが上位者の責任という部分も加味すると渕上氏の罪のほうが大きいと思っています。

別の通りすがり

UMLも知らず、実は自分が一番内容わかってなかった人が威勢がいいねぇ。

別の通りすがり

いや、ちゃんと読めばわかるが、最初にユースケースと書いて、
次にUMLとすり替えたんだよ。

へろへろ

みんな通りすがりすぎ(笑)。

どこかの仮○○イダーじゃあるまいし、そんなに通りすがりまくってると、
AMさんが言ってるみたいにコメント欄が破壊されてしまいますよ~。

別の通りすがり

恥の上塗りしたいの?
このプロジェクトではインターフェースは設計ずみでしょといったら、ユースケースができればインターフェースが出来るとでも思ってるの的なこと返したので、UMLもしらなかったかとなったわけ。
つまり、ドキュメントとして要求された設計項目のUMLはインターフェースを決定せずには書けないことを読み取って無かったんだよ。
多分MVCもSRPも実感として全然わかってないし、ホライゾンの実力も実感できてないね。
上っ面だけで、ネズミひでーひでーしか言えないわけだわw

名無し

ののしりあいも悪いとはいわんが誰が誰をってのがわからんとな。本院同士はわかってるようだがw

今週は渕上マネージャの出番が少なかったから盛り上がらなかったのかな。東海林さんも前回名前が出ただけだし。
来週に期待しよう。もう月曜が楽しみでたまんないですな。
ドラマ化とか決定しないかなw

ちょっとは盛り上がってきましたが、
先週とかに比べると明らかにたりてないですし、
そもそも内容と関係のない話ばかり。

悪役がちゃんと活躍してくれないと、
話が盛り上がらないということですね。

ホライゾンでは足りなかったか。

別の通りすがり

逆ギレかよ。w

>読み取って無かったんだよ。

あんたの願望なんか、知ったこっちゃないよ。
恥をかきたくなかったら、解説の必要がないような文章を書くよう、心がけるこった。

別の通りすがり

UML知らなくても別にいいけど、知らないからこそこの物語の背景を理解できて無かったことはみとめようよ。みぐるしいわー。
まーあんたには技術的なことでもっとやり込めることもできるんだが、見逃してあげるから安心して渕上叩きなよ。

別の通りすがり

一応書いとくけど、俺が相手してるのはEdossonって名のってた人だと思うんだけど、何で名前変えたのか意味不明。
そうじゃない別人なら尚更何したいのかさっぱり意味不明。

個人投資家

>取りあえず、このことは黙っていることにした。

 下請けに開発スキルが無いことが判ったのに、そんな大事なことをなぜ報告しないのだろう。
 少なくとも磯貝課長に打ち明けて善後策を講じないと。
 手に負えない問題は抱え込まずにとにかく上にぶん投げる。
 黙っていれば、問題は解決せずにいつか爆発して、その責任は自分になる。

コメントを投稿する