その会社、「企業理念」を設計できていますか？
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。
ここでは、編集部がおすすめするコラムを紹介しよう。企業理念の設計ミス、会社との理想の付き合い方、ミステリアスソースのケーススタディ、の3本を取り上げる。
- 会社を上流工程で読み解く - 要求分析・要件定義
- 入社してからの「こんなはずではなかった」を回避するために
- ソースコードは自分を映す鏡なの？
会社の要件定義
北海道のソフトウェア企業 エスプランニング 代表取締役 ふくにし氏の『SEによる会社リファクタリング』。ブラック企業（設計ミスを放置してバグだらけになった会社）について、今回は上流工程、「企業理念」の設計部分を考察する。
アプリケーションやシステムを作るときは、「何を解決するのか？」「何のために作るのか？」をきちんと理解しなければならない。会社も同じだ。会社は「社会のニーズを満たす＝生産を行って利益を上げる」ことを目的とする。このとき必要となる要件が「企業理念」だ。
システム開発同様、要件定義や実装が正しく行われているか、チェックしてみよう。
- 企業理念は定義されているか
- 企業理念の設計方針は正しく理解されているか
- 企業理念は正しく実装されているか
「こんなはずでは……」
ギャルプログラマの森姫氏による『恋愛感情で仕事はできるか？』。今回は、入社してから「こんなはずでは……」と頭を抱えたエピソードを紹介する。
「土日は完全休み」と聞いていたのに、実際は「有給をあてることで休みにする」状態だった。「残業代はちゃんと出る」といわれたが、実は試用期間中のみだった。森姫氏は「人間も会社も、都合の悪いことは隠すものだ」と語る。
ただし、会社に対してのみ「ウソをつくな」というのは問題がある。なぜなら、社員の方も、都合の悪いことは隠したり、ウソをついたりするからだ。社員が「こんなはずでは」と思っている隣で、会社も「こんなはずでは」と思っているかもしれない。まずはお互い、ウソをつかないところから始めるのが理想ではないか、と森姫氏はまとめている。
「自信」がミステリアスソースを打ち破る
草食系妙齢プログラマ 野口おおすけ氏による『不思議そうで不思議でないちょっと不思議な現場の話』。今回は、ケーススタディを通じて「ミステリアスソース」を考える。
筆者はミステリアスソースの例として、共通処理をコピー＆ペーストで済ませるケースを紹介している。どの言語でも、同じような処理を複数の場所で行う場合にはファンクションを作成し、それを呼び出すことで処理の共通化を行う。これを無視して、同じ処理をコピー＆ペーストでソースコード内に複数回記述すると、ソースの複雑度が跳ね上がる。これでは、テストや問題発生時の対応にかかる工数が数倍以上に膨れ上がってしまう。このようなソースが発生する原因について、野口氏は「設計段階で共通処理の洗い出しが正しく行われていない」ケースが多いと語る。
プログラマは常に最適な実装を目指す必要がある、と筆者は主張する。実装法を細部にわたって記述している仕様書など存在しない。実装法の選択はプログラマに任されているのだ。だからこそ、ペアプログラミングやソースコードレビューを行ったり、ブログにソースコードを書いたりして、「自分の実装法」をさらけ出し、レビューしてもらうことが重要なのだ。
「ソースコードをさらす」ようになると、やがて自分の実装に自信が持てるようになる。自信を持って書かれたソースは、ミステリアスソースにはなりにくい、と筆者はアドバイスをする。
コラムニスト募集中 |
| エンジニアライフではコラムニストを募集しています。 応募資格は ・ ITエンジニア（元でも可） ・ ITが好きで、将来はIT業界に就職しようと考えている学生 ・ ITエンジニアの採用に関わっている人事担当者 ・ ITエンジニアの育成に関わっている教育担当者 ご興味のある方はコラムニスト募集ページをご覧ください。 |
【過去の「おすすめエンジニアライフ」】
・エンジニアを悩ませる「ミステリアスソース」
・「TOEICで700点取得」は、手段か目的か？
・漫画から学んだ「人のせいにしない」生き方
・「年下のリーダーって微妙だよ」といわれたら
・海外で働くとき、生かせるスキル、生かせないスキル
・キャリアパスの責任――企業責任か自己責任か？
・楽天「社内会議の英語化」への意見をまとめてみた
★2010年5月の「おすすめエンジニアライフ」
☆2010年4月の「おすすめエンジニアライフ」
★2010年3月の「おすすめエンジニアライフ」
☆2010年2月の「おすすめエンジニアライフ」
★2010年1月の「おすすめエンジニアライフ」
