全体感の把握を行うために

アーキテクトとしてソフトウェア開発プロジェクトに関わっていると,各人の作業が本格的になるに従って,成果物のレビューを行う機会が増えてくる。今までの経験上,設計を行う実際の作業者や,実際にプログラムを行うプログラマの成果物は,洞察力が足りないために,多くの状況に対応できない内容であることが多い。本当は設計やおよびプログラマを信用したいところだが,どうしても「成果物にはミスがあって当然だ」という基本概念の下にこっちも考えざるを得ない。 多くの場合,各担当者はリーダークラスの役割を持つ人間にタスクを振ってもらうことで仕事が発生する。しかし,それでは各担当者が満足せず,達成感も感じることができないということが分かってきた。つまり,ある分野の中でやらなければならないタスクの全体量を,各担当者にまで共有することが必要になってくる。更に,各担当者へのタスクの割り振りや,作業時間の見積もりに関しても,チーム単位で決めてもらうことが,達成感の獲得の必須項目である。これは,まさしくアジャイルであり,スクラムである。 要は,各チームに仕事の進め方を決めてもらうことになるので,その内容をプロマネやアーキテクト,進捗管理者が見ることができなければならない。今までだと,トップダウンでタスクを配分することになるので,末端の担当者になればなるほど,全体を把握することができなくなる。しかし,上記のようなやり方をとれば,まずはタスク全体が各チームに大きなまとまりで配分されるので,タスクの量の全体感を知る人間が多くなる。その結果,各担当者が「次に何をすればいいか」を考えられるようになる。 「次に何をすればいいか」ということが分かるようになった担当者は,アーキテクトからすると,非常に信頼を置くことができるようになる。担当者は,全体感を持って仕事を行うようになるので,いろいろな共通化や,詳細な部分が全体に及ぼす影響を判断することができるようになり,問題点も見つけやすくなる。そうなればしめたもので,レビュー時の指摘事項もすんなり理解してもらえるようになるし,そもそも初版の品質は驚くほど高いものになる。 実装を行うためには,設計書が必要だ。そして,質の高い設計書を書くためには,質の高いやり方をとらなければならない。上記をまとめてみると,

  • まとまったタスクを担当者自身が見積もることで,全体を知る人間が多くなる。

  • 見積もりが末端から集まってくるため,自然と見える化が進む。

  • 全体を把握することが「次に何をするか」の把握につながるので,初期の段階から洞察力が働き,質が高まる。 もっというと,担当外の分野について,言い換えるとほかの担当者の作業も把握できるようになれば,自分の成果物や仕事の進め方に対して相対的な評価ができるようになるので,より担当者自身が能動的に達成感の獲得のための努力を行うようになると思われる。但し,これは開発者の意識によって差が出てくるので,一概に全員がこのような感じになるとは限らない。担当者にそこまで求めるのも酷なので,多くの場合はレビュアーがコントロールする部分だろう。 さて,こんなような仕事の進め方は,もちろんプロジェクトを管理する人間やレビューなどに携わる人間全員が共通の認識を持っていないといけない。しかし,すごく言い方が難しい。一歩間違えると,「性善説を信じる人間に性悪説を納得させる」くらいの大事になってしまう。コミュニケーション能力,プロジェクト全体を見渡せる眼力が必要だということだろう。 しかし,こういったプロジェクトの作業方針を決定することは,誰の仕事なのだろうか?アーキテクト?プロマネ?チームリーダー?うーん。。。

このエントリーをはてなブックマークに追加

関連記事

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます

Google I/O 2022でのGoogleアシスタント関連のセッション

Remap Organizations feature has been released