[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用]

Pocket

最近考えていることに、「習得したスキルの再利用」というものがあります。

再利用
再利用

小学生でも分かるように言えば、ならった足し算・引き算・掛け算をつかって、販売する商品の料金を計算することです。
何を当たり前のことをと思われるかも知れませんが、このごく当たり前のスキルではなく、社会人になって業務や勉強して取得したスキルを同様に応用できないでしょうか。

IT業界のエンジニアでいけば、そのプログラミングやサーバ構築、ネットワークの敷設は他に役に立たないだろうかと。
まぁ、残念ながらこのようなプロダクトに依存するスキルというものは再利用が難しいのですが、プロジェクト管理やアーキテクチャデザイン(設計)、はてはコンサルで使うテンプレートや、交渉術と言ったものは抽象度も高く、日常への転用・再利用性が高いものと言えます。

せっかく、習得した技術です。これらを使って、日常生活を豊かにすることができないだろうか、なんてことを最近考えて暮らしています。

目次

1.プロジェクト管理は応用の幅が広い

Meetingコンサルティングツールのほうが応用が利きやすいですし、一つ一つが細かいので適用分野が多いのですが、エンジニアがだいたい関わっていて再利用性が高いものとして、プロジェクト管理をあげます。
プロジェクト管理は、とくに ITに特化した話ではなく、どのようなものでも「プロジェクト」でありさえすれば、どこにでも応用が利きます。
日常生活ではあまり発生しないけれども、人生において数度は発生するであろうイベントは、ほとんどのケースにおいて「プロジェクト」とみなすことができます。

例えば、引っ越しや結婚式、身近なものでは誕生日パーティーのイベントの実施など、これらは「プロジェクト」として扱うこともできるでしょう。私個人としては、50人以上が参加した花見や、200人規模のオフ会において、こういったプロジェクト管理技法を使って、実践したケースもあります。このあたりは、長い時間をかけて実現しているので、再利用性の高いものが結果として残っています。機会があれば、ご紹介したいですね。

さて、「プロジェクト管理」と言ってもさまざまなツールやプロセスがありますね。
その中でも特に「WBS “Work Breakdown Structure – Wikipedia“」は一番使い勝手の良いツールではないでしょうか。少し大きなイベントになりますと、いつまでに何を実行して、誰が何をするのか、どのタスクを実行するには、何が終わっていなければならないかがはっきりしないと、ぎりぎりになっててんやわんやすることになります。そうならないように、タスクを並べて、実現可能性を検討し、計画を立てることが WBSでは可能です。
アプローチとしては、大きな枠となる「準備」「当日」「事後」といった「期間」や「居間」「寝室」「台所」といった「場所」といった網羅性のあるものをベースにブレークダウンしていく方法が良く取られます。 [I]だから Work Breakdown なんですね
ありがちな方法として、思いつく小さなタスクを集めていってグループ化するボトムアップで実現する方法もありますが、この場合、それらのタスクに網羅性があるかどうかが判断しにくいため、トップダウンのアプローチを利用することを推奨しています。このように実行するタスクの網羅性を担保した上で、誰が何をいつまでに実現するかを明確にすることができ、作業の抜け漏れを防ぐことができます。

むかし、MS Projcet のサンプルテンプレートに、「引っ越し」や「結婚」のサンプルがはいっていました。このように、すでにあるものを再利用することも、網羅性の観点からは、良いアプローチと考えられます。

2.日々の雑然としたことはアジャイルですませている

agileそんなこといったところで、とても面倒じゃない、日々の活動には、そこまで考えられないわ、という人もいるでしょう。ただ、知らぬ間に勝手に使っているケースがあります。それがアジャイルのアプローチです。

部屋の模様替えをしようと言ったとき、どのようにしていますか?
「机を窓際に並べたいなー」という「要求」を元に、少しずつ変えることはありませんか?
ひとまず、机の位置を変えて、それでしっくりくるかどうかしばらくの間試してみて、問題なければそのまま、不都合があればまた別の場所へ移動するか、元の場所へ戻すでしょう。このように、テストをした上で再評価し、また変更作業を繰り返していきます。短い期間で見ると分かりませんが、5年程度のスパンで見てみれば、人によっては幾度となく模様替えをしていたりしないでしょうか?

