システム開発と役割②

はじめに
前回までと今回のテーマ
開発部隊を掘り下げ
さいごに
関連する投稿

はじめに

社内教育用に話したことを再編している物です。
特にプログラマーに語りかける切り口になっています。
最終的にプロジェクトスタートアップに向けて
チームの意識を同じ方向に向かせることが目的です。
新人も対象なのでかなり当たり前な話も含まれます。

前回までと今回のテーマ

お客さんと、ベンダーの役割をざっくり説明しました。
今回は開発部隊内の役割を掘り下げます。
プログラミング作業を行える状態になるまでに、いろいろな人がいろいろと準備をしてくれているから、プログラミンに専念できていると言うことを知ってもらうことを目的とします。

システム開発と役割①

はじめにシステム開発に関わる人々システムには様々な人が関わります。プログラマーだけでシステムが出来上がるわけではありません。お客さんと会社をつなぐ営業システムを発注するお客さん受注までの手続きに関係する人々お客さんの要件をまとめ...

開発部隊を掘り下げ

ちょっと前回の画像から、開発部隊のところを分割してみます。
※分け方はいろいろありますが、ここではこう分けます。

アーキテクト

少し広義に捉えています。
アーキテクトが居ないとそもそも開発に着手出来ません。
場合によっては見積もりが出来ません。
何故なら、以下の様な作業を担っているからです。

お客さんやSEの要件を元に、最適な実行環境、開発環境の選定などを行います。
お客さんの予算なども絡んでくるため、営業やSEとも行動を共にする事が多いです。
提案なども行う場合もあり、アウトプットやプレゼンの能力も問われる場合もあります。
プロジェクトのリソース管理方法などのルール作り。
社内で言うところの、Redmineやsvnの構築や、使用ルールの策定などを行う。
開発フレームワークの選定を行います。
フレームワークも日々最新の物が現れてくるので、常にアンテナを張っている必要があり、知見が問われます。
最適なソフトウェア設計モデルを策定します。
三層スキーマにしてみたり、マイクロサービスでコンテナにしてみたり。
メンバーのスキルも考慮する必要があるため幅広い視野が必要です。
ソフトウェアのライセンス管理を行う。
商用ツール等のライセンスは言うに及ばず、他にもOSS、GPL、MIT等のライセンス物を使う必要のある場合のチェックなど
リリース後のデプロイ方針や、デプロイ手順ツールの選定などを行う。

アーキテクトは開発方針のコーディネーターなのです。

デザイナー

主にシステムのUI/UXの設計と実装を担います。
全く同じ機能でもデザインが変わっただけで全く違った印象や操作感になる事もあり、その存在は必要不可欠です。
それ故にお客さんへの提案やプレゼン時のシステムの印象を決定づけることもあり、営業やSEと開発の初期段階で行動を共にする事も多い役回りとなります。
前述のアーキテクトとデザイナーがタッグを組むと、お客さんへの印象がかなり変わった物となり重要なポジションです。

デザインのワイヤーフレーム設計や、カラーコーディネートも行います。
これはWEBでも、OS-Nativeなシステムでも同じです。
ユニバーサルデザインなども知識も必要です。
現在のエンドユーザはネットで優れたデザインに慣れ親しんでいるので必須です。
デザインのポリシーなどの策定も行います。
業種によっては上と反しますが、とにかく入力効率重視（職場独自）と言う事もあります。
その際は要件によってはWEB→OS-Native等の変更も視野に入れる場合もあります。
（実際ありましたブラウザのレスポンスだと遅いと…）
ペルソナの作成を行います。
これはエンドユーザと直接話す必要もありコミニュケーション能力も問われます。
特に業務システムの場合は使用者がかなり高齢の管理者であることもあり、不用意にフォントが小さいシステムでデザイン考え直せとなったこともあります。

プログラマー

ここでお待ちかね、プログラマーの登場です。
SEの設計したものを、
アーキテクトの策定した、環境、ルールに従って、
デザイナーの設計した、デザインを踏襲し、
プログラムを作り上げます。

でもちょっと待ってください。
私は同じプログラムをする人でも、プログラマーとコーダーに分けて考えています。
コーダーについては後述しますが、簡単に言えばそのプロジェクトにおいて

置き換えがきかないのがプログラマー
置き換えがきくのがコーダー

と定義しています。
何故なら、プログラマーはプロジェクトの中でアンテナの張り方がコーダーとは異なるからです。

ここだけは、プログラマーに向けて話した内容なのでべきろんで語ってしまいますがお許しください。

SEの作った設計書を理解できるスキルを持たなければならない。
- 良く「それは設計書に書いていないので出来ません」と言うメンバーがいるが、それはプログラマーではない。
  その主張をする人の多くは、設計書をちゃんと読み込めば自ずと答えが出る物なのに、ずばりこうしなさいと言う指示を求めていることが多い。
  ※もちろん、基本設計書にちゃんと記述されているのにと言う事が前提ね
