webエンジニアなのに社内のIT全般統制勉強会に参加してきたよ！

「IT全般統制って大変。。。。」
「この時期本当にやだ。。。」

この時期になるとなざか聞くことが多くなる

IT全般統制

という言葉。

自分には関係ないと思っていましたが、 社内向けに勉強会が開催されていたので、

「何か手伝えることないかな？」
「普段意識しないといけないことってなんだろう？」

という疑問を解決するべく、 社内のIT全般統制勉強会に参加してきました！

参加してきたメモは以下のとおり！

参加理由：

開発には全く触れない部分

財務諸表が超大事！

• 　→　世間に公開する責務
• 　→　上場すると責務、未上場だと任意
• 　→　正しさが大事

請求プロセス & 原価プロセスって？

• 　→　会計関係システム & 勤怠関係システム
  

フロー

計画(規定・マニュアル)
運用(レビュー・承認)
監査(エビデンス)

各規定項のエビデンスを収集・確認するのが超大変

エビデンスの参考例

• 社内サーバールームの入退室記録
  

Git Hub・メールでもいいので、レビュー・承認を残すのは監査にやさしい、監査は嬉しい

• 　→監査はプルリク、マージ大事

• 　→一番ダメなのは口頭確認。エビデンスが残らない。
  

既存システムから請求書を発行するようになったらそれはIT全般統制の対象

• 　→[質問]広告掲載やユーザー課金、広告課金は対象？

• 　　→課金額で対象なるならないが変わる。
  

その他

グループ企業が連結のインパクトが大きいと、 グループ企業にも内部統制のプロセスが必要になる場合がある。

僕はこう思ったよ！

IT統制の最も辛いのはエビデンス取りというのが意外だった。 Web業界ってエビデンスよりも成果、フローよりアウトプットとなりがちなのでこのあたりは 意識していきたい！ でも、それ専用の企業やSIerや開発ってのはやりたくないなー。。。

エンジニアなのに社内のディレクション勉強会に参加してきたよ！

今回、弊社で行っていた

作業を分解してスケジュールを立てるというディレクション業務を覚える

という目的を持った社内のディレクション勉強会に参加してきました！

以下、その時のメモ内容になります！

目的をあきらかにする

• 本質的な問題点がどこにあるかを考える
• 言われたことが本当に適切か
• 達成後に会社の利益につながるか

成果について

• 成果は必ず先に決めておく
• 守るべき品質、コスト、スケジュールが達成できたか。
• 成果は達成判断が可能な状態か？

醍醐味

• 理想と現実のギャップに悩みながらそこから最大限の成果を実現する

作業プランの作成

①作業を分解(WBS
②作業の順番を決める(作業フロー図)
③スケジュールを決める(作業工程表)

①作業行程の抜け漏れが無い事が前提

図として可視化することで抜け漏れのチェックと第三者によるレビューが容易

tips

• 一つ一つの作業をシンプルで確実に行えるサイズまでに分解
• 必ず第三者の有識者レビューを行うこと

②①を前提に一つ一つ掛かる時間を見積もって流れを明確にする

そうすることで、クリティカルパスの明確化による最短工数が見積もれる

tips

• 作業時間が見積もれない場合は更に細かく
• 作業時間が一週間を超える場合は作業がうまく分解できていない可能性がある

③作業の難易度、負荷状況から作業行程表を作る

その際、事業部長にはより抽象化して提案することで認識の齟齬が回避出来る

tips * この時点で作業スケジュールが立てられない場合は本質的に作業が分解出来ていないことが原因。

注意

• そもそもの目的が見誤っていると上記の工程および、スケジュールは破綻する

ワークショップ

お題： 新年会やろう！

• 会場の予約
• 資金
• 出し物
• 当日の役割

の4つの大枠の中でタスクの洗い出しと工数見積もり、スケジュール図を作成するというもの。

ワークショップの目的

実務にいきなり取り入れだけでなくまた、今回の講義内容を知識として覚えるのではなく 自分で体験して「難しい点」や「自分の中でのクセ」に気付いてもらい、 より実務にイメージしやすいようにすることが目的

実際は。。。

• 実際の作業プラン作成は難しい
• 前提となる知識が不足している
• 人が絡むので思うようにいかない

その他

• PMBOKおすすめ

• プロジェクト管理者の道具箱というサイトがおすすめ

• 論理的に物事を考える力がディレクションには必要

• 思い込みを捨てて考えるがディレクションには必要

本質をとらえる設問の仕方とは

×残業を減らすには？

• 　→×業務時間内の生産性を向上させる→短絡的な回答

• 　→×余分な会議を減らして作業に集中する→短絡的な回答

○必要な仕事量に合っているか？ ○本当に必要な作業はこれで本当にあっているか？

質疑応答

仕様変更、要件変更ってどうしても発生しちゃう。
⇒バッファを設ける
⇒コミュニケーション頻度をあげる

仕様やタスクがめちゃくちゃ多い。これを実現するにはリリースが先延ばしになっちゃう。。。
⇒品質を落とさずに必要なリソースの再考、機能要件の最小化の実現を最優先にした方が良い。

僕はこう思ったよ！

説明内容も丁寧だったので理解しやすく、知っているではなく使える知識だったなーと感じました！ またこのような講座はエンジニア、ディレクター、デザイナーに限らず新卒研修、インターン研修に 取り入れるとより質の高いアウトプットが生まれるのではないかと感じました！ そして何よりwebエンジニアがこのあたりを意識するだけで全然作業の進捗が変わってくるなと。。。 少しずつ自分も覚えていって「ディレクションも分かるエンジニア」、「コードが書けるディレクター」を少しずつ 増やせるように勉強会が開けることを目指します！