こうして僕らは腐る

ねえ、秒速100Usersなんだって、このブログがバズる速度。秒速100Users

PR

スタンダードという素晴らしさ

ブラック案件も一息ついた頃ですが、まだ余波は残っており課題があります。

 

いつもプロジェクトでいつも思うのですが、どうしてスタンダードから外れた技術を使おうとするのだろうかということです。

もしくはなぜスタンダードの技術を利用せず解決を試みるのかということです。

 

割りとIT以外の大企業のプロジェクトが多いのですが、例えば有名なオープンソースを使わないというルールです。

 

この前も契約を申し出てきたプロジェクトではPHPフレームワークを使わないというルールで頑張っているようです。

 

率直に言って自前で作ったPHPソースコードほど見苦しいものはありません。

フレームワークを使うほうが何はともあれスッキリするものです。自前のコードに比べれば。

彼らの言い分では「どのような不具合があるかがわからない。だからダメだ」と。

自前でソースコードを全て組み上げた上での不具合と、フレームワーク潜在的に持っている不具合はどちらが多いのだろうと思いますね。

 

今回の問題は大企業側が要求してきたストレージサービスへのアクセスAPIです。

ファイル保存としてクラウドのネットストレージを利用することはもはや珍しくはありませんが、その分野ではAmazonが圧倒的です。

別の案件で僕も使ったことがありますがなんせライブラリが豊富で、すぐに使えるという優れたサービスです。

 

ところが今回ボクの案件で使っているのはAmazonではありません。

日本のとある大企業がそれを指定してきたという理由だけで、日本語マニュアルさえないサービスを利用することになりました。

 

現在どうなったか?未だにAPIが利用できていないという惨状です。

そしてサービス提供業者と我々との間で責任のなすりつけ合いみたいになっているという地獄。

 

これを書いてるときもAWSサービスだったらなあと思っております。

Amazonのサービスはなにせマニュアルや実績が豊富なので調べる時間が短縮できます。何のために大企業が指定してきたのか、というのは難しい話ではなく大企業のお友達企業だからに他なりません。

 

そうしてしわ寄せはすべて現場に来るわけです。

有名な技術を使うと圧倒的に調べる時間が短縮されます。そのメリットを生かさないのであれば時間は割りと余裕を持って設定すべきです。

 

とはいえ技術のことなんてさっぱりというお客なので、必然的に企業をつめることしかできません。かなしい。

 

そうやって怒ってケツを叩くしかできない企業は潰れてしまえばいい。

最初からきちっとした仕様と環境に合わせた技術選定をしていれば納期遅れだって起きなかったはずだ。

 

いつだって僕はスタンダードで多数派の技術を採用するんだということを忘れてはいけないと思いました。

 

 

 

あわせて読みたい

www.byosoku100.com

www.byosoku100.com