代表ブログBlog

システムチームを構築中

シナジーデザインでは、10年以上に渡りシステムを作っています。

一番最初は自分が作った、簡易的なQRコードをブログに張り付けるプログラムで、
そこから

・自社のオリジナルブログ
・車検のポータルサイト
・デキテル
・抱きしめ~る

と自社サービスを作ってきました。

ただ、これらはプログラマーが単独でこなした仕事で、チームを組んで開発に当たるということがほとんどありませんでした。

プログラマー3人が同時在籍した時期もあるのですが全員がバラバラに動いていて、同じプログラマー同士でもお互いが何をやっているのかよくわからない、という状態でした。
そうなると、仕事の苦労や成功事例を共有できていないのでいい仕事をしても評価してもらえず、なかなか仕事からやりがいを得にくい環境になっていたと思います。

そこで、いま在籍しているプログラマー3人は全員で同じ業務に当たるチームを構築していこうと動いています。

チームにしたい理由としては

・お互いに評価し合って、仕事のやりがいを得る
・課題を協力して解決して生産性を高める

ということが挙げられます。

チームを作るうえでは、最も重要なのは
・情報を正確に共有すること
と考えています。

言葉の定義があいまいだと情報がしっかり伝わらないので、
これまであいまいに決めていた言葉をしっかりと定義する必要があると感じ、週に1回のミーティングを重ねて定義していっています。

今回はその中で定義したものを、さらにまとめなおしたので、共有する意味で記事にしたいと思います。

今回定義するのは

要望

要件

仕様

そして
見積り

の4つについてです。

システムを作っていくうえでこの3つの言葉の定義があいまいだと、しっかりと話し込むことが出来ずに不明瞭な部分が残ってしまいます。
不明瞭な部分はエラーや不具合につながるので、しっかりとシステムを作るためにはこのあたりを明確にする必要があります。

このあたりを情報整理の基本である
5W
1H
を使って整理したいと思います。

要望 What?
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
相手の欲しいものは何か?

を制作者が明確にしたものです。
デキテルの場合はお客様からの要望や社内の問題定義からスタートすることが多いのですが、相手の言葉をそのまま受け止めるのではなく、常に「問題の本質は何か?」という目線で考える必要があります。

そのためにヒアリングを行いますが、情報をしっかり聞き出すと同時に曖昧な部分を潰し、問題や課題を明確にしていく必要があります。
現在のプログラムチームのリーダーがよく使っている言葉は「最終的に何をしたいんですかね?」というものです。
自分の望んでいるものを言葉にするのはかなり難しい作業です。システムの内容を把握していなければなおさらです。
ヒアリングで得た情報を元に、論理的思考能力で要望の本質を見つけ出すのもプログラマーの重要な仕事です。

お客様がおっしゃっているのはA、
だからBになるから
当然にCが問題の本質だ

といった形でしょうか。

お客さまや社内の欲しいものをプログラマ―が明確にしたものを要望と言います。
明確になっていない、「フワフワしたもの」は要望とは呼ばないので、明確にして要望化してください。

システム要件 HOW?
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
要望をどうやってシステムで解決するのか?
どう作るのか?
いくつのパターンが存在するか?
を考え、作り方を比較して戦わせながら最適な方法を明確にする、のがシステム要件です。

仕様 Where?
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
システムのどこを、どう触って実現するのか?
を具体的に記したものです。

どこに何をどのように、変更や追加をするのかを
具体的な方法として記述する必要があるので、
テーブル構造やメソッドを把握していないとできない仕事になります。

必要な知識としては
・テーブル構造
・システム全体の知識
となります。

仕様を作るにあたっては、3つの時間軸を持つことが重要です。
3つの時間軸とは当然ですが
過去
現在
未来

です。

・過去
過去に作った他の機能に影響が出ないように作る

・現在
要望を要件として定義し、それを満たす仕様を作り、それをもとにコーディングを行う

・未来
将来の保守性や機能拡張に耐えうるシステム仕様で作る

見積り When
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
仕様通りに頭の中で作ったらどの程度の時間がかかるか?
を記載したものです。
ざっくりと曖昧に出すのは見積もりではありません。

いったん、頭の中で作ってそれの時間を測定するイメージです。
見積りにも曖昧さを無くし明確にする意識が非常に大切です。

担当者 Who
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
後は誰が担当するかを決定して、実際に作業に入ります。

曖昧になりがちな言葉を定義してみました。
他にも曖昧な言葉はどんどん定義していこうと思います。

メモ
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ポイント制
 タスクにポイントを付ける
 その週にこなすタスクを自分で選ぶ
 週末に出来たかを確認する
 アウトプット量を客観視できる
 3人で60ポイントを1週間で実現できるようになっていきたいと思います。

デキテルはお試しいただけましたか?

デキテルバナー 「デキテル」を利用すると1分ほどで御社のホームページが作成できます。
お試し作成が無料となっておりますのでぜひお試しください。
デキテルHPへ

このページの上部へ戻る