活動を開始して今年で4年目になりました。プログラマーとして業務システムなどを受託開発してきた経験は、そもそも異業種交流のようなものだったのですが、今度は自分から異業種の世界に出て行くという動き方になっています。持って行くのはITそのものだけでなく、要件定義や運用設計などを手がけて培ってきた情報処理技術です。同業者からは当たり前の行為や知見であったとしても、異業種の世界では特異な存在らしく、その点が強みとなっています。「くらし」を「なりわい」に古川家として活動する核の1つには、日々の暮らし、ライフスタイルをそのままビジネスにできるか?という挑戦があります。料理研究一家と名乗るのは、食卓を彩り、支える、家族という存在が欠かせず、食卓を起点として、それぞれの得意なことを生かし、力を合わせて活動していくというビジョンがあるためです。日々繰り返される家族との暮らしがとても大切な事だからこそ、消費するのではなく生産していく、そして新たな可能性に向けて投資していきたい。考えることで、自分の活かし方、活かされ方への意識が大きく変わりました。「専門家」から「兼業化」へプログラマー、SIer、ソフトウェアエンジニア、呼び名は様々あれど未来についてはなぜか暗い話が付きまといがちです。誇りを持って仕事をし、技術の研鑽に励む日々にも関わらずです。駆逐される、ネガティブな未来は枚挙に暇がありません。これからどう歩んでいくのか?プログラマーとしての歩み方にはいくつかあると思いますが、すぐ思い浮かべるのは、新規テクノロジーを生み出し、世間に広めることで人々のライフスタイルそのものが変化する道かと思います。クラウドやスマートフォンが良い例ですが、世界が一変します。1つは、既存テクノロジーを別分野に適用する方法です。私の場合は、テクノロジーというより人材そのものを応用するという考え方です。これが兼業を指します。プログラマーでありながら料理研究のような、新たな業に取り組むというスタイルです。規模は小さいのですが、即行動できること、少額投資で済むというのがメリットだと思います。コンピューターを軸にした情報処理技術を、食という文脈から別業種に適用していくのです。食は裾野が広く、飲食店だけでなく様々な文脈で登場します。そこが魅力であり可能性が大きいと考えています。当たり前になってしまっているものだからこそ、価値を再発見していきたいという思いも含め、兼業していくことを選びました。コミュニケーションは不可視コスト別業種と関わるということは知識交換が必要になります。自分の技術が有用だと分かってもらうよりも、相手の実現したいことや暗黙知となっていることなどを掘り起こして、接点を探しながら相手の知識をこちらの血肉にしていくことが肝要です。コミュニケーションは必須ですし、とても重要と言えます。適切なコミュニケーション設計を行わないと、認識の齟齬や情報の混乱によってストレスばかりになり、プロジェクトそのものが止まったり、最悪の場合は解散となります。予算、納期、ビジョン。プロジェクトを進める上で確かに重要なものですが、どのようなコミュニケーションをとって進めていくか最初に合意するというのは、同じぐらい重要だと経験から感じています。言って、とりあえず話し合おう、集まろう、アドバイスを求めようを繰り返すのは本末転倒です。ここでのポイントは、コミュニケーションもコストの一種だと考えて、少ない回数にしたり、関係者を最小限にしたりと、削減できた方が良いものという視点です。協業プロジェクトでは、他のメンバーが本業を持っていたり、案件の掛け持ちをしていることもよくあるため、なかなか進まないことがままあります。3つのハードルでは、こういうツールを使いましょう、こういう運用をしましょうとなった時に出てくるハードルがあります。プログラマーとしては、このツールを使えば問題をクリアできるなと思いつくのですが、それがこのメンバーに向いているかは別問題ですし、根付くかどうかはその後の動き方にもよります。見えてくるのは知識のハードルです。ITになれた人にとっては当たり前の感覚が、別業種では通らないというのはよくある話です。主な原因は情報の非対称性、つまり得意な知識に差があることです。ここは先ほどでいう、異業種間の知識交換を積極的に行うことで解消できるのですが、次に出てくる心理的ハードルが立ちはだかります。ITヘの苦手意識、トラウマとも言える過去の失敗や恐怖心が、知識交換に対する意欲を削いでおり、これが根本の原因であることが多々ありました。最初に越えなければならないのは、この心理的ハードルだと考えています。既知をもって未知に踏み込むでは苦手意識や恐怖心の根底には何があるのでしょうか?私はそれを未知だと考えています。知らない、分からない、経験がない、そういう状態が漠然とした不安になり、過去の経験と相まって苦手意識や恐怖心になっているようなのです。新しいツールを使いましょう、それにはこういうメリットがあってと説明するのは、こちらの領分ですから難しくありません。合理的な説明であっても相手が受け入れるとは限りません。1つ自分の中で良い方法だと手応えがあったのは、既知の方法をとるということです。知っている、分かっている、経験があるということは、心理的距離を近く感じるため、抵抗感が薄れたり、安心できるという可能性が高くなります。使うツールなら対面で説明しながら動かしてみる、相手が1人で試すのは不安そうなら自分が相談窓口となる、相手にとって未知のことに対して、相手にとって既知の方法をとるとハードルを越えていけます。使うツールをメールで説明する、これはハードルを越える可能性が低くなります。悪手とは言えませんが、他に既知の方法がないか検討する余地があるのではないでしょうか。誰のための技術なのか技術があるとして、誰を中心にして考えるのか?そこが大きな分岐点だと考えています。職業柄、新しい技術を試し、既存の技術を研鑽するというのは現役でいる限り避けられません。技術そのものは手段にすぎないというのが私の方針です。技術を目的にするというのも楽しい一面があります。自分だけ喜んでいても前に進むことはできないとも実感しています。様々な業種、そこで働く人たちがいて、歯車の大きさやスピードも様々です。新規テクノロジーは、それそのものが大きな歯車と言えます。強制的に周りを動かしてしまう力を持っており、それによって世界が変わってきたというのは、歴史を見れば明らかです。兼業という私のアプローチは、潤滑油のようなものです。違うのは、存在や意味を知ることで、元々の歯車が加速するだけでなく、歯車そのものが大きく力強くなる可能性を持っている点です。異業種へと踏み込み、方々で歯車を加速させたり、力強くすることで、世界全体が加速していけるのではと、私は考えています。次回に期待して各地に散らばるCPIエバンジェリストが一堂に会するというのは、発表者側としても刺激になります。1年に1回というのは、持ち寄ってこれる情報も濃くなっているので、ちょうどいいのではないでしょうか。来年、新たな事例や学びを持って、このイベントに臨めたらと思っています。Pro(以下、DCP)は、concrete5でコンテンツを編集・レイアウトするための機能であるブロックを自分で拡張できるプラグインです。これを利用することで、独自の入力フォームを持ったブロック(カスタムブロック)を作成することができます。カスタムブロックを作るために必要なプログラミングの量をほぼ無くしてくれるので、HTMLによる表現部分だけに集中することができ、デザイナーの画面作成やなクライアントの運用をサポートすることができます。immature本番稼動しながらDCPブロックへ入れ替えたいテスト環境でブロックを作って入れ込んでしまうと、本番環境でまた作成しなおさなくてはなりません。データベースのダンプで入れ替えても良いのですが、並行して稼働したい場合だと難航します。メンテナンス時間を長くとっての移行はなるべく避けたいところです。concrete5は下書き保存で変更後のプレビューができるので、本番サーバーは現状を維持しながら編集を進められます。ローカルではブロックの動作のみ確認し、中身は本番サーバー上で入力して公開すれば、メンテナンス時間をかなり短縮できます。テーマファイルには、ブロック化する前の内容を静的に埋め込んでおいて、そこに編集エリアを併記します。ブロックの追加と中身の入れ込みも、下書き状態であればログインユーザー以外には見えません。内容がOKとなった段階で、静的に埋め込んだ部分を削除したテーマファイルを反映し、下書きを公開すれば入れ替えがスムーズです。ブロックタイプを追加すると自動生成されるファイル群/blocks/[block_hanle]/view.php/packages/designer_content_pro_blocks/blocks/[block_handle]/tools/edit_repeating_item.phpadd.phpcontroller.phpdb.xmledit.phpview.phpブロックタイプを追加した時点で、後述のインストールが自動で行われます。その際、データベース上のBlockTypesテーブルにブロックタイプについてのレコードが追加されます。ブロックのインストール、アンインストール、削除DCPで作成したブロックは、いつでもインストールとアンインストールができます。インストール自動生成されたファイルのうち、重要なのはdb.xmlです。インストール時にブロックハンドルのアンダースコアをキャメルケースにした名前で、ブロック用のテーブルをデータベース上に作成します。テーブルの名前はブロックハンドルがtest_blockだとすると、btTestBlockとなります。テーブル定義がdb.xmlで管理されることで、データベース上でテーブル編集など直接操作を行う必要がありません。アンインストールページ内で作成したブロックを使用している場合はそれらも削除されてしまうので注意が必要です。作成したブロックをアンインストールしても、テーブルや自動生成されたファイルは消えません。削除すると以下の内容が削除されます。BlockTypesテーブルからブロックタイプのレコード移行の手順DCPをインストール済みとして、自動生成されたファイルを本番サーバーへ同じディレクトリ構成でアップロードします。技術と戦略という2つの要素がメインですが、どちらがなくとも成り立たないものと思います。個人的なスタンスとしては、開発者・制作者は「作れて当たり前」、それが価値であり存在意義のひとつと考えています。しての活動を軸に据えることになりました。「作れて当たり前」だけれど、それだけでも通用しない状況に変化していく中で、自分を棚卸しして戦略を立て直すというのは、自然な流れです。独立当初からスタンスはさして変わっていない2008年にフリーランスのプログラマーとして活動をし始めてから、スタンス自体は変わっていません。経験を積んで、確信できることが増えてきました。これだけ流行廃りが早い業界なので、変化と安定という観点から不安になる人も多いと感じているのですが、変化し続けることを受け入れることが大切と考えています。変化といっても、状況に流されていてはSNS疲れや勉強疲れを起こすだけです。いう軸で生きていくつもりなのか、まず一個人としてどうあるべきかを問われているように思えてなりません。Specialあなたはフリーランスとして生き残れますか?フリーランスの製作者が考えるべきプロジェクトのバランス今後のWebサイト制作との向き合い方を改めて考える古川家から見える3つのキーワード担当したセッションでは、まず「戦略」として、なぜ古川家をはじめようと思ったのか?について共有。その後、古川家の価値観として3つのキーワードを抽出し、それを実現するために使用しているツールや技術を紹介するという構成で進めました。”くらし”を”なりわい”に家族という日常を続けながら、この社会で生きて行くには稼いでいくことは避けられないでしょう。日常、つまり暮らしをコンテンツとして食べていけるように舵を切ってしまえば、暮らすことそのものが生業になります。家族の理解は大事ですし、よくある家族営業とも少し意味合いが違うので、周りの理解も得ていかなくてはなりません。古川家は「食と家族」を切り口に新しいマーケット、居場所を自分たちの手で作ろうと考えています。食は「非言語コミュニケーション」であり、家族は「人類最小のコミュニティ」。暮らしに集中するために、大事なこととはいえ作業はなるべく手短に済ませたいもの。最初は「今日の古川家ごはん」として、Facebookページで日々の食卓を公開しました。暮らしの見える化としては、よくある方法なのですが、自分たちなりの工夫を重ねる中で企画・プロデュースのお声がけをいただいたり。Webサイトはもはや名刺代わりですが、いざ自分たちのとなり、必要になったタイミングも急だったりすると突貫工事が必要です。そこで採用したのは下記のツール群。IFTTTとりあえず立ち上げるに当たって、色々な選択肢はありましたが、できるとはいえ言語や文法のちゃんぽんは効率を下げます。言語(このときはRuby)・文法・設計概念などが揃っていれば、スピードはかなり上げられます。専門家から兼業家へエキスパートという言葉は憧れを抱きますが、技術もツールも手段であり、目的達成のためにどう取捨選択をするべきか?という決断には、幅広い知識やスキルが必要です。100点と20点より、70点を2つとれば総合力は上回ります。自分がエキスパートには向かないと割り切り、その上でどうやって結果を出していくか?という問への自分なりの回答です。その代わり、あらゆる知識やスキルを少しずつ底上げするには時間がかかります。暮らしを生業にした以上、一生をかけて高めていけば良いのですから。いえ、兼業が増えれば増えるほど、仕入れるべき情報もアウトプットも多種多様になります。いった状況では、整理しながら情報収集できたり、下書きしながら清書できたり、一石二鳥以上の効果を持つツールで武装していく必要があります。Twitter検索)でMouの代替アプリも紹介されていました。181つ以上のチャレンジを古川家は基本的に自分たちで企画から何から全部を手がけます。いつもチャレンジが生まれるのかもしれません。すべてをいつも通りではなく、1つだけでも未知の領域があると、これまでの経験もゼロベースで考え直したり、良い棚卸しになったりします。それまで「これが1番」と思っていたツールも、時代とともに進化したり、シェアが変わっていたります。新しいことを始めるときは、改めて調べ直す良い機会かもしれません。古川家の場合、メンバーの得意分野は当然違います。すべてではないにしろ、前提知識や場所を問わず利用できるツールは重宝します。MailChimpまとめツール・技術は料理で言うと包丁がそれにあたります。包丁1本で料理にまつわるすべての工程をまかなっているか?と言われると、まったくそういうことはありません。適材適所の使い分けが必要です。研ぎ澄ました技術も、振るう場所がなくては意味がありません。今はその技術を振るう場所を、自分で作ることもひとつです。私自身、プログラマーとしての開発業務は今のところ辞める気もなく、古川家とのバランスを調整していくスタンスです。多種多様な知識や経験を蓄え、担っていることそれぞれで循環していくサイクル作りをできるように取り組んでいきます。}まとめ強引な方法だけれども、Laravel5内のリソースにアクセスできた。Eloquentも普通に使えるはずなので検証を継続。スマートな方法があれば情報求む。情報提供パッケージコントローラーのon_start()で読み込むとスッキリだった。寄稿者の権限で投稿を受け付ける場合、その人以外の投稿を見せないようにするためには、フィルターフックとアクションフックの両方を利用する必要があります。日本語版WordPress上で投稿データを表示するときなど、何か表示するタイミングで独自のプログラムを実行させることができます。日本語版WordPress上で投稿ボタンを押したときなど、何か動作が発生したタイミングで独自のプログラムを実行させることができます。投稿一覧で「すべて」「公開済み」などの投稿状態フィルタを非表示にする寄稿者が自分の投稿数0件の状態でも、投稿一覧で他者の投稿が見えないようにする上記を満たすために、フィルターフックとアクションフックをテーマ内のfunctions.phpに記述していきます。'show_owned_posts_only');投稿状態フィルタそれぞれの内容はコールバック引数で受け取る、$viewsに入っています。unset()で要素を削除することで制御できます。今回はすべての要素を非表示にすることで、「所有」という自分の投稿数のみ表示されるようになります。注意点としては、CODEXにある「views_edit-post」は「投稿(投稿タイプ=post)一覧」のフィルターフックだという点です。カスタム投稿タイプを利用する場合は、「views_edit-hoge」のように投稿タイプ名に置き換える必要があります。'hide_other_posts');フィルターフックで投稿状態フィルタを非表示したとしても、寄稿者の投稿数が0件の状態で投稿一覧にアクセスすると、他者の投稿が見えてしまいます。pre_get_postsアクションフックを使い、ある特定の画面(この場合はカスタム投稿タイプの投稿一覧)で、ログインしているユーザー(この場合は寄稿者)の投稿のみ取得しています。$current_screenと$current_userで現在表示している画面とログインしているユーザーを特定しています。ユーザーを特定できれば、$wp_queryからauthorパラメータで投稿を絞り込むことができます。(コガワ・マサヤ)テスト環境の保持期限ってどのぐらい?約2年前にシステム納品したプロジェクトから障害発生の連絡。原因をたどっていくと、とあるプラグインの設定に誤りがあったのだが、これに気づくまで意外と時間がかかった。テスト環境は正常に動作している状態なので、内容を比較していって原因を特定。管理画面からプラグインの設定をいじらない限りはならないはずだが、いつ誰がやったのかまではさすがにわからない。設定を変更した履歴まで残すとか、そこまでケアしたシステムではないし、個別にアカウント作ってガチガチの管理というわけではない。ミッションクリティカルでもない限り、そこまで追跡する機能は作り込まないだろう。今回はテスト環境が正常な状態で残っていたので分かったようなものの、今の技術スピードだと2年前のものですら化石に見える。.scssとかもう使ってないし。5.2系なんて、レガシー扱いだ。いいながらも、開発した案件はほぼすべてテスト環境をのこしたまま、ディスクに眠っている。最古の環境は7年以上前(カームテックの創業前!)だ。テスト環境として利用しているものも、今となっては同じものを揃えられるか怪しいものばかり。これまでの経験では残しておいてよかったと思うばかりだった。7へ端末ごと変更ということで、商品データ生成ツールの環境構築をしてきたが、当時と同じにしようと思っても色々と環境が違って四苦八苦した。ちなみにそのシステムを納品したのは2005年か2006年あたり。法人は、帳簿を備え付けてその取引を記録するとともに、その帳簿と取引等に関して作成又は受領した書類(以下「書類」といい、帳簿と併せて「帳簿書類」といいます。)を、その事業年度の確定申告書の提出期限から7年間保存しなければなりません。法人が、取引情報の授受を電磁的方式によって行う電子取引をした場合には、原則としてその電磁的記録(電子データ)をその事業年度の確定申告書の提出期限から7年間保存する必要があります。その電磁的記録を出力した紙によって保存しているときには、電磁的記録を保存する必要はありません。法人会計ですら7年間。システムの寿命は思ったより長い。その産業のサイクルに準じており、よほど致命的なセキュリティ対策等がない限り延々と使い続け、それを前提に教育された業務が「文化」「社風」となっていく。受託システムにおける稼働サイクルというのは、思っているよりも長く息づくことが多い。そこまでを見通して設計となると、やはりクライアントへ歩み寄り、企業文化を含め知らなくてはいけないことがとても多い。関係者が増えると、同じ温度で案件が進むことは少ない。東日本大震災でもそうだった。耐震設計の時、どこまでを見通せば良かったのだろうかと、ふとよぎった。システムを設計するプログラマーは、時として予言者のような立ち位置になってしまう。2013の一番手です。私は今年とにかく使い込んだツール、TaskPaperを紹介したいと思います。TaskPaper便利すぎ・・・TaskPaperは、シンプルなTODO管理ツールとしてMac、iPhone、iPadで利用できます。TODO管理だけではもったいないぐらいに便利で、こいつがないとやってられない!というぐらい私には必需品になっています。今はマークダウンでドキュメント管理したり、多様化した時期をすぎて、シンプルな記法や管理方法に落ち着く人が見渡していて多いと感じています。TaskPaperで気に入っているのは、以下の点です。Dropboxで複数間デバイスの同期ができるショートカットがほどよくて、エディタとしてがしがし書ける後から書いたことを探せるついでにTODO管理ができる管理のこつは1プロジェクト1ファイル色々と使い方を探ってきた中で、1つのプロジェクト(公私問わず)に対して1つのTaskPaperファイルを作るのが一番しっくりきています。TaskPaperで作成したファイルは、「.taskpaper」形式のファイルとして保存されます。中身を見ると、インデントや記号を活用したシンプルなもので、なるほど!と思いました。仕事の場合、私はひとつの案件もしくはクライアントで1つのTaskPaperファイルを作っておきます。そこには議事録や仕様やメモなど、なんでも全部いれます。Evernoteでそういう風にやろうとしたときもあったのですが、行入れ替えといったエディタとしての機能やファイル内での検索を考えるとEvernoteの機能では合いません。スキャンデータや画像、静的ドキュメントはEvernoteにプロジェクト用のノートブックをひとつ用意して、やはりそこに全部ほうりこんでいます。TaskPaperファイルとEvernoteノートブックを見れば、そのプロジェクトに関しての記録は全部いつでも振り返られる状態にしています。見る場所が少なく、特定されているというのは後から探すことがとても楽ですね。ひとつ、1プロジェクト1ファイルにする理由は、TaskPaperはタスクバー上に表示されるTaskPaperアイコンから、いつでも他のドキュメントを選択できるからです。1プロジェクト1ファイルだと、その行き来がしやすくなりますし、見通しが良いというメリットがあります。TaskPaperの構成は「Project」「Note」「Task」「Tag」TaskPaperは上記4つで構成されていて、それぞれショートカットキーで入力できます。Enter)Projectの使い方で、TaskPaperの使いやすさは大きく変わってきます。Projectはアウトラインエディタにおける見出しみたいなものをイメージしてもらうと良いと思います。tabでインデントさせると、アウトラインとして見渡しやすくなります。全体の様子を見せるサイドバーが表示されます。]で、現在カーソルがあるProjectのみに絞り込んで表示できます。Enter)個人的に使用頻度がそう高くないのですが、何か補足事項をいれておきたいときに使っています。Enter)1項目1Taskとして、がしがし必要事項を書いていきます。Taskもインデントで入れ子にできますので、箇条書きにしていきます。議事録の場合は、Projectで絞り込んで表示されているTaskを、そのままPDF化して共有しています。最初に登録されているTagは@doneというものです。Dで最初から割り当てられていて、これを実行するとTaskに打ち消し線が入ります。完了したこと、状況が変わってなくなった事項は、消去せずに@doneのTagをつけておきます。すると、時系列がのこっていくので振り返りに便利でした。ロギングTaskPaperはアウトラインと箇条書きで思考や情報を整理する人には、TODO管理を超えてかなり便利に感じるんじゃないかと思っています。苦手な部分もあります(添付ファイルとか視覚的なことは無理)ので、やはりツール選びだけじゃなくて、その運用の仕方や思考法が合ってるかも一緒に考える必要はあります。TaskPaperいかがでしょうか?テキストベースでの操作に慣れている人は、少し触ってみるだけで、「あー、なるほどね」と納得できるかと思います。サードパーティーアプリケーションが書き換えられなくなっているためのようです。ターミナルを起動して、以下のコマンドを実行します。Pro.app適用されたかどかは、以下のコマンドで確認できます。私の場合は、マシンも再起動してみました。起動できないというケースも散見されています。今後も使わないのであれば、自動起動からも削除してしまうと良いと思います。環境構築メモGuardはコマンドラインツールで、ファイル変更を監視してコンパイルや結合などのタスクを実行できます。Middlemanでプロトタイプを構築して、既存システム(PHPベース)に移植という段取りだったのですが、Middlemanのディレクトリ構成をそのまま持ち込むことはできません。Guardを採用した理由としては以下があります。CoffeeScript、concat、uglifyはまた今度に。Compass、CoffeeScript、Slimといった様々なライブラリを複合で扱えるBundlerでGem管理ができるRubyベースなので資産を再利用しやすかったまず、CompassとFoundationを導入する段取りについて。GemfileGuardプラグイン各種を入れておきます。"rb-fsevent"Bundlerでインストールします。vendor/bundlerconfig.rb各種Gemをrequireしておきます。'compass-normalize'Sassファイルでは以下のようにインポートしておきます。"foundation";Foundationについては、これですべてのスタイルが読み込まれます。GuardfileCompassでSassファイルをコンパイルするタスクを用意します。両方をコンパイル対象にしています。guardコマンドを実行するとタスクが実行され、さらにファイル変更の監視を始めます。今回のセミナー、一線で活躍されている方々の舞台裏が生々しく語られました。Togetterにまとめがありますが、完全非公開の内容が多く、気になる方は多くいらっしゃるのではと予想しています。再演の機会があれば、どこかでお披露目できるのかもしれませんね。ここでは私が発表した内容についてのポイントと、全体を通しての内容について振り返ります。数値化&洗い出しシステム導入が必要となり、エンジニアと協業する時のポイントについてお話ししましたが、その中で一貫して重視したのは、数値化&洗い出しでした。何かを実現するに当たって「定期的に」「なるべく」「おおよそ」等といった、あいまいな言葉を含んだ状態は決まっていないのと同じという考え方です。極端に感じるかもしれませんが、人がよしなに動かしていたものを、言われたとおりにしか動かないコンピュータに任せるためには、その下準備が重要になってきます。要件と要望は違うソフトウェア開発の世界では、なにかを作るために必要なものを明確にしていくプロセスを要件定義と言います。ある失敗として、できあがったものが思っていたものと違うというケースがあります。これは、要件と要望を混同することによる双方の認識違いが原因のほとんどです。要件は必要不可欠なもの。要望は願いではありますが、なくても問題ないものです。要件を具体的にし、関係者間で認識を一致させていくために、数値化&洗い出しという観点は少なからず助けになると思います。人の行動をコンピュータの処理に置き換えていくために、様々なことを具体的にしていかなくてはなりません。それはシステムに限らず、Webデザインの世界でも同じであり、ディレクションの一部として必要不可欠だと思います。講師陣それぞれに、ディレクションする際に基準となる軸が存在していました。何を実現するのか、何を得意とするのかはバラバラです。軸があることで目的を見失わずに済んだり、比較したりすることができるようになるのだと思います。私がそれぞれの講師から学んだ軸としては「気遣い」「共有と可視化」など、他にも色々とありましたが、なぜその軸を大事にしているのかを聞けたことが大きかったと思います。思いつきで軸ができたわけではなく、失敗や成功の積み重ねで得た教訓ですから、自分の今後に落とし込んで検証する必要があります。いくつか試してみたいなと思ったもの、参考となる気になっていた書籍などが出てきたので、また色々と吸収できるようにしていきます。自分にとっても、暗黙となっていた部分を整理する良い機会となりました。