- こんな実例をもとに話しました。
  「あるプロジェクトの基本設計書は約2,000ページの設計書です。
  でも、そのページ数でもシステムに必要な最低限の約束事しか書けません。
  もし、みんなの主張するレベルで設計書を書いたとしたら、多分その10倍のページ数になります。
  20,000ページ及ぶ設計書を作ったとしてちゃんと読んでくれる？
  今の設計書でさえ全てには目を通していないメンバーが多いのに、読めないんじゃないかな。
  それに、そのレベルになると「こう作れ」というレベルまで要求されるけどそんな窮屈なルールの中でプログラミングしたい？」
- SEはこのシステムがどのような業務を想定したのか、何故必要なのかを設計書に記載します。
  その部分を理解せずに進めると、当然その業務を知っていれば防げる不具合に気がつくことも出来ません。
- 無論、上の二つの主張はSEが然るべき精度で設計を行っていることが前提です。
プログラマーは詳細設計（実装設計）を行います。
SEが作った設計をシステムとして実現するための設計です。
むしろ、SEが作りにまで影響する設計を出してきた場合は「うるせぇ！」と突き返してください。
単体試験を計画し、試験を実施します。
俗に言うブラックボックス試験は、プログラマー以外には行えません。
テスターは、結合試験や総合試験で登場します。
また、試験の基準策定や、結果の確認なども行う必要があります。
アーキテクトの指定した環境での開発を行います。
何故、アーキテクトはこの環境を選んだのか、どういう構成で考えているのかを理解しなければなりません。
デザイナーの設計したデザインポリシーで開発を行います。
何故、デザイナーはこの方針にしたのか、どういうペルソナを想定したのかを理解しなければなりません。
開発作業ルールの策定を行います。
毎回行うことはないでしょうか、プログラミンの方針立てはプログラマーしか出来ません。
これはコーディングルールだけに留まりません。
バージョン管理を行っていればそのコミットのルール等も含まれます。
コーダーのソースレビューを行います。
プログラマーは他の人のソースも基準に則っているか確認をする必要があります。

細かい作業はまだありますが、コードを書くだけではなく全方向にアンテナを張りながら作業を進めているのが分かると思います。
コードを書くだけがプログラマーの仕事ではないからです。
だから、私はプログラマーを尊敬します。

ただ、上記の全てを一人で行うのは難しいので、今度は役割の分担ではなく、作業の分担を複数人でするわけです。
なので、一人ではプログラマーの要件が満たせなくても、複数人でプログラマーの仕事をする事は出来ます。
このプログラマーグループに入った時点で総体としてのプログラマーなので、プロジェクトから抜けてもらっては困ります。
置き換えがきかないメンバーになります。
置き換えがきかないとは、こういったアンテナがなくなってしまうと途端に開発が混沌におちいるからなのです。

コーダー

コーダーは読んで字のごとく、言われたとおりのコードを書く人です。
ルールはプログラマーが作るのでそのルールに則って作業を進める必要があります。
基本的には詳細設計書などの指示書と、ルールブックで作業を行うことになります。

どうだろう、みんながプログラマーの仕事だと思っていたことは実はコーダーでしかなかったと言う事は無いだろうか。

もし、そのルールに不満があるのであれば、迷わずプログラマーになる事です。
但し、プログラマーは考えなしにコーダーに仕事を振っているわけではありません、上記のプログラマーの作業を統合してルールを作成します。
いきなり全ては出来なくても、一つ一つ意識して作業をすることで、知らず知らずのうちにプログラマーになれるはずです。

品質管理

システムの品質を担保する為に、様々な確度から品質をチェックする人です。
場合によっては、品質管理部隊がテスターとなって、結合試験や、総合試験なども行います。
品質の担保とは、プログラムのチェックだけではありません。
必要に応じて、試験計画の作成や、ドキュメントの整合性の確認（結合試験や総合試験をする際に必然的に整合性がチェックされます）
プログラマーとは違った観点でチェックを行う人達です。
また、お客さんによっては品質管理報告書の提出を求められる場合もあり、そういった資料作成なども行います。

よく品質管理部隊を敵視するプログラマーもいますが、彼らは敵ではありません。
プログラマーが一番仲良くすべき人達です。
そして、システムの問題点に一番精通している人でもあるので、開発当初に巻き込んでおくと様々なメリットがあります。

なぜなら彼らは様々な問題のケーススタディを行っています。
そのため、事前の計画段階から問題になりそうな工程の勘が働くのです。

さいごに

開発と一言で言っても、いろいろな役割があります。
役割なので、それぞれの役割をさらに複数人で作業分担することもありますし、複数の役割を一人で行う場合もあります。
ただ、プログラマーとして作業していると言うときに、どの役割までアンテナを張って作業をしているのかを考えてみることは大事です。
それがコーダーであれば最初にあげた画像の1/10にも満たない面積の中でしか仕事をしていないことになり
全方向にアンテナを張れるプログラマーは、その守備範囲がSEを含めた開発部隊全てを意識しながら作業が出来る人になります。
※だからと言って、プログラマーが全部作業をするわけではない。

まず知って欲しいことは、プログラマーだけではシステム開発は始まらないと言うことでした。

次回からは、プログラマーの役割ではなく、今回の役割が何故プログラマーがアンテナを張らなければならないのかを投稿します。