プロジェクトの成功とは？

先日、社内で

プロジェクト成功の定義は？

という議論をしました。

アジャイルやリーンとしては「価値提供」かと思います。

素早く、価値を提供出来る事が成功かと。

これをもっと具体化した目標値が達成出来れば、

成功かと思います。

議論では、

問題があっても対応出来ていれば成功

イテレーションが回せていれば成功

などなど。

どれも成功だと思いますが、

議論になるという事は、

成功基準をプロジェクト開始前に決めていない証明でもありますね…

しかし、プロジェクトとしては成功しても、

エンジニアとしては納得行かない点も多くありそうですね。

あそこは、あーしておけばよかったー

とかとか

設計視点や、コード視点など、

それぞれ視点を変えると、後悔が無い事の方が少ない気もします。

プロジェクトとしての成功

個人としての成功

などなど、複数の定義はあってイイ気がしますね！

しかししかし、改めて考えると目標達成と後悔は違いそうですね。

目標は達成しても後悔する事はありそうです。

目標値はあくまで目標値で

完璧な仕事というか、完璧な業務というか、

後悔のない仕事というか、後悔のない業務

は難しいですね。

改めて、

目標以外の視点で「ふりかえる」事も大事ですね。

ヒアリングの違和感

仮説を立てて、聞くではなくて、

仮説を立てて、見せて、見る

昨年あたりから、

ヒアリングは何かが違う気がしています。

単純にインタビューのテクニックが無いだけとも言えますが…

何か、違和感がずっとある状態です。

そして、最近、再度『アントレプレナーの教科書』を読んで、

顧客開発のファーストステップである

顧客発見フェーズでのヒアリングが違うのかな

って、思い始めました。

顧客発見フェーズにて、

発見できた顧客や支援者に対してのヒアリングは問題無い？

いや、ここはまだ分かりません。

発見した顧客へのヒアリングは

相手も本気で回答する可能性は高い気がします。

ただ、これまでのヒアリング経験では、

相手が本気で考えていないというか、本気で答えていない気がしています。

フォーカスも合っていない感じがありました。

いまは、それよりも、

動くものを見せて、相手の反応を見る

方が収穫が多いと感じています。

相手の本気度も分かり易くなるというか、

事実が発見し易くなるというか、

フォーカスも合っている感じがします。

いや、フォーカスが合っているか、ずれているかが分かり易いだけかもしれません。

具体的な話になり易い気もします。

この点ですかね。

違和感は。

もちろん、どちらも仮説があるのは前提条件です。

ヒアリングより、見せる＆見る　

問いかけるより、見せる事、

聞くより、見る事

そのほうがフォーカスも合い、具体的な話になり易い。

もしかすると、ヒアリングも基本は、聞いて、相手の反応を見る

という事なのかもしれませんが…

この違和感、もう少し考えたいと思います。

熱伝導率

県内の方とは、対面でのミーティングが増えつつありましたが、

再び、オンラインでのミーティングが増えています。

対面で何度かお会いしているので、

オンラインでもスムーズにコミュニケーションが取れています。

一度対面していると、その後がオンラインでも

対面と変わらない成果となるといったデータもありますが、（参考：職場の人間科学）

それも納得です。

どちかというと、この状況に

生気を取られているというか、元気が奪われている感があります。

この状況に負けない為に

なんとか元気を取り戻そうと、熱量を取り戻そうと

いま出来る形でのアクションやイベントを作っています。

ただ、いまひとつ盛り上がらない感じがします。

オンラインでは熱伝導率が悪い？！

などとも思います。

オンラインでなくても、いちど下がったものを再び盛り上げるのは難しいですね。

アクションやイベントだけでなく、

オンラインで熱伝導率を上げる方法を考えなくては！

オンラインの工夫

先日、とある高校の「総合的な探求の時間」の社会人講師として

お話しました。

当初は、教室でAR体験などしてもらいながらお話する予定でしたが、

前日に急遽オンラインとなりました。

当然、準備していた体験は出来ません！

全90分（質問で15分くらい）の中で、体験で40分くらいで考えていましたので、

まるまる75分、お話しをする事になりました！

オンラインで、高校生を飽きさせないようにしながら

何をお話するか？！

しかも、準備する時間はほとんどありません！

頭の中にUDEクラウドが浮かびます…（納期と内容充実のジレンマですね！）

