やっぱり難しいです。 日本のこの業界って、批判される側が往々にして「改善する努力をしていない」とか言われて悪いとされますよね。反面、批判する側もあまり厳しく批判すると「人間力が無い」とか言われます。

１つのプロジェクト内でメンバーがdisりあう、なんてわりとよく見る光景なんですが、これについて「仕方ないよな」と思う自分と「不毛だよな」と思う自分とがいます。

ちょっと標準化についてのエントリーを見る機会があったので、例によって便乗して考えてみました。

プロジェクト・チームという組織を考える時、たまに思います。 理想的な究極の組織、それはやはり「軍隊」ではないでしょうか。 いや、ちょっと思っただけなんですけど。。。

中まとめ、ほど完成してもないですが、いくら徒然って言ったってあまりにだらだら書きすぎている気もしていて、一段落おきたいです。

方式設計について、色々考えた事を書いてきましたが、そろそろまとめます。

前回、方式設計のミッションと思われる（ちょっと自身ない）を列挙してみました。こうすると、方式設計とはプロジェクトそのものをデザインする工程だと思ったです。ソフトウェア・デザインと同様、この設計が後の工程に与える影響は少なくないです。無駄な…

一瞬わき道に反れてしまいましたが、設計というプロセスについてです。まずは方式設計。 対象のシステムの実装の仕方を設計します。その為、まずは実装方針の指標ともなるシステム・アーキテクチャ設計が必要となります。そのアーキテクチャに沿ったハードウ…

システムのデザインの最適化を考えるのと同じくらい、プロジェクトの置かれた状況を意識しないと、本当に設計と言える設計は出来ない、という前回からの続きです。

前回[id:itengineer:20070602]、少し書き残した事がありましたので、補足します。自分が設計フェイズを担当した際、まず気にするのは開発要員の技能レベルです。一時はこれを無視して自分なりに最も最適化された、効率化された設計をしようとしていましたが…

寝付けなかったので、ちょっと追加。 以前、プロジェクトの中で無駄は省かなくてはならない、と書いた気がします。省かなくてはいけない無駄とは何か、を考えないと正しいものは見えてきません。単純に「作業していない時間＝無駄」とするのは大変危険です。…

自分が思うフレームワークと共通化の意義についてです。最近、ちょうどTeedaについて取り上げたので良い機会だと思って書きます。自分の周囲で勘違いされているのが、フレームワークや共通化を進める事で最終的に実現したい目標は、実は「社内標準化の作成」…

プロジェクトに必要不可欠なもの。 それは、タスクをリストアップできるエンジニアも、効率的なアーキテクチャ設計が出来るエンジニアも、遂行に適したプロセスを運用できるマネージャも必要で、それを疑うべくもないのですがが、それよりなによりまず「リス…

はてさて。 プライベートに忙殺されていて、なかなか思うように書けなくなりつつありますが、始めた当時の勢いでがりがりと書いていられたのもここまでなので、これからは勢いより内容を考えて書かねばなりません。 一段落ついでに、システム開発のプロジェ…

ドキュメントの向こう側に何があるんでしょう？ この業界って、プログラムソースとか帳票とか、とかく成果物と言ってもプログラムとかシステムとか、出来上がって動くものに目がいきがちです。でも、ちょっと前からのUMLブーム、そして内部統制を踏み台にし…

自分の周辺の人の中で「上流工程やりたい」って人が多いんですが、「じゃ具体的に上流（と呼ばれるフェイズ）に何をしたいんだ？」と聞くと真っ先に出てくるのが「要件定義」。次に「設計」です。更に「要件定義」「設計」で君は何が出来るのさ？と聞くと、…

技術だけでは駄目です。 と、前回までを否定する訳ではなくて、技術だけではプロジェクトというビジネスの成功には足らないのだな、と思うです。マネージメントというファクタが、どうやっても必要になりますよね。例えば、「技術の粋を極めたシステムを設計…

技術が必要、というのは前回書きました。次に必要になるのは、その技術を使ってタスクを洗い出す事と、そのタスクに適した要員をアサインする事です。これはややもするとマネージャの仕事として扱われそうなんですが、要員の特性と技能を見極めた上で、タス…

自分的には技術だと思うです。何をおいても技術ですよ、だってエンジニアなんですから。 でっかい案件取ったどー！とかコレは業界に新風を〜とかいう提案が通っても、それをこなせなければ所詮画餅です。っていうか、お金が絡んでるだけに損害しか生まないで…