転職８ヶ月で異動となりました。
といっても組織が変わることによる異動なので、仕事が変わるわけではありません。それでも人の出入りはあり、「変わる」ということに対して、漠然としたストレスがあります。
ところで異動の内示。前職も前々職も直属の上司から、こっそりと辞令をもらっていましたが、今の会社は人事部長から内示をもらいます。異動対象者７０名くらいが大会議室に集められて、異動先が同じ人たちがカタマリで別室に呼ばれて、人事部長から内示をもらいます。ちょっと不思議な感じ。
しかも辞令がありません。もらったからといって、記念に取っておくようなものでもなく、すぐに捨ててしまっていたけれど、辞令をもらわずに異動というのも不思議な感じ。
異動対象者全員が一箇所に集められるので、「あれ？△△さんも異動なんだ」「あれ？○○さんがいない（異動と思ったのに）」というような声があちこちから聞こえます。
会社によって異動の仕方もずいぶん違うんだなあと勉強になります。
アプリケーションを開発する際に、通常、複数の工程に分けてプロジェクトを推進・管理します。
なぜ工程を分けるのかというと、期間が長かったり、主体者が変わったりすることで、区切りをつけるためです。
自分のためだけのアプリケーションを一人で開発をする場合には、工程など分けません。設計書も作らず、いきなりアプリケーションを作りはじめ、作った部分を動かしながら動作確認をして完成させていきます。
これが仕事を請け負い、設計書等の成果物を納期までに納める必要がある場合、一連の作業を複数の工程に分けて、発注者に進捗報告をしていく必要があります。発注者も管理責任があるので、きちんと開発が進んでいるか把握しなければならないからです。
さらに開発を複数の会社で分担する場合、責任の所在をはっきりさせるためにも工程を分けます。上流工程は元請けベンダー、下流工程は下請けベンダーといった分け方をする場合、元請けベンダーの担当範囲を要件定義、基本設計、総合テスト、下請けベンダーの担当範囲を詳細設計、製造、単体テスト、結合テスト、といった形で分けます。それによって、テストでバグが見つかった場合、どちらの工程で埋め込まれたバグなのかを評価し、元請けベンダーと下請けベンダーのどちらが修正するかを決めていきます。
開発の工程には、ある程度はIT業界共通の工程の境界がありますが、その境界はグレーゾーンが多いのが実情で、プロジェクトを進めるとしばしばこの境界で意見が対立することがあります。
元請けベンダーと下請けベンダーであれば、「このバグは基本設計の記載が曖昧だからいけない」、「いやいやこれは詳細設計で決めていくレベルの内容だ」といった意見のぶつかり合い（責任の押し付け合い）、発注者とベンダーであれば、「これは要件を出さないユーザー側の責任」、「こんなものは基本設計でベンダーが対応箇所として洗い出すべきもの」といった意見のぶつかり合い（責任の押し付け合い）が、しばしばあります。
また工程の分け方自体にも複数あるから厄介です。設計工程を基本設計、詳細設計という呼び方で分けたり、外部設計、内部設計という呼び方で分けたり、ベンダー独自の呼び方があったり。単体テストという同じ呼び方でも、範囲が異なっていたり。
その辺りの実情も踏まえながら、企画含めた開発の一連の作業を、以下の各工程ごとに説明していきたいと思います。
①戦略・企画
②要求定義
③要件定義
④基本設計
⑤詳細設計
⑥製造
⑦単体テスト
⑧結合テスト
⑨総合テスト
⑩受入テスト
うちの会社の社長はESGにとても熱心で、年始の朝礼で４０分のうち３０分はESGの取り組みについて話しをするほど。
でも、とある女子社員に「会社のESGの取り組みは分かりました。では社長一個人としては、どのような取り組みをされていますか？」と質問され、ぼそぼそと「なるべく節約するようにしています・・・」と歯切れの悪い回答。
自分が不便な思いをしてまで、環境問題に取り組むのって難しいなあと、逆に社長に共感しました。
地球温暖化、プラスチックゴミ、サンゴの白化、原子力の問題、ニートや引き蘢り、非正規雇用の問題、待機児童、世の中には様々な社会問題があって、それに真剣に取り組んでいる人たちがいます。
その一方で、大変だ、何とかしなきゃ、と思い、真剣に取り組む人たちを応援しながらも、どこか他人事の自分もいて。
スポーツ観戦なら応援するだけでいいけれど、本当に応援したいことは、自分が自分事として取り組まないといけないんだなあと反省。
まずは、節約からはじめてみようかな・・・。
