最近誰かに「やったほうがいいよ」と伝えた7のこと というスライドがとても良かったので、僕なりに、何故やった方がいいかを書いてみたいと思います。
- 共通言語を決める
- 関連する法令はチェック
- 技術的コミュニケーションを大事にする
- タイムリミット、マイルストーンを設置する
- ドキュメントを作りすぎない
- トラブルを楽しむ
- 無理な時は無理
共通言語を決める
同じ事柄を指しているのに、 サーバとフロントで英単語が違うとか、 MTG会話の中での微妙な使われ方が違うとか。 認識のズレの温床になるので、見つけたら名寄 せする。
ほんとこれ重要。同じ事柄を指す言葉は一つに集約されてないと、必ずトラブルの元になります。エンジニア間のコミュニケーションでもそうですし開発の依頼者(企画だったり顧客だったりでしょう)とエンジニアの間でもそうです。よくドメイン言語などと呼ばれますが、対象のドメインの言葉、つまりサービス開発であれば対象のサービスで使われる用語に統一しておくといいでしょう。
プログラミングという仕事は、設計にせよコーディングにせよ、どの作業段階においても、適切な名前を付けるという行為はきわめて重要です。このひとかたまりはどういう意味を持っていて、どういう名前を付ければ適切に読み解けるのか・理解出来るのか、名前から責務が容易に想像できるのか。プログラミング関連のスキルの50%位は適切な名前とのつきあい方に集約されるでしょう。
関連する法令はチェック
できる事・できない事、制約条件になるので早めに認識しておくべきですね。
技術的コミュニケーションを大事にする
誰が、どの領域を、どれぐらい詳しいのか。 今まで何をやってきて、今後何をしたいのか。 興味のあること、興味が全然ないこと。 各人が持っている知識や経験を チームメンバーで共有できる雰囲気は大事 お互いのレベルがわからないと、 あうんの呼吸が生まれず、一体感が出ない。
これもほんと重要ですね。人をないがしろにする組織だとこれができません。たとえば、相手が興味のあること、ないことを、許容できない、認めることが出来ない人、「べき」論で他人にスキルセットの習得を強要してしまう人がいると、成立しません。
タイムリミット、マイルストーンを設置する
いつまでもズルズルやっちゃう技術調査、 緊急対応はタイムリミットを設定する。 「やってみないとどれぐらいかかるかわかんな いからとりあえずやってみましょう」は やってみる時に必ず期日を設定する。 「この日までに終わってないとリリース延期」 をちゃんとマイルストーンとして置く。
重要ですねほんと。特にリーダーの人はバランス感覚が重要になってきます。あなたの会社でも「全然中身決まってないんだけど、とりあえずやってみよう」で始まって終わらないプロジェクトありませんか？特にこれは「決める人」がいない時に顕著になります。「やめる、やめないの判断ができる人」ですね。まぁここらへんは立場によって出来る事がかわってきますが、総じてそういう状況下だとグダグダになってしまうので、タイムリミット、マイルストーン的なものは全員が意識した方がいいでしょう。
ここで重要なポイントとしては、四つの要素を意識しましょう。
- 時間
- 予算
- 品質
- スコープ
今回、時間を固定にするというやり方だし(予算はそうそういじれないだろうから)、残る要素としては品質とスコープです。スコープというのは「どこまでの機能・要件を実装するか」です。
四つの要素全部が固定されていると、待っているのはデスマーチです。時間が決まってるんだからその範囲でできる事をしましょう。あなたの組織がメンバーに残業を強要しないことを願っています。
ドキュメントを作りすぎない
本当にこれも重要ですね。ドキュメントがあるとそれを真実だと見なして皆行動するはずです。この時、ドキュメントと実際のコードに乖離があると混乱を招くことになります。ドキュメントが全く無い状態も辛いですが、作り込まれた嘘のドキュメントがあっても混乱を招くだけです。凝ったドキュメントはとにかくメンテナンスコストが増大してしまう原因です。なるべくDRY原則を守ったうえでうまくメンテナンスできる方法のバランスを見極めましょう。
トラブルを楽しむ
たぶん大事です。僕は胃の痛い思いばかりしてきましたが、時にはテンションがあがる感覚があるのも確かです。
トラブルは起こしちゃダメだけど、 起きちゃったものはしょうがない
ほんとこれ。
少なくとも過失であった場合にはメンバーが責められない、萎縮させない環境は必要でしょう。
無理な時は無理
全くもってその通りです。無理な時は無理なんです！！！！！！！！！！
無理を通し続けると僕のように長い冬休みを取る事になるので注意しましょう。