tech

ソフトウェア開発にあたっての経験を語る 開発管理編

前回の続きです。今回はウォーターフォールモデルの各工程という観点から離れて、開発全体で必要になる開発管理について考えてみたいと思います。

開発管理について

いろいろな意味がありますが、今回はスケジュール管理について焦点を当てたいと思います。中でも管理人が散々苦しんできたリカバリのためのスケジュール変更と関係者への説明について管理人の経験を記載します。

リカバリのためのスケジュール変更

開発がすべてあらかじめスケジュールされたとおりに完成できることはまずはありません。そして残念なことに計画通りに進まないことはよい方向に働くことはなく悪い方向へ傾きます。そういった場合、当然スケジュールを見直しリカバリを図ることになります。こういったリカバリに備えてスケジュールを立てるときは大概ある程度のバッファを盛り込みます。そしてさらに運が悪い場合、こういったバッファすら食いつぶすことがあります。バッファを食いつぶした後のリカバリがある意味スケジュール管理において真価を試されることとも言えます。
最悪の場合においてのリカバリは、どうするか。多くの場合は検証項目を削減することになります。検証項目をこなすことは品質を担保するために行うことですから、完成品の品質の低下を覚悟する必要があります。どの項目を削るかは優先度にもよりますが、実際に開発対象の内容をよく知っておかないと判断できません。こういった場合にも要求仕様や設計に通じていることが活きてきます。また机上で行う設計と異なり、検証する環境や人員といったリソースを考慮する必要があります。
これまでに説明してきた「リカバリのためのスケジュール変更」を適切に実行するためには、常に開発全体を見通す視点を持つ必要があります。開発の内容はもちろんのこと、環境、人員、そしてお客さんなどの関係者のスケジュールを把握しておくことが重要です。事前に情報を知っておくことで情報収集に時間を割く労力が減り、内容や期限について相手先と交渉する余地ができてきます。スケジュール管理を実施するポイントは自身の範疇にとどまらず状況を把握しようと心がけること、そしてトラブルがいつ起きても対応するための心構えを持つことです。

関係者への説明

トラブルが起きた際に重要なもう一つのことが関係者への説明です。多くはお客さんになると思いますが、身内である開発関係者ともコミュニケーションをとる必要もあります。プログラムの開発や検証に関与していると技術的なスキルだけ持っていればよいという意見も聞きますが、管理する立場においては不十分です。特に規模が大きな開発になるほど、関係者は増えるので技術的なスキルだけでは手詰まりになります。技術者であってもコミュニケーションをとるためのスキルは磨いておくべきです。
コミュニケーションスキルといっても、面白い話をしろなどというわけではなく、ビジネス情報を伝える力が必要となります。開発や検証の進捗管理に関しては下記が特に重要です。

  • 要点を絞って、わかりやすく適切な情報を伝える(図などを用いて専門家でなくて理解しやすい形で表現できればなおのことよい)。不要な情報は省く。
  • 問題が起きた場合は、可能な限り早く報告する。
  • 嘘はつかない。

ビジネスにおける報・連・相と要素は同じですね。特に嘘をつかないことは重要です。以前に問題を小さく見せようとして嘘を関係者に伝えた結果、のちに大炎上した開発を見たことがあります。なるべく早く適切に報告すればその場は紛糾しても大概何とかなります。これもまた経験から言えることなのできちんと共有するようにしましょう。お客さんも含め鬼ばかりではありません。
開発への影響の要因はいろいろあります。自分が原因であったり、他所が原因であったりします。自分がミスしてしまった場合は必ず振り返り対策を講じて二度と過ちを犯さないようにしましょう。お客さんや関係者は鬼ではありませんが、仏でもありません。ミスはよくないことであり、二度としないことが基本です。相手のミスが原因である場合も、責めるばかりでなく適切に叱責したのち貸しを作るつもりで協力しましょう。経験的に開発はそのほうがうまくいきます。「情けは人の為ならず」を後ほど実感できると思います。

あとがき

開発の経験に基づいて、これまで投稿してきましたが、まだまだうまくいかないことばかりです。それでも試行錯誤を重ねて、こうしておけば、という要素を今回の投稿に記載したつもりです。管理人よりさらに上位スキル者はたくさんいらっしゃいますが、そういった先輩方は修羅場を乗り越えた場数が違うので胆力がちがいます。とは言いつつも場数を踏まなければ成長できないというものではないので、すごい人を見つけたらそういった方の管理スキルや行動をぜひ真似してみてください。時にトラブル発生時の考え方を聞いてみるのもよいでしょう。新たな気づきになるし自身の指針として取り入れることもできます。
それでもホッとするのは対象の開発がすべて終わった時です。完了するまではなかなか休日でも休まらないことが多いですね。同じような経験されている方は多いと思います。今回の情報が何かの役に立てば幸いです。

-tech
-, ,