30過ぎのプログラマ

プログラマは30才位まででしょう なんて言われたりします。 一方、 プログラマとして優秀なら、 ずっとプログラマでもいいのでは という考えもあると思います。 どちらが正しいのでしょうか? 例えば、優秀な管理者、SEの元であれば、 30過ぎてプログラマでもいいと思うのですが、 SEが優秀ではなく、ボロい設計を作られてしまったら いくらプログラマが優秀でも、良いシステムは 作れないと思います。

エラーチェック

例えば、数値型の変数にアルファベットを代入すると プログラムは異常終了してしまう。 当然、代入する前に数値かチェックし、 数値で無いなら処理をせず、 再入力を促すメッセージを出力すべきです。 当たり前の事ですが、上流企業担当者が プログラム未経験だと、よく分かってない 場合もあるようです。 運用してから苦労する場合、 きちんと説明すべきでしょう。

情報処理試験

情報処理技術者試験 というのがありますね。 合格すれば、履歴書に記述できたり、 上司に申告して資格手当てをもらえたり・・・ ここでは、ちょっと別の見方をしてみましょう。 例えば、 どうやって開発を進めれば良いか悩んだとき、 情報処理技術者試験を作成している人達なら どの様に解決するのか想像してみましょう。 試験問題と模範解答から出題者の考えを 想像してみてください。

夕食

SEの仕事は残業が多いですね。 その為、夕食は深夜、寝る前 という人も多いのではないでしょうか。 この様な生活は 胃もたれ、肥満の原因と なりそうですよね。 もし、18時～20時位に夕食を とりたいなら、 上司にお願いしてみてはどうでしょうか。 まずは、自分の意思を伝える事が重要 だと思います。

進捗会議

開発スケジュールが遅れだすと、 進捗会議を頻繁に行うようになったりします。 しかし・・・ 進捗会議に時間を取られ、 作業時間が減ってゆき、更なる遅れが・・・ 悪循環だけは注意してほしいものですね。

デスマーチその2

例えば、VBのプログラマーを経験した人が、 VBの設計を担当する場合は良いのですが、 この人が次にJavaのWEBアプリの設計を担当するとなると、 前回の記事(デスマーチ)で記載した下記の様な状態となります。 この様な問題をどう解決していくかが、 管理者の課題だと思います。

デスマーチ

デスマーチとは何でしょうか。 いくら開発を進めても終わりそうに無い状態でしょうか。 複雑な機能を一度にたくさん盛り込みすぎたりすると 起こりやすくなると思います。 実装能力のない人が設計を担当すると、どうしても 現実離れした仕様となる場合が多い様です。 せめて、シンプルイズベストぐらいは心がけてほしいですね。

納期

ソフトウェアの開発に納期はつきものです。 しかもたいへん厳しい... 納期に間に合わせる為、 長時間の残業や、時に徹夜等も珍しくないと思います。 以外に見落としがちなのが、設計工程の遅れです。 設計書に不備や進捗の遅れがあったから、その分、 製造工程の納期も遅らせてもらえるという事にはならないですし、 製造工程は下請けがやっているので立場が弱かったり... 納期が迫っていても仕様変更しまくっているプロジェクトも 珍しくないと思います。 製造工程の責任者が設計工程の責任者にきちんと設計工程の 進捗と品質について話ができるかがポイントになると思..

SEの定義

SE(システムエンジニア)の定義は結構曖昧だと思います。 広義には、 設計者、製造者、環境構築者、運用管理者、 すべての人に使われる様ですが、 狭義としては、設計者の事だと思います。 プログラムを組むのはプログラマと考えるべきですし... マイクロソフトの資格に MCSE(マイクロソフト認定システムエンジニア) というのがありますが、これはOS周りの技術なので SEでは無いと思います。