3月8日、株式会社ゴルフダイジェスト・オンラインの清水様、ワタベウェディング株式会社の石毛様が発起人となり新たなスタイルのユーザー交流会が開催されました。
今回は清水様、石毛様の発案で、最初からテーブルにドリンクをご用意。アルコールが潤滑油となり普段のユーザー会では聞けない本音トークが飛び交う貴重なユーザー交流の場となりました。
各講演レポート
GDOの内製化・外注事例の紹介
株式会社ゴルフダイジェスト・オンライン
TECビジネスユニット システム開発担当 シニアプロジェクトマネージャー 清水 正朗 様
「いきなりディスカッションしましょうと言っても難しいと思いますので、最初に私からGDOのケースをお話しします。」と清水様より以下のような内容について実事例を交えてお話しをいただきました。
清水様が考える内製化の条件
- スケジュールに余裕があること
- 連携構成が正しく把握できること
- 開発環境が社内で用意できること
- ビジネスへの影響度が低いこと
注力していること
- 社員による外注コントロール
- アンチパターンの蓄積
- ドキュメントの整備
- 他のユーザーやアステリア社員との関係性を積極的に構築し、各社とノウハウを交換
事例紹介およびディスカッション
株式会社ワタベウェディング システム統括部 システム企画開発グループ 係長 石毛 信次 様
続いて株式会社ワタベウェディングの石毛様より自由に開発させたことで起きた失敗事例などをご紹介いただきました。またいくつかの課題提起をいただき、その後参加者全員でディスカッションをしました。
Q. 外注と内製の線引きをどのようにしてますか？（石毛様）
- 会計連携などクリティカルなものは外注。お手軽ツールや業務アプリの連携は融通を利かすため内製。
- SAPやパッケージ製品など相手先の仕様を社員が理解していない場合には外注。仕様がわかれば社員がやった方が早いので内製化。
- 手を出すと”やばい”と思うことは外注。「やばい」「やばくない」は長年の経験による勘。
- 原則内製化。外注するのはリソースが足りない場合だけ。外注する際にも設計書のレビューは必ず社員が実施。
Q. 内製の場合、開発者は社員？業務委託？（石毛様）
- 委託の場合でも、未経験者の教育は比較的容易。
- 業務内容と密接にかかわる部分が多い。修正頻度から考えても可能であれば社員の方がいいのでは。
- ASTERIA Warpの開発を最初社員はやりたがらなった。常駐している外注者が開発したものの成果が出てから社員も開発し始めた。
Q. ドキュメントはどこまで整備してますか？（参加者）
- フロー実行スケジュール表を作っている。平常時は大変だが何かあったとき再起動してよい時間帯がわかる。
- 仕様の左側には連携元、右側には連携先、何と何の連携をしたいか。何をしているのか、主管部門はどこか。このドキュメントが揃っていないとシステム部門がリリースしない。システム部門がここに対して強権を発動できないとだめ。
- 仕様書以外に開発意図がわかる企画書を作成している。サブバージョンにもコメントを記載し始めた。
Q. 社内開発ルールはどのように整備してますか？（石毛様）
- フォルダの作り方、エラー処理は共通ルールを作成しないと厳しいのでは。
- ASTERIA Warpの良さはフットワークの軽さなのであまりルールを厳格にしすぎてもいけない。
- ルールの必要性はその開発のクリティカルレベルや利用機能による。
- どの開発でどこまでルール化が必要かは人に頼らざるを得ない。この開発は”やばい”と思ったら厳格にルール化する。
- つなぐシステムによってルールを決める。
- フローの検証は業務を理解している人と品質保証（チーム？）の両者で行うルールを運用している。
- 設計指針・開発指針をドキュメント化するルールを設けている。
などが話し合われました。
参加者からは次のようなコメントをいただきました。
- 生の事例、問題点知ることができてよかった(リポジトリ管理、コード規約など)。
- 知らないことが、毎々あるのかなと…いいおみやげができました。
- ユーザー間で交流することはあまりないので他社の話が知れてよかった。
編集後記
ユーザー交流会終了後も１時間以上、同会場での個別の会話が続きました。さらに一部の方はその後場所を変えて深夜まで続きをされていたとの噂も・・・（^^）。
清水様、石毛様、参加者の皆様、大変有意義なディスカッションを実現いただきありがとうございました。
