2013年2月28日木曜日

アウトプット

学んだことについてアウトプットするのは大事なことだと思う。

本当は人に「これはこういうことなんだよ」と話が出来ればよいが、
聞きたくないこともあろうし、都合が合わないことも多い。

ぜひともアウトプットにこだわっていきたい。

記憶も強化されるし、考えをまとめることもできる。
皆が知りたい情報であれば 喜んでもらえる。
良い事づくめである。


2013年2月26日火曜日

プログラム開発 標準化

プログラムのつくりを統一しておかないと、作る方もメンテナンスするほうも大変である。

必要とは思いつつも、零細、小人数の体制ではしっかりとした開発標準のような
ものを検討する余裕がない社内SEさんも少なからずあると思う。

すでに存在しているものに作りを合わせるのが簡単である。

これをやっている人はよいのだが、まったく異なる仕組みで、同じ組織で仕事を
しているとは思えないつくりになる場合もあるから困る。

多少まずい作りであっても、ある程度統一された作りになっていれば救われる。
まったく異なると0からコードを解析しなければならない。

Visual Studioならば、サンプルとなるプロジェクトを用意して、これをテンプレート化し、
ここから大きくハズレないようにしてもらうなどの工夫が必要であろう。

あまり極端に作りが変わると、人によって生産性が何倍も変わってしまう。
他の人に引き継げない。

システム内製

システムを内製するかベンダー(業者)に依頼するか、という議論がある。

・ベンダーに頼んでもまともにつくってくれない
・遅い
・費用が高い

では内製すれば解決できるのか。
必ずしもそうは言えないと思う。

結局、内製するにしても外製するにしても、それなりのスキルも必要であるし
とくに重要なのは顧客、現場の目線に立てることだと思う。
(なんでもかんでも希望を取り入れてしまうのも問題であるが・・・)

その上で内製するメリットを考えてみると

・現場の要望にそって作りやすい
・早い
・費用は比較的少ない
 (遅い人が作業すれば遅いし、当然その分の人件費を無駄にする)
・変更に対応しやすい


開発スタイル

システム開発

ちかごろXPなどのアジャイルな開発が流行っている。

特に、顧客のそばにいるわれわれ社内のSEにとっては親和性が高いように思う。

XPにはいくつかのプラクティスがある。

そのうち、取り入れられそうなものを使っている。

※必須と思うもの

 ○YAGNI(単純な設計)

 ○リファクタリング

  とりわけ「単純な設計」が非常に重要であると思う。

  その人しかわからないような新しい技術をつかいたがるひともあるが、
  保守作業、小規模開発が多いわれわれ社内SEにはほぼ必要ない。

 ○頻繁なリリース 

  変化の早い時代、スピード感のあるリリースサイクルが重要だと感じる。
  環境の変化に素早く対応するには、上記のように単純でわかりやすい
  仕組みになっていることが必須と思う。 

  早くリリースすることで、要望とずれがあっても早期に修正できる。

※部分的に適用しているもの


 △TDD
  単純な処理や、データベースに出し入れするだけ、のような処理には
  省略できるのではないか。

  複雑なロジックをともなう処理、業務には有効だと思う。
 
  △ペアプログラミング
   他人のソースコードを確認することで、一定の効果があるように思う。

※今後検討したいもの
 ミラー
  「もっとも重要な情報は自然に視界に入るようにするのがベスト」
  システム開発における見える化という事だが、各人まかせにすると
  優先順位がおかしかったりする。


コンセプトをよく理解して、うまく取り入れれば非常によいと思う。

参考文献:エクストリーム・プログラミング入門 ケント・ベック著






2013年2月25日月曜日

はじめに

ある社内SEの日常

社内SEの身の上にふりかかる日常の出来事を書いていきます。