これこそまさにアジャイルなアプローチと言ってもいいんじゃないでしょうか?
ということは、日常生活でのちょっとした改善活動や、新たな要求事項に対して、アジャイルのアプローチを適用して実現することも可能ということを示唆しています。

多分。

3.ウォーターフォール型アプローチ

waterfallその中でも特に私が推していきたいのは「ウォーターフォール型アプローチ」です。
今更かよとか言わないでください。イベントや要求の実現にあたって、頭の中を整理するために良いアプローチと言うことで、実現方法はアジャイルとの組み合わせでも構いません。ただ、ベースに基礎となるアプローチを理解していれば、組み合わせの応用などへの適用もカンタンになります。
まず、要求事項を整理して、何を具体化したら良いかを判断するために、一体、今の財力でどこまで実現をできるのか、と言うことを整理して実践してみようということです。

まず、ウォーターフォール型アプローチとはなんぞやと言いますと、一つのフェーズが終わって「完了!」となったら次のフェーズへ行く、シリアライズされたものです。
聞いたことはあるかと思いますが「要件定義(RD [II]Requirement Definition )」→「基本(外部)設計(ED [III]External Design )」→「詳細(内部)設計(ID [IV]Internal Design )」→「開発(CD [V]Coding )」→「テスト(UT/IT/ST/UAT [VI]Unit Test / Integrated Test / System(Cycle) Test / User Acceptance Test )」というのが一般的な流れです。これらを順番に実施していくわけです。
従って、要件定義のフェーズが完了しないことには、設計には移れず、各フェーズでの遅延が先々にも響くということになり、スケジュールの調整と管理が重要なアプローチです。
また、後続のフェーズで、前段のフェーズのまちがいに気がついたときなど、一旦、前のフェーズに戻ってやり直す「手戻り」が発生し、スケジュール遅延は必至になります

このように、リスクの高いアプローチではありますが、一つ一つを順番に区切って進めていくので、構成自体が単純で理解しやすく、コントロールしやすいメリットが上げられます。
また、どうしても手戻りを発生させたくなかったり、プロジェクト規模がおおきすぎて、統一した見解と全体のコントロールが必要な場合は、必然的にウォーターフォール型アプローチを採用せざるをえない状況にあります。大規模プロジェクトは、関わる人間が多いこともありますが、関連するサブシステム(他者)が多く、調整ごとが大変なため、フェーズを区切って対応していくことが望まれます。そのほうが、スケジュールの精査が実施しやすいからです。また、複数の作業をひとまとめで実施できるため、集中して作業を実施することで作業工数を削減する効果もなきにしもあらずです。

このように、時間軸をベースにアプローチするので、「事前」「当日」「事後」を元にフェージングしていく方法が多いのですが、ほとんどのケースにおいて、先に述べた RD→ED→ID→CD/UT→IT→ST→UATが使えます。
大抵のイベントによるプロジェクトは、何らかの「要求」をベースに開始されるため、この方式で順次展開していくことが可能です。引っ越しも「新しい家に住みたい」だったり「転勤で…」という制約から発生する場合もあります。結婚も「結婚したい」という要求から実現するわけですから、この流れを順当に進めることで対応できるのではないでしょうか。

ということで、実際に、ウォーターフォール型アプローチによる、最近実際に実践した方法と組み合わせてみましたので、次回ご紹介します(次に続くのかよ)

[tmkm-amazon]4798025224[/tmkm-amazon]
[tmkm-amazon]B00E5JZ8WW[/tmkm-amazon]

References

References
I だから Work Breakdown なんですね
II Requirement Definition
III External Design
IV Internal Design
V Coding
VI Unit Test / Integrated Test / System(Cycle) Test / User Acceptance Test

“[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用]” への1件の返信

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください