冷たい方程式（5） コストダウンの技術
次に、渕上マネージャがホワイトボードに書いたのは、
- OS
だった。
「OSをRHELにしたのはなぜだ？」
質問の意図がよくわからない。あたしは左右を見たが、上司からも後輩からも助けは得られそうになかったので、正直に答えることにした。
「プリインストールになっていたからです」
「君は一通りLinuxが管理できるのだろう？」
「一応は」ウィザードレベルを期待されても困るが、Webアプリケーションの環境を整えるぐらいはできる。
「社内でしか使用しないサーバだ。サポートも必要ない。世の中には無償のLinuxディストリビューションがたくさんある。CentOSか何かにしたまえ」
またもや磯貝課長が手をあげた。
「すでにRedHatのプリインストールで発注して……」
「わかっている」渕上マネージャはみなまで聞かずに遮った。「それもこちらで訂正しておく」
次に書かれたのは、
- バックアップ装置
データベースのバックアップ用に追加した、LTOドライブのことだろう。
「社内の共有ファイルサーバは、現在でも深夜にバックアップを取っている。そちらでまとめてやってもらうように、仕組みを考えたまえ」
また余分な仕事が増えた。まあいい。こういうのは、亀井くんに押しつけるとしよう。
「最後はこれだ」
- 社内の開発工数
「開発工数ですか？」磯貝課長が不思議そうな顔をした。「これはどういう意味でしょうか」
渕上マネージャは、磯貝課長の質問には答えず、あたしと亀井くんの方を見た。
「業務系は、君たちが設計、実装するそうだな」
「そうですが」
「なぜ、そう決めた？」
「経営戦略本部から、丸投げは不可、というお達しがあったからですよ」磯貝課長が答えてくれた。
「それに業務系は、このシステムのコアの部分です」あたしも援護した。「運用を開始してからも、仕様の変更は頻繁に入るでしょうから、うちで実装した方がいいんじゃないでしょうか？」
渕上マネージャは、小さくため息をついた。
「君たちには、コストという考えはないのか？」
「……」
「君たちは正社員だ。君たちが実装作業をやれば、どうしても残業が増える。うちは残業の上限カットなどはしていないから、残業代を支給しなければならない」
「……」
「つまりコストが増大するということだ。なぜ、そういうことを考えようとしないのか」
「そうはいってもですね」磯貝課長が控えめに反論した。「現実的に、システム開発というものは時間がかかるもので……」
「今、全社的に残業削減が推進されているのは、あなたも知っているだろう。そのことをどう考えているのか」
磯貝課長は沈黙した。確かに、他部門では社員の残業時間を減らすべく、さまざまな試みが実行されているようだ。水曜日と金曜日をノー残業デーにするとか、月間の残業時間数の目標を設定するとか。でもITマネジメント課では、誰も気にしていないし、課長も特に何も言わない。そもそも、開発グループは残業がほとんどないグループだ。
――何を求めてるのかね、この人は。
「つまり、どうしろとおっしゃるんですか？」
渕上マネージャの眉間にしわが寄った。この人が、感情らしきものを露わにしたのは、これが初めてだった。
「今後は、1日30分以上の所定外労働を禁止する」
「え！」あたしと亀井くんの声がきれいにハモった。
「少なくとも、カットオーバーまでだ。どうしても越えてしまった場合は、別の日の所定外労働をその分減らすこと」
「ちょっと待ってください」さすがにあたしも声を荒げた。「いくらなんでも無茶です。スケジュールが遅れてしまいます」
「君のスケジュールは、残業を前提として線を引いているのか。考え方がおかしいとは思わないのか」
――そりゃ、正論だけどさ。
「それはきれいごとです。現実的には、この人数で、残業なしで設計も実装も終えるのは、不可能です」
「残業をするなとは言っていない」渕上マネージャは、冷たく指摘した。「どうしてもオーバーしてしまう場合もあるだろうから、毎日30分は認める。それ以上は不可だ。もちろん休日出勤などは論外だし、仕事を自宅に持ち帰ることも厳禁だ」
この人は、システム開発業務に携わったことがあるんだろうか。
「お言葉ですが、30分では実質的にないのと同じです。奇跡でも起こせとおっしゃるんですか？」
「簡単な解決方法がある」
「へえ？」あたしはつい挑発的に揶揄するような声で訊いた。「それは気付きませんでした。なんでしょう？」
「業務系も外注する」
「は？」
「君たちが残業すれば、時間単位の残業代だが、外注すれば1本単位の金額で済む」
「いやいやいや、ちょっと待ってくださいよ」呆気にとられて言葉を失っていた磯貝課長が、セーフモードから復帰した。「丸投げ不可は経営戦略本部の意向ですよ。業務系までホライゾンシステムに出してしまったら、それは丸投げになります」
「丸投げというのは、要件定義から実装、テスト、保守まで全ての行程を任せることを指す。今回は要件定義と設計まではうちでやるから、丸投げにはならない」
「でもうちがまったく実装をやらないというのは……」磯貝課長が助けを求めるような視線をあたしに向けた。
「さっきも言いましたが」あたしは渋々発言した。「業務系は頻繁に仕様変更が入ると思うので、うちが実装した方が、後々のことを考えると……」
「つまりこういうことか」渕上マネージャは、あたしのセリフをぶった切った。「君たちには、他人が書いたコードを読む能力がない」
「そんなことは言ってません」
本音は、あたしも亀井くんもプログラミングが好きなので、設計だけやるのはつまらない、というところだが、正直に言うわけにはいかない。
渕上マネージャは、目を細めてあたしの顔を見た。
「コーディングルールは渡してあるな」
「はい」
「フレームワークもうちが指定したものだな」
「あ、いえ、それは」しまった。フレームワークの件を、報告書に書こうと思って忘れていた。「ちょっと先方の都合で、別のフレームワークでやることに……」
「きちんと報告書に書いておくように」渕上マネージャは叱責したが、そこには拘泥しなかった。「どんなフレームワークを使うと言っているんだ？」
あたしは八木社長から聞いた話を伝えた。渕上マネージャは、少しの間、黙って何かを考えていたが、あたしに顔を向けた。
「ホライゾンシステムとの次の打ち合わせは？」
「別に予定はありませんが」
「では、来週にでも設定するように。私も参加する」
「はあ。何の件の打ち合わせと伝えますか？」
「今後の方針についてだ」
渕上マネージャは、そう言うと立ち上がった。ただでさえ頭の位置が高いのに、こっちが座ったままだと、ランドマークタワーの展望台から見下ろされているような気になる。
「では、これで終わる。先ほど言った4点のコストダウン対策については、速やかに実行するように。完了したら、私に報告に来たまえ。以上だ」
ひょろ長い身体が、さっさと会議室から出て行った。あたしたちはしばらくの間、無言で凝固していた。
「ずいぶん一方的に、言うだけ言っていきましたね」亀井くんが呆れたように口を開いた。「コストダウンのことしか頭にないんですかね、あの人は」
「それが仕事だからね」と磯貝課長。「ぼくたちはシステムを完成させて評価される。渕上さんはコストを下げて評価される」
確かにあたしたちがデータベースやOSを決定したとき、確固たる信念があったわけではないので、渕上マネージャの言っていることが、しごく真っ当なことばかりなのはわかる。わかるが、今さらトップダウンで方針をひっくり返されるのはどうにも業腹だ。
「まあとにかく言われた通りにするしかないなあ」
「あーあ」あたしは呻いた。「ホライゾンさんに電話しないと。課長、お願いできます？」
「え、いや、それは日比野くんの仕事だよ」磯貝課長は笑ってごまかした。「ぼくは一回しか会ってないしねえ」
「ですよね。いえ、いいんです。言ってみただけですから」
「オレが電話しましょうか？」亀井くんが勢い込んで身を乗り出した。
「あんたが？」
「はい。片寄さんに電話すればいいんですよね」
――それが目的か。
「いや、いい。私が、“八木社長”に電話するから」あたしはきっぱり言った。「あんたはデータベースの変更に取りかかってくれる？」
亀井くんは露骨に落胆した表情を見せた。こいつは何しに会社に来てるんだ。
「……何にすればいいですかね？」
「ん？ そうねえ……」
あたしは一応考えたが、そもそも悩むほど選択肢が多いわけではない。エンタープライズ用途で使用実績があり、情報収集が容易なプロダクトとなると、PostgreSQLかMySQLぐらいだろう。あたし自身は、どちらも少しかじった程度だ。前の会社では、OracleかSQLServerなどの商用データベースがほとんどだった。
「PostgreSQLか、MySQLか……」あたしは声に出して考えた。「使ったことあったっけ？」
「うーん、MySQLは少しありますけど」
じゃあ、MySQLにするか、と決めかけて、思い直した。どうせなら未経験のデータベースを勉強する方がいい。
「PostgreSQLにしようか。ストリーミング・レプリケーションもあるし。使ったことはないけど」
亀井くんも特にMySQLにこだわりがあるわけではないらしく、素直にうなずいた。
「わかりました。調べてみます」
磯貝課長がポンと手を叩いた。
「じゃあ、よろしく」
その言葉を機に、あたしたちは立ち上がると会議室を出た。あたしは頭の中で、ホライゾンの八木社長に伝える言葉を考えて気が重かった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
abc
だめだ。
はやくこのリスク要員をカットしないとｗ
オールラウンダ
前2作は序盤から的を射ていたが、今回は無理やり書いてる気がする。
書きたいことはいろいろあるが、所詮フィクションなので、まぁいいかって。
ほまらら
残業休出不可って、
一気に難易度ベリーハードですな。
まあ、それでできるならそれに越したことはないですが、
現実問題として無理ですね。
手足縛って「泳げ」と言われたら競泳選手だって溺れますがな・・・
それにしても、これは誰が悪いのかな。
現実が見えていないコストカッターが悪いのか、
現実に即していないルールを決めた会社が悪いのか、
残業休出しなければ完遂できない案件を取ってきた営業が悪いのか、
そんな案件しかないご時世が悪いのか、
そもそも日本のIT業界の体質がウンヌンカンヌン（以下略）
としろう
これは酷い
変にルールを強要するとか手段と目的がオカシイ感じ
書類と制約で責任逃れするのが第一で、本当の目的が成就されるのを忘れた
本末転倒の結果を導く典型ではないだろうか？
ここは合意して変更したと見なされないよう
キッチリこの変更の責任を彼にあると言う事を残しておくべきですね。
責任逃れ主体の人間ならこれで動きが制限できるかも。
少なくとも痛い目に会わないと学習出来ないみたいだし。
hoge
んー、ソフトウェアの選定とかは別に酷いとは思わないなあ。
ただ、残業代と外注費だったら請負会社の会社取り分がなくなる分前者の方が安くなると思うし、メンテナンス工数は確実に社内開発の方が安く上がるはず。
金がかかるから駄目だと主張されてるんだから、その点を反論しなきゃいけないはずなのに、ちゃんと数字を出せないんだから、やっぱり押し切られてもしょうがないんじゃないかなあ。
banana
情シスです。
渕上マネージャーと同じことやっています。
今日もシステム構成案からロードバランサーを削りました。
150万円コストカットできました。
それが何か問題でも？
どこかのSE
これって普通でしょ？
前回のDB教育コストは兎も角、
サポートを必要としない自社サーバのOSにRHELとか、
標準バックアップの方法があるのに、LTOとかは必要無いでしょ。
流石に、この要件定義だったら俺でも却下するなぁ。
後は人件費か。
こればかりは、外注よりも先行投資で社内に投資するべきだと思うけどね。
実際にコード書くのと、他人のコード読むのとじゃ理解度も変わってくるし。
ATM
うーん、Linuxとバックアップについては、コストカッターの判断を支持したいな。
時期的に、こんなギリギリでシステム変えて大丈夫なのか、というのが不安だけど。
メタ的に見れば、わざわざ書いたってことは、これもまた何らかの不具合を誘発する判断なのかね。
> こいつは何しに会社に来てるんだ。
しかし、別に仕事に潤いくらい求めても良いと思うけど。
まさかこの人の価値観では、会社では仕事以外の事は一切せず、結婚相手は残業が終わって電車もまばらな時間帯の、夜の街でしか探したらダメなのか？
ハムレット
> じゃあ、MySQLにするか、と決めかけて、思い直した。どうせなら未経験の
> データベースを勉強する方がいい。
この辺、別の意味でトラブルの火種ですよね。残業規制が掛っているので、調査に十分な時間が取れないのに、そんな冒険しちゃね・・・・・。
ちけんち
けっこうコストカッターを支持する人が多いのに驚きました。私は業務系の知識がないので、「ああ、また厄介な上司が登場したのか」くらいに考えてたんですけど、変更を決めた時期を除けば、すべてが理不尽な内容というわけではないのですね。
となると…一作目、二作目とは違ってこのコストカッターがプロジェクトを成功に導くストーリーも期待できる…かな？
mutta
逆にこの内容で無理やりとか難易度ベリーハードとかの反応があることに驚いた。
残業しないと仕事が回らないなら元々の見積もりがおかしいわ。
この話でひどいのはMからの指示にまともな反論もできず技術力不足でできないことをできないと言えないSE、何も仕事しない課長、それに気づかない（気づいても対処しない）Mの行動だろう。
後はハムレットさんに全面的に同意。どうみても死亡フラグ
外注にFW押し切られたことといいこのSEはだめすぎる。開発失敗してもMのせいにしてまったく反省しないんじゃないかなー
くくな
なんか、ヒロインがSEとして変、みたいな声があるけど、
本業がSIerじゃないなら、意識が違って当たり前だとおもうが。
開発で利益を出すわけじゃないんだからさ。
khaosG
物（OSとLTO）のコストについては、コストカッターの言うことも分かるかな。
一応、運用費については社内で賄うことが前提で、種類を変えても大して変わらないと判断できるから。
工数の方はどうだろう。
オーバータイムのバッファは20%程度は見込むと思うのだが、1日30分は少なすぎ。
内製が良いか、外注が良いかは、コストカッターもシステム部門も試算をしていないところがおかしい。
試算して比較した上で、決裁をとるべきでは？
まあ、あるべきが通用しないのが世の会社みたいだけど…。
としろう
>残業しないと仕事が回らないなら元々の見積もりがおかしい
見積もオカシイかもしれないけれど、それ以上に
納期と金が先に決まっていて、その割に後から変更点を出してくる
そういう異常な世界。
時間を見積通りにしたいなら、DB変更他冒険要因は減らすべきのはずだが。
冒険を求めつつ予定通りも求めるのはベリーハードだ
単純作業のように工数が正しく見積もれる事も予定通りに進む事
なんてありえないのに、変動バッファが30分などありえない。
納期の方をずらしてもOKなら誰も反対などしない。
外注なら向こうが無理しなければ出来ないようになっても関係ない
という、リスクの押し付けでしょ。この時点での変更や作業の追加は。
ここで外注がおりたらどうするんだろう。
話の都合上、降りる事はなく、泥沼進行になるのだろうけど。
某大手SIer
このコラムはポイント、ポイントだけ見ると正しそうに見えるけど、経営戦略も踏まえた開発業務という観点でみると、誰も全体的なロジックが成り立ってないね。
QCDのバランスが崩壊した動かないシステムとか、動いてもバグだらけとか使い物にならないシステムを作る人達の典型的な思考回路に見えて仕方ない。
24
いつも楽しみに拝見させていただいております
今回はいつもと違ってトラブル解決できそうなSEがいない…
すごいモノが出来そうだ
ＢＥＬ
確かに渕上さんはそこまでめちゃくちゃなことは言ってないとは思う。
往々にして予定通りいかないのだから、なおさら予定"外"の部分だけを
残業で考えるべき。せっかく線引く前なんだから。
モジュール納品だと悲惨だがソース納品ならどうにでもなる。
まあコーディングルール細かく設定しないと、要件満たしていれば文句言えないから、
「何だこのひどい実装、うちで作り直した方がいいわ。。」ということになりがちだが。
毎秒ガンガンアクセスされるわけでもないだろうし何のDB使うかは
そんなクリティカルじゃないと思う。SQL書く分には全然違うものでもないし。
ただ、この人のこのプロジェクト内での仕事はなんなんだ。
日々コストカットの事だけ考えるなら、いない方がコストカットになるわ多分。
コストカットなんてメンバー間で意見だして、あくまでもそのプロジェクトでの
最適解を出すべきであって。能力が同じ人なんていないんだから一般的な解はつくりにくい。
そもそもこの小さなプロジェクトに"マネージャ"と課長両方なんていらないし。
だいたい、非機能要件を見ないからこういう、メンバー間で意見が割れるようなことになる。
最悪データもプログラムも吹っ飛んでかまわないのか、
数時間ごとに細かいバックアップ残さなきゃいけないのか、とか
要件を見ていけば、ミニマムコストとしての落としどころはチームで結論がだせるはず。
コストカットは「一番うまくいったときの最低コスト」を出すものではない。
「サーバ４台＋ロードバランサ」と１台のみでは当然前者がコストが高くなるが、
負荷が高くなって１台がダウンしたケースなんかを想定したら、、、
「何も起きなければ安くつく」って理論ではだめだ。
しかしこの渕上さんはムスカかなんかか？ｗ
主人公は綾波？あんたとかいってるし
BEL
アスカか
banana
プロジェクトチームだけで決めることなんて不可能。
ステークホルダーはむしろプロジェクトの外にいる。
あるシステム開発プロジェクトが冗長化みっちり、
セキュリティ対策ばっちりの構成を組んだが、
システム化の対象となる業務はどう控えめにいっても
クリティカルとはいいがたい。
社内的に重要と位置づけられる業務は当然、先にシステム化されている。
昔は冗長化技術はともかく、
セキュリティ対策はコンピュータウィルスぐらいだから、
最新の構成案と比べると見劣りがする。
これがプロジェクトチーム外の人、
たとえば役員クラスにはどう見えると思う？
wm
渕上さんの言う事を見ながら考えたのは
「この人は、この調子で成功させたプロジェクトってあるのか？」
という事。
無理難題を押し付けてプロジェクトを破綻させた挙句、
「ほら、こんなプロジェクト無理だったんだから、最初からコスト切り詰めててよかったでしょ？」
と言うのが仕事のような気がする。
@ITの記事よりRails Castsは100倍面白い
渕上さんの上を行くのは簡単。
私なら以下のようにする。
サーバ: Heroku
Webアプリケーションフレームワーク: Rails
Railsオープンソースアプリケーションを流用できればなお良い。
渕上さんも古いね。
しかしながら、残業休出不可という意見は正しい。
しかし、私なら、そんなくだらない社内システムはそもそも要りませんと言うかもしれない。
へろへろ
勤怠管理システムということは、
・退勤時に社員のほとんどが同時アクセスしても耐えられるリソース
・月締めや決算期に大規模な集計を所要時間内に終了させられる性能
が必要なはず。
社内で使うシステムとはいえ、〆日や決算時はクリティカルな状態であるし、
動きが遅くなっては前システムの二の舞のはず。
その辺の議論もなくバサバサ切ってしまうのはコストカットではなくて、
単に予算の枠に収めるためだけのつじつまあわせであり、スケジュールを
脈絡なく決められた締切日から引いていくのと同じ行為でしかない。
@ITの記事よりRails Castsは100倍面白い
勤怠管理システムのような一般的なシステムを社内開発するなど無駄。
salesforce等に移行すれば済む話。
日本は無駄なシステム開発だらけ。
BEL
渕上さんは何も、プロジェクトに参加する形になる必要はなくて、
このプロジェクトが決まった時に、一通り要件を見通して
このくらいのコストでできるはず、って上からの立場として存在してればよかった。
あとの微調整は課長が渕上さんと部下の橋渡ししてつめればいいことだし。
(セーフモードに入っちゃう課長じゃだめかなｗ)
一通り下ごしらえ済んだあとで登場したからややこしくなったわけで。
コストカットなんて、複数のプロジェクト同時に見渡すくらいじゃないと
それこそコストになってしまう。
まさか「君たちはバグを作る前提で開発を行うのか？」とか言って
テストまでカットするのかな。
「実は、君たちに新しい技術を身に着けてほしくて、
あえて未経験の製品を使うようにしたんだよ」なんて結末じゃないだろうし。
banana
皆さんのコメントを呼んでいると情シスとして反省せざるを得ません。
私はプロジェクトが検討する前に、
ガイドラインなり目標値なりを示すことができず、
一通り固まったところの相談という場で切っています。
プロジェクトチームからすれば
最初に言ってくれたらよかったのにと思うのでしょうが、
私の力量が及ばないというか、目の間にくるまでわからないというか・・・
あとだしジャンケンです。
遅すぎるタイミングで口を出して
ややこしくしているという自覚がないわけではありません・・・
LFR
↑一通り固まったところで話しているんなら問題ないのでは
ないかと。
最初に言っても、あまり検討していない段階だと無用な反発
を招くだけだろうし・・・。
淵上さんの登場タイミング云々という話があるけど、今言わ
ないと毎年維持費が無駄にかかるお荷物システムができあが
る可能性があるわけで・・・。
というか、予算は事前に承認済みだろうに淵上さんが派遣さ
れたということは、会社としてそもそも主人公たちを信用し
てないということなんじゃ？
あと、ヒロインはSIerじゃないのでという意見がありました
が、システムの上っ面だけみてシステム作れます！って勘違
いしている感じなので、そもそもシステム開発者／社内SEと
して失格なのではないのかと思います。
何はともあれ、今までと違い主人公サイドがだめだめすぎて、
物語形式での記述は読んでて楽しめませんね。
内容がおかしいわけではないんですけど・・・。
BEL
＞一通り固まったところの相談という場で切っています。
それでいいんだと思います。問題がなければそのままGOでしょうし、
目の前に来ないとわからないのは確かです。
予見できないような「これはさすがにないだろ」って内容をプロジェクト側が
出して来たら、多少遅くても口出した方がいいですし。
何も、この世で最も安く(しかも堅牢に)作る、という解を出す必要はなく、
その状況で、コスト・クオリティ等に問題ないものを作るのが重要なわけで。
コストカッターに、可能性も含めたすべてが見えてるわけじゃないはずですし、
「こう決めたならこれでやるか」って考え方もある程度は必要と思います。
もちろんあとで「ここは削れたな」って回顧はあってしかるべきですが。
開発リソース削ればそれだけほころびができやすくなるってだけで、
その限界ギリギリで作る必要はない(というかリスクばかり増える)。
実装サイドが「さすがに○○を削るのはまずい」ってことを
言いすぎでない範囲で言えるのも必要な能力ではあるが。
それが無駄だったのかは後でわかる(とか状況が変わって不要になる)ことはありますが
「本当は必要だったのに作ってない」ことがあとで分かるよりは数段マシです。
まさか淵上さん8月25日休出扱いで付けてるのかなｗ
ななし
みなさんのようにはうまくいってないです。。。
書かれているダメなパターンばかり。なかなかうまくいかないもんです。
ところでこの作者さんは評判見ながら内容かえてくタイプなんですかね。
だとするとこのへんのコメントも影響していくんですかね。
大手SIer
2000年代に続出した失敗プロジェクトに見られる様に要件定義が甘すぎかな。
「なぜこのプロジェクトが発足したのか？」
「このプロジェクトで達成すべき、守るべき目標は何か？」
が一度も論理的思考で分析でされていない。
たとえば
勤怠管理システムを刷新するのが目的だ！
→なぜ刷新するの？
→なぜ・・・
→なぜ・・・
てな感じで理詰めで考えればQCDの観点でのバランスのとり方や
守るべきものなんてすぐにわかるのにね。
最近読み始めたのですが
> 「君たちは正社員だ。君たちが実装作業をやれば、どうしても残業が増える。うちは残業の上限カットなどはしていないから、残業代を支給しなければならない」
> 「君のスケジュールは、残業を前提として線を引いているのか。考え方がおかしいとは思わないのか」
この発言者は残業を前提としてお話しされているようですが･･･