Jのブログ

人生の記録

【読了】オープンオーガニゼーション

読みました。すごくいい本でした。経営者が何に悩みどういうアクションが会社の成果につながったのかが分かりました。また、超トップダウンの企業からボトムアップ企業への転職したCEOなので、そのオープンな組織とのギャップが描かれていました。これまたおもしろい。

一番印象に残ったことは、実力主義な組織ということ。役割関係なく実力あるものが発言力もあるし成果を出しているということ。オープンでフラットな組織がどういうものか、そしてオープンな組織で求められるリーダー力がありのまま書かれていました。とても参考になりました。

内容を思い返すと、「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。」という言葉を思い出す組織だなと。

心に残ったことをメモ

モチベーションと情熱

  • リーダーの役割は、継続的に社員の情熱を掻き立てること
  • 論点がずれていても社員のディスカッションを大切にする。それは必ず主体性につながる。ギブアンドテイクが必要
  • フィードバック自体に価値はないかもしれないが、ちゃんと向き合うことは従業員の主体的な参加を引き出す
  • 悪いニュースは直接の話すのがよい。誠意を持って対応する。
  • 自分の仕事は、背景、課題、ゴールを作るところ
  • アワード、アンケートをポイント制にする。リワード。信頼関係、透明性、実力主義を支える
  • 業務、ブログ、革新の割合決める
  • イデアを、試すのに承認が面倒とかあったりします?
  • 事例化は顧客をヒーローにしたい、という思いから
  • 提案しやすい雰囲気を作る、働きやすい環境
  • 月次で職務技術書を振り返る
  • 強力を得るには困ってることを打ち明ける
  • リーダーは誠実で率直であること
  • 評判を得るには時間と努力が必要
  • 全員がリーダーでありマネージャーであるなど、入社時のオンボーディングに入れる
  • 難易度の高い課題に立ち向かう姿勢
  • 顧客フィードバックを大切にする
  • ディスカッションできる場を作るための勉強する
  • 議論において創造的摩擦というのがある。紛争が破壊よりも創造にながりもっともうまく機能する。ピクサーはこれに従っている。集団的知識と率直な意見を引き出す。
  • 自分が利用したい!というサービスになっているか?
  • 理想主義と現実主義とのギャップをどう埋めるか