考え、悩んだ末、

やっぱりオンラインでも、高校生達とインタラクティブにやりとりしたい！　

対話、会話をする事で、飽きない時間に出来るのでは？！

という事で、

お話する小テーマをいくつか作っていたので、

小テーマ（言葉）１つだけを1スライドに大きく記載したスライドを作成し

学校で印刷＆黒板に貼り出してもらいました。

そして、当日は、そこに投票してもらい、話をしました。

投票などで、体を動かす事や、何に投票するかを考える事、

投票理由を聞く事などで、

興味を引く事は出来た気がします。

このようなちょっとした工夫がオンラインでは重要な気がしました。

同じ釜の飯を食う　ではないですが、

オンラインでも同じものを見て、持って、触る

事で、一体感というか、共同体的な感じが出る気がしました。

工夫、大事ですね！

マルチタスクとチャット

以前、簡単なマルチタスクのテストで、

私は非マルチタスクよりマルチタスクの方が早い結果が出たのですが、

それと、最近、チャットで仕事を進める事が多く、

複数プロジェクトが走っている状態での指示、確認に

チャットが向いているなー

と実感する事が多々あり、

活用するツールで、マルチタスクの負荷や効率はある程度改善出来る？！

と、ふと思いました。

マルチタスクが効率悪いのは疑う余地はなく、

私のテスト結果は、たまたま　だと思っています。

チャットの短いコミュニケーションは、短い故に

ちょこちょこアドバイスする程度であれば、

比較的マルチタスクの状態でも、脳の切り替え負荷も小さくなる気がしました。

ドキュメントチェックなども

ちょこちょこ追加、変更して共有してもらえると

確認も短時間で終わるので、切り替え負荷が小さく感じました。

となると、やはり使い方も関係しますね。

結局、どんな事も、状況に応じた活用ツールの選択と使いかたですね！

理想？のプログラミング体験

先々月、とある活動にて、高校生二人から相談を受けました。

こんな事したいのですが、出来ますか？

という相談で、「こんな事」は、以下の通り。

1）文化祭で音楽を流したい。

2）時間で流す音楽を変えたい。それまでは同じ音楽を流し続けたい。

3）WindowsPCかMAC Bookで再生したい

ソフトウェアエンジニアなら誰でも同じように答えると思います。

「もちろん、可能だよ！」

二人ともMAC Bookは個人で持っているので、パソコンの知識はあるようです。

アプリやインターネットが身近になっても

ソフトで出来る事、PCで出来る事は、まだまだ未知の世界のようですね。

考えてみれば当たり前ですが、とてもとても新鮮でした。

と、同時に、やりたい事、実現したい事があった上での

プログラミング体験は、とても貴重だなと思いました。

ただ、言語のルールを教えて、Hello World　を動かすより、

やりたい事から、言語を学ぶというより、動かしながら変更していく方が

どんどん吸収していくように思いました。

今回は、私が作成したバッチファイルをコピーせずに、

画面で見せて、タイピングしてもらいました。

もちろん、意味もわからず打ち込みますからタイプミスもあり、

一発では動作しません。

表示処理を入れながらデバッグしていきます。

これで、十分なプログラミング学習だと実感しました。

やりたい事から始まるプログラミング体験！
とても貴重な体験でした！

デモで繋がる

ソフトウェアで出来る事、

ARで出来る事のデモ活動で人が繋がっています。

我々も技術で何が出来るかを知ってもらう為にデモしていますが、

こんなにも繋がるものかと驚いています。

最も大きい要因は、人の力だと思います。

人が人へ伝える力が大きいのだろうと想像しています。

しかし、それだけでは繋がらないと思います。

どんな要因の影響が強いのでしょうか？

デモの内容が伝え易い？面白い？

エンジニアがやっているから興味を持ってくれる？

珍しい事していると思われている？

我々の「活用してもらう為に、知ってもらう」が刺さった？

実は、知りたいと思っていた潜在ニーズがあった？

たまたま？

などなど考えますが、どれもしっくりきません。

となると、やはり、人の力のみ

という事でしょうか。

活動を知ってくれた人、繋げてくれた人のみなさんの力でしょうか。

今年の4月から開始して、ここまで繋がるのは、一人一人の力ですね。

おそらく、インターネットやSNSでは、同じ結果にはならなかったと思います。