ご無沙汰しています。
鵜野です。
豆蔵デベロッパーサイトアドベントカレンダー2023第8日目の記事です。

豆蔵は ITコンサルなので業務委託のイメージが強いと思いますが、私のチームでは請負開発もやっています。
いま作っているシステムは稼働して数年たち、今ではDevOpsのような改善活動がメインになっていますが、それでも未知の要求、課題など発生したら、開発メンバと議論出しながら課題や解決方法などを議論および提案しながらプロジェクトを進めています。
豆蔵では、契約形態がどうだから、どう活動する・・・といった違い(※1)はありませんが、円滑に活動できるのも優秀なチームがあってこそだと思っています。

プロジェクト遂行においては強力なチームが必要不可欠だと思っていますが、プロジェクトが始まったときからそのような人達が揃っている状態でスタートできるケースは稀だと思ってます。

• 初めて一緒に仕事する人のためよくわからない
• パートナー含めどのような技術力を持った人なのか情報がない
• 途中でメンバ交代がある

さらに、プロジェクトを成功に導くのに欠かせないのは、自分達のチームだけでなく、クライアント側のチーム構成や先方の事情、能力なども関係してきます。

もちろん、ソフトウェアエンジニアリングは各工程で必要なものではありますが、プロジェクトでは関与してる人達が毎回異なるので、採用技術、開発プロセス、管理プロセスなどを書籍などから学習しても、その通りにならないことのほうがほとんどです。

今回は上記のような難しい生き物（＝プロジェクト）を扱うにあたり、私なりに普段から心がけていることを記事にしたいと思っています。

• 最も心がけていることは、プロジェクトに参画している各人がモチベーション高く活動できているか？これに尽きます。
• 出来上がった製品の良し悪しは使ってもらってお客様が判断することだと思いますが、その製品品質を高めるのは、作っている人たちのやる気が左右しているのだと思っています。

• がんばったら休むでもよし、やる気がでなくなったから休むでもよし。
• 各々がモチベーションを維持する為の休みを推奨しています。

• 挨拶することすらモチベーションが下がるほど話すが苦手な方以外はやっています。特にリモート開発でやっていると特に、自宅で一人ぼっちで作業しているのは寂しいので、「おはようございます」「お疲れ様です」「ありがとう」「ごめんなさい」「お疲れ様でした」と声を聞くだけも一緒にやっている感がでると思っています。
• 社会人として当たり前なことを書いているだけなのかも知れませんが、よい人間関係を築くにはやっぱり大事だなぁとしみじみ感じてます。

• いわゆる業務フローを書いて、人、もの、金、情報の流れなどを表現します。
  • 地道な活動が必要だったりしますが、実際にシステムを作る上では最も重要なInputだと思っています。
  • これがないと、相手と「ここの中は何している？」とか言えないので、「ここ」指し示せる共有の図が必要だと思っています。
• 動的な図が書けたら、静的な図を書いてます。業務フローには様々なオブジェクトが登場してきますので、それが何なのか、用語集としてまとめられるようにオブジェクト同士の関係図を作ります。こちらも業務フロー同様、「これ」を指し示せる共有の図として役に立ちます。ゆくゆくはこれがデータモデルに繋がってくるのでとても重要な情報になります。
  • ここで、「誰が作り、誰が更新し、誰が消すのか」がわからないオブジェクトが出ていた場合は、多分業務フローのヒアリングが足りてないので、ここを突っ込んでお客様に確認したりしてます。
    • ちなみに業務フローを書いている段階では、よくありがちです。いわゆる業務システムではマスター情報を扱ってトランザクション機能の処理分岐とかすることが多いと思いますが、そのマスター情報は誰が最初に作るのかとかわかってないことが結構あります。

