SI用語講座（非システム開発者向け）
【バグ】
明記された要件や仕様を満たしていない、あるいは実装ミスなどによりプログラムが正しく動作しない状態を指します。
利用者の主観で思い通りに動作しないこと、設定ミスによる動作不良、仕様を変更したいなどはバグの定義から外れます。
なんでも安易にバグ、バグ騒ぐと信用されなくなるので注意しましょう。
事象の原因が特定できていない場合は『不具合』等の表現が穏当です。
【修正】
安易に使いがちですが、意味は『間違ってるから直せ』です。
あきらかな仕様誤りやプログラムミスの改修指示以外の用途で使用するのは甚だしく不適当です。
この場合は変更、改修などの表現が適当です。
発注元という立場であれば、面と向かって指摘されることはありませんが、影ではどんどん嫌われていくので注意しましょう。
人手不足の世の中で仕事の方が余っている現状ですので、偉そうに発注者ヅラしていると、SIerの方から三行半を突きつけられますので、こちらも注意しましょう。
マニュアル開発
システム開発の委託先からの要望として、指示にさえ従えばプログラマの技量に関係なく、自動的に一定の品質が担保できる開発マニュアルが欲しいといった話が出ました。
（おいおいウチは元受けベンダーじゃなくてユーザー企業だぞ。どこまでお前んとこの請負開発にコミットさせるんだよ・・・という話は置いておいて）
確かに誰が担当しても均一なプログラムにできあがる定型化された作業に落とし込めれば、管理する側にとってはこれほど楽なことはないでしょう。
システム開発におけるひとつの理想であるとは思います。
クラシックなフレームワークを採用した大規模で定型的な開発であれば、その手法に一定の有用性もあるでしょう。
そのためにひと昔前に、日系の大手ベンダーもStrutsベースの巨大な自社フレームワークを育ててきたのだと思います。
（もし今もそんなものを使っていたら脆弱性対応で死にそうになっているだろうけどｗ）
管理上のメリットは認めるけれども、それにはそういったものをキチンと整備するには専任のエンジニアが必要になります。
大手ベンダーでもないイチ零細ユーザー企業ではそんなことに人員は割けないですし、そんな体制は開発規模に対してオーバースペックすぎます。
どうせいつものように行き場のない人間のための有名無実のポジションになるに決まっています（毒）
なにより一番大きな理由は自分自身がプログラムを単なる作業、均一な工業製品に貶めることとを好みません。
ただただ定型作業をこなすだけでは、想定外のケースに対する想像力が育たないと思いますし、新しいものへの対応力も身に付きません。
そもそもやらされ仕事はまったく楽しくありません。
社内政治の結果選定されたベンダーと今後も継続して長く付き合っていきたいという気持ちもないので今回の話は華麗にスルー。
システム開発として「きちんと体系的に整理して組織として大規模な開発にも対応できる体制を整える」というのが王道で、「手の届く規模に限定して好きなように作りあげたい」というのは間違っているのは百も承知ですが、自分のやりたいやり方を放棄するつもりはありません。
もし会社として自分の自由に制約をかけるような動きがあれば、別の自由な場所を探すのだろうなあ。
ベンダー（という名の人売りですが・・・）勤務時代に一周回って（ムダな）マネジメントや管理が大嫌いになった今日この頃。。
オフショア開発
社内の新規開発がどうにか進んでいるわけですが、相変わらずなぜオフショアを採用したかの合理的な理由が見つからない。
（政治的な理由ならいっぱいある。。）
確かにPG単価は少し安いかもしれないけれど、不必要な標準工程や、管理工数、ブリッジSE工数、コミュニケーションコストなどで、社内に日本人の委託チームを作るより、むしろ圧倒的に割高なわけですが。
もちろん作業を重ねることでルーティンの習熟によって生産性の向上が期待できるという可能性はありますが、それは開発案件を数多く手がけるSI企業での話。
保守作業がメインで、数年に一回の新規開発があるのみという我が社では百害あって一理なしなわけで。。
まぁ戦略の誤りを現場の戦術でなんとかするというのは、昔から日本の兵隊さんのお役目なわけなので、やれるところまではがんばります。。
ビジネスモデルのお話
某業界に属する我が社。
取り扱う商材はハード含めたシステムソリューション。
ぶっちゃけてしまえば、2000年代前後の日系SIerの古いビジネスモデルそのまま。
システム導入が一巡し、ハード老朽化を理由としたシステムリプレースビジネスが主な収入源。
新規導入であれば、ノウハウやユーザーとの調整能力などが問われます。
しかし更新案件であれば、大した作業もなく正直なところボロいことこの上なしといった印象。
現在のシステム界隈はハードのクラウド化が進み、某赤いメガバンクですらそちらに舵を切り、ハードの更新という概念自体が消滅しつつあります。
海外の大手システム関連会社はパッケージ売りを諦め、クラウドサービスなどの従量課金へと移行しました。
しかし日系SIerはクラウドサービスでは完全敗北、ハード需要の減少をモロに受けて、炎上案件での中抜き人月ビジネスが頼みの綱といった惨状に見えてしまいます。
旧態依然のうちの業界も、いずれはその流れに飲み込まれるのは必定で、新しいビジネスを生み出せないまでも、単純に従量課金の方向に変えていくなど考えないと、収入源が尽きてしまうわけで。
…なのですが、誰も考えていないだろうなぁ…。
まぁ個人的には今取りかかっている製品開発の仕事をやりきれたら満足です。
仮に会社が立ち行かなくなっても、システム開発の職場は現職だけではないので、個人的には問題ないですが、会社ドップリな人はどうするのかなぁ。。
開発のお話
数年ぶりに立ち上がったシステム開発プロジェクトのお話。
社内に開発できる人はいる。
ただし、他社に委託できるレベルの設計書をかける人はいない。
そもそも設計書を書くというスキルを会社として育成してこなかったので当然。
よって、社外から調達が必要なスキルは『プロジェクトマネジメント』『設計』のはず。
にもかかわらず、外部から開発を調達して、社内の人間に経験のない設計をさせようとしている。
しかも社内事情により、コミュニケーションで問題を抱えることが多く、難度の高いオフショアを採用する方針。
会社として設計する人間を育成するためにある程度の失敗は覚悟のうえなのか？
数年に一回の社内開発プロジェクトの一発勝負で勝算はどれくらいあるだろう。
まー、炎上は確定でしょう。。
いまさらGit入門
いまさらGit入門
Gitの複雑さは今の社内では受け入れられないだろうと導入をあきらめていました。
もう少し調べてみるとgit-svnという、SVNと連携する手段があることを知り、ここしばらく使っていました。
結論から言うと、Gitすんばらしい！！
もっと早く使えばよかったです。
私は自社パッケージ製品の保守運用を担当しているため、中規模案件が走りながらも、バグフィックスや細かい案件が複数同時に走ることが日常茶飯事です。
これまではいちいち使いにくいsvnのブランチや複数のローカルコピーを使い分けていて、なかなかストレスフルでした。
これをローカル環境のみGitに置き換えたことで、ブランチを切り替えての平行作業がスムーズに回り、仕事がはかどるはかどる。
ガシガシcommitしてもsvnのログも汚れないのも嬉しいです。
最初は慣れないGitの操作が不安でしたが、ローカルでいくら失敗しても、svnには影響がないという安心感も大きかったです。
他メンバーは慣れたsvnを使い続けることができ、うまく住み分けられるのもイイ！
ちなみに今の開発は
①svnからローカルGitのmasterブランチに最新ソース取り込み
②masterブランチから目的のブランチをバンバン切る。
③バシバシブランチを切り替えながらやっつける！
④終わったものからリベースしてログを統合、masterにマージしたらブランチ削除。
⑤masterからsvnに反映！
という感じで回していますが、心なしか開発にもリズム感がでて良い感じです。
あくまでGitはローカルの資産なので、念のためjenkinsさんに別マシンに全ブランチを定時バックアップしてもらっています。
私のようにいまさらGitを触ってみようという奇特な方へのアドバイスとしては
・取っかかりとしてはgit-svnはおススメ（既に開発環境にsvnが導入されている場合など）
・ダミーのリポジトリでいろいろ操作してみて、概念や挙動を理解する
ことでしょうか。
Web系だったり、流行の技術を扱っていないからGitも敬遠していた方でも、私と同様の業務を担当しているなら、一度この武器を手に入れたら絶対に手放せなくなりますよ。
肌に合わなければ止めればよいだけです。
まずは触ってみましょう！
バージョン管理システムの変更
バージョン管理、Gitにしようかと考えたのだけれど、いろいろとクセがあるし、悩みどこ。
確かに使いこなせればメリットもあるだろうけれど、
・学習コストが高い
・運用ルールの徹底が必要
とちと我が社の環境ではハードルが高い。
みんながみんな新しいものに対する意欲があるわけではないし、リテラシーもさまざま。
Gitは概念の理解とかソフトウェアエンジニアでないとちと厳しいのではないかな。
別チームは骨董品のVSSなので、即移行検討対象なのだけど、ウチのチームはSVNを使っていて、とりあえずそれで困っていない。
やっぱり道具はある程度明確な目的を持って導入すべきであって、手段を目的化するのは好ましくないので見送るかなぁ。。
