経営理念の結晶化
以下の記事が非常に良いだったので、まとめておく。
経営理念は当たり前の原理原則に行き着く
記事中にこのような記述がある。
柳井さんのような優れた経営者の頭の中にある原理原則とは、実はこうした膨大な具体的経験、具体的なトラブルから抽出された、論理の結晶体なのです。わかりやすい言葉で言えば、「要するに、こういうことだ」なのです。
この「要するに、こういうことだ」を純化して純化して純化し切ると、般若心経のごとく簡潔極まりない「経営理念23カ条」に行きつく。柳井さんが何を聞かれても「当たり前ですけど」と答えるのは、それだけ経営理念が結晶化されていて、ブレがないからなのです。
つまり、経営理念というものを結晶化していくと、当たり前の原理原則に行き着くということである。
だからこそ、A︰当たり前のことを、B︰馬鹿にせずに、C︰ちゃんとやる、ことが大切である。
原因を追究する
記事中には以下の記述もある。
商売のセンスがない経営者は、前者のように「カツ丼がダメなら天丼」という「具体の横滑り」をします。「青いフリースが売れないけれど、隣の店では赤いフリースが売れているから、今度は赤を仕入れてみよう」というように、横の具体へ飛ぶことで問題解決を図ろうとするのです。こうした経営者は、キョロキョロと周囲を見渡しては、目まぐるしく経営方針を変えていくため、いつまで経っても原理原則を確立できず、無限にぶれ続けることになります。
（中略）
優れた経営者は問題に直面したとき、「横の具体に飛ぶ」のではなく「具体を抽象化する」ことで、自分の原理原則を磨き上げ、そこで培った原理原則を別の具体に適応していくのです。そして、柳井さんのような経営者は、この具体→抽象→具体という往復運動を、あたかも呼吸をするかのようにごく自然に繰り返しています。だから問題解決の手法はその都度違うようにみえても、その背後にある原理原則は決してぶれることがないため、掘り下げていくといつも同じ答えになるわけです。
優れた経営者は、何かの問題に直面した時に、原因を掘り下げる。
そして、原理原則としての経営理念に昇華する。
システム開発のポイント
前回に続いて、システム開発のポイントをまとめる。
WBSの粒度設定
前回の記事で、WBSの粒度を揃える必要があることを書いた。
更に、 作業者が実施したタスクを管理者がレビューできる単位で分解する必要がある。
そのため、まず、タスクを成果物が存在する単位で分解する。
成果物がないと、管理者が作業者のタスクをレビューできないからだ。
作業者は成果物単位ではなく、自分の作業の節目単位でタスクを分解しがちだ。
もちろん、作業者が自身で作業しやすいように細かくタスクを分解するのは良い。
しかし、プロジェクトのWBS上では成果物が存在する単位で分解したほうが良い。
次に、タスクをレビュー可能な単位で分解する。
作業者と管理者のスキルの違いによっては、成果物があっても管理者がレビューできないことがある。
例えば、管理者のITスキルがそこまで高くなく、作業者は管理者が発注したITベンダーだとする。
この場合、開発されたコードの一つ一つを管理者がレビューすることは困難だ。
こういったケースにおけるレビューの方法としては、進捗状況の星取り表を成果物としてレビューを実施するというのがある。
APIや画面単位で星取り表をつくる。
そして、各APIや画面が完成したら、星をつけて、その表をレビューする。
各APIや画面のレビューはできないが、進捗状況は追える。
仕様通りに機能が開発されているかどうかは、ユーザーテストの段階でレビューする。
クリティカルパスの明確化
タスクを分解した後で、クリティカルパスを明確にしておく必要がある。
クリティカルパスというのは、「システム構築などのプロジェクトを進めるうえで、ネックとなる部分を指し、事実上プロジェクト全体のスケジュールを左右する作業の連なり」を指す。
具体的な手順としては、まず各タスクに番号を振る。
そして、各タスクのメモに、そのタスクの前に実施する必要があるタスクの番号を書く。
ここまでの作業で、タスクのつながりが明確化される。
最も期間が長くなるタスクのつながりが、クリティカルパスとなる。
クリティカルパスを明確化することで、タスクが遅延した場合でも、スケジュールを調整することができるようになる。
クリティカルパスではないタスクが遅延したら、クリティカルパスに影響が出ないように期限を設定し直す。
クリティカルパスのタスクが遅延した場合には、後続のタスクで巻き返せそうか、もしそれがムリなら、プロジェクト完了の後倒しが可能か検討する。
工数見積もりにおけるバッファの確保
各タスクの工数見積もりにおいては、バッファを確保することが必須である。
各タスクが最短で終わる場合の工数と、最長でかかりうる工数を算出する。
そして、その二つの工数の平均値を、見積もり工数とする。
こうすれば、無理のない範囲で、バッファを確保できる。
もし、何か懸念されるリスクがあれば、そのリスクが発言した場合の対応工数もバッファとして積んでおく。
8月中間振り返り
前回の振り返りからの改善状況も含めた振り返りを実施する。
ABCに関する振り返り
前回の振り返り（8/1）から、半月たち、どのように改善したか、もしくは悪化したかをまとめる。
- 夜は早く寝て、朝は早く起きる（△⇒✖：夜早く寝ることを徹底できていない。朝は早く起きようとしているが無理があるため、疲れがたまってしまっている）
- 朝一で、一日の作業を計画する（△⇒✖：大まかな計画に基づいて行動しているものの、朝早く起きられていないため、朝一で一日の作業を十分に計画できていない）
- 計画を立てるときは、本当にその選択肢しかないのか、第三の選択肢はないか、常に考える（△⇒✖：考えられていない）
- 計画はデスクトップリサーチや人に話を聞いて検証する（〇⇒〇：立ち止まって、実現性を考えることができている）
- 作業はやりかけで終わらせずに、完了させる（△⇒✖：中途半端にやりかけのまま仕事を中断することが多い）
- 日次でブログを書いて、自分の一日を振り返り、PRDCAサイクルをまわして、改善する（✖⇒✖：全くブログを書けておらず、振り返りができていない。そもそも日次で振り返ることが困難なため、本項目は廃止。ただし、日次でアウトプットをすることは有意義なため、継続）
- 週次、月次で振り返りのタイミングを設けて、やり残しがないか、反省点はないか振り返る（△⇒✖：全くブログを書けていない）
- 振り返りから導いたアクションを確実に実行にうつす（△⇒✖：実行できていない）
- 毎日、日経新聞やその他の新聞や雑誌や本を読んでインプット量を確保する（✖⇒✖：インプットできていない）
- インプットした内容は、ブログにアウトプットする（✖⇒✖：できていない⇒「時間的にかなり難しい。これまでのように1500字で書こうとするとかなり難しいので、500字程度で、クイックに学びをアウトプットするようにする」という改善策も実行できていない）
- 有名な方の本の内容をノートにまとめて見返す（✖⇒✖：できていない。「本は読んでいるが、まとめられていない。上述の通り、ブログにアウトプットするようにする」という改善策も実行できていない）
- 一週間に一回は体に負荷がかかる運動をする（△⇒✖：運動できていないため、体力が低下している）
本日書いたブログにまとめたように、経営者として経営理念を結晶化すること、当たり前の事を確実に遂行することが大事だ。
改善施策は前回の振り返りと変わらないので、実行していく。
一週間の振り返りの実行状況
対策として挙げた3つの施策に関して、実行状況を確認する。
- ユーザーヒアリングのペンディング（✖：ペンディングしていない。また追加でアポイントを取得している。Do＆Don'tでいうところのDon'tが徹底できていない。いつまでたってもタスクに追われる状態が続いている。）
-
自社事業の将来構想の立案・進化（〇：ミッションから改めて事業計画を練り直すことができた。しかし、更に具体化していく必要がある。ファーストステップとして、やりたいことを実現するために必要なことを洗い出す。）
-
会社設立・運営タスクの洗い出し（〇：直近でやらなければならないことは洗い出せた。今後、領収書の処理など定期的に発生するタスクがあるので、スケジューリングしておく。）
振り返り
8/6～8/14までの振り返り。
感情への配慮
相手の期待値を下回ると、相手の感情は非常に悪化する。
だから、実現できないことを、約束してはならない。
特に、共同創業などの人生の転機になるような大きな約束は、迂闊にするべきではない。
相手との相性や、取り組む事業内容や、事業における役割分担などが十分に明確にイメージできてから、話を進めるべきだ。
日程調整時の日程指定の仕方
日程調整において、一つの日程しか提示されない場合には、「ほとんど会う気持ちがない」ということを意味する。
その場合、提示された側は、本当に会いたいのであれば、何としてでもその日程に行かなければならない。
もし、そこまで会いたくないのであれば、別の候補日程を提示するのもアリだが、ほとんど決まらないと思った方がよい。
メンバー選択の重要性
プロジェクト実施時には、最初のメンバーの選択次第で、プロジェクトの成否が決まる。
最初のメンバーを間違えなければ、プロジェクトは成功する。
メンバーの選定にあたってのチェックポイントには、以下のようなものがある。
・プロジェクトの実現イメージは明確か
・そのイメージはメンバー間で共有されているか
・メンバーのスキルは補完関係にあるか
・メンバーの価値観は一致しているか
これらが全てOKであれば、プロジェクトは成功する。
収支計画の見積もりミス
「売上は半分、支出は倍で見積もる」が原則。
特に支出において、予想もしない出費が発生する可能性は高いからだ。
十分なバッファを確保しておく。
ただ、いつまでも売上は半分、支出は倍だと、正確な見積もりが立てられない。
バッファは確保するものの、見積もりに関してはPDCAを繰り返して、精緻化していかなければならない。
サービス初期におけるプロトタイプ制作の重要性
プロトタイプを実際のUIのイメージで構築することは非常に重要。
UIはフローチャートや文章でも表現できるが、それだとイメージがつかめない。
プロトタイプを制作すると、具体的にイメージがわき、ユーザーの気持ちになって検証することができる。
チームメンバー間の意志も統一させることができる。
安心・安定の再定義
8/2分。8/7記載。5日遅延。
キングコング西野さんのブログを読んだ。
キングコング 西野 公式ブログ - ライバルの売り上げを伸ばせ - Powered by LINE
この記事にある考え方は、保険業界にも当てはまるのではないかと思うので、考えをまとめておく。
まず、上記の記事には、このように書かれている。
インターネットで世界が繋がり、スマホによって、これまで「ライバル」としてカウントされなかった全ての事柄が横並びになった。
（中略）
つまり、『革命のファンファーレ』を選んでもらう為には、まずは何より「本って面白い」という印象を持ってもらわなければならない。
シルク・ドゥ・ソレイユや東京ディズニーランドではなく、本屋さんに足を運んでもらわなければならない。
限られたテレビの枠を、オススメグルメよりも、オススメ書籍に割いてもらう必要がある。
まずは『本』というジャンルでパイを勝ち取らないといけない。
その後、自分の作品に分配される。
エンターテイメントという枠においては、東京ディズニーランドも、テレビも、YouTubeも、本も、漫画も、同列で比較されるようになってきているということだ。
これと全く同じことが、保険にも当てはまるのではないかと思う。
保険という商品の機能は、「安心・安定を保障すること」だ。
しかし、この"安心・安定"という概念は変わりつつある。
少し前までは新卒採用のタイミングで大企業に入ることが安心・安定を確保する一番の手段だった。
そして定年まで大企業で勤め上げて、まとまった退職金をえて、退職金と年金で余生を過ごす。
そこに保険を上乗せされていた。
若い頃に万が一のことがあった時の保障を保険で確保する。
返戻率の高い運用型の保険で老後の資金も追加で確保する。
これがステレオタイプの"安心・安定"をもたらすための仕組みだった。
しかし、近年、状況は変わってきた。
まず、大企業で勤め上げることが絶対に可能な時代ではなくなってきた。
また、平均寿命は100歳に到達するのではないかというぐらい長生きの時代になり、60歳定年で退職金で暮らす時代ではなくなった。
更に、年金制度も徐々に高齢者の負担が増えていくことが予想される。
では、こんな時代に、安心・安定を確保するための手段にはどんなものがあるのか？
保険というのも引き続き有効な手段である。
しかし、ある人は保険ではなく、将来価値がぁ上がることを見越して、自分が勤めるベンチャー企業の自社株を買いたいと思うかもしれない。
また、ある人は、副業をすることで、リスクを分散させるかもしれない。
また、ある人は強固なつながりのあるコミュニティに所属することで、何かあったときに助けてくれる仲間を増やすかもしれない。
選択肢が増え、保険という手段も、誰もが当たり前に入るものではなく、他の安心・安定を確保するための手段と比較させるようになってきたのではないか。
そのため、保険業界がこれからも存続・発展するためには、保険に関わる人や商品の魅力が向上する必要があるのではないか。
保険会社同士・保険営業マン同士の争いの前に、業界自体の魅力が高まる必要がある。
名言まとめ
8/1分。8/5記載。4日遅延。
最近聞いていいと思った言葉をまとめておく。
成功は成長の果実である
金銭的な成功、事業の成功、そういったものを実現したいときに、その成功を目指すことにフォーカスするのではなく、成長にフォーカスすることの重要性を言い表している。
成功というのは結果に過ぎないので、そこに至るまでの成長というプロセスにフォーカスするということである。
成功に至るために必要なスキルや、やらなければならないことを分解し、それを身に付けたり、実行したりしていく。
成功という遠い先の未来ばかりを見るのではなく、足元を見て、日々一つずつクリアしていくということである。
お金は信用である
この言葉もフォーカスすべきポイントを言い表している。
信用を積み重ねていけば、自然とお金はついてくるということだ。
お金になるかならないか、という視点だけでなく、信用を積み重ねることができるかできないかという視点を持つ。
目の前の人や仕事を大切にしていると、信用が積み重なっていく。
信用が積み重なっていくと、自然と仕事も舞い込んでくるようになるし、お金も入ってくるようになる。
プロジェクト管理のポイント
7/31分。8/5記載。5日遅延。
プロジェクト管理のポイントについてまとめておく。
①：タスクの粒度をそろえて分解する
まずどんなプロジェクトでも、最初にタスクを分解して、WBS（Work Breakdown Structure）を作成する。
この際には、粒度をそろえることが大切だ。
例えば、システム開発であれば、
要件定義・設計・開発・テスト、と分けられる。
更に、要件定義であれば、
システムの目的の定義・機能一覧の作成・業務フローの作成、と分けられる。
設計であれば、
データ定義・API設計・画面設計（画面遷移含む）、と分けられる。
開発であれば、
DB構築・API開発・画面開発、と分けられる。
テストであれば、
こういった基本のフレームワークを使うと粒度をそろえられる。
また、自身で洗い出す場合にも、同じ粒度で切り分けることが重要だ。
同じ粒度になっていると、抜け漏れに気づくことができる。
②：タスクの成果物を定義する
タスクを洗い出して、WBSを作成したら、各タスクの成果物を定義することが必要だ。
成果物を定義することで、はじめて、タスクの完了条件が明確になる。
タスクの完了条件が不明確だと、タスクがズルズルと遅延する原因になってしまう。
理由は二つある。
まず、完了条件が不明確な場合、そのタスクで達成したいことや目的が不明確であったり、タスクが細分化しきれていなかったりすることが多い。
そうすると工数が精緻に見積もれないため、遅延してしまう。
次に、完了条件が不明確だと、タスクを実行する本人も、タスクの管理者も、何をもって完了したかが判断できない。
期限が来ても、そのタスクをクローズしてよいのかどうか、判断できないので、タスクが終わらず、遅延する。
完了条件を明確化し、タスクの期限のタイミングでその条件をクリアしたかクリアしていないかを評価することで、タスクを確実に完了させることができる。
③：工数の精緻な見積もり
成果物が明確になった後は、工数を精緻に見積もる。
工数まで見積もろうとすると、更に思考が深まり成果物がより明確になる。
また、工数が精緻に見積もれていないと、プロジェクトを提案する場合にも金額の見積もりに失敗する。
いずれも基本的なことだが、これらを徹底することでプロジェクト管理はうまくいく。
