複雑な話を分かりやすくする方法

はいこんにちは。毎度おなじみゼバ会です。

。。。あ、いやいや違う違う。私の名前はゼバ会じゃない。
私は中島ね。
そんで会の名前がゼバ会。
あれ、それも違う。会の名前は「絶対バグらないシステム作ろうぜの会」だったはず。
ん、、、？　てことは「ゼバ」っていったいなんだったっけ、、、？(汗

まいっか。
本日は、「複雑な概念を分かりやすくかみ砕く」という話です。
デキるビジネスパーソンの必須スキル《スモールステップ化》でございます。
プログラマーに限らず、どなたでも便利に活用できるテクニックです。

皆さんの中にも、こんな人いませんか？

1. 自分はとっても忙しいのに、だからといって部下をつけられても振る仕事が作れない
2. プログラムを書きながらじゃないと詳細設計ができない
3. 仕事を始めようとした途端、心理的抵抗を感じて嫌になる

これらは、自分がやる仕事をリスト状に分解して考えることができていない人に起こるものです。

仕事（に限らず人間の行動の全て）には必ず「順序」ってものがありますよね。
だって、複数の物事を同時にやる人はいませんからね。
まぁ、絶対に無理ですからね。

とはいえそんなふうに言われると、「いやいや、私はいつもたくさんの並行作業をやってるよ」って人はいると思います。
ですが、それは色んなタスクに時間を小分けに割り振るという作業のやり方に「平行作業」という名前をつけているだけであって、２種類の行為を物理的に同時にとっているわけではありません。
人間が２つの行動を文字通り同時に行うのは、生体的にも物理的にも不可能です。
ということは、ゆえに理屈のうえでは、人間がとりうるありとあらゆる行動は、書いてある通りにやれば成功するという手順書が作れるはずなわけです。

もちろん理屈のうえでは、なので、この世のあらゆる仕事に手順書を作るのは無理です。
ミリオンヒットするマンガを描く手順書とかあったら、そんなんみんな使うわ。

が、とはいえ「普段毎日やってる自分の仕事の手順書が作れない」のは正直言って問題です。

ビジネス本などを読むと、手順書が作れない業務の典型例として「プログラマー」が挙がっていることがよくあります。
てゆーか、みんな判で押したようにプログラマーの仕事は手順書が作れないことにしたがるんです。
あれなんで？

だってさ、もし皆さんがプログラマーなら、
1. 作業開始前に上司の話を聞くでしょ？
2. 聞いたらいったん資料を紐解いて疑問点洗うでしょ？
3. 質問とかするでしょ？
4. すでにできてる部分がどこまでできてるかの分析調査とかやるでしょ？
5. そっから作業日数出すでしょ？
6. プログラム書くでしょ？
7. プログラム書き終わったらテストやるでしょ？
8. レビュー依頼（確認依頼）するでしょ？

加えて、実際にプログラムを書くときも、「メソッドを作る」→「ロジックを書く」→「分からないところがあったら検索する」って手順自体は変わらないでしょ？
ほら。ちゃんと手順あるじゃん。
これのどこが「手順化できない仕事」なの？

決まった手順書がないのは「作成するプログラムの内容が毎回違う」ってところだけです。
それを言ったら「レジ打ちバイトが商品をスキャンする順序」だって毎回違うよ。
でもだからって、それを理由に「レジ打ちバイトは手順書が作れない」なんて言い出す人はいないでしょ？
実際には、多くの開発現場に開発標準という名の手順書もちゃんとあります。

そう。
プログラマーの仕事に本質的に手順書が作れないのではなく、手順書を作るのが苦手な人や手順書の手順を守るのが苦手な人が多いだけです。
だって、そういう作業を昔からコンピューター任せにしてきた人種だからね。
心当たりあるでしょ？

〇あなたはなぜ手順書を書くのが苦手なのか

ここで人間の脳内に注目してみると、この「頭の中で手順を作る」という能力は、大きな概念を小さく分解して推し量るという脳内の分析器官が関係しています。
具体的な名前でいうと扁桃体や右側頭葉です。
その訓練不足により、「観察力／物品配置能力」が低いことが、物事を整理できない根本原因となります。

要は、これからやるタスクに対して、
1. 全体を細かいところまでよく観察して
2. 構成パーツの配置を考える
ことができてないっちゅーわけですね。
プログラマーの場合だと、観察対象となるイメージに形がない（その形をこれから作るんだから当たり前）ことによって、観察しづらさを感じていることが多いのではと思います。

はい。
てなわけで脳のこの部分を訓練しましょう！
それが今週の課題です！

あ、ちなみにですけど、上記の説明を聞いて「脳の能力不足が原因なら、もうどうしようもないんじゃないの？」と思った方。
もしいらっしゃれば、ですけど、そういう方にあらかじめ言っておきます。
いい？　よく聞いて？

うるさい。いいからやれ。

できるから。
問題ないから。
絶対大丈夫だよ。オジサンやりかた分かってるから。
ね？

まぁ、訓練つっても大したことじゃないんです。
いったん覚えたらあとは日々の心がけなんで、練習自体は５秒で終わりです。

ポイントは、「どういうポイントに着目すればいいか」（つまり、いわゆる観点と呼ばれるもの）を、あらかじめ頭に入れておくことです。
その場で考えるんじゃないよ？
観点を「あらかじめ知っている」ことが大事なの。

たとえば美術の授業で「家の絵をスケッチする」というケースを例にとって考えてみます。
「描く」という行為が同じでも、そこにどういう観点で着目するかによって、見え方は変わってくるのです。

人物Ａ. 実際に住んでいる人の暮らしぶりに着目して描く
人物Ｂ. その家を設計した人の美的センスに着目して描く

全く同じ家を同じ角度から観察してスケッチしたとして、はたして人物Ａ. Ｂ. が描く絵は、全く同じ出来栄えになるか？　です。
加えて、３人目となる人物Ｃ. が「なんの観点もなしに見たまんま描く」という観点で絵を描いたとしたら、その Ｃ. の出来栄えが Ａ. Ｂ. を超えることはあるでしょうか？

。。。そう！
Ａ. Ｂ. の絵の出来栄えが完全に同じになることも、Ｃ. の絵の出来栄えが Ａ. Ｂ. に勝ることも、どちらもありえないのです。
なぜなら、Ａ. Ｂ. はそれぞれ観点が違うし、対して Ｃ． には観点がないからです。

もし Ｃ. がプロの絵描きで、Ａ. Ｂ. が素人であれば、Ｃ．が実力で上回ることはあるかもしれません。
でもそれは Ｃ. がプロであるがゆえに標準的な観点をあらかじめ知っていただけで、これは観点なしに絵を描いているのとは明確に違います。

つまり、あなたが「自分がやる仕事の観察」を苦手としているのは、「どんな観点に着目すればいいか」を単純に知らないから、というだけの理由だったわけなのですよ！
なんだ、そんなことだったのか！

〇一般的な観点の例

はい。ではプログラマーが一般的な作業をするにあたって、着目すべき観点の例を示します。
ただしここに示すのはあくまで例ですので、自分なりの観点があるんだったらそれでも構いはしません。

ですがもし自己流で行くんだったら、その自己流の観点を実際に紙に文章で書いてみてください。
もし書けなかったら、それは「観点を理解していない」ことを示します。

1. ユーザーは、どんなアウトプットを欲しているだろうか？
2. ユーザーは、そのアウトプットがいつまでに欲しいだろうか？
3. そのアウトプットは、直前にどんなアウトプットがすでにあることを前提としているだろうか？
4. ユーザーは、何をあらかじめ理解しており、何があらかじめできるだろうか？
5. この作業にあたって、いったいどんなリスクがありえるだろうか？
6. このプログラムは、どんな全体感を持つサービスの中の、どんなパーツだろうか？

こんな感じ。
とりわけ大切なのが、最後の「６．」番です。

プログラマーに限らず世の中全般的になんとなーく察しの悪い人は、物事の全体感を把握することが苦手で、もちまえの想像力で割とデタラメな補完をしようとする傾向があります。
（特にリスク考慮不足のことが多いです）

私の場合、サービス全体の流れのことを「サービスフロー」と呼んでいるのですが、このサービスフローを「どんなサービスでも主軸は１本のはずである」というのが私個人の観点の１つです。
なぜなら、サービスフローは「そもそもなにがしたいか」が確定すれば、必然的に決まる部分だからです。

ゆえに私の理屈では、サービスフローに関する認識がプロジェクトメンバー間で異なっていてはいけないことになります。
なおかつ、サービスフローが「そもそもなにがしたいか」が確定すれば必然的に決まるのだとすれば、サービスフローは作る製品の完成イメージそのものであると捉えることもできます。

ですので、メンバーは「多分こういうことなんだろうなぁ」とか勝手に想像で思ってはいけないし、リーダーはメンバーに勝手に想像させる余地を与えてもいけないことになります。
つまり観点とは、「自分達がそもそも何をやりたいのか」というのと全く同じなわけです。

今やってるプロジェクトで、サービスフローがみんなと共有できているか、時間をとって確認してみてもいいかもしれません。
なんとなくミスの多いメンバーがミスをする理由が、実は「サービスフローを理解してないだけだった」なんてこともあるかもしれません。

〇観点から必要なステップを書き起こす

本日的に何がやりたいのか、の部分が確定したら、その中で自分が担当すべき作業についてよく観察してみましょう。
そんで次に「その達成のために、今の自分（達）には何ができるのか」を考えていきます。
まずは「自分（達）にできること」の一覧を雑多に列挙し、それから順番に並べていきます。

その際は、あくまで「今の自分（達）にできること」を考えるのがミソです。
スモールステップ化が苦手な人の中には、自分（達）にできるかどうかを考えずに、「理想的にはやるべきこと」をいきなり考え始めてしまう人もいます。
極端な場合、その作業が「理想的にはやるべきだが、不可能」というケースもあって、そういう人がリーダーになるとチームはパニックです。

システムエンジニアリングに限らず、仕事というのは「現実に実施可能なステップ」のみを積み重ねて完了させなければいけません。
なので、どんなにやるべきことであったとしても、できないことはできないのです。

そんなときは、「本当に達成すべき、たった１つのこと」を考えればいいです。

頭の中の整理が苦手な人は、「締め切りも守りたい」「品質も守りたい」「上司からの評判も守りたい」と様々なことを全て実現しようとし、それを全て完璧に達成できる方法論などないといつまでたってもあきらめきれない人も多いです。
それ、今すぐやめてください。あなた１人が困るだけならいいですけど、ぶっちゃけ周りにすげー迷惑かけてます。

「本当に達成すべきこと」言い換えれば「要するにやりたいこと」を１つに絞り込み、それを達成することだけに集中します。
「要するにやりたいこと」→「そのために自分（達）にできること」→「その最適な順序」と順番に考えることで、効率的で的確なステップが作れます。

そして最後に、ステップ１つ１つについて「あとは機械的に手を動かすだけ」の状態にまでブラッシュアップします。
（ブラッシュアップのやり方は粗目のステップを書くときと全く同じです。ただ規模が小さくなっただけです）

「理屈のうえでは、できるはず」とか「そのときになったら多分できる」じゃなくて、自分が作業しているところを自分で想像できる粒度に落とし込んでおくのが、あとで楽をするために大切なことです。

無論、理想的な計画が常にいつでも作れるわけではなく、ときにはエイヤで行動しないといけないことだってもちろんあります。
とはいえ、そのような行き当たりばったりな行動は、可能な範囲でなるだけ避けるべきです。
なぜなら人生というものはより高度な結果が楽して得られるなら、それに越したことはないからです。
楽をする選択肢があって、それを回避する理由がないのに、わざわざ好き好んで苦労する必要などないのです。

さて、例を示します。
たとえばですが、これは実行不可能な例です。

悪い例
１．ユーザーにメール発信する処理を実装

皆さんがプログラマーであれば、メールを発信することくらい造作なく感じるでしょう。
ですが現実には、「宛先となるメアドが権限的に取りようがない」かもしれないし、「メールサーバーにアクセスしようがない」ことや、もしくは「文面を考える人が仕事をしてくれない」ことだってあるかもしれません。
そのようなリスクが「作り始めてから後から出てきた」のではあなた自身も嫌になるし、上司だってギョッとしてしまいます。

第一、そういったリスクを「手を動かしながら考えていく」のはとても大変なことです。
とりわけ、若いときからずっとスモールステップ化が苦手だった人は、考えながら手を動かすのが当たり前になりすぎているケースもあります。
そのような人は、あらかじめ考え尽くしてから作業をするととても楽だということを、純粋に知らないことも多いです。

そうなるのを防ぐためにも、「あとは手を動かすだけ」の状態にまで、あらかじめステップを作りこんでおくのが大事なのです。
完成間際になってようやく道筋が見えることに比べれば、より良いアイデアが後から出てきてしまうことの方がまだずっとずっとマシです。

〇ステップを上手く作るコツ

そうはいっても、やる前にあらかじめ考えるって難しい。。。
そんな風に感じる人は多いでしょう。
そんなときは、皆さんおなじみの「あの感覚」を利用するといいです。

皆さんの中にも「なにかを始めようとした途端、心理的抵抗感を感じて手が止まる」という経験をした人は多いと思います。
「さて、やるか」とつぶやいてから、実際に手を動かし始めるまでに数分から数十分かかってしまうケースです。
だいたいの人は、ほんの少し後には「それでもやるしかない」とあきらめて、辛い気持ちを我慢しながら作業をし始めます。

スモールステップを作っていると、「この作業は実際やるとき抵抗を感じるかもしれない」という予感がしたり、もしくはスモールステップを作ること自体に抵抗を感じることもあるかもしれません。

このような抵抗を感じたときこそが、ステップをより上手に作るチャンスです。
ステップをとりあえず適当に作ってみて、もしかしてここで抵抗を感じるかもと感じたら、それはステップが十分に小さくなっていないことを表すからです。

必要なステップの大きさ（作業粒度）は、１人１人違います。
あなたの同僚がとても目の粗い作業をなんなくこなすからといって、あなたが同じ粒度で作業できなければいけないわけではありません。

物凄く目の細かい、かなり綿密なスケジュールが出来上がっていなければ手が動かない人もいます。
それどころか、一挙手一投足があらかじめ定義されてないと指１つ動かせない人だっています。

あなたがもしそういうタイプなのであれば、遠慮なくどんどん細かくしていってください。
あまりに過度に細かくなりすぎた結果上司に笑われようと、仮にそれを天の神が許すまいと、私が個人的に許します。
天の神より俺を信じろ！
大丈夫だから！

さ、あとはやってみて！

〇 次回予告

はい。てなわけで今回はここまで。
とはいえ、今回のこの記事を読んでいきなりスモールステップ化ができた人は、おそらく以前から少しずつできていた人です。
通常、文章を読んだだけでいきなりできるようにはなりません。
私だってそこそこできるのに３年くらいかかってるし、今でも全然完璧ではありません。

計算上、「少しはできるようになってきたかなー」と最初に小さな実感を覚えるまでに、ざっくり３ヶ月はかかるはずです。
人によってはもっとかかるかもだし、私のように本当に３年かかる人もいるでしょう。
ですが長い人生、時間はたっぷりありますので、次回からじっくり練習していってください。
ポイントは、ステップを「実際にやるときに心理的抵抗感を感じないように作ること」です。

このスモールステップ化は、仕事に限らずプライベートでも、あらゆることに応用が利くスキルです。
とても便利なスキルなので、ぜひとも習得してください。

さて、次回もスモールステップ化の手助けとなるような内容でお送りします。
自分が何をしているのか整理しやすくて、あとから読んでも手順が明確になるようなプログラムの書き方。
いわゆる「構造化プログラミング」の分野の話です。

「Gotoを使うな」とかそういう表面的なテクニックの話ではなくて、
・そもそも「構造」とは何か
・何のためにそれを意識するのか
といった本質的な部分に触れていきたいと思います。
お楽しみに！