とあるエンジニアが
「これってどうやってリリースするの? あんま、わからないのでよろしく!」
(私の担当じゃないので、深堀りもしたくないし、チームとして知っておいた方がいいのはわかるけど仕事増えるし。
なのでよろしく!)
というチームがあった時、問題はありますか?どのよに解決しますか?
1.問題はありません
2,問題は、リリースどうやってって言っているメンバーがいることです!誰でもできてしかるべきじゃないか!?
3、問題は、リリースの手順がマニュアル化されていないことです。
4,問題は、リリースが自動がされていないことです。
というように、組織や個人によって、チームの構成・役割分担によって問題の角度はは様々だと思います。
私は、
リリースはメインなコンポーネントであれば、SPFをなくすべきで最低でも2人はリリースが可能であるべき
と考えます。その上でリリースどうやってやるの?はこのひとがリリースをしっていて然るべき人材であれば
問題であるのと考えます。更にマニュアルの所在や質、あと周知度など確認するてんは沢山あると思います。
しかし
重要なのは、予めリリースできるメンバーを定義しておくこと。そして、
そのメンバーは確実にリリース作業ができるようになっておくこと
が大事だと思います。
そのための時間は咲くべきだし、ドキュメントなども適宜、準備・説明がされていることが期待される。
次の問題、
ドキュメントをつくってハイ終わりではない。
きちっと叱るべきオーディエンスに伝えなければならない。この時は
一方方向の伝え方ではなく、肝心なのはオーディエンスが自分でその作業を実際やってみることだ。
リーダーは
それをシッカリ確認することができる仕組か監視をするべきである。
ドキュメントの陳腐化について。
ドキュメントって直ぐに古くなる
最新の情報でないところが点在してくる、ひどい時はほぼほぼ使えない。
ひとつは、ソースコードからドキュメントを生成する。
しかし、これではハイレベルな設計思想がわからない。その部分は別途、ドキュメント化されている
のdが普通だろう。
チーム、組織がどこまでドキュメントを重視しているかによるだろう。
グーグルなんかは設計ドキュメントなしではレビューが通らないほど、会社単位で大事にしている。
ドキュメントがないことのほうが結果的に、もたらす工数はおおいのだろう。
急がば回れ。
かつ、
エンジニアの文章力もつくし、
抜け漏れを見渡せる。
あたらしいメンバーもつっつきやすい。
一石三鳥くらいありそうだ。
欠点はドキュメントをかく時間だろうか?
これは前述の通り、長期的な利点でみれば無視できるだろう
以上です。