• 業務を理解した上で、じゃあ何を望むの？を理解します。なぜそれが必要なのか、どういうゴールとなるのがよいのか、関係者各位の方向性をよく理解するようにしています。
  • よく間違うこととしてはいきなりシステムに対する要求を聞こうとすること。これは誤りで、システムにに改善を求めているというより、いま運用している業務をより良くしたいというのがお客様側の本音なのがほとんどです。
  • そのため、背景を理解して、いまの辛さも理解し、なるべく根本解決するための情報を引き出します。
    • なるべくと言っているのは、使っているものが外部サービスやプロダクト製品だったりで手を加えることができない領域だったりするので、どうしても無理なものは生じてきます。
• 理解が足りなければ、相槌を打たず、深く突っ込んで確認する。ここは恥ずかしがる必要ないです。知らないものは知らないので、「教えてください」と強引にでも巻き込むようにしてます。

• サブリーダーや末端の技術者といった役割別に情報を分けたりせず、なるべくフィルターをかけず嘘偽りなく伝えるようにしています。理不尽なこと、嫌なことも共有します。
  • 人と人との関係ですので、クライアントのたまに出てくるイヤな人に理不尽なことも言われたり、好き勝手に心無いことを言われたりと、こういうシーンもなきにしもあらずです。こういうことも包み隠さず共有します。
• 逆に、こちらの不都合（当初見積もりが甘く、全然終わらなかった）なども稀に発生したりもしますが、これも素直に謝って正確に報告するようにしています。

• 目的、背景、がわかった上で、アーキテクチャや各種プロジェクトで用意したコンポーネント等の部品などの理解が進めば基本的には組み合わせてものづくりはできると思っていますので、細かく詳細設計ドキュメント等作ったり、指示したりせずとも皆さんのちからで実装できると思っています。
  • 口頭ベースで済むときもあれば、外部サービスと絡み合うサービス、共通的なコンポーネントなどが必要となってくる・・・といった場合は、モデルなどを使いながらクラス構造などを共有した上で作業するなども必要に応じて実施します。
• 私も昔はSIerと「詳細設計」という名のもと、大量に無意味な資料を作らされたりもありましたが、やっぱりムダなことはしたくないと考える人のほうが多いと思いますし、むしろ、ここが各技術者の一番自由度が高く、楽しい部分だと思っています。

• 上記のおまかせの部分とも関係しますが、やはり技術力は各々で異なりますので、あるメンバは理解できても、あるメンバには伝わってないということもしばしばあります。このときいつも誰かが教えるのではなく、みんなでサポートし、みんなで成長する感覚で対応します。

• 細かく指示せず作業は各人におまかせするので、その人がこれから作る機能はどのぐらいかかるか？は、本人が宣言します。
  • 作業者によっては、1週間と宣言して、そのうち1日ぐらいバッファとして見ているかもしれません。
  • または、7日かかると思っているものを、無理に1週間としているのかもしれません。
  • 管理している自分は、自分ならこれぐらいかかるだろうを予測していますので、ここで自分の感覚と大きくズレがあれば、議論する場合はもちろんありますが、本人にまかせて信じますので、1週間でできると言われれば、完了まで1週間と予定するようにしてます。
  • もちろんここで決まった期日は、ステコミやお客様との進捗報告などでもストレートに伝えるようにしています。ここも透明性ですね。

• 以前あるCMで「この惑星の住人は、締め切りがこないとがんばれない」と話していました。昔からこれは本当に思っていました。
  • 夏休みの宿題は、8/31 までに終わればよい　→　頑張るのは、夏休み終わるギリギリになってしまう
  • これを避ける為に、1週間と宣言された工数の内訳としては、2日目に設計内容等を共有しましょうか、4日目に検証機にリリースしましょうね　とかを共有します。身近な中間リミットがあることで適度な頑張りどころが生まれます。

なんだか文書だらけになってしまいました。
自分自身もまだまだ学習して成長してゆく必要がある身ですが、ソフトウェア開発プロジェクトに携わっている方々に少しでもお役に立てば嬉しいです。
ここんところもっと詳しく！とか要望がでたらまた書きたいと思います。