実力主義

  • 実力主義とは、自然と非公式のリーダーが生まれ、経営システム全体の鍵を握る。実力を持っている人が決定権の割合が大きくなる。誰かが決めるのではなく自然とそうなるのが実力主義
  • 先駆者の文化を作る(成果高いメンバーをプリンシパルにする
    • 一貫性があって私心がない
    • ずる賢く立ち回るだけだと成果として認められない文化
    • 会社のミッション、目的に積極的にかかわり、目的地達成のため汗を流した人が影響力を持つ
    • ポジティブな実力主義を作る
    • 管理職はエンジニアリング+マーケティングなどの二重の技術を持つ物がより昇進するようにする。これがより実力があるということ。
    • 全員何かしらのスターになってほしいなぁ
    • フィードバックを恐れない、誰でもオープンに発言できる。ただし、批判だけするものは評価されないだろう。批判に加えてアクションを起こしたものが評価される。
    • カスタマーエクスペリエンス&エンゲージ部門がある
    • フラットにしている。自己紹介で副社長という紹介はしない。サポート野郎だという。
    • カジュアルな服装だけではなく、オープンな振る舞いが大切。
    • 多くの企業は、率直な対話が欠如している
    • 経営者がやることは、スタッフからアイデアを引き出し、常に貢献させること
    • フィードバックは贈り物だと捉える
    • 部屋の中の像を避けていないか?どうやったら議論できるか考えよう

意思決定

  • 意思決定に社員を巻き込む、当事者意識が生まれる
  • 自分の考えに意見もらうようにする、どう思う?、一緒に解決策を練ることに価値がある
  • 意思決定に反対する人は少なからずいる。そのとき、命令で無理やり意見を通すのではなく、耳を傾け代案を提示するのがよい。例えば、やってみて失敗したら元に戻すなど。
  • 個人的にもっとファシリテーションの勉強したほうが良い、もう少しオープンに話したい
  • なんだかんだ、最終的な意思決定社員はリーダー
  • 不人気な施策でも、透明性をもって時間をかけて説明することで、計画を進めることができた
  • オープンソースの早く頻繁にリリースを組織の意思決定にも利用する
  • 企業理念をオープンな手法で決めた話。フラットに社員に意見を求める。共感できたし、みんな納得感あるものになる。
  • ミッションやビジョンについて、確信が持てる納得できるまで質問や提案をしてもらう。企業戦略立案の民主化
  • 社員とのコミュニケーションを取るのではなく、関係性を深めるところを重要にしている
  • この意思決定プロセスを顧客ともやっている
  • 欠点は、意思決定に参加したい人は思ったほど多くないということ、グループでの意思決定は時間がかかること、全体へ広げるには徐々にすすめる
  • まずは先駆者メンバーからの意見をもらう
  • 誰かが驚くような意思決定か自問自答し、驚く人がいれば巻き込む
  • リーダーは触媒、海にある杭のようなもの。杭があることで様々な生物が集まる
  • リーダーの役割は課題設定し議論の範囲を定め、ひとをまとめる場を作る力
  • リーダーとしての立場をどう力するか?
  • 直接あって話すことも大切
  • 生焼けでも考えを共有する
  • リーダーの役割は部下たちの感情にリアルに響くメッセージと目的意識を明確に述べる、ポジティブな方向へと動かすこと
  • 製品のパフォーマンスや機能など技術的な利点、使いやすさやドキュメント品質、この次に求められるのは顧客ビジネスを理解することが求められる。成長すればするほど顧客に焦点を当てることが必要かとなる
  • 顧客に耳を傾けることが重要。それによりより強力な製品になる。ただし、最前線のテクノロジーと顧客の要望に応えることはトレードオフの関係。顧客に耳を傾けることは今後の将来において重要だということを説明する。具体的なアクションやチームを作るわけではない、これが生焼けのアイデア
  • 行動を起こすきっかけを作るのがリーダーの仕事
  • 社員全員が課題を正しく理解し、自由な発想で問題解決に取り組めるよう、絶妙なバランスで体制を整える
  • 小さく頻繁にリリースし、早く失敗する、これを組織運営にも取り入れている。成功したプロジェクトは自然と大きくなり、失敗したプロジェクトは終了しメンバーはまた違うプロジェクトへ移っていく
  • 議論する場合を見つけるor作る、課題への質問をする、解決プロセスはあえて曖昧にする、チームにアイデアや提案を求める
  • ボトムアップで緻密な飛行機が作れるか?この問いは、密結合な飛行機、疎結合なソフトウェアの違いに感じた。逆に飛行機を疎結合にできたらボトムアップでも作れそうな
  • 短期的な成果よりも、長期的な成長期を重要にする

    なぜ無料のソフトウェアで稼げるか?なぜ人は水を買うのか?と同じ。インターネットのソフトウェアは沼地の水をのようなもの。それをペットボトル入りの水にしている。マルウェア対策などのセキュリティ向上、様々な変更を可視化しテストすることで様々なデバイスでの動作を保証している。

    トップダウンは密結合な組織、オープンな組織は疎結合な組織な印象でした。

    オープンソースコミュニティは、同じような課題を持つ会社がタッグを組む場所。協力し合うことで早く高い価値を得られる。例えばLinuxを一から作ると、8000年収と100億ドルかかる。オープンなコミュニティによるグローバルなげんきだまで、これらがものすごいスピードで作られ、かつ無料で利用できるのは本当すごい。

【読了】日本医療の不都合な真実

どの業界でも闇というか、課題があるんだなと思いました。また、ITで普通に使っている仕組みなど、他の業界では当たり前じゃないのだなと。そして逆も然りかもです。他の業界を見るのもいいなと改めて感じました。

ただ守ればいい。ではなく、本人の意思も尊重すべきだ、と考えさせられる本でした。

  • 日本の一人当たりの病床数は世界トップ
  • しかしコロナで確保された病床数は2%以下、なので足りない、ホテル使ったり
  • 背景には、公共の病院が少ないので、国から指示が出せない。病院側も未知の領域のため強力に躊躇して。国としても統制ができない。そんな感じ。
  • また、なぜ日本の病床が多いかというと、市場失敗の原理が適用されているから。日本は国で保険を用意し、病院行っても負担が少ない。なので、気軽に病院に行き検査や入院も気軽にできる。海外は別。医療費保険がない場合もある。日本は病院を立て、病床数を確保し、継続的な通院や入院により利益が増える。気軽に利用してもらう。利用者が増え医師不足。この状況が成り立ってしまう保険制度。国の医療費が増える一方。国から負担しているため、公共の病院にしすると解決するのでは?という提案。
  • 現状、たくさんある病床は高齢者メインで利用されている。介護に近いレベルのもの、老衰末期の延命対応など。
  • ビジネス構造的には建売に似てるなと思った
  • イギリスではプライマリケアという制度があり、必ず担当医がつく。その人を知り、幅広く見てくれる。重症な場合は、高度な医療へエスカレーション。サポートでいうと、ヘルプデスクとエスカレーションチームのような関係。確かに効率的なやり方はありそうだなと思った。
  • 夕張では財政破綻し、大病院が縮小し、医療破綻が叫ばれた。だけど結果を見ると死亡者が増加していない。プライマリケアのように、在宅メインの診療にしたり、クライアントに寄り添った対応をすることで、柔軟な対応により病床数が減ったが、実質医療崩壊は起きなかった。医療費も減った。経験より、縮小してもやっていける。
  • ITILの運用プロセスの考え方が、プライマリケアに似てるな感じた

【読了】読むだけで絶対やめられる禁酒セラピー

読みました。ゆっくり2ヶ月くらいかけて。結果はというと。

  • お酒に対するコントロールを失っていた事に気づいた
  • 依存していないと考えていたが、毎晩飲まずにはいられない状態は依存しているということを理解した
  • アルコールは体に良くない、毒であると理解した
  • 毎晩やっていた晩酌がなくなった
  • 飲んだ後のだるさが怖くなった
  • 飲まなくても眠れることに気づいた
  • だるくて体調が悪い日がなくなった
  • 時間がめちゃくちゃ増えた
  • ゲームとか読書の時間が増えた
  • 暇だなーと思うことが増えた、アルコールから解放されたんだなと思うようになった
  • 「飲むことが幸せ」から「飲まない方が幸せ」という考えに変わった
  • 禁酒した結果、いいことしかない

過去を思い出すと、もともとかなりお酒は弱い自分だった。135mlの小さいビール缶も残すくらいの人だった。気づいた時は500ml を3缶飲み、飲まないと一日が終われないという考え方になっていた。休日の昼から飲む時もあった。暇な時の時間潰しに飲む時もあった。

今思うと、「時間がない」原因がアルコールだったんだなと思う。

新しい自分を手に入れた感じがして、とても清々しい。

タバコやめた時、辞めるのはかなり辛かった。タバコは毒だと言い聞かせ、吸うのが恐怖になるくらいタバコについて調べまくったことを思い出した。この感覚に近い。この本は、アルコールは毒だということを教えてくれる。無理に辞めるのではなく、不要なものだと理解させてくれるので自然とやめられる。依存していることに気づかせてくれる。

自分にとって、かなりいい本だった。ありがとう。

AWS Certified Database - Specialty Practice 勉強しました記録

AWS Certified Database - Specialty Practice 受験しました。 勉強したことをメモしておきます。

ToDo

よくある質問、Blackbelt、AWSドキュメントを読む

  • [x] DMS・SCT(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] KMS(blackbelt未、よくある質問する未、AWSドキュメント未)
  • [x] DynamoDB(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Neptune(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] DocumentDB(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Elasticache(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] Aurora/Global/Serverless(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] パフォーマンスインサイト(blackbelt無、よくある質問済、AWSドキュメント未)
  • [x] RDS(blackbelt済、よくある質問済、AWSドキュメント未)
  • [x] AWS Backup

後で読む

AWS環境操作

RDS/Aurora

  • [x] DBへの接続方法(認証方式、IAM認証、Lambda実行、SSL)
  • [x] aurora IAM認証
  • [x] aurora パラレルクエリー
  • [x] aurora バックトラック
  • [x] 暗号化スナップショットのリージョン間コピー
  • [x] Aurora Multi Master/Global/Serverless/リードレプリカ論理/Parallel Query
  • [x] DBエンジン間の移行、EC2からの移行、mysqlからauroraへの移行
  • [x] バックアップリストア、rds、dynamo 、 elasticach
  • [x] aurora グローバルデータベースの作成(別リージョンへの物理的なリードレプリカ)
  • [x] Auroraクロスレプリケーションインスタンスに対するリードレプリカの追加
  • [x] Auroraクロスレプリケーション(物理/論理)
  • [x] aurora サーバーレス作成
  • [x] 別リージョンへのリードレプリカ作成
  • [x] 別リージョンへの移行、暗号化インスタンス
  • [x] 拡張メトリクス有効化、cwlogs確認

インスタンス構築、バックアップ、冗長化、暗号化、DR

  • [x] SCT
  • [x] DMS
  • [x] Elasticache
  • [x] Neptune
  • [x] DocumentDB
  • [x] DynamoDB

DynamoDB

  • [x] Dynamodb オンデマンド
  • [x] ローカルセカンダリインデックスの作成とGetItem
  • [x] グローバルテーブル
  • [x] GSIの設定
  • [x] LISの設定

ElastiCache

  • [x] アプデ、アプグレ(エンジンはサービス更新、インフラは継続的な管理メンテナンスで必須)
  • [x] ノードが置き換え対象となった場合に実行可能なアクション
  • [x] 通信暗号化
  • [x] データ暗号化
  • [x] バックアップ・リストア

模擬試験

Udemyの正解が間違っているケースがたくさんありました。自分を信じていきましょう。

試験の時間配分

  • 180分
  • 65問
  • 2分/1問 + 見直し50分
  • 悩んだ問題はフラッグ立てて、後から新しい目で見直す

勉強ノート

RDS

  • DBプロキシ: プーリング機能の保持、フェイルオーバーの高速化
  • リードレプリカ、ソースDB削除
  • シャーディング: 1インスタンス以上のパフォーマンスを得たいばい
  • 移行
  • ポイントインタイムリカバリ。戻したい時間を指定して、インスタンスを新規作成

Aurora

  • Auroraへの移行
    • mysqldump
    • RDS スナップショット
    • Aurora リードレプリカ作成、昇格
    • DMS
    • S3インポート
  • リージョンレベルのフェイルオーバーは手動
  • フェイルオーバー動作
    • 読み込み:一時中断、新プライマリへ割り当て。障害発生したノードが復旧後、リードエンドポイントは復旧ノードへ
    • 書き込み:フェイルオーバーし、昇格した新プライマリノードへ
  • レプリケーション
  • MultiMaster: 複数のAZに渡って、書き込み性能をスケールアウトできる
  • Aurora Serverless
    • コスト効率、予測不能なスケール、不定期利用などがメリット
    • Auroraクラスタからの移行は、スナップショットを利用
    • VPC内からのみ接続可能
    • 事前に特定のキャパシティを明示できる
    • ロングトランザクションや、テーブルロックなどにより自動スケールできない時がある
  • Database Cloning: コピーオンライト方式でクローン。完全なコピーではないので、データ容量への影響がほぼない、本番への影響もない。本番データを使った、検証、分析、DBの再構成などに利用
  • Parallel Query
    • 分析クエリ(OLAP)の高速化
    • 分析クエリの処理をストレージレイヤ内の数千ものCPU分散する。インスタンスへのデータ転送量も減るため高速化される。また既存のOLTPへの影響は出ない。
    • Aurora MySQLのみ対応
  • バックトラック:戻したい時間を指定して復元、インスタンスが新規作成されず既存のデータベースのデータが戻る。テーブル単位での巻き戻しはできない。
  • RDS MySQL/Aurora MySQLは、S3上のバックアップデータ(Percona XtraBackup )からリストアが可能
  • AuroraではRAMを利用した、アカウント間でのインスタンスをクローン化(データ更新した分だけ料金が発生する)
  • グローバルデータベース
  • IAM認証
    • RDSへユーザー追加、aws rds generate-db-auth-tokenでトークン取得、mysql コマンドに証明書とcleartext-pluginを指定し接続する

DynamoDB

  • 1キャパシティ:リード4KB、ライト1KB
    • 強い結果整合性の場合は、キャパシティを2倍使う
  • パーティションキー設計をうまくやらないと、偏りが発生してパフォーマンスが出ないことがある
  • キャパシティは過去300秒までリザーブする。このリザーブを使ってバーストすることができる
  • LSI(Local Secondary Indes):キーは固定、ソートキーを追加できる
  • GSI(Global Secondary Indes):キー自体を追加できる
  • Point in Recoveryに対応している。復元したい時間を指定して、新しいテーブルを作成
  • AWS Backupによるバックアップに対応している
  • アダプティブキャパシティ:アクセス頻度の高いデータは別パーティションに自動で分離する
  • DynamoDB オンデマンド:既存テーブルの移行可能、事前のキャパシティ設計不要でプロビジョニング。クエリごと単位での確認

mamcached

  • コンフィグレーションエンドポイントにノードリスト。aouto discovery ライブラリで、アプリ側でノードの追加削除を自動検知
  • マルチコア

redis

  • クラスター無の場合は、RDS同様なフェイルオーバー方式
  • バックアップ リストア
    • スナップショット
    • スナップショットからRDBファイルをS3へエクスポート
    • スナップショット、RDEファイルからリストア
  • シングルコア
  • 監視: CPU、メモリ使用率、Eviction(キャッシュアウト数)、キャッシュヒット率、swap、レプリカラグ
  • redisクラスタ
    • シャード単位で分散、最大15シャードまでスケール
    • クラスタ専用のライブラリ、クライアント側でマッピンを保持
    • シャードごとに最大5つのリードレプリカ
    • プライマリノード障害時は、リードレプリカがプライマリへ昇格、フェイルオーバー
    • ダウンタイム0で、シャードの増減が可能、オンラインリサイズ機能
  • 暗号化: クライアント間通信、S3とディスク上のバックアップファイルを暗号化

DocumentDB

Neptune

  • アーキテクチャはAurora
  • データ移行は、S3またはDMS
    • S3:ノード用のCSV、エッジ用のCSVをそれぞれ用意する
  • 対応言語
    • Apache TinkerPop Gremlin (ノード、エッジ、プロパティ)
    • RDF(主語、述語、目的語)、プロパティは述語と目的語で追加していく
    • 両方のエンドポイントポイントをそれぞれ用意されているが、データは共通ではない
  • インデックスは自動管理、ユーザーで変更できない
  • OLTP、OLAP両方対応できる
  • クロスリージョンレプリカは非対応
  • 暗号化されてないデーベースの移行には、新規インスタンス作成後、データ移行が必要
  • リーダーエンドポイントには負荷分散機能がない。アプリ側で分散するか、Route53を利用する

DMS

  • フルロード
    • DBソース:1万行8テーブルのSELECT > INSERT
    • To Redshift:1万行8テーブルのSELECT > CVS to S3 > Redshift Copy
    • S3ソース:
  • フルロードの監視:CPU、Swap、メモリ、ストレージの空き、ネットワーク帯域
  • CDC(変更データキャプチャ)
    • CDCの開始時間を指定する
    • ソースDBのトランザクション(バイナリログ、WAL、REDOログ)を5秒間隔でキャプチャ
    • DMSがSQLへ変換、トランザクションコミット順にターゲットDBへ実行
    • 接続できな、遅い、フルロードが未だなどの場合は、DMSでキューイング
    • the_endなどマーカーを入れておくと、同期の確認ができる
  • フルロード + CDC
    • フルロード中の更新をキャプチャ
    • フルロード完了後、キューイングした1の更新を適用
    • 完了後は、トランザクションとして更新を適用
  • CDCの監視:
    • CDCChangeDiskSource(ソースのコミット待機数)が多い場合は、ディスクサイズをあげる(キューイングが多く発生するため)
    • CDCChangesDiskTarget(ターゲットのコミット待機数)はターゲットの処理能力が原因の可能性
    • CDCLatencySource(ソースDB実行完了から、DMSがキャプチャするまでのラグ)
    • CDCLatencyTarget(キャプチャからターゲットへ適用するまでのラグ)
  • 暗号化されたデータの読み書きが可能
  • SCT
    • スキーマ変換、複雑性分析、RDSでの制約、アプリのSQL変換、プロシージャの変換、データウェアハウスをRedshiftへ移行

【読了】その仕事、全部やめてみよう

スタートアップから大企業へと転職したことでの組織の違い、大企業でも柔軟なエンジニアチームへと変化させられるよというメッセージングでした。印象としてはタイトルと内容にギャップを感じましたが、大企業の事業会社で組織内にエンジニアチームを立ち上げるためのTipsが色々あるんじゃないかなと思いました。事業会社でエンジニアチームに課題感を持っている方が読むと良さそうかな思いました。

キーワード - ダイバーシティー - 採用の工夫 - まずは自分でやってみる

私の宿題

  • 採用に悩んでたが、もっと分かりやすいメッセージング、共感してもらえるようなものに変える
  • 他業種の成功事例をもっとキャッチアップする

【読了】スピーチの教科書

思いが伝わる、心が動く スピーチの教科書

思いが伝わる、心が動く スピーチの教科書

  • 作者:佐々木 繁範
  • 発売日: 2012/02/17
  • メディア: 単行本(ソフトカバー)
スピーチをする機会が増えたのですが、毎回自信を持ててなかったので読みました。まず、圧倒的に準備が足りてないことをがわかりました。心を込めてスピーチを準備し、心を込めて話すぞ!伝えたいことは、すぐ出てこない。悩みに悩む。今後は体験を伝えることを意識していこうと思いました。私にとっては、すごくいい本でした。例が沢山あって圧倒的に分かりやすくて読みやすい。

読書メモ

スピーチの核を作る

相手を知る

主催者は誰か、何を求めているのか

  • 会の主旨
  • 何を達成しようとしているのか
  • スピーカーへの期待
  • 何を配慮すべきか

聴衆は誰か、何を求めているのか

  • 聴取は誰か、特徴(構成比)、焦点を当てる対象
  • 聴衆は何について聞きたいか
  • 一般的にどのようなことが言われているのか
  • 聴衆の期待を上をいくために何が必要か(新たな視点やアイデアを伝える、眠れないほど心配していること、何を気にしているのか、何で元気が出るか、勇気づけられるか、マインドマップでまとめる)

メッセージを絞る、最も伝えたいこと

  • スピーチ後にどうなっていて欲しいのか
  • メインメッセージ
  • サブメッセージ
  • マインドマップでスピーチを作る

話を効果的に組み立てる

  • メインメッセージ
    • オープニング:関心を掴む、心を通わせる、テーマとロードマップ
    • ボディ:メインメッセージにつながる、体験、ストーリー
      • タイプ1:ポイント提示型(聴衆と前提となる共通識別が必要)
      • タイプ2: 問題解決型(モンロー型:注目、問題点、解決策、視覚化、アクション
      • タイプ3:ストーリー型 (擬似体験、状況設定・葛藤・解決・メッセージ
    • クロージング

全体構成とボディ(伝わりやすい構造、順番)

オープニング

  • 心を掴む
  • 個人的、意外性、目新しさ、挑戦、ユーモア

ボディ

クロージング

  • 要約、具体的なアクション、引用(誰かの言葉

原稿、リハ、本番

リハ

  • 入念な準備が必要
  • 原稿の用意:基本構想、アウトライン、フルテキスト、言葉磨き、中学生レベルの簡単な言葉を使う
  • リハのポイント:息継ぎ、文章間で合間、時をり目線を聴衆へ、第三者のチェック
  • デリバリー:感動の本質は心が通い合うこと、歌を歌うように

【読了】一番よくわかる総務・労務・経理基本と実務

読みました。ざっくりですが、総務・労務経理についてインプットしました。 法律とか経理とか、ぼんやりしかわかってなかったのですが、ある程度把握しましたが、細かいところはやっぱり専門家に任せないと難しい分野だなーと思いました。いつもお世話になってるチームには感謝です。

会社と法律

  • 法律の把握は総務の大切な仕事:契約関連性、登記など
  • 株主総会:1年の活動結果を株主に報告する
  • 過半数の株を持っているものは、すべてを決定できる
  • 営業・開発の部門に対し、雑務から解放し本業に集中してもらうことが総務の重要な仕事。また、社外の関係者と良好な関係を保ち。発展させる役割もある
  • 総務の主な業務
    • 主な手続き関連(社内外・契約書・印鑑・官公庁手続き・行事や催事の企画と運営)
    • 主な設備管理業務(OA機器購入や管理、社用車・建物の管理、社宅の管理、防災・防犯、警備の管理)
    • 主な庶務業務(郵便物・宅配物管理、消耗品購入管理、受付来客・電話対応、ゴミや廃棄物処理株主総会の運営、社長・役員のスケジュール管理、歳暮・中元・年賀状)
  • 印鑑の種類
    • 代表印刷(法務局に届けたもの)、銀行印(口座開設時のもの)、角印(見積・注文などに利用する)、ゴム印(業務効率化のための印鑑、例えば会社名と住所が記載されたもの)
  • 許認可
  • 情報管理
    • 情報流出防止(パスワード、アクセス管理、社外持ち出し)
    • バックアップ取得
    • ウィルス対策
    • メール誤送信対策
  • 取引先の倒産
    • 入金の遅延、支払サイトの長期化
    • サービス提供を停止する
    • 催促状や内容証明郵便を使う
    • 倒産した場合は、債権届出書を提出する
    • 倒産時の手続き:会社更生(裁判所の元経営を刷新して継続)、民事再生(裁判所の認可を受け再生計画を元に経営者交代なしで継続)、破産(弁護士のもの財産を元に債権者に配布)、特別精算
    • 信用調査会社を利用し与信する

物品管理とサービス

  • 従業員が業務に集中できるように、物品管理・環境整備を行う総務の欠かせない仕事
  • 印刷発注完了(会社案内、車名入り封筒、ファックス、見積書、請求書、納品書、注文書、名刺など)
  • 文書管理・破棄、法律で保存年数が決まりがある
  • 郵便物・宅配物管理
  • 取引先・従業員名簿の管理
  • データのバックアップ
  • リースと購入:リースの場合は初期費用が安くなる(月額費用の支払い)だがトータルコストは高めになる。税務処理も購入時は減価償却など方法が変わってくる。
  • 社用車の管理と安全対策
  • 社宅・社員寮の管理(会社負担の金額により所得税が社員に発生する場合もあるので注意、50%程度が目安)
  • 社内外の慶弔に関する規定(冠婚葬祭・中元歳暮・見舞金など)
  • 社内外の行事やイベント開催

人材管理

  • 労務・人事の役割:事業と従業員の業務・能力を結びつけて、業績の最大化を目指す
  • 人材の採用と配置、教育、評価制度管理
  • 社会保険、労働保険、雇用契約、入社契約書、就業規則、給与規定
  • 人材募集、面接、採用
  • 就業規則:会社の法律
    • 給与規定:基本給、各種手当て、賞与
    • 労働時間、休日、休暇ルール
  • 雇用契約:採用時の契約
  • 勤怠管理
  • 人事考課
  • 懲罰制度:訓戒、減給、出勤停止、油脂解雇、懲戒解雇
  • 福利厚生
  • 労働契約の終了、退職

保険業

経理の基本

  • 財産・利益を把握し、今後の計画を立てる
  • PL、BS、CS、資金繰表、決算書
  • 税金:法人税、法人住民税、法人事業税、消費税
  • 手形:期日と場所、金額の支払いを約束する証書。現金化には数日かかる。急な現金化には割引手形(銀行へ利息払う)、裏書手形
  • 小切手:金額を支払うことを約束する証書。銀行などで現金化
  • 資金調達:融資と出資、出資は一般的に返済や利息支払いが不要。社債

記帳の基本

  • 仕分け:資産、負債、収益、費用、純資産
  • 金管理:小口現金
  • 証憑(しょうひょう):取引における書類
    • 見積書:数量や仕様、条件、金額などについて記載
    • 注文書:買い手が注文に同意したことを示す(個別契約)
    • 納品書:注文書の通り納品したことを伝える。書いてはこれをベースに研修する
    • 請求書:代金を請求する
    • 領収証:代金を受領したことを示す
    • 税法で7年、会社法では10年保存するように決まっている

給与計算

  • 総支給額計算:基本給、住宅手当、交通費など
  • 控除項目計算:社会保険雇用保険所得税、住民税など
  • 給与明細。源泉徴収書作成
  • 時間外勤務、深夜勤務、休日勤務
  • 年末調整
  • 会計参与:社内役員として、公認会計士や税理士の資格を有する専門家として会社の決算内容に責任を持つ。正確性と信頼性を高められる。

決算と申告

  • 1年に1度決算書を作成する:1年間の儲けを計算
  • 棚卸し、売上原価、減価償却、収益、費用、財産と負債の確定
  • 年次決算と月次決算
  • 売上原価:仕入原価
  • 固定資産:販売ではなく使用することを目的とした資産。有形固定資産(建物や機械設備など)、無形固定資産(ソフトウェアや特許権など)、投資その他資産(株式や長期貸与金など)がある
  • 固定資産と経費:10万円以上を固定資産
  • 営業成果