理念共有型ワークスタイル
ネオジニアは、クオリティの高いシステムを提供するために、開発ワークスタイルをつくり、社内のみならず、協力会社の方とも働き方の意識を共有し、開発しています。
ヒト－同じ理念を持ったエンジニアたちのシゴト－
ワークスタイルが重要な理由
開発現場の実態
一般的な開発現場の実態がどのようになっているか、ご存知でしょうか。
マネジメントが行き届かない多重下請構造
大規模な開発の場合、開発を請け負う企業が階層化されています。お客様の利用部門があり、情報システム部門、１次請けのSIer、2次請け、3次請けと、会社をまたがり、体制が作られています。
プロジェクトマネジメントは、スケジュールを守るために、無駄のないように効率的に、いいものをつくるためにお客様の要望に対して真摯に、そして、品質を高めるために、なされるべきものですが、一般的なシステム開発の現実は、それとはほど遠いのが実態です。
スケジュールは守られず、無駄な作業も多く、お客様の要望は基本的に受けないように、品質管理という名の無駄な管理作業が負担になっているのが実態です。こうした現場で長く仕事をしていると、エンジニアはそれが当たり前のことのように思ってしまいます。
上からの指示にひたすら耐え続ける現場のエンジニアたち
お客様は、スケジュールが遅れたり、品質が悪いことを「当たり前」と考えているはずがありません。
お客様は、スケジュールは守って欲しいし、品質も良いものを納品して欲しいと思っています。ただ、そのことと、自らの要求が結びついていることに、気づかずに要求しているに過ぎません。
お客様の要求に対して、スケジュールや費用、品質に関わるものは、その時点でお客様と相談する必要がありますし、そもそもそのようなことを、如何に調整するかがマネジメントです。
ほとんどのケースで、そのマネジメントが行われていないために、多くのエンジニアが、上からの指示を当たり前ように受け入れ、そして耐え忍んでいるのです。
誰がどうつくるかの重要性
その様な事態を当たり前として受け入れているエンジニアが開発しても、決していいシステムはできません。自ら、良し悪しを判断することなく、ただ、上からの指示だから、というだけで作業する習慣のついてしまっているエンジニアには、設計も、納期を守ることも、品質の高いソフトウェアを開発することも、ましてや、変更に強いシステムをつくることなど、到底できません。
そのため、ネオジニアは、ネオジニアとして提供するシステムのクオリティを確保するために、「ワークスタイル」の考え方を導入し、開発を行っています。
効果のないマネジメント強化
一般的に品質向上のために品質管理などの管理業務を追加するといったプロジェクトマネジメントが強化されていますが、それでは決して品質は向上しません。
むしろ、不必要な作業が増える分、工数は増大し、エンジニアの士気は低下し、品質はむしろ低下しかねません。
本質的な問題は別のところにあるのです。
「開発ワークスタイル」共有の必要性
本質的な問題は、多重下請け構造の寄せ集め体制にあります。本来の目的も、開発の理念も共有されることなく、伝言ゲームのような形で意味不明な情報が伝達され、開発しなければならない環境にあります。
こうした環境を改善し、品質を低下させる管理業務を排除し、結果としてプロジェクトマネジメントが強化されるような「開発ワークスタイル」を共有することが本質的な対策として必要なのです。
ネオジニアの考え方
開発目的の共有
ネオジニアの開発では、チームメンバーと理念を共有し、開発を行ないます。社員か協力会社のメンバーであるかも関係ありません。所属会社に関係なく、ネオジニア開発に従事する全てのメンバーと理念を共有します。
ネオジニア開発理念は、以下の通りです。
開発する商品・サービスとして
- 「変更に強いシステム」を構築する
- お客様の本来の目的に合致したシステムを開発する
開発エンジニアとして
- エンジニアとしてレベルアップする
会社・組織・チーム・プロジェクトとして
- 開発に関わる情報を共有し、一翼を担う者として、互いに尊重し配慮し合う
目的達成のために必要となる姿勢
理念共有型ワークスタイルを実現させるため、ネオジニアでは、細かいルールを規定し、それが守られているかどうか、といった一般的なシステム開発で行なわれている開発を阻害するマネジメントは行ないません。
しかし、開発を成功裏に収めるために、下記のような仕事に対する姿勢を共有します。
何のために仕事をしているのかを考えて仕事をする
「変更に強いシステム」の実現、一人のエンジニアとしてのレベルアップ、プロジェクトの成功、およびそのために何をどうすべきかを考え、仕事をする
主体性を持ち、自主的に開発する
指示通りではなく、その指示者およびその基となっている依頼人の意図なども考え、この仕様でいいのか、を考えて開発する
プロジェクトメンバー間で、進捗を把握、共有する
全員が全体としての納期やそのためのスケジュールを共有し、プロジェクトマネージャだけではなく、各自が担当範囲はもちろんのこと、全体としての納期意識を持って開発する
具体的なアクション規定は、それ自体が目的化するという弊害を生むため、必要不可欠かつ必要最小限のものに留め、それ以外のことについては基本的に規定しません。
個人の自主性の基に開発します。
プロジェクトのマネジメントは、この「開発ワークスタイル」の共有を通じて、個々の行動レベルの改善、課題解決を図ります。
