去る10月14日、技育祭2022[秋]に登壇させて頂きました。
本記事では、そのとき頂いていた質問に答えたいと思います。
- プログラム言語は知っておいた方が良いか？
- 「アウトプットを小さく」とはどういう意味？
- ビズリーチではQCDSのうち、どこを固定しているのか？
の３本です。
なお、「技育祭」とはサポーターズさんが主催する「エンジニアを目指す学生向け」テックカンファレンスです。最近は、春と秋の年2回開催されています。私のセッションは189名の方が聴きにきてくれたそうで、ありがとうございました！ 当日は、「はたらく」前に知るべきIT企業5つのヒミツ、と称してセッションを担当しました。資料はこちらになります。
セッション冒頭では、Miroで簡単なアンケートを取りました。まず最初に『どこで聴いてくださってるんですか？』と質問したところ、なんと全国津々浦々から聴いてくださっていました。勝手に関東の人だけかな？と思っていたので意外でした。ダメ、思い込み。
もうひとつ、『何年卒予定ですか？』と質問したところ、以下のような結果に。意外と幅広く聴きにきてくださっていたようです。
それでは、質問に答えていきましょう。
プログラム言語は知っておいた方が良いか？
プログラムの授業がない学科なのですがやはり何かの言語でも知っておいた方が就職や入った後いいですよね？どのレベルまでしておけばよろしいでしょうか。
プログラミング未経験の方からの質問ですね。
まず、自分にとってプログラミングが「合う・合わない」みたいなことを早めに理解するためにも、プログラミング言語は知っていたほうが良いと思います。たとえば、家のゲーム機やWi-Fiルーターの配線が「苦手なひと」と「得意なひと」がいるように、プログラミングにもそういう相性みたいものはあると思うのです。普段の生活では、配線が得意な人にやってもらえば良いですが、仕事にする場合は「苦手」とは言ってられません。
ところで。
そもそも質問者の方は、なぜこのような疑問を持ったのでしょうか？
私は、子供の頃から走るのが苦手……どちらかといえば嫌いでした。
運動会のかけっこはびりっけつで、高校のマラソン大会は「嵐で中止になれっ！」って祈ってたタイプです。
40代を過ぎたある日、運転免許の書き換えに出かけました。みなさんも良くみかける風景だと思いますが免許センターでは献血を呼びかけていたので、私はなにげなく献血センターの門をくぐったのです。献血をするまえに、まずは採血をし、血液の成分検査をするとのこと。
しばらくして、看護師さんに呼ばれます。
「高橋さん……誠に申しわけないのですが、アナタの献血は受け付けられません」
……えっ!？
ショックでした、想像以上に。悪玉コレステロールの値が高いので、献血としては不適合とのこと。
あぁ……じゃあ、もし家族や友達になにかあったとして、私の血は提供できないんだ……
私の血は、だれの役にもたたないんだ……
ワタシハ ダレカラモ ヒツヨウト サレテ イナインダ……
闇に落ちそうになりましたが気を取り直して、私は体質改善を目指します。目標は「献血が出来るようになること！」 待ってろ献血センター！
手っ取り早く内臓脂肪を減らすには運動が一番だそうで、とりあえずあんなに嫌いだったのに「走る」ことにしました。最初は近所の公園を1周するところからはじめ、つぎに町内を周回、近所の大きな幹線道路を5〜8キロ、10キロマラソン大会、と徐々にステップアップをし、ハーフマラソン大会、ついにはフルマラソン大会も走れるようになりました。
走り始めて約一年。私は渋谷の献血センターに向かいました。
「高橋さん、正常値ですねー。じゃあ、400mlお願いしてもいいですか？」
よっしゃーーーーっ！！！ こうして、念願の「献血が出来るようになること！」というゴールを達成しました。
閑話休題、そもそもの質問である、「何かプログラム言語知っておいたほうがいいですよね？」
この問いは、上記の私のランニングに例えると 「ちょっと近所、走ってみたほうがいいですよね？」 という質問に似ているんです。今は本もWeb教材もたくさんありますし、開発環境もブラウザがあればクラウドで簡単に作れるので、はじめる敷居が下がっています。興味があるのなら、すぐに始めると良いと思います。
そもそも、プロダクト開発者にとってプログラミングは手段の一部にすぎません。プロダクト開発者の目的は技術を使って事業やサービスを成功させることです。そのためには、プログラミングはもちろんさまざまなスキルを身に付けなければなりません。プロダクト開発はどこまでも奥が深く、学び続ける必要があります。
私は「献血が出来るようになること！」という最終ゴールのために、中間ゴールとして「ハーフマラソン大会を走る」や「フルマラソン大会を走る」を設定して、ステップアップして行きました。
質問者の方はなぜ「プログラム言語」を覚えたほうが良いと思ったのか？ その「最終ゴール」をきちんイメージして言語化してみてほしいです。ゴールのイメージがはっきりすれば、それに向かってさまざまなやるべきことや取り組みが浮かんでくると思うのです。
ちょっと余談ですが、 「最終ゴール」だと思ってたのに「中間ゴール」だった…… なんてことは、人生で何度も発生します。私は7回転職しているのですが、つねに思い通りの仕事をできていたわけではなく私の人生のモチベーションは下図グラフのように乱高下。
それは、転がる楕円のラグビーボールのようなものだったと思います。
世の中、目標に向かってキャリア形成が出来ている人なんてほんの一握りだと思います。どちらかと言えば、多くのひとは私のように偶然が重なってスキルは形成されるのです。
アメリカンフットボールの名コーチであった Lou Holtz は
「人生とは、我が身に起こることが10％、それにどう対応するかが90％だ」
と言う名言を残しています。本当に、そのとおりだと思います。時代や環境が変われば、やらなくてはいけない事も変わります。
IT業界は変化が激しい世界ですが、その変化や進化が楽しい世界とも言えます。私の場合も、その時々によって必要な技術・テクニックが変わるので、転換期ごとにアンラーニング（学びほぐし）が必要でした。でも、あたらしい技術を学ぶのは楽しかったとも言えます。
「VUCAの時代だからこそ」、「理系だ文系だ」って言う前にあらゆることを学び、組み合わせ、問いを立てる。正解が分からないからこそ実験を繰り返し正解を導く、そんな時代です。学生の皆さんは、時間がたっぷりある今だからこそ、貪欲にいろんな方面を学んでください！
社会人になると学びの時間を確保するのは、とてもとても大変になりますからね！
「アウトプットを小さく」とはどういう意味？
アウトプットを小さくとはどうゆうこと？（最小限の成果で相手に最大限に喜んでもらうということ？）
下のスライドにもらった質問ですね。とても良い質問です、ありがとうございます。
「アウトプットは小さく」とは、プロダクトのフィーチャー（機能や特徴）は、無駄なものを作らないようにすることです。そして、なるべく小さいアウトプットでお客様の 「困った！」を「良かった！」 に変えるのです。この「良かった！」効果のことを アウトカム（成果） と呼び、これの最大化を目指しています。その方が、最終的にはコストを抑え品質もキープできるのです。
ちなみに、プロダクトの「アウトプットが大きい」とは、こういう状態を指します。
ガンバル自分へのご褒美に、100徳ナイフ買っちゃった！ 顧客プレゼンにこれを持っていって、アプリの機能減らす提案すれば勝つる！ pic.twitter.com/c0GK8axCAV
— 深津 貴之 / THE GUILD (@fladdict) August 28, 2013
十徳ナイフならぬ141徳ナイフですが実用的じゃないですよね。でも、あながち冗談ではなく、ITシステムはこういう状態になりやすいと思っています。
この要因のひとつに、David J. Bland が名付けた 「プロダクトの死のサイクル」 があります。
This is what I'm calling the Product Death Cycle pic.twitter.com/1XtPlViOl7
— David J. Bland (@davidjbland) May 16, 2014
① 顧客に足りないものを聞く→
② 足りない機能をつくる→
③ 誰もプロダクトを使わない→①に戻る
プロダクトマネジャーがもしウェイター（注文を受け付ける人）タイプだったら、確実にフィーチャーは爆発し、開発チームは「機能を作る」ことばかりに集中してしまいます。こうなると、アウトプットが大きくなりやすい。
お客様へ届けるべきアウトカム（成果）やベネフィット（効果や利益）の意識がおろそかになってしまいます。
この現象を Melissa Perriは 「ビルドトラップ」 と名付けました。
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
私たちはビルドトラップを回避しお客様のベネフィットに集中する必要があります。それがつまり、 「アウトプットは小さく、アウトカムを最大にする」 ということなのです。
ビズリーチではQCDSのうち、どこを固定しているのか？
ビズリーチでは（QCDSのうち）どこを固定しているのか教えてほしいです。
これは、荒ぶる四天王の部分で頂いた質問ですね。これは、ビズリーチというよりプロジェクト単位の決めごとです。プロジェクトにおける「鉄の三角形」は、「スコープ」「時間」「予算」のバランスで構成されます。ピンを固定できるのは2つまでであり、固定していない部分をマネジメントするのが成功の道と言われます。
固定する場所は、プロジェクトの特性で決めます。たとえば、BtoB向けのプロダクトは、ある程度スコープを固定してから進めたほうがよいと言われています。複雑な法令に対応しないとダメなプロダクトなら要件に抜け漏れが無いかチェックするのに時間がかかります。なぜなら、あとから法律違反だった……なんて分かったら大慌てで改修作業となります。
また、商習慣や国のルールでリリース時期（時間）が固定されるプロダクトもあります。（例. 年末調整アプリなら11月から、確定申告アプリなら2月から使えないと意味がない…など）
会社がスタートアップだったりすると、プロダクトの要件やサービスのうち「顧客に対して、何がヒットするかわからない」状態だったりします。こういう場合は予算と時間を固定させ、スコープだけをコントロールして何度も短期間でリリースし、市場の反応を確認しながらブラッシュアップやピボットする手法を取ります。
QCDSとうまく付き合いながらビジネスを成功させる、これがプロジェクト・マネジメントでありPMの腕の見せ所とも言えます。
プロジェクトマネジメントに関しては、初心者向けに良質な本がたくさん出ています。
たとえば次に紹介する本は、
- テーマパークを作ることになったらどうするか?
- 家のリフォームをすることになったらどうするか?
- オフィス移転を任されることになったらどうするか?
- 夏まつりを仕切れと言われたらどうするか?
など、ケースごとにプロジェクトマネジメントを使ってどう解決すれば良いか、丁寧に解説されています。よかったら手にとってみてください。
PMBOKはじめの一歩 スッキリわかるプロジェクトマネジメントの基本
では皆さん、これからも学びを止めずにともに頑張りましょう！
