システムエンジニアから見た自社開発で大切にすべきコミュニケーション

ファブリカコミュニケーションズは自社開発の会社です。
当社の開発で求められるのは「開発スピード」そして「品質」。さまざまなアイディアが出され、今までにないサービスをいち早く提供していくことをビジョンにかかげ、スピーディな意思決定されています。そんななか開発も、いかに早く品質のいいものを提供できるかが重要になっていきます。

システムエンジニアは、企画担当者、プログラマー、インフラ等いろいろな人達と連携して作業を進めていきますが、「開発スピード」と「品質」を担保するためには、チームのコミュニケーションをシステムエンジニアがサポートするべきだと考えています。
今回はシステムエンジニアが大切にすべきコミュニケーションについて書きます。

ヒヤリング&提案

まずは現状課題についてヒアリングを行い、影響範囲や実現性、工数をベースに企画者と共に要求を整えていきます。また、実施することが適正なのかもその際に確認します。

単に「出来る」「出来ない」という機械的な回答ではなく、課題感や優先度など状況に応じて判断してもらいやすいように、下記のような提案型の回答を心がけています。

例：一般ユーザーの質問に専門家が回答するQ&Aサイトの開発
＜松案＞
フル機能（Q&Aシステム、ランキング機能）     工数：60人日
＜竹案＞
主要導線のみ（Q&Aシステム） 工数：45人日
＜梅案＞
一部機能（Q&A静的ページ）     工数：5人日

設計書を書く前の情報整理

ファブリカは自社サービス開発が主なので、既存システムの改修があります。

当社で開発しているサービスの１つ「symphony」は、中古車ビジネスの総合プラットフォームとして顧客・販売管理、在庫管理システムと連動したマルチ広告出稿システム、『ヤフオク！』および『Yahoo!ショッピング』への出品システム、中古車輸出連携、社内グループウエアなど多彩なサービスを提供するシステムです。

そのような大規模なシステムの場合、影響範囲や設計の方向性等、考慮しないといけないことが多々あるため、設計前に改修箇所以外も含めた全体概要図的な資料を作成します。

その資料をたたき台に関係者を集めレビュー会を実施し、考慮が漏れていないかや、他システムとの関連性、設計上のリスクなど、様々な意見を伺い、システムに対する全体的なイメージを具体化していきます。

事前レビュー会→設計→設計書レビュー
という流れでコミュニケーションをとって進めるとこで、設計完了後の修正の手戻りや、開発工程での課題・問題発生リスクは少なくなります。

開発スピードに応じた情報整理

また必ずヒアリング時に「MUST要件」「WANT要件」の分類分けを行っています。流動的に変わる世の中に対応するため、自社サービス開発において「要望の優先順位づけ」はとても大切なことです。

要望の中でメインとなる機能、サブ的にあったら良い機能を、「企画者」やスケジュールや品質管理を担う「ディレクター」が把握することで様々な状況に応じた取捨選択が可能となります。

設計時の背景を含めてプログラマにインプット

既存システムの改修の場合、設計時にソースを確認し、内容の把握と修正方法まで検討します。プログラマの作業時の不安を減らすため、該当箇所に限らず、気になったことや懸念点、注意事項などなど、より多くの情報をインプットするように心がけています。

また、設計の根拠を伝えることで開発時にプログラマが判断しなければいけない場合に解決方法目処がつけやすくなるため、「開発スピード」の向上にもつながります。

まとめ

われわれはシステムではなく「コミュニケーション」を作っています。より良いコミュニケーションを作るためには、チームが一つの方向を目指し、まとまらなければいけません。

当社の「設計」を担当するシステムエンジニアは、特に「コミュニケーション」を大切にすべきだと、私は考えています。