プログラミングを独学で脱初心者する為のロードマップ
元々IT系ではなかった僕ですが、必要に迫られてホームページを作ったことをキッカケに、コードを書くようになりました。「もっと上手くなりたい」と試行錯誤をしている内に、気がつけば仕事の中でもコードを書いて業務効率化するようになっていました。そして、先日ついに初めてのiOSアプリをリリースしました。ようやく自分の中でも、プログラミング初心者を脱した感覚があり、これまでの勉強法をまとめておきたいと思います。
*いまや黒い画面も怖くないぞ
独学で身につけるプログラミング
プログラミングの上達のコツは「作りたいものを作る」ことにあると思います。僕はホームページがキッカケだったので、HTML, CSS, JavaScriptから学習が始まりました。Web系の学習は成果が見えやすく、モチベーションが保ちやすいのでお薦めです。具体的なインプット（学習リソース）とアウトプット（成果物）を合わせて記述していくので、学習者の皆さんの「このぐらい勉強すれば、こういうことが出来るようになる」という指標になれば嬉しいです。
1. WordPressでWebsiteを作る
インプット
Codecademy
ドットインストール
書籍
アウトプット
メモ
まず初めに、WordPressというブログソフトウェアを使ってホームページの作成をしました。WordPressはPHPという言語で動いているので、一応PHPの入門コースの動画を見てみたのですが、ほとんど理解できずに意味がありませんでした。しかし、実際にアウトプットのホームページは完成しています。この"わからないけど動く"というのは大事なことだと思っていて、乱暴に言えば初めのうちは理解できてなくても動けば良いぐらいだと思います。
僕はCodecademyというサービスを使って、HTMLとCSSの勉強をしましたが、英語が得意ではない人はProgateを使うのが良いかもしれません。両サービスとも手を動かしながら学習できるのが特徴で、とても頭に入りやすいです。HTMLとCSSできるようになれば、それだけで見栄えの良いWebsiteを作ることが可能です。WordPressの環境設定は手間ではありますが、ググると大量に情報が出てくるので、特に気合を入れて勉強しなくて大丈夫だと思います。
2. JavaScriptで動的なWebsiteを作る
インプット
Codecademy
ドットインストール
- JavaScript入門
- JavaScriptで文字数チェッカーを作ろう
- JavaScriptで割り勘電卓を作ろう
- JavaScriptでパスワードジェネレータを作ろう
- JavaScriptで5秒当てゲームを作ろう
- JavaScriptでストップウォッチを作ろう
- JavaScriptでおみくじを作ろう
- jQueryで作るスライドショー
- jQueryで作るキャラ診断
書籍
アウトプット
メモ
次にJavaScriptを使って、動きのあるホームページを作りました。アウトプットにあげたのは、友人のBarのホームページを作成したときのものです。Bootstrap を中心に外部のライブラリを使って実装しています。ある程度のプログラミングの基礎を掴めば、公開されているライブラリを活用して、それっぽいものが作られるようになってきます。
このときの学習は、お手本通りに書き写す「写経」が中心でした。写経はあまり楽しい学習法ではありませんが非常に効果的です。Codecademyと書籍で基本的な文法を学び、後はひたすらドットインストールの動画を真似していました。紹介している「JavaScript本格入門 」はとてもお薦めです。初級レベルならこの一冊で良いぐらいだと思います。ホームページを公開するには、独自ドメインをとってレンタルサーバーを借りてと、JavaScript以外の知識も入りますが、Google先生に聞きながら真似するだけで事足りると思います。
3. Node.jsでWebアプリケーションを作る
インプット
- プログラミング入門 Webアプリコース
書籍
アウトプット
メモ
ここでは外部のAPIを使ってアプリケーションを作り始めました。APIが使えるようになると、一気にプログラミングが楽しくなってきます。紹介している振り仮名ジェネレーターは業務の中でも大活躍してくれました。が、独学者にとっては、この辺りが学習の一つのハードルではないでしょうか。内容も難しくなってくるので挫折する人も多いと思います。
そこでお薦めするのがドワンゴが提供するN予備校です。はっきり言って、めちゃめちゃクオリティが高いです。環境構築、コマンドラインの使い方、セキュリティなど、実践的な内容がカリキュラムに組み込まれています。N予備校で勉強しつつ、JavaScript 第6版、通称サイ本で知識を深めるというのが自分に合っていて、かなりレベルアップすることができました。
4. React NativeでiOSアプリを作る
インプット
Udacity
アウトプット （※現在はストア掲載は停止）
メモ
JavaScriptでもReact Nativeという技術を使えばスマホアプリの開発が可能です。JavaScriptの魅力の一つは、この言語だけで様々なことを実現できることだと思います。ES6, ES7と、コードの書き方が多少変わったりするものの、基本的にはこれまで学習した内容を活かしてスマホアプリを作ることができました。
ここではUdacityのNanodegree Prgramを受講しました。安くはないですが（しかも最近値上げをしている）、カリキュラムの充実度を考えると費用対効果は悪くないと思います。Nanodegree Prgramの良いところは、1. コードレビューがあること、2. 学習コミュニティがあること、です。独学をしているとコードレビューを受ける機会があまりないので、凄く勉強になりました。
おわり
以上です。最近は、大人こどもを問わず、プログラミングの必要性が社会で論じられています。僕は全員がプログラミングを学ぶべきとは思いませんが、ひとつ確かに言えるのは、プログラミングがわかると仕事が楽になる、ということです。僕は1~2年間はプログラミングを勉強していますが、その時間的投資に対するリターンは充分にあったと感じています。単純作業が自動化できますから。それになにより純粋に、モノづくりは楽しいです。PC1台から始められて、仕事にも活かせる大人の趣味。そんな風に気軽に始めてみるのも良いかもしれません。独学者の皆さん、お互い頑張りましょう！
「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト
「曖昧性とのたたかい」という本をご存知でしょうか？日立製作所で、みどりの窓口などの開発に携わった名内氏が、自身のプロジェクトマネジメントの経験をまとめた名著で、プロジェクトマネージャーなら必読の一冊です。アジャイルやリーンというモダンな開発手法が確立されていないなかで、大型のシステム開発をする厳しさは想像に難しくありません。また、その厳しさがタイトルによく現れていると思います。
システム開発に関わるプロマネに必須のチェックリスト
「曖昧性とのたたかい」は疑うことのない名著ですが、SE出身の著者ということもあってか、システム設計への言及などその内容は多岐にわたります。そこで純粋なプロジェクトマネジメントの要素に主眼を置いて、自分に刺さったところを「契約フェーズ」「設計フェーズ」「実装フェーズ」に分けてリストアップしてみました。詳しくは本書の購入をお薦めしますが、概要を斜め読みしたい人は参考にどうぞ。
契約フェーズ
提案と交渉
ポイント
- 提案依頼書に要求仕様などの詳細が書かれていることはまずない
- 完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
- 曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
チェックリスト
- 仕様が膨張するものとして、予算増額の必要性があることを事前に伝える
- 顧客からの仕様変更要求に際しては、必要な対策日程の確保と対策費用を負担していただくことを契約に盛り込む
- 予算増額の論拠を用意しておく（当初見積もりの前提条件を明確にしておく）
- 時間の許す限り、顧客の要求を文書化する
- 仕様の膨張が濃厚であれば、開発段階を区切り、最初の段階だけを見積もらせてもらう
- 契約納期と絶対納期（顧客側で死守しなければならない期限）を把握しておく
- 契約納期には「仕様凍結後○ヶ月」のような条件をつけておく
- 検収条件を「条件Xのとき結果Y」のような明示的なものにするか、検収期間を有限にして検収テストは全て顧客に実施してもらう
- 見積もりは再見積もりが許される条件設定をしておく
- 要求仕様が曖昧すぎる場合は、仕様確定までは「要員派遣ベースによる仕様確定契約」としてもらい、仕様確定後に「システム開発請負契約」にしてもらう
設計フェーズ
要件定義
ポイント
- 受注が決定したら、全力を挙げて受注条件の明確化、再確認、システム仕様の早期確定に努めなければならない
- 基本的に契約金額内で仕様をまとめることが両者にとって大事なことであり、かつ両者の利益につながるのだという共通認識を確認し合って仕様の確定に臨む
チェックリスト
- 契約書のみならず（提案と交渉の時の）覚書や議事録も確認する
- 検収条件をよく読み、無理なく検収されるような検収条件になっていることを確認する
- 見積り条件や検収条件に不備があれば、今後どう正常化してゆくべきかを営業担当者とともに善後策、および顧客といかに交渉するか戦略を立てる
- 打合せに入る前に、まず見積り / 契約条件に盛り込んだ（受注者側の考えている）システム仕様をより具体的に文書化して提示する
- 詳細を説明した後、発注者からの「変更要求」を聞くようにするのが仕様の早期確定に有効であるばかりでなく、「仕様変更要求項目」の明確化にも役立つ
- システム全体の開発費用は仕様確定後に決めるという段階的契約方式をとる場合も、顧客側には予算の腹づもりがあるはずなので 、総予算を聞き出して、この予算枠内で仕様をまとめるように顧客をリードする
-
いつまでにシステム仕様を固めるか全体工程の中で顧客と合意し決める
-
もし発注者側の体制や統制力に問題がある場合には、幹部、営業と協力して、発注者幹部に善処してもらえるよう早めに申し入れる
- 業務仕様をどういう順序で確定していくかあらかじめ作戦を立てておく
- プロトタイプ方式を採用するときは、終結時限（仕様凍結時限）を明確に定め、いつまでもやり直しや修正が続かないようにする
- 何のためにシステムが必要とされ、何が一番重要なことなのかを全員が正しく理解する（真の目的を把握していれば、より合理的、より経済的な代案システムの提案も可能となり、システム機能の膨張の抑制につながる）
- 業務の正確な理解に努める（正確な理解とは、その業務の目的、やらなければどういう不都合が生じるのかということまで理解すること）
- 仕様追加がある場合は、要求しても無理だろうなどと考えず、粘り強く予算増額交渉をする
- 仕様が凍結したら、新たな仕様変更要求が出てくる前に、仕様変更案件管理、変更承認手続き、顧客による変更予算認可手続きなどの管理方式を顧客と共同で用意する
- 受注したら直ちに第三者を含めてプロジェクト推進作戦会議を開催し、多角的にリスク回避戦略を議論する
工程設計
ポイント
-
受注後、プロジェクトマネジャーがまずやらねばならないことは、工程の設計と目標原価の設定
-
プロジェクト工程計画とは、そのプロジェクトに挑むプロジェクトマネジャーの作戦計画であるから、まさにマネジャーの、そのプロジェクトに関するすべての知識と認識、今後発生しうる各種の事態に対する予測を含めた見解を表現したものとなる
-
人件費は、ざっと言えば投入工数のみで決まる。投入工数が予算以上に増えるのは工程（スケジュール）が遅延するか、開発量が膨れ上がるか、予想以上に品質が悪いかが主たる原因である。したがって、 コスト管理はとりも直さず、進捗管理、品質管理、仕様変更管理の問題に帰着する
チェックリスト
- 稼働日（=納期）に絶対不可欠な機能と、無理をすればあとからでも追加可能な機能に分ける
- やってみなければわからないことが多くても、最初に全貌を考えぬく積りで極力詳細な工程を設計する
- PERT図の考えを取り入れ、前後関係、相互依存関係が明確になるようにする
- 重要な仕事にはその前に必ず準備作業（仕事の前の仕事）が必要であることを忘れないように
- 工程配分は過去のプロジェクト実績データを参考にすべきであるが、少なくとも3分の1の工程を設計工程に割り当て、手戻りのない設計を目指す
- あらかじめどういう手段で進捗を計るのか考えておく。特に各工程の終了条件を明確に決めておく必要がある（定量的進捗度の把握が大事であるが、質的な進捗度の把握については中身のレビューで補う）
- 計画時には悲観的に最悪事態を想定した準備を行い、実行時は楽観的に明るくプロジェクトを推進する
- 最悪の事態に陥った場合、納期延期を申し入れる日を秘かに決めておく
- 同時に納期までに完成が困難と予想されるときは逃げ道を考えておく（代替手段、部分稼働、従来システムとの並行運転など）
- 工程表が作成できたら顧客と打合せを実施する。このときには、特に仕様凍結日、提出書類の承認期限、顧客側で準備してもらう各種ドキュメントなどの準備期限について合意を得る
- プロジェクトで用意するドキュメント体系、およびその作成基準を定める
- よく使われる業務用語（ジャーゴン）については、素人の人にもわかるような用語集（グロッサリー）を用意し、プロジェクトのステークホルダー全員が共通の理解を持てるようにする
- 大規模プロジェクトの場合はプロジェクトマネジャーの補佐組織として、ライン設計部隊とは別のプロジェクト統括部隊を編成する
- 開発するシステムの目的や基本コンセプト、プロジェクト運営の基本的考え方、プロジェクト共通基準、工程計画に関するプロジェクトマネジャーの考え方などを説明し、全員に理解してもらう（このような全員ミーティングは少なくともプロジェクトのスタート時、主要メンバーが揃って定期的進捗管理が始まったとき、全メンバーが揃ったときの3回は実施したほうがよい）
実装フェーズ
進捗管理
ポイント
- 進捗を定量的、客観的に捉えるとともに、質的な面、つまり設計の充実度、ドキュメントの記述レベル、その内容なども重視して、工程（あるいはスケジュール）の進捗を妨げる問題点の早期把握に努めなければならない
- 仕様変更はプロジェクトの円滑な遂行にはマイナスの影響を与えるが、仕様変更なしのプロジェクトは稀である。したがって、適切な仕様変更管理が必須になる
- プロジェクトの成否を決めるのは、プロジェクトメンバーの力であり、そのチームとしての組織力
チェックリスト
- 計画と実行の差を明確化することに主眼を置かなければならない。すなわち、遅れを遅れとして正しく認識できること
- 進捗度の事前定義と全員への徹底
- プログラム開発においては、無理をしてでも進捗度を定量的に把握する（ページ数、画面数、帳票数、コーディング行数、メモリー量、項目数、定義数、チェックリスト消化数など）
- 責任追及より実態把握を重視。何の助言もなく厳しいだけの管理はかえって実態を隠蔽する危険性がある
- 仕様確定工程は絶対遅れさせないようする。不幸にして顧客の体制が整備されていなかったり、顧客の決定が遅れてきたときは、幹部や営業の協力を得て、顧客幹部に善処してもらえるよう申し入れる
- 進捗把握は担当者から報告された内容だけに頼ってはならない。自分の目で、現場現物を確認する
- 定量的進捗度と同じぐらい重要なのがレビューを活用した質的な進捗度の把握・評価
- レビューは部厚い仕様書ができ上がってから実施するのでなく、ある程度まとまれば少しずつ実施し、だんだんレビューの質あるいは難易度を高めてゆく
- レビュアーの誰かが大幅な変更ややり直しの必要性を訴えるような場合、プロジェクトマネジャーは一番悲観的な意見を採択し、設計のやり直しを決断したほうがよい
- ある担当者の開発部分の品質が時間が経っても一向に改善しないとき、その担当を更迭して一からやり直すのは勇気がいるが、思い切ってやり直しをしたほうが良い結果を生む
- 要員不足だからといって、能力の劣る要員による応援はかえって混乱を招く
- 工程表を書き直していると、工程が遅れてきた実態がわからなくなり危機感も薄くなる。工程表の書き直しは極力やめるべき（やむを得ず書き直して納期を先に延ばす場合は、思い切って実態を正直に反映したものにする）
- 進捗状況がかんばしくないときは早めに営業担当者にその旨漏らしておく
- 混乱したら思い切って開發を止めて、マネージャーの頭の中に実態が正しく認識されるまで徹底的に実態把握に努めるべき
仕様変更管理
ポイント
- 顧客と開發側双方が仕様凍結を宣言できたあとでさえ、さらなる仕様変更が出てくることは実際には多い
- 「仕様変更は不可避」であることを覚悟し、仕様変更による工程の混乱や、収益悪化のリスクを回避するために、変更があってもミニマムな対応ですませる作戦と仕掛けをあらかじめ用意する
チェックリスト
- 仕様変更が続くということは単にベンダーだけの損失でなく、顧客にとってもリスクであり、損失であることを顧客によく理解してもらう
- 仕様変更要求が出た場合、窓口は一元化し、案件管理の手順を定め、変更決定時のソフトウェア/ハードウェア/ドキュメントなどの変更手続きもあらかじめきちんと決めておく
- バグの管理と仕様変更の管理ははっきり分け、別管理にしておく
- システム稼働開始前後数ヶ月の仕様変更は、稼働に不可欠の機能を除き、絶対禁止
組織管理
ポイント
-
プロジェクトメンバーに意欲を持って仕事を行わせるにはモラル（morale: 士気）管理が欠かせない
-
数十名、数百名に及ぶプロジェクトにおいては、メンバー間、チーム間、組織幹部や顧客との間の適切なコミュニケーションが大きな課題になる
チェックリスト
-
担当する仕事が本人や会社にとっても、社会にとっても、どれだけ重要でどんな意義を持っているかを全員にはっきり意識させる
-
チーム編成にあたっては単に技術力中心に考えるのでなく、メンバーのモラルにもできるだけ配慮する
-
プロジェクトメンバーが揃った時点で顧客のリーダーから、開発しようとしているシステムの目的やシステムの全貌、将来構想などを説明してもらう
-
プログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やす
-
プロジェクトメンバー全員を集め、各サブシステムの代表者が、自分たちが何をやって何に苦しんでいるのかを説明し合うプロジェクト説明会を開催する
-
担当させている作業が終わったら次に何をやるのかを早めに示しておく（次の仕事がないと思って、仕事をペースダウンさせてしまうメンバーが出てくるため）
-
あとからプロジェクトに入ってきたメンバーには、単に設計基準を手渡すだけでなく、どうしてそういう基準を作っているのかにまで言及した教育をする
-
大事な内容については別のルートからも確かめるなどのダブルチェックをする
-
大事な連絡や決定事項は文書化が必要
-
仕事の指示をするときは、やるべき仕事と、仕事の期限をはっきり設定することは当然として、何のためにその仕事をやる必要があるのか、仕事の目的を明示する
-
逆に上位者からおおまかな指示を受けた場合、自分と上位者の間には経験や問題意識の差があるのが普通であるから、自分の理解したイメージを自分の言葉で表現して上位者に質問する
-
良い報告はサボってもよいが、悪い報告はできるだけ早くする
-
マネジャーは嫌な報告でも喜んで聞いてやらなければならないし、なんらかの見返りも必要だ。適切なアドバイスが一番望ましいが、最低限激励だけでも良い
-
悪い報告がタイムリーになされないのは部下の躾の悪さより、報告を受けたときのマネジャーの対応に大半の非があると考えて間違い
-
週報や月報は、プロジェクト終了後の反省会の資料にもなるので、大規模プロジェクトや難プロジェクトでは必ず書くようにする
-
部下やチームメンバーに週報、月報等の定期的報告を要求するなら、報告に対して、なんらかの返事やコメントを書くようにする
-
報告に必ず部下を同行する人がいるが、こういうことは極力やめたほうがよい（部下の貴重な時間が無駄であるし、自分一人でゆけば、自分のわかっていないところが明確になって勉強になる）
最後に
プロジェクトマネジメント、簡単な仕事ではありませんよね？プロジェクトでは不確実性、曖昧性が不可避であり、どうしてもドタバタっとしてしまう時が出てしまいます。そんな時は、自分ひとりの知識で戦うのではなく、「曖昧性とのたたかい」のような先駆者の残した知見を頼りに、立ち向かっていきたいものです。本書のなかには、テストや外注先との付き合い方などにも触れられていますので、興味のある人はぜひ手に取ってみてください。自分も経験が積み重なっていけば、現代のシステム開発に適した知見をまとめて本にしたいなとも思ったり。今日も一日がんばりましょう。
「知識ゼロから学ぶソフトウェアテスト」でテストの基本を学ぶ
ソフトウェア開発において切っても切り離すことのできないのが不具合（バグ）。そして、そのバグと表裏一体な存在がテスト。プロジェクトマネジメントをするうえで、テストを適切に工程へ組み込むことは非常に重要なことですが、PMがテストの中身を全く把握していないのは良くないと思い、「知識ゼロから学ぶソフトウェアテスト」を読んでみました。この本、本当に知識ゼロでも読むことができるのでお薦めです。
ソフトウェアテストの実力診断
この本は「完全無欠なソフトウェアテストは可能か？」という問いかけから始まります。そして、いかに完全なソフトウェアテストが難しいものであるかを示すために下記の演習問題が出題されます。
このプログラムでは、ユ ーザーが三つの整数を入力します。この三つの値は 、それぞれ三角形の3辺の長さを表すものとします 。プログラムは、三角形が不等辺三角形 、二等辺三角形 、正三角形のうちのどれであるかを決めるメッセ ージを印字します 。このプログラムをテストするのに十分と思われる一連のテストケースを書いてください。
いかがでしょうか。テストケースのイメージ、湧きますか？僕もこの問題にチャレンジしてみたので、参考まで三角形の判定プログラムとそのテストコードを貼っておきます。※Node.jsのMochaとChaiで書きました。
どう思いますか？これで適切にテストパターンの洗い出しが出来ていると思いますか？...残念ながら答えは「いいえ」です。例えば、僕が書いたコードだと"0, 0, 0"とユーザーが入力した場合でも、正三角形と判定されてしまいます。これは正しい挙動とは言えません。
こうして実際に自分でやってみるとテスト設計の難しさがよくわかります。やはり専任の経験あるテスト担当者がいなければ、品質を担保して製品をリリースすることは難しいでしょう。
では、次に実際にどのようなテストが行われるべきなのかを見てみたいと思います。
ブラックボックステスト
ブラックボックステストは、プログラムを一種のブラックボックスと見立て、さまざまな入力を行うことによって、ソースコードを利用せず（見ずに）行う、というものです。本によれば、現在のソフトウェアテストの大半はこの手法が使用されているとのこと。さっそく詳細を見てみましょう。
同値分割法と境界値分析法
同値分割法
同値分割法は大きく次のような手順で進んでいきます。
- 同値分割
- 有効同値、無効同値に分類
- テストケースを書く
同値分割とは、入力領域をいくつかのクラスに分けて、そのクラスの中の値は同値とみなす行為です。先ほどの三角形判定プログラムのUIが、ユーザーが任意の値を自由に入力できるフォームであると仮定すると、「数字」「文字」「記号」というようにクラス分けできると思います。
次に、有効同値と無効同値ですが、システム仕様から見て、有効な値か無効な値かという意味です。三角形判定プログラムでは、三つの整数が求められている値ですから、有効同値が「数字」、無効同値が「文字」「記号」ということになります。
最後にテストケースを書いていきます。三角形判定プログラムは、入力値が三つの整数だけで、無効同値も2種類しかありませんので、全ての有効同値と無効同値の組み合わせの強固なテストケースが書けると思います。しかし、実際のプログラムでは、無効同値の数や組み合わせ数が多く、テストケースを作ることが困難なこともあります。その場合は、テストケースを省略せざるを得ませんが、だからと言ってバグが起きても良いわけではありません。ちなみに、僕が書いた三角形判定プログラムでは「あ、あ、あ」と入力しても正三角形と出力されます。苦笑
境界値分析法
境界値分析法は、入力領域の境界に焦点を置いてテストを行う手法です。三角形判定プログラムでは、そもそも仕様が「三つの整数」としてあるのが問題でもあるので、整数の境界に焦点を置くのはあまり良いアイディアではありません。ここは三角形が成り立つ数値か？というところに視点を切り替えるべきでしょう。そうすると、入力領域は整数の中の「正の数（1以上の数値）」となります。
では、正の数の境界はどこか考えてみましょう。下の境界は簡単ですね。0以下は正の数ではなくなります。一方、上の境界はどうでしょうか。正の数に上限はありませんので、数値はどこまでも大きくなります。しかし、システム的に処理できる数値には上限があります（JavaScriptの場合は 2^53 - 1）。なので、仕様ではどこかに上限を設定しておくべきだと思います。
実際のテストでは、異なる処理が行われる一番近い2地点を用います。三角形判定プログラムの下の境界で言うと、「0」と「1」です。この境界値分析法と同値分割法を組み合わせることで、効果的かつ効率的にテストケースを作ることができます。
ディシジョンテーブル
ディシジョンデーブルは、すべての入力の組み合わせとそれに対する出力を表にまとめたものです。三角形判定プログラムでは、数値によって、「正三角形」「二等辺三角形」「不等辺三角形」と出力結果が変わります。組み合わせの複雑になるので、それらを表に可視化することで、漏れを防ぐことができます。基本のアイディアは同値分割法・境界値分析法と同じですが、多数の入出力をチェックするときに有効な手段となります。
自分の書いたコードでやってみました。本プログラムでは、各三角形ごとの組み合わせの入力値を書いてまとめた方がわかりやすいかなと思いました。本では、状態は「TRUE」「FALSE」だけの記載でしたが、実態に合わせて臨機応変にしても良いと思います。しかしまあ散々な結果ですね。ひどい。苦笑
状態遷移テスト
状態遷移テストは、状態によって出力結果が変わる場合に用いられるテストです。どういうイベントのときに、どのように状態が遷移するかを一覧にし、各遷移をチェックしていくというものですが、この三角形判定プログラムの例では説明できそうにありません。詳細は下の記事がよくまとまっているので参考にしてください。
ランダムテスト（モンキーテスト）
これはランダムにソフトウェアを操作し、バグを洗い出すテストです。著者はこの手法に関しては、批判的な意見を持っているようで、推奨していませんでした。テスト設計の必要もないし、一定数のバグは見つかるだろうが、バグはランダムテストでは見つからないところにまだまだ潜んでいると。
以上がブラックボックステストの手法として紹介されているものでした。ソフトウェアの複雑さにもよりますが、「同値分割と境界値分析 → ディシジョンテーブル → 状態遷移テスト」は、どのソフトウェアにおいても最低限実施すべきものだと思います。ランダムテストについては、個人的にはそこにテスターの労力を割くのであれば、別のテストを実施した方が良いと思いますね。
まとめ
本では、ブラックボックステスト以外にも「探索テスト」「非機能テスト」「セキュリティテスト」などの重要なものが説明されています（詳細はぜひ本をお読みください）。月並みな感想ですが、テストの奥深さと難しさに驚きました。プログラムを書くこと以上にテストを作ることの方が難しいのではと思ったぐらいです。品質要求を満たしたプロダクト、不具合のないプロダクトを出すために必要な労力を改めて認識し、今後のプロジェクトマネジメントに活かしていきたいと思います。
マイヒーロー、イチロー
イチローの試合を観戦するために、シアトルのセイフコ・フィールドに行ってきました。が、残念ながらイチローのプレーを観ることはできませんでした。ご存知の通り、5月4日にイチローは球団の特別アドバイザーに就任し、今シーズンはもう試合に出場しないという報道が出ています。僕がチケットを取ったのは4月16日だったので、タッチの差で間に合いませんでした。僕のことをよく知る人は「あれ？そんなに野球が好きだったっけ？」と思うかもしれません。実際、野球がそこまで好きというわけではありません。ただイチローが好きでした。セイフコ・フィールドに行ってきて、高まった気持ちを胸に盛大にポエらせて頂ければと思います。
あいにくの曇り。それでも美しいセイフコ・フィールド
イチローとの出会い
そもそも野球を見ない僕は、日本でのイチローをあまり知りません。パワプロで「サクセスじゃないのにオールAに近い選手がいる」と思っていた程度です。むしろイチローは扱いづらいキャラでした。ミートが広くてパワーが中途半端にあると打ち損じが出やすいというの僕の自論です。ヒット狙いの選手はミートC、パワーCぐらいがちょうど良い。...話を戻します。
僕がイチローの試合を初めて見たのは、メジャー移籍後のオールスターゲームでした。当時の僕は中学校3年生。試合は学校の時間でしたが、野球部の同級生が「先生、お願い！イチローの打席だけ見せて！」と懇願しました。「第一打席だけだぞ」と返す先生。いま思うとこの先生も見たくて堪らなかったに違いありません（ちなみに野球部の顧問の先生でした）。そして、僕たちはイチローがランディー・ジョンソンから内野安打を打つところを目撃したのです。
イチローに興味を持つ
それから3年後、イチローはメジャーリーグの年間最多安打記録を塗り替えようとしていました。当時の僕は高校3年生。学校へ行く前にテレビを見ていたのですが、イチローのニュースは毎日取り上げられていました。しかし、はっきり言って、僕は無理だと思っていました。たしか夏休みの終わった9月中頃に、イチローは一度無安打をやってしまいます。その時、ニュースのレポーターも「これで残り◯試合で◯本、1日◯本のペースでヒットを打たないといけません。厳しくなってきました。（※はっきりと数字を覚えていないが15試合で20本ぐらいの厳しい数字だったはず）」と話していたのを覚えています。ところがどっこい、その後イチローは5打数5安打, 6打数4安打とヒットを量産して逆境をひっくり返してしまうのでした。
そしてその瞬間へ。もうね、映画ですよね、これ。鳴り止まない歓声と拍手、駆け寄るチームメイト、前記録保持者のジョージ・シスラーの娘との握手、まるでひとつのショーを見ているようです。
イチローのファンへ
僕は2004年の記録達成をきっかけにイチローのファンになったわけではありません。 ファンになるのはそれから3年ほど経ってからのこと。当時の僕は成人して、社会人になっていました。仕事は個人宅への外回りの営業職、簡単な仕事ではありませんでした。「いま天ぷら揚げているから結構です！」何度こう断られたことでしょう。「マジでこの断り文句が使われるのか」などと思いながら、毎日16時〜21時の間は外回りをしていました。
夏は暑いし冬は寒い。業務の過酷さに加えて、なかなかのブラック企業だったので、酷いときは2ヶ月間休みがないときもありました。仕事の調子の良いときは、稼げせてそれなりに楽しい仕事でしたが、調子の悪いときはかなり辛いものでした。1日誰にも話すら聞いてもらえず、インターホンで断られ続け、会社に戻ると上司に激詰めされる。「売れるまで帰って来るな！」と、電話で突き放される日もありました。そんな職場だったので、モチベーションをいかに管理するかは多くの社員の共有の悩みでした。
「トッキー、良い本があるよ。」
そう声をかけてくれて、とある人に手渡されたのが、イチロー 262のメッセージという本です。
- 作者: 『夢をつかむイチロー262のメッセージ』編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2005/03/11
- メディア: 単行本
- 購入: 12人 クリック: 143回
- この商品を含むブログ (119件) を見る
この本にはイチローがメジャーデビューから4年の間にした発言が抜粋して載せられています。特になにか解説があるわけでもなく、ただ淡々とイチローの発言が紹介されているだけなのですが、これが妙に心に刺さりました。一部を引用して紹介します。
こんなに苦しいのは自分だけか、と思うこともあります。それを見せるか見せないかだけの話です。みなさん、ぼくのことは、疲れていないと思っていませんか？
ぼくも、グラウンドに行きたくない日はたくさんあるのです。そのときには職業意識が出てきます。「仕事だからしょうがない」と、自分に言い聞かせるときもあるのです
グラウンドの上では、自分の築きあげてきた技術に対する自信、今までやってきたことに対する自信、「やりたい」と思う強い気持ちが、支えになります
僕はこの本を読むまで、イチローがこんなに苦しみながら野球をしているとは考えたこともありませんでした。メンタルをコントロールし、高いプロフェッショナル意識をもって野球と向き合うイチロー。一気にイチローのファンになりました。
それから毎日イチローのニュースを追いかけました。勝手にイチローをライバル視して、イチローがヒット2本なら、僕も2契約を取るまで頑張ろうと、仕事の目標にしたりもしました。他にも、mixiのイチローコミュニティで実況しながら試合を見たり、「Road to 4256」というトピックでイチローのヒットを皆でカウントしたりとか。ちなみに、4256とはピート・ローズが残した通算安打数のMLB記録です。当時カウントしているときは遥か先の夢のような数字でしたが、本当に達成してしまうイチローは本当に凄いです。
仕事の営業の数字に追われていた日々の中で、イチローの安打数という他に意識を置く数字ができたことは本当に救いでした。また、イチローの野球への姿勢を少しでも見習おうと心がけて仕事をすることで、自分の中にも徐々にプロフェッショナル意識が生まれてきたように思います。職業人の理想像であり続けてくれたイチローには感謝しかありません。
最後に
特別アドバイザーに就任して試合にはもう出場しないということから、事実上の引退という声も出ています。マリナーズとの契約としては、来季試合に出場する可能性は残した内容になっているそうですが、僕も来年になって第一線へ復帰するのは難しいと言わざるをえないと思います。しかし、イチローは常々50歳までプレーしたいと公言していますし、チームに帯同しての練習は続けていくそうです。現在44歳のイチロー、今後どうなっていくのか、何をしていくのか、まだまだ目が離せません。最後の最後までイチローを応援していきたいと思います。ありがとう、イチロー！
All the feels.
— MLB (@MLB) 2018年5月3日
💚 💙 #ThankYouIchiro pic.twitter.com/U5fQAx1uWW
おまけ
オバマ前大統領がイチローの話をしているこのシーンがとても好き。
I talked to Ichiro and I said, now, how exactly do you throw that ball from in the outfield to home plate like a laser? He said, "Soft muscle." He said, "You don't need to be big." it was a very zen-like answer. He's an impressive guy.
レーザービームのような送球をどうやって投げるのか？というオバマの問いに対して、「ソフトマッスルです。大きな筋肉は必要ありません。」と答えたイチロー。オバマはそれを”まるで禅のような答え”とコメントしています。オバマにさえ認められるイチロー、素敵すぎる。
後、イチロー 262のメッセージ、イチローが好きな人には本当お薦めです。 未読の方はぜひどうぞ。
- 作者: 『夢をつかむイチロー262のメッセージ』編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2005/03/11
- メディア: 単行本
- 購入: 12人 クリック: 143回
- この商品を含むブログ (119件) を見る
- 作者: 「未来をかえるイチロー262のNextメッセージ」編集委員会
- 出版社/メーカー: ぴあ
- 発売日: 2007/12/19
- メディア: 単行本
- 購入: 6人 クリック: 84回
- この商品を含むブログ (36件) を見る
ムダ・ムラ・ムリを取り除け！トヨタ生産方式に学ぶプロジェクトマネジメント
前回のエントリーで、プロジェクトの遂行能力を上げるには、組織の体制や行動習慣を向上させる必要があるということを書きました。組織の行動習慣と言えば、やはりトヨタ。車の製造は、ITの世界と勝手が違っていても、モノづくりの現場から学ぶことは多くあるはずです。特に、何かを大量に作らなければいけないプロジェクトでは、特定の技術力だけではなく、大量生産に耐えられるノウハウが重要です。ということで、「トヨタ 仕事の基本大全」という本を読んでみました。
大量生産型モノづくりの指針「ムダ・ムラ・ムリを取り除く」
IT業界は大量生産とは無縁なのではと思うかもしれませんが、実はそうでもありません。自分の過去の業務を振り返っても、SEO対策をしていたときはブログの記事を、教材開発をしていたときは問題や例文を大量に制作していました。
一つのモノの品質を追求するには職人の技が必要ですが、何万個のモノを同じ品質で提供するにはシステマチックなマネジメントが必要です。トヨタは年間で一千万台以上の車を製造していますが、いずれも高い品質を保っており、高度な技術力と生産方式を兼ね合わせた素晴らしい企業だと思います。
そのトヨタで推奨されているのが「 ムダ・ムラ・ムリを取り除く」ということ。プロジェクトマネジメントの本質は時間・コスト・品質をマネジメントすることですが、このムダ・ムラ・ムリはそれらに密接に関わっています。
ムダ
「トヨタ 仕事の基本大全」によると、ムダは次のように定義されています。
トヨタでは、ムダを「付加価値を高めない現象や結果」と定義し、「７つのムダ」（❶つくりすぎのムダ、❷手待ちのムダ、❸運搬のムダ、❹加工そのもののムダ、❺在庫のムダ、❻動作のムダ、❼不良をつくるムダ）をなくすことを徹底しています
このようなムダをなくす為に、あの有名な「5S」や「自工程完結」という考え方があるというわけです。この２つは既にご存知の方も多いと思いますが一応説明をします。
「5S」は整理・整頓・清掃・清潔・しつけの頭文字をとったもので、これを徹底することで "必要なもの" を "必要なとき" に "必要なだけ" 取り出せることができるようになります。
「自工程完結」は作業のやり直しが発生しないように自分の工程で作り込むことを意味します。例えば、教材の問題作りで、ラフ作成の手を抜いてしまい、最後の校正で問題の作り直しになったとします。そうなれば、ラフ作成の後にした作業、例えばデザインあて等の時間がムダになってしまいます。一つひとつの工程でしっかりと作り込んでいれば、やり直しのムダはありませんし、通常工程の校正の工数も軽くなります。
ムダが出れば出るほど、工数に影響があるため、ムダをなくすことはコストを抑えることと同義であると言えます。上で引用した7つのムダをなくす為に、様々な改善活動を続けるのがトヨタの仕事の進め方だそうです。
ムラ
モノづくりでは、納品の後に不良品がないかを調べる「検品」や、発注した内容通りに作られているかをチェックする「検収」というものがあります。もし不良品率が高ければ、不良を作るムダが発生していますし、そもそもクライアントの信頼を損ねて今後のビジネスがなくなってしまうかもしれません。品質にムラを出さないというのは非常に重要なことです。では、トヨタではムラをなくす為にどのような取り組みをしているのでしょうか。
トヨタには「標準」という考え方があります。 標準とは、各作業のやり方や条件であり、作業者はこれにもとづきながら、仕事をこなしていきます。簡単にいえば、標準とは、「このようにつくりましょう」という取り決めです。具体的には、作業要領書や作業指導書、品質チェック要領書、刃具取り替え作業要領書など「標準書」は多岐にわたります。これらは、少しずつ各職場でつくられてきたもので、まさに現場の知恵が凝縮された手引書です。たとえば、ある部品のボルトを締める作業があるとき、「しっかり締めろよ」と教えても、人によって「しっかり」の解釈に誤差があるため、ボルトが緩い状態になってしまう可能性があります。しかし、「カチッという音がするまで締める」という標準が決められていれば、誰でも同じ強さで締められます。標準とは「誰がやっても同じものができるしくみ」なのです
大量生産型のモノづくりでは、特定の人や機械に依存することはできません。あの機械を使えば良いものができるがこの機械を使えば不良品が出る...そんな状況では不良品率は跳ね上がってしまうでしょう。きちんと品質を担保する為、誰がどこで作業しても同じ品質が出るようにムラをなくすことは非常に重要です。
ムリ
さて、ここまで ”プロジェクトマネジメントの本質は、時間・コスト・品質をマネジメントすること”とし、ムダはコスト、ムラは品質に関わっていることを書きました。では、ムダはどういう位置づけなのでしょうか？実は、「トヨタ 仕事の基本大全」ではムダについてはあまり触れられていませんでした。そこで、自分なりに考えてみたのですが、ムリはムダやムリを生む根本原因になるという結論に至りました。
例えば、要件定義が十分でないのに仮説で仕様を決めて実装をするというムリをすると、後になって実装のやり直しが発生する可能性が高まります。つまり、ムダが生まれやすくなります。例えば、長時間労働を前提にプロジェクトを進めるというムリをすると、日常業務の集中力が落ちて不良品が出る可能性が高まります。つまり、ムラが生まれやすくなります。
このように、あれほど良くないと述べたムダやムラを容易に生み出してしまうのがムリです。プロジェクトではムリをせざるを得ない状況が出てくるのは避けられないと思いますが、計画段階ではムリを最大限排除するのが賢明でしょう。一見、不必要にゆとりがあるように見える計画が、実はムダとムラを取り除ける効率の良いプロジェクトの進め方なのだと思います。
最後に
失敗したプロジェクトの事例を見てみると、精神論が先行したマネジメントが散見されます。精神論の多くはムリを誘発するもので、その最たる例が大日本帝国だと僕は思っています（計画性のないムリな侵略で100万人を超える餓死者を出した）。 プロジェクトは不確実性との戦いであるからこそ、まずムリのない計画を立てること。そして、その上で、ムダとムラをなくせる仕組みづくりをすることが重要なのだと思います。
トヨタ生産方式、業界を問わず、モノづくりに関わる人にはお薦めです。
Googleスプレッドシートでプレシデンス・ダイアグラム法（PDM）を自動生成するアドオンを作ってみた
プロジェクトマネジメントの手法の一つにプレシデンス・ダイアグラム法（Precedence Diagram Method）というものがあります。これを使えば、各アクティビティごとの作業順序や依存関係が明らかになり、どのアクティビティが、絶対に遅れてはならないクリティカルパスなのか、逆に遅れてもよいフロート*を持つものなのか、を知ることができます。しかし、有効な手法である反面、一つひとつのアクティビティを依存関係に沿って繋ぎ、期間を計算をするのは骨が折れます。そこで、Googleスプレッドシートで自動生成をしてくれるアドオンを作成してみました。
*フロートとバッファはよく混同されますが別のものです。フロートとはスケジュールに影響なくアクティビティを遅らせられる期間を意味します。ちなみに、フロートが0のアクティビティを繋いだものがクリティカルパスです。
Precedence Diagram Maker
アクティビティをリストアップし、必要な情報を入力するだけで、自動でネットワーク図を生成してくれるアドオンです。WBS作成後など、やることが決まって「さあこれからスケジュールに落とし込むぞ」というときに活用するのが効果的です。
インストール
Precedence Diagram Maker - Google Sheets add-on
上記にPCからアクセスして、Googleアカウントにログインし、「インストール」をクリック。
Precedence Diagram Makerで出来ること
- PDMのネットワーク図を自動生成
- プロジェクト全体の必要総期間を自動計算
- クリティカルパスを赤色で表示
仕様
アドオンメニュー
| 目次 | 動作結果 |
|---|---|
| プレシデンス・ダイアグラムの作成 | listシートを作成 |
| サイドバーの表示 | サイドバーを表示 |
サイドバー
| 目次 | 動作結果 |
|---|---|
| Project Nameフォーム（任意） | プロジェクト名を入力すればネットワーク図に反映される |
| 実行 | diagramシートを作成し、listシートの情報を元にネットワーク図を自動生成 |
listシート
| 目次 | 内容 |
|---|---|
| アクティビティ一覧 | アクティビティ名を入力（IDが自動付与される） |
| 期間 | 数字を入力 |
| 先行ID |
先行するアクティビティIDを入力。最初のアクティビティの場合は0に 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: 1,2） |
| 関係性 |
アクティビティの依存関係を入力。FS (Finish to Start), SS (Start to Start), SF (Start to Finish), FF (Finish to Finish) のいずれかを選ぶこと 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: FS,SS） |
| リード / ラグ |
数字を入力。リードタイムのときは負の数を、ラグタイムをのときは正の数に 先行アクティビティが複数ある場合はコンマ区切りで入力すること（例: -10,0） |
diagramシート
| 目次 | 内容 |
|---|---|
| 欄外 | （ID）関係性_リード/ラグ）の順で先行アクティビティの情報を表示 |
| 一列目 |
赤色...クリティカルパス、灰色...一般のアクティビティ アクティビティIDと必要期間を表示 |
| 二列目 | 最も早い開始日と終了日を表示 |
| 三列目 | アクティビティ名を表示 |
| 四列目 | 最も遅い開始日と終了日を表示 |
お薦めの活用法
大雑把にですが、スケジューリングは次の順に進んでいきます。5番目のところで、このアドオンを用いて、全体の工期（クリティカルパスの期間の合計）を出すのがお薦めの活用法です。
- プロジェクト達成に必要なアクティビティを洗い出す
- 各アクティビティを担当するメンバー構成を考える
- 作業量と担当するメンバーから対応に必要な期間を出す
- 着手に必要なインプットと、完了時のアウトプットを整理し、アクティビティの依存関係を明らかにする
- 依存関係に基づいてアクティビティをつなぎ、全体の工期を計算する
制約
- シート名を変更しない
- 1行目より上に行の挿入をしない
- 非表示の2行目を編集 / 削除しない
- 各項目の間に列を挿入しない
以上です。ソースコードはGithubに公開しているので興味がある人はどうぞ。また、追加して欲しい機能やバグなどあればこちらのフォームからご連絡ください。まあ正直なところ、今回のアドオンは用途が限定的なので、どれだけの人に役立つか不明なのですが。個人的には仕様に落とし込む過程で理論を深く理解することができたので、開発して良かったなと思います。もし「ちょうどこんなアドオンが欲しかったんだぜ！」という人がいれば、ぜひいつものあれをお願いします。
=> Amazon欲しいものリスト / PayPal
プロジェクトの遂行能力を高める方法
プロジェクトの遂行能力を高めたいというのは、プロジェクトマネージャーの共通の願いであると思います。しかし、どのように遂行能力を高めるか？の答えを持っている人は少数ではないでしょうか。このエントリーでは、日揮でプロジェクトマネージャーを務めていた佐藤知一氏の著書「世界を動かすプロジェクトマネジメントの教科書」を引用しながら、その方法論を考えてみたいと思います。ところで、佐藤氏のブログ「タイム・コンサルタントの日誌から」は玉石混淆なインターネットの中にある素晴らしい情報源です。プロジェクトマネジメントに関わる人は必読です。
世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
プロジェクトの遂行能力とは？
佐藤氏は著書の中で、プロジェクトはチームで取り組むもの。プロジェクトの遂行能力は、リーダー個人の能力ではなく、組織の能力である。優秀なプロマネをスカウトしてリーダーに据えれば上手くいくというのは誤りで、個人を支える組織の体制や行動習慣が重要である、と提唱しています。また、それをコンテンツ・アプリケーション・OSに例えて、下記のように図解しています。
コンピュータにコンテンツだけあっても有用とは言えません。コンテンツを活用する為のアプリケーションがあって然るべきですし、そのアプリケーションもOS（Operation System）がなければ動きません。同様に、個人の持つプロジェクトマネジメントの知識だけではあまり意味がなく、社内にあるデータや制度、そして何より、その会社に属する人の行動習慣が重要になる、ということです。つまり、プロジェクトの遂行能力を高めるには、組織のOSをアップデートする必要があると言えます。
現実的には「鶏が先か、卵が先か」で、優秀なマネージャーがいなければ、優れた組織体制や行動習慣は生成されないかもしれません。ここで大事なことは、コンテンツ・アプリケーション・OSの3つの要素を強化する必要があると、まず認識することだと思います。その前提に立てば、経験豊富なプロマネを採用して終わりとはならず、本質的にプロジェクトの遂行能力を高めるところまで進めるはずです。
さて、次にプロジェクトマネジメントのコンテンツ・アプリケーション・OSが何なのか自分なりに考えてみたいと思います。
コンテンツ（プロマネ個人スキル）
プロマネの個人スキルは、知識・経験・人間力の3つ要素で構成されていると思います。
知識は、EVMS (Earned Value Management System) ・ WBS (Work Breakdown Structure) ・ PDM (Precedence Diagram Method) などのプロジェクトマネジメント理論や、アジャイル型開発・ウォーターフォール型開発などのフレームワークを指します。
経験は、上記の知識を業務で使用したことがあるかどうかです。やはり、"知っている”と”やったことがある”には大きな差があります。状況に合わせて適切な判断を下すには、それぞれの理論やフレームワークのメリット・デメリットを身体で理解している必要があります。
最後に人間力。プロジェクトメンバーが人間で構成される以上、感情の要素を除くことはできません。様々なステークホルダーと信頼関係を築き、プロジェクトを円滑に回すことは重要なスキルの一つです。
アプリケーション（データ・業務プロセス）
上記のピラミッドでは、アプリケーションは過去データや情報システムなどの要素で構成されていますが、ここは大きくデータと業務プロセスに分類してしまって良いと思います。
データは、過去に同種のプロジェクトに要した時間やメンバー構成、WBS、発生した欠陥などの情報を指します。プロジェクトマネジメントは、端的に言うと、時間・スコープ・お金の3点のマネジメントです。それらの過去データが蓄積されていれば、正しい判断を下せる可能性が高まります。
業務プロセスは、作業要領書や仕様書のようなドキュメント、gitやredmineのようなツール、その他ヒューマンエラー防いだり、作業速度を上げる為のシステムなどを意味します。ドキュメントやツールを用いて、品質を高められた状態で作業の標準化ができれば、個人への依存度が下がり、効率的に作業を進められるようになります。
OS（組織体制・行動習慣）
さて、ピラミッドで一番の比重を占める OS、つまり組織体制と行動習慣ですが、個人的には組織体制よりも行動習慣の方が重要度が高いと考えています。
組織体制は定義の広い言葉ですが、代表的なところで言えば、意思決定のスピード・権限委譲・人事制度・財務制度などでしょうか。こうした組織体制が整っていないと、たとえ個人がどれだけ頑張っても、またはどんなに便利なツールがあったとしても、あまり意味がありません。
次に行動習慣ですが、これは会社の文化と言い換えられるかもしれません。僕はトヨタグループの商社で働いた経験があるのですが、そこでは隅々までトヨタの文化が浸透しているのがよくわかりました。
例えば、有名な三現主義。"三現"とは、現場・現物・現実を指し、 現場に足を運び、現物を手に取り、現実を自分の目で見て確認するというものです。これは驚くほどの徹底ぶりでした。役職者の現場を見ずにの意思決定は見たことがありません。効率が悪いのでは？と思う人もいるかもしれませんが、こうした初期フェーズにパワーをかけることによって、不良品の流通を防ぎ、長期的な効率化が図られていると思います。
トヨタの良い文化を説明し始めると長くなるのですが、僕が感銘を受けたものをもう一つ挙げると、バッドニュース・ファーストというものがあります。これは「悪いニュースほど真っ先に報連相せよ」ということなのですが、言うは易く行うは難しで、組織として実現する難易度は高いです。というのも、上長は悪いニュースを受けても部下を感情的に怒らないというのがセットでないと成立しないからです。僕がいた組織では、どんなに悪いニュースを報告しても「報告してくれてありがとう」と、上長が部下を褒めるところを何度も見ました（ちなみに、バッドニュースの報告が遅いと怒られますw）。これも組織に根付く行動習慣の一つだと思います。トヨタグループでは、問題が起きるとすぐに上長へ情報が届き、適切な初期対応を取ることが可能になっています。
まとめ
プロジェクトの遂行能力のピラミッドを考えると、個人に出来ることは限られています。しかし、大前提として日々の勉強を怠ってはいけません。プロジェクトマネジメントは科学的なアプローチの研究が進んでいるので、積極的にその理論は取り入れるべきです。
ただ、組織体制や行動習慣に大きな比重がある以上はここを改善していく施策も行っていく必要があります。しかし、僕ではその効果的な具体策が今ひとつ見えないのが現状です。第一歩は周囲の人にその重要性を認識してもらい、味方を増やしていくことでしょうか。組織体制や行動習慣を個人の発信で変えるのは簡単ではありません。が、佐藤氏も著書の中で言っていましたが「ローマは一日にして成らず」。理想像をしっかり持ち、一歩ずつ前に進んでいくことが地道ですが確実な方法だと思います。
世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方
- 作者: 佐藤知一
- 出版社/メーカー: 技術評論社
- 発売日: 2015/